Handle VIR_STORAGE_TYPE_DIR in qemuBlockStorageSourceGetBackendProps so
that a 'vvfat' driver is used, which emulates a FAT filesystem
containing the folders.
qemu requires us to add it as a storage layer, since a 'raw' layer is
usually put on top of it.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Move it to the validation callback and make it more robust. This will
also put the checks in the correct place to use with -blockdev.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Add a flag denoting that a virStorageSource is going to be used as a
floppy image. This will be useful in cases where the user passes in
files which shall be exposed as an image to the guest.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
'file' backend in qemu supports few more options than the current
implementation. Extract it so that changes don't pollute the code.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Some properties don't make sense to be configured for every single layer
of the backing chain, but to avoid needing to pass the disk structure we
will copy them to the individual virStorageSource.
Zero detection is applied only for the top layer image, while caching
and iomode for all layers.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Save and restore node names if we know them or when we will be
generating them in the status XML.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Everything besides the top of the chain is readonly. Track this when
parsing the XML and detecting the chain from the disk. Also fix the
state when taking snapshots.
All other cases where the top image is changed already preserve the
readonly state from the original image.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
This capability is unused since we stopped parsing -help output.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
The -no-kvm-pit-reinjection option has been deprecated since
its introduction in QEMU 1.3. See commit <1569fa1>.
Drop the capability since all the QEMUs we support allow tuning
the kvm-pit properties via -global.
Also add the QEMU_CAPS_KVM_PIT_TICK_POLICY to the clock-catchup
tests, since expecting it to succeed with QEMU that does not
have kvm-pit makes no sense.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Since we started assuming QEMU_CAPS_MACHINE_OPT in
commit <69420756>, this function can only be reached
for unsupported virt types.
Replace the call with a virReportError.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
When adding a new object to the domain object list, there should
have been 2 virObjectRef calls made one for each list into which
the object was placed to match the 2 virObjectUnref calls that
would occur during Remove as part of virHashRemoveEntry when
virObjectFreeHashData is called when the element is removed from
the hash table as set up in virDomainObjListNew.
Some drivers (libxl, lxc, qemu, and vz) handled this inconsistency
by calling virObjectRef upon successful return from virDomainObjListAdd
in order to use virDomainObjEndAPI when done with the returned @vm.
While others (bhyve, openvz, test, and vmware) handled this via only
calling virObjectUnlock upon successful return from virDomainObjListAdd.
This patch will "unify" the approach to use virDomainObjEndAPI
for any @vm successfully returned from virDomainObjListAdd.
Because list removal is so tightly coupled with list addition,
this patch fixes the list removal algorithm to return the object
as entered - "locked and reffed". This way, the callers can then
decide how to uniformly handle add/remove success and failure.
This removes the onus on the caller to "specially handle" the
@vm during removal processing.
The Add/Remove logic allows for some logic simplification such
as in libxl where we can Remove the @vm directly rather than
needing to set a @remove_dom boolean and removing after the
libxlDomainObjEndJob completes as the @vm is locked/reffed.
Signed-off-by: John Ferlan <jferlan@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
The vm name is not needed for any functional requirement, but it will be
useful when debugging problems to identify which VM is associated with a
filter, since UUID is not human friendly.
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Alter qemuBuildTPMDevStr to format the tpm-crb on the command line
and use the enum range checking for valid model.
Add a test case for the formation of the tpm-crb QEMU device
command line. The qemuxml2argvtest changes cannot use the newer
DO_TEST_CAPS_LATEST since building of the command line involves
calling qemuBuildTPMBackendStr which attempts to open the
path to the device (e.g. /dev/tmp0).
Signed-off-by: Stefan Berger <stefanb@linux.vnet.ibm.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
QEMU on x86_64 (since v2.12) can support tpm-crb devices.
Introduce qemu capabilities for this device.
Signed-off-by: Stefan Berger <stefanb@linux.vnet.ibm.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
The 'domrename' command needs to check if the new domain name contains
the slash character. This character is not accepted by libvirt XML
definition because it is an invalid char (see Cole's commit b1fc6a7b7).
This commit enhace the 'domrename' command adding this check.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1333232
Signed-off-by: Julio Faracco <jcfaracco@gmail.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
The virStorageFileSupportsSecurityDriver and
virStorageFileSupportsAccess currently just return a boolean
value. This is ok because they don't have any failure scenarios
but a subsequent patch is going to introduce potential failure
scenario. This changes their return type from a boolean to an
int with values -1, 0, 1.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The virStorageFileGetBackingStoreStr method has overloaded the NULL
return value to indicate both no backing available and a fatal
error dealing with it.
The caller is thus not able to correctly propagate the error
messages.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Use the TLS env for migration when starting the NBD server if TLS is
enabled for migration.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
To allow encryption of the non-shared storage migration NBD connection
we will need to instantiated the NBD server with the TLS env.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
The NBD server in qemu supports TLS transport. Detect this capability.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
When a VM is destroyed while being migrated (waiting in
qemuMigrationSrcWaitForCompletion) the private object cleanup code frees
the 'current' job info. Since the migration code attempts to setup
various aspects of the current job even on failure this results into a
crash.
Job data is cleared in qemuDomainObjPrivateDataClear since commit
888aa4b6b9
Fix this by skipping all of the code which requires the qemu process to
be alive if the VM is not active any more.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Since libvirt is currently not able to setup the NBD migration stream
secured by TLS we should not allow such migration since data would be
transferred unencrypted.
This will break compatibility of TLS migration if non-shared storage is
requested but the security implications are more severe.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
The code setting TLS parameters verifies that TLS is supported by
looking at the dump of parameters which will be reset after migration,
but sets the parameters in the list of new parameters. As
qemuMigrationParamsSetString did not set the 'set' property, the TLS
parameters would not be used.
This is a regression after the series refactoring migration parameters
and it resulted into TLS not being used even when requested.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Introduce a perl script that is able to regroup both
the QEMU_CAPS constants and the capability strings.
Check correct grouping as a part of syntax check.
For in-place regrouping after a rebase, just run:
tests/group-qemu-caps.pl
without any parameters.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
The attribute can be used to disable ROM loading completely
for a device.
This might be needed because, even when the guest is configured
such that the PCI ROM will not be loaded in the PCI BAR, some
hypervisors (eg. QEMU) might still make it available to the
guest in a form (eg. fw_cfg) that some firmwares (eg. SeaBIOS)
will consume, thus not achieving the desired result.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1425058
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Rework the code such that virDomainObjListFindByID will always
return a locked/ref counted object so that the callers can
always do the same cleanup logic to call virDomainObjEndAPI.
Makes accessing the objects much more consistent.
NB:
There were 2 callers (lxcDomainLookupByID and qemuDomainLookupByID)
that were already using the ByID name, but not virDomainObjEndAPI -
these were changed as well in this update/patch.
Signed-off-by: John Ferlan <jferlan@redhat.com>
Reviewed-by: Jim Fehlig <jfehlig@suse.com>
Now that every caller is using virDomainObjListFindByUUIDRef,
let's just remove it and keep the name as virDomainObjListFindByUUID.
Signed-off-by: John Ferlan <jferlan@redhat.com>
Reviewed-by: Jim Fehlig <jfehlig@suse.com>
If virJSONValueArraySize(caps) <= 0, then we will still need to
virJSONValueFree(caps) because qemuMonitorSetMigrationCapabilities
won't consume it.
Found by Coverity
Signed-off-by: John Ferlan <jferlan@redhat.com>
The code is generic enough to be reused. Move it into a
separate function.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
So far all the properties we are trying to fetch are device
properties, i.e. -device $dev on qemu command line. Change
misleading variable names to express what's queried for better.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The current private XML parsing code relies on the assumption
that NUMA node IDs start from 0 and are densely allocated,
neither of which is necessarily the case.
Change it so that the bitmap size is dynamically calculated by
looking at NUMA node IDs instead, which ensures all nodes will
be able to fit and thus the bitmap will be parsed successfully.
Update one of the test cases so that it would fail with the
previous approach, but passes with the new one.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1490158
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Allocated in qemuMigrationParamsNew() we need to free
priv->job.migParams when no longer needed.
==8061== 234 (192 direct, 42 indirect) bytes in 1 blocks are definitely lost in loss record 112 of 123
==8061== at 0x4C2CF26: calloc (vg_replace_malloc.c:711)
==8061== by 0x5325D05: virAlloc (viralloc.c:144)
==8061== by 0x1984F9: qemuMigrationParamsNew (qemu_migration_params.c:218)
==8061== by 0x19A352: qemuMigrationParamsParse (qemu_migration_params.c:1185)
==8061== by 0x1604D8: qemuDomainObjPrivateXMLParseJob (qemu_domain.c:2390)
==8061== by 0x160AE9: qemuDomainObjPrivateXMLParse (qemu_domain.c:2517)
==8061== by 0x5419EAE: virDomainObjParseXML (domain_conf.c:20442)
==8061== by 0x541A25E: virDomainObjParseNode (domain_conf.c:20555)
==8061== by 0x541A2FC: virDomainObjParseFile (domain_conf.c:20574)
==8061== by 0x13607D: testCompareStatusXMLToXMLFiles (qemuxml2xmltest.c:75)
==8061== by 0x14F3E8: virTestRun (testutils.c:180)
==8061== by 0x14DCD0: mymain (qemuxml2xmltest.c:1200)
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The disk cache mode translates to various frontend and backend
attributes for the qemu block layer. For the frontend device the
'writeback' parameter is used and provided as 'write-cache'. Implement
this so that we can later switch to using -blockdev where we will not
pass the cachemode directly any more.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
QEMU translates the cache mode of a disk internally into 3 flags.
'write-cache' is a flag of the frontend while others are flag of the
backing storage. Add capability which will allow expressing it via the
frontend attribute.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Add helper which will map values of disk cache mode to the flags which
are accepted by various parts of the qemu block layer.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
When qemu does not support changing of the backing store string, we'd
reaport that block pull is not supported instead of block commit.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Replace direct usage of disk->src->driverName with the existing
accessors. The parser code where we assign the driver from XML is
intentionally not fixed to save an allocation.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
There were two places where we'd check this independently. Move it to
the disk definition validation callback. This also fixes possible use of
NULL in a printf for network storage.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
On Core i5 650 x86_64 kvm guest fail to start with error [1] for next cpu config:
<cpu mode='host-model' check='partial'>
<model fallback='allow'/>
<feature policy='require' name='x2apic'/>
</cpu>
The problem is in full CPU calculation in virQEMUCapsInitHostCPUModel.
It is supposed to include features emulated by qemu and missed on host. Some of
such features may be not included however.
For Core i5 650 host CPU is detected as Westmere and reported CPU as
SandyBridge. x2apic is missed on host and provided by installed qemu. The
feature is not mentioned in reported CPU features explicitly because SandyBridge
model include it. As a result full CPU does not include x2apic too.
Solution is to expand guest cpu features before updating fullCPU features.
[1] error: the CPU is incompatible with host CPU: \
Host CPU does not provide required features: x2apic
Signed-off-by: Nikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
So far we are repeating the following lines over and over:
if (!(virSomeObjectClass = virClassNew(virClassForObject(),
"virSomeObject",
sizeof(virSomeObject),
virSomeObjectDispose)))
return -1;
While this works, it is impossible to do some checking. Firstly,
the class name (the 2nd argument) doesn't match the name in the
code in all cases (the 3rd argument). Secondly, the current style
is needlessly verbose. This commit turns example into following:
if (!(VIR_CLASS_NEW(virSomeObject,
virClassForObject)))
return -1;
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Whenever we declare a new object the first member of the struct
has to be virObject (or any other member of that family). Now, up
until now we did not care about the name of the struct member.
But lets unify it so that we can do some checks at compile time
later.
The unified name is 'parent'.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Add comma escaping for loader->path and loader->nvram.
Signed-off-by: Sukrit Bhatnagar <skrtbhtngr@gmail.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Add comma escaping for disk->vendor and disk->product when being
built for the command line (and not from hotplug).
Signed-off-by: Sukrit Bhatnagar <skrtbhtngr@gmail.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
In order to not affect running VMs, refreshing the halted state
is only performed if QEMU supports the query-cpus-fast QAPI.
Signed-off-by: Viktor Mihajlovski <mihajlov@linux.vnet.ibm.com>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.vnet.ibm.com>
Reviewed-by: Marc Hartmayer <mhartmay@linux.vnet.ibm.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Extract architecture specific data from query-cpus[-fast] if
available. A new function qemuMonitorJSONExtractCPUArchInfo()
can then call architecture-specific extraction handlers.
Initially, there's a handler for s390 cpu info to
set the halted property depending on the s390 cpu state
returned by QEMU. With this it's still possible to report
the halted condition even when using query-cpus-fast.
Signed-off-by: Viktor Mihajlovski <mihajlov@linux.vnet.ibm.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Use query-cpus-fast instead of query-cpus if supported by QEMU.
Based on the QEMU_CAPS_QUERY_CPUS_FAST capability.
Signed-off-by: Viktor Mihajlovski <mihajlov@linux.vnet.ibm.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Detect whether QEMU supports the QMP query-cpus-fast API
and set QEMU_CAPS_QUERY_CPUS_FAST in this case.
Signed-off-by: Viktor Mihajlovski <mihajlov@linux.vnet.ibm.com>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.vnet.ibm.com>
Reviewed-by: Marc Hartmayer <mhartmay@linux.vnet.ibm.com>
Acked-by: Peter Krempa <pkrempa@redhat.com>
If QEMU uses a seccomp blacklist (since 2.11), -sandbox on
no longer tries to whitelist all the calls, but uses sets
of blacklists:
default (always blacklisted with -sandbox on)
obsolete (defaults to deny)
elevateprivileges (setuid & co, default: allow)
spawn (fork & execve, default: allow)
resourcecontrol (setaffinity, setscheduler, default: allow)
If these are supported, default to sandbox with all four
categories blacklisted.
https://bugzilla.redhat.com/show_bug.cgi?id=1492597
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
QEMU commit 1bd6152 changed the default behavior from whitelist
to blacklist and introduced a few sets of system calls.
Use the 'elevateprivileges' parameter of -sandbox as a witness
of this change.
https://bugzilla.redhat.com/show_bug.cgi?id=1492597
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Exit early if possible to simplify the logic.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Move the building of -sandbox command line into a separate function.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Implied by QEMU >= 1.2.0.
Delete the negative test cases now that they always pass.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Implied by QEMU >= 1.2.0.
Also delete the now redundant disk-drive-copy-on-read test.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
This function is indeed getting -device properties and not
-object properties. The current name is misleading.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Trying to delete the non-existent TLS objects results in ugly error
messages in the log, which could easily confuse users. Let's avoid this
confusion by not trying to delete the objects if we were not asked to
enable TLS migration and thus we didn't created the objects anyway.
This patch restores the behavior to the state before "qemu: Reset all
migration parameters".
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
This will help us decide what to do when libvirtd is restarted while an
async job is running.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
We store the flags passed to the API which started the migration. Let's
use them instead of a separate bool to check if post-copy migration was
requested.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
We store the flags passed to the API which started QEMU_ASYNC_JOB_DUMP
and we can use them to check whether a memory-only dump is running.
There's no need for a specific bool flag.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
migrate_cancel QMP command cannot be used for cancelling memory-only
dumps and priv->job.dump_memory_only is used for reporting an error if
someone calls virDomainAbortJob when memory-only dump job is running.
Since commit 150930e309 the dump_memory_only flag is set only if
dump-guest-memory command was called without the detach parameter. This
would incorrectly allow libvirt to send migrate_cancel while the
detached memory-only dump is running.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
When an async job is running, we sometimes need to know how it was
started to distinguish between several types of the job, e.g., post-copy
vs. normal migration. So far we added a specific bool item to
qemuDomainJobObj for such cases, which doesn't scale very well and
storing such bools in status XML would be painful so we didn't do it.
A better approach is to store the flags passed to the API which started
the async job, which can be easily stored in status XML.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
To be able to restore all migration parameters when libvirtd is
restarting during an active migration job, we need to store the original
values of all parameters (stored in priv->job.migParams) in the status
XML.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Most QEMU migration parameters directly correspond to
VIR_MIGRATE_PARAM_* typed parameters and qemuMigrationParamsFromFlags
can automatically set them according to a static mapping between libvirt
and QEMU parameters.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The API is renamed as qemuMigrationParamsGetULL and it can be used with
any migration parameter stored as unsigned long long.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
When an always-on migration capability is supposed to be enabled on both
sides of migration, each side can only enable the feature if it is
enabled by the other side.
Thus the source host sends a list of supported migration capabilities in
the migration cookie generated in the Begin phase. The destination host
consumes the list in the Prepare phase and decides what capabilities can
be enabled when starting a QEMU process for incoming migration. Once
done the destination sends the list of supported capabilities back to
the source where it is used during the Perform phase to determine what
capabilities can be automatically enabled.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Some migration capabilities may be enabled automatically, but only if
both sides of migration support them. Thus we need to be able transfer
the list of supported migration capabilities in migration cookie.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Since the monitor code no longer needs to see this enum, we move it
to the place where migration parameters are defined and drop the
"monitor" reference from the name.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
We want to have all migration capabilities parsing and formatting at one
place, i.e., in qemu_migration_params.c. The parsing is already there in
qemuMigrationCapsCheck.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Adding support for new migration parameter requires a lot of places to
be changed (most likely by copy&paste engineering): new variables to
store the parameter value and the associated *_set bool, JSON formatter
and parser, XML formatter and parser (to be added soon), and the actual
code to set the parameter. It's pretty easy to forget about some of the
places which need to be updated and end up with incorrect support. The
goal of this patch is to let most of the places do their job without any
modifications when new parameters are added.
To achieve the goal, a new qemuMigrationParam enum is introduced and all
parameters are stored in an array indexed by the items of this enum.
This will also allow us to automatically set the migration parameters
which directly correspond to libvirt's typed parameters accepted by
virDomainMigrate* APIs.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
It's no longer used by the monitor code so we can hide it inside
qemu_migration_params.c.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
We want to have all migration parameters parsing and formatting at one
place, i.e., in qemu_migration_params.c.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
We want to have all migration parameters parsing and formatting at once
place, i.e., in qemu_migration_params.c.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Use this internal structure only in qemu_migration_params.c and change
other non-test users to use the high level qemuMigrationParams struct.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Let's separate the code which queries QEMU for migration parameters from
qemuMigrationParamsCheck into a dedicated function.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
By merging qemuMigrationAnyCompressionParse into
qemuMigrationParamsSetCompression we can drop the useless intermediate
qemuMigrationCompression structure and parse compression related typed
parameters and flags directly into qemuMigrationParams.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Since every parameter or capability set in qemuMigrationCompression
structure is now reflected in qemuMigrationParams structure, we can
replace qemuMigrationAnyCompressionDump with a new API which will work
on qemuMigrationParams.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
There's no need to call this API explicitly in the migration code. We
can pass the compression parameters to qemuMigrationParamsFromFlags and
it can internally call qemuMigrationParamsSetCompression to apply them
to the qemuMigrationParams structure.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The API will soon be called from qemuMigrationParamsFromFlags. Let's
move it to avoid the need to add a forward declaration.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
It's become only a tiny wrapper around virBitmapSetBit, which can easily
be called directly. We don't need to call virBitmapClearBit since
migParams->caps bitmap is initialized with zeros.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
So far it's used only for CPU throttling parameters which are all ints,
but we'll soon want to use it for more parameters with different types.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Propagate the calls up the stack to the point where
qemuMigrationParamsFromFlags is called. The end goal achieved in the
following few patches is to merge compression parameters into the
general migration parameters code.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Most migration capabilities are directly connected with
virDomainMigrateFlags so qemuMigrationParamsFromFlags can automatically
enable them.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Some migration capabilities are always enabled if QEMU supports them. We
can just drop the explicit code for them and let
qemuMigrationParamsCheck automatically set such capabilities.
QEMU_MONITOR_MIGRATION_CAPS_EVENTS would normally be one of the always
on features, but it is the only feature we want to enable even for other
jobs which internally use migration (such as save and snapshot). Hence
this capability is set very early after libvirtd connects to QEMU
monitor.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
It's just a tiny wrapper around qemuMigrationParamsSetCapability and
setting priv->job.postcopyEnabled is not something qemuMigrationParams
code should be doing anyway so let the callers do it.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Every migration entry point in qemu_driver is supposed to call
qemuMigrationParamsFromFlags to transform flags and parameters into
qemuMigrationParams structure and pass the result to qemuMigration*
APIs.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Some migration parameters and capabilities are supposed to be set on
both sides of migration while others should only be set on one side. For
example, CPU throttling parameters make no sense on the destination and
they can be used even if the destination is too old to support them.
To make qemuMigrationParamsFromFlags more general and usable on both
sides of migration, we need to tell it what side it's been called on.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Instead of checking each capability at the time we want to set it in
qemuMigrationParamsSetCapability we can check all of them at once in
qemuMigrationParamsCheck.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
We reached the point when qemuMigrationParamsApply is the only API which
sends migration parameters and capabilities to QEMU. Thus all but the
TLS parameters can be set before we ask QEMU for the current values of
all parameters in qemuMigrationParamsCheck.
Supported migration capabilities are queried as soon as libvirt connects
to QEMU monitor so we can check them anytime.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
We reached the point when qemuMigrationParamsApply is the only API which
sends migration parameters and capabilities to QEMU. Thus all but the
TLS parameters can be set before we ask QEMU for the current values of
all parameters in qemuMigrationParamsCheck.
Supported migration capabilities are queried as soon as libvirt connects
to QEMU monitor so we can check them anytime.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Prefer xbzrle-cache-size migration parameter over the special
migrate-set-cache-size QMP command.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Originally QEMU provided query-migrate-cache-size and
migrate-set-cache-size QMP commands for querying/setting XBZRLE cache
size. In version 2.11 QEMU added support for XBZRLE cache size to the
general migration paramaters commands.
This patch adds support for this parameter to libvirt to make sure it is
properly restored to its original value after a failed or aborted
migration.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Rework all remaining callers of qemuMonitorSetMigrationCapability to use
the new qemuMonitorSetMigrationCapabilities API.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Migration capabilities are closely related to migration parameters and
it makes sense to keep them in a single data structure. Similarly to
migration parameters the capabilities are all send to QEMU at once in
qemuMigrationParamsApply, all other APIs operate on the
qemuMigrationParams structure.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Our current monitor API forces the caller to call
migrate-set-capabilities QMP command for each capability separately,
which is quite suboptimal. Let's add a new API for setting all
capabilities at once.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
All users of migration parameters are supposed to use APIs provided by
qemu_migration_params.c without having to worry about the internals.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The new name is qemuMigrationParamsApply and it will soon become the
only API which will send all requested migration parameters and
capabilities to QEMU. All other qemuMigrationParams* APIs will just
operate on the qemuMigrationParams structure.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
There's no real reason for qemuMigrationParamsEnableTLS to require the
callers to pass a valid virQEMUDriverConfigPtr, it can just call
virQEMUDriverGetConfig.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The function checks whether QEMU supports TLS migration and stores the
original value of tls-creds parameter to priv->migTLSAlias. This is no
longer needed because we already have the original value stored in
priv->migParams.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The code can be merged directly in qemuMigrationParamsAddTLSObjects.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Restore the original values of all migration parameters we store in
qemuDomainJobObj instead of explicitly resting only a limited set of
them.
The result is not strictly equivalent to the previous code wrt reseting
TLS state because the previous code would only reset it if we changed it
before while the new code will reset it always if QEMU supports TLS
migration. This is not a problem for the parameters themselves, but it
can cause spurious errors about missing TLS objects being logged at the
end of non-TLS migration. This issue will be fixed ~50 patches later.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Currently, only job->phase is passed and both APIs will need to look at
more details about the job.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Any job which touches migration parameters will first store their
original values (i.e., QEMU defaults) to qemuDomainJobObj to make it
easier to reset them back once the job finishes.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
When connection to the client which controls a non-p2p migration gets
closed between Perform and Confirm phase, we don't know whether the
domain was successfully migrated or not. Thus, we have to leave the
domain paused and just cleanup the migration job and reset migration
parameters.
Previously we didn't reset the parameters and future save or snapshot
operations would see wrong environment (and could fail because of it) in
case the domain stayed running on the source host.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Currently migration parameters are stored in a structure which mimics
the QEMU migration parameters handled by query-migrate-parameters and
migrate-set-parameters. The new structure will become a libvirt's
abstraction on top of QEMU migration parameters, capabilities, and
related stuff.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
It provides just another view on some migration parameters so let's move
it close to them. The end goal is to merge compression parameters with
the rest of migration parameters since it doesn't make any sense to
handle them differently.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
It's no longer used since we do not store the struct on a stack anymore.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
It will get a bit more complicated soon and storing it on a stack with
{0} initializer will no longer work. We need a proper constructor.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Our *Free functions usually do not take a double pointer and the caller
has to make sure it doesn't use the stale pointer after the *Free
function returns.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The function is connected with the code which handles migration
parameters and capabilities, let's move it to qemu_migration_params.c.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Since the function is tightly connected to migration, it was renamed as
qemuMigrationCapsCheck and moved to qemu_migration_params.c.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
In the end, this will allow us to have most of the logic around
migration parameters and capabilities done in one place.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
The function is now called qemuMigrationParamsFromFlags to better
reflect what it is doing: taking migration flags and params and
producing a struct with QEMU migration parameters.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Introduced in d3db304d2e. Instead of returning immediately we
need to jump onto cleanup label where @paths is freed.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
The (now assumed) QEMU_CAPS_CHARDEV_SPICEVMC is preferred.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Last use was removed by commit 0586cf98 deprecating
QEMU_CAPS_DEVICE.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Implied by QEMU >= 1.2.0.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Fixed-up-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Implied by QEMU >= 0.12.0.
Deprecated by QEMU commit 1ed2fc1 included in 0.12.0.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
The last use of qemuMonitorMigrateToCommand was removed years back in
commit 2e90c9daf9
Author: Daniel P. Berrange <berrange@redhat.com>
Date: Fri Nov 6 16:50:26 2015 +0000
qemu: assume support for all migration protocols except rdma
Prior to that commit, 'exec:' to used to replicate the 'unix:' protocol
by spawning 'nc'.
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Remove unnecessary virFileIsExecutable check after virFindFileInPath.
Since the commit 9ae992f virFindFileInPath will reject non-executables.
Signed-off-by: Radostin Stoyanov <rstoyanov1@gmail.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Avoid the need for the drivers to explicitly check for a NULL path by
making sure it is at least the empty string.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Ensuring that we don't call the virDrvConnectOpen method with a NULL URI
means that the drivers can drop various checks for NULL URIs. These were
not needed anymore since the probe functionality was split
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Declare what URI schemes a driver supports in its virConnectDriver
struct. This allows us to skip trying to open the driver entirely
if the URI scheme doesn't match.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Add a localOnly flag to the virConnectDriver struct which allows a
driver to indicate whether it is local-only, or permits remote
connections. Stateful drivers running inside libvirtd are generally
local only. This allows us to remote the check for uri->server != NULL
from most drivers.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Currently the virDrvConnectOpen method is supposed to handle both
opening an explicit URI and auto-probing a driver if no URI is
given. Introduce a dedicated virDrvConnectURIProbe method to enable the
probing functionality to be split from the driver opening functionality.
It is still possible for NULL to be passed to the virDrvConnectOpen
method after this change, because the remote driver needs special
handling to enable probing of the URI against a remote libvirtd daemon.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Implied by QEMU >= 1.2.0.
Delete this one first, because QEMU_CAPS_NODEFCONFIG is only used
when QEMU_CAPS_NO_USER_CONFIG is unsupported.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
We require QEMU >= 1.5.0, assume every QEMU supports it.
Sadly that does not let us trivially drop qemuMonitor's
priv->monJSON bool, because of qemuDomainQemuAttach.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Now that we assume QEMU_CAPS_NETDEV, the only thing left to check
is whether we need to use the legacy -net syntax because of
a non-conforming armchitecture.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Now that we assume -netdev support, we no longer set the VLAN
or need the hostPlugged bool.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
This makes qemuDomainSupportsNetdev identical to
qemuDomainSupportsNicdev and leaves some code in
qemuDomainAttachNetDevice to be cleaned up later.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Up until now we have only formatted non-default GIC versions on
the command line, in order to maintain compatibility with older
QEMU versions that didn't implement the gic-version option to
begin with; however, doing so is entirely unnecessary for newer
QEMU versions, where the option is available. Moreover, having
the GIC version formatted on the command line at all times
ensures that QEMU changing its own defaults doesn't affect the
ABI of libvirt guests.
A few test cases are removed to avoid extra churn. It doesn't
matter for coverage, as those scenarios are already covered by
other parts of the test suite.
This patch is better viewed with 'git show -w'.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
According to the policy described on https://libvirt.org/platforms.html
the QEMU versions in the oldest relevant releses are:
SLES 12: 2.0.0
RHEL 7: 1.5.3
Ubuntu 14.04: 2.0.0
Set the minimum to 1.5.0 and drop support for RHEL 6.
This will let us assume lots of capabilities.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Remove the qmpOnly argument of virQEMUCapsNewForBinaryInternal
and instead always assume it's true.
This effectively sets the minimum QEMU version to 1.2.0.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Because we allow a QEMU_JOB_DESTROY to occur while we're starting
up and we drop the @vm lock prior to qemuMonitorOpen, it's possible
that a domain destroy operation "wins" the race, calls qemuProcessStop
which will free and reinitialize priv->monConfig. Depending on the
exact timing either qemuMonitorOpen will be passed a NULL @config
variable or it will be using free'd (and possibly reclaimed) memory
as the @config parameter - neither of which is good.
Resolve this by localizing the @monConfig, taking an extra reference,
and then once we get the @vm lock again removing our reference since
we are done with it.
Signed-off-by: John Ferlan <jferlan@redhat.com>
Reviewed-by: Marc Hartmayer <mhartmay@linux.vnet.ibm.com>
Rather than VIR_ALLOC, use the New function for allocation. We
already use the Free function anyway.
Signed-off-by: John Ferlan <jferlan@redhat.com>
Reviewed-by: Laine Stump <laine@laine.org>
Reviewed-by: Marc Hartmayer <mhartmay@linux.vnet.ibm.com>
The array of strings we are building is indeed array of const
strings. We are not STRDUP()-ing them nor FREE()-ing them.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Marc Hartmayer <mhartmay@linux.vnet.ibm.com>
Since virCloseCallbacksRun was ignoring the value anyway, let's
just change it to be a void function.
Signed-off-by: John Ferlan <jferlan@redhat.com>
Reviewed-by: Marc Hartmayer <mhartmay@linux.vnet.ibm.com>
Upon entry from virCloseCallbacksRun, the @dom will have a
Ref and Lock from virDomainObjListFindByUUIDRef, so there's
no need to take an extra reference nor should the code call
virDomainObjEndAPI when done since that both Unref's and
Unlock's the @dom which means the callers call to EndAPI
would be unlocking an unlocked object. At least the Ref
saved the code from referencing something already freed.
Signed-off-by: John Ferlan <jferlan@redhat.com>
Reviewed-by: Marc Hartmayer <mhartmay@linux.vnet.ibm.com>
Just like the existing areMultipleRootsSupported, this will
allow us to change the results of the driver-agnostic PCI
address allocation logic based on whether the QEMU binary
supports certain features.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
The new controller will not yet be used automatically by
libvirt, but at this point it's already possible to configure
a guest to use it.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
This capability will be set when the pcie-pci-bridge device
is available in the QEMU binary.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
We're going to add a similarly-named attribute later, and we'd
like to be consistent.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
https://bugzilla.redhat.com/show_bug.cgi?id=1557769
Problem with device mapper targets is that there can be several
other devices 'hidden' behind them. For instance, /dev/dm-1 can
consist of /dev/sda, /dev/sdb and /dev/sdc. Therefore, when
setting up devices CGroup and namespaces we have to take this
into account.
This bug was exposed after Linux kernel was fixed. Initially,
kernel used different functions for getting block device in
open() and ioctl(). While CGroup permissions were checked in the
former case, due to a bug in kernel they were not checked in the
latter case. This changed with the upstream commit of
519049afead4f7c3e6446028c41e99fde958cc04 (v4.16-rc5~11^2~4).
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
The qemu command line generator code set disk caching of shareable disks
to 'none' when formatting the command line silently. Move this code to a
common place when preparing the domain definition for startup so that it
does not have to be duplicated.
The new test case shows that the actual cache mode will now be recorded
in the live XML definition.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
The old qcow2 encryption format was buggy, so the new approach is to use
luks inside qcow2. As it turns out, it didn't require that many changes.
It was necessary to fix the command line formatter to stop mangling the
format when secrets are present and specify the encryption format and
secret in correct format.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
This format is used by the storage driver and other hypervisors but qemu
does not have notion of the 'iso' format and libvirt does not translate
it to anything useful, so it would not work anyways. Users should use
'raw' instead.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
This is a storage driver type, which is not handled in qemu driver
properly. For accessing directories, disk type 'dir' is used instead.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
It will be necessary to initialize various aspects for the detected
members of the backing chain. Add a function that will handle it and
call it from qemuDomainPrepareDiskSource and qemuDomainDetermineDiskChain
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
For some reason we've decided to silently translate the disk
detect_zeroes mode if it would be invalid. Extract the
logic so that it does not need to be copypasta'd across the code base.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Make the function more usable by returning the full disk definition and
fix the only caller for the new semantics. The new name for the function
is virDomainDiskDefParse.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
My commit 2e0d6cdec4 claimed qemuMonitorJSONCheckError guarantees
"return" object exists in the JSON reply. But it only makes sure the key
is there, while the type of the value is not checked. A lot of callers
do not care since they only want to see whether their QMP command failed
or not, but any caller which needs to read some data from the reply
wants to make sure the correct data type was returned.
This patch adds a new API called qemuMonitorJSONCheckReply which calls
qemuMonitorJSONCheckError and checks "return" contains a value of the
specified type.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Rather than trying to prevent stealing of the 'actions' virJSONValue
into the monitor command replace the code so that it does the same
thing, since 'actions' was actually not really used after calling the
monitor.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Use virJSONValueObjectGetArray instead of virJSONValueObjectGet so that
it's not necessary to check whether it's an array.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
It was not possible to determine whether virJSONValueObjectAddVArgs and
the functions using it would consume a virJSONValue or not when used
with the 'a' or 'A' modifier depending on when the loop failed.
Fix this by passing in a pointer to the pointer so that it can be
cleared once it's successfully consumed and the callers don't have to
second-guess leaving a chance of leaking or double freeing the value
depending on the ordering.
Fix all callers to pass a double pointer too.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Mediated devices support hot-{plug,unplug} since their introduction in
kernel 4.10, however libvirt has still been missing support for this.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Mediated devices support hot-{plug,unplug} since their introduction in
kernel 4.10, however libvirt has still been missing support for this.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
qemuDomainDetachWatchdog uses the infrastructure for waiting
for the DEVICE_DELETED event, but the asynchronous delete
was not implemented.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
https://bugzilla.redhat.com/show_bug.cgi?id=1560976
For historical reasons we've used 32 bytes long static buffer for
storing PTY aliases. This breaks users scenario where they try to
start a machine with user alias consisting of "ua-$uuid".
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
If someone set a user alias or pcihole64 on an implicit controller,
we need to format it to migrate the domain properly.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reported-by: Joseph Richard <Joseph.Richard@windriver.com>
QEMU on S390 (since v2.11) can support virtio input ccw devices.
So build the qemu command line for ccw devices.
Also add test cases for virtio-{keyboard, mouse, tablet}-ccw.
Signed-off-by: Farhan Ali <alifm@linux.vnet.ibm.com>
Signed-off-by: Boris Fiuczynski <fiuczy@linux.vnet.ibm.com>
QEMU on S390 (since v2.11) can support virtio input ccw devices.
Introduce qemu capabilities for these devices.
Signed-off-by: Farhan Ali <alifm@linux.vnet.ibm.com>
Signed-off-by: Boris Fiuczynski <fiuczy@linux.vnet.ibm.com>
S390 guests can only support a virtio-gpu-ccw device as a video
device. So set default video model type to VIR_DOMAIN_VIDEO_TYPE_VIRTIO
for S390 guests.
Signed-off-by: Farhan Ali <alifm@linux.vnet.ibm.com>
QEMU on S390 (since v2.11) can support the virtio-gpu-ccw device,
which can be used as a video device.
Signed-off-by: Farhan Ali <alifm@linux.vnet.ibm.com>
QEMU on S390 (since v2.11) can support virtio-gpu-ccw device.
Let's introduce a new qemu capability for the device.
Signed-off-by: Farhan Ali <alifm@linux.vnet.ibm.com>
Signed-off-by: Boris Fiuczynski <fiuczy@linux.vnet.ibm.com>
https://bugzilla.redhat.com/show_bug.cgi?id=1558317
Similarly to b133fac356 we need to look up alias of CCID
controller when constructing smartcard command line instead of
relying on broken assumption it will always be 'ccid0'. After
user aliases it can be anything.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Starting with commit id 'fab9d6e1' the formatting of:
{ "command-name", QEMU_CAPS_NAME },
was altered to:
{ "command-name", QEMU_CAPS_NAME},
and then commit id 'e2b05c9a' altered that to:
{ "command-name", QEMU_CAPS_NAME}
So, let's just fix that up to make things consistent with the
rest of the structures.
Signed-off-by: John Ferlan <jferlan@redhat.com>
virQEMUQAPISchemaTraverse would return previous-to-last queried item on
a query. It would not be a problem if checking if the given path exists
since error reporting works properly but if the caller is interested in
the result, it would be wrong.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
The JSON array was processed to the hash table used by the query apis in
the monitor code. Move it to a new helper in qemu_qapi.c.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Change the prefix of the functions to 'virQEMUQapi' and rename the two
public APIs so that the verb is put last.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
<memballoon model='none'/> is the only way to disable balloon driver
since libvirt will add one automatically if the memballoon element is
missing. In other words, there's no balloon device if model is 'none'
and generating an alias for it makes no sense. The alias will be ignored
when parsing the XML and it will disappear once libvirtd is restarted.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Commit b4c2ac8d56 made a false assumption that IOMMU support necessary
for an mdev device to be assigned to a VM. Unlike direct PCI assignment,
IOMMU support is not needed for mediated devices, as the physical parent
device provides the isolation, therefore, simply checking for VFIO
presence is enough to successfully start a VM.
Luckily, this issue is not serious, since as of yet, libvirt mandates
mdevs to be pre-created prior to a domain's launch - if it is,
everything does work smoothly even with IOMMU disabled, because the
parent device will ensure the iommu groups we try to access exist.
However, if there are *no* IOMMU groups yet, thus no mdev exists yet, one
would see the following error:
"unsupported configuration: Mediated host device assignment requires VFIO
support"
The error msg above is simply wrong and doesn't even reflect the IOMMU
reality, so after applying this patch one would rather see the following
error in such case instead:
"device not found: mediated device '<UUID>' not found"
Signed-off-by: Erik Skultety <eskultet@redhat.com>
https://bugzilla.redhat.com/show_bug.cgi?id=1552127
When building command line for USB controllers we have to do more
than just put controller's alias onto the command line. QEMU has
concept of these joined USB controllers. For instance ehci and
uhci controllers need to create the same USB bus. To achieve that
the slave controller needs to refer the master controller. This
worked until we've introduced user aliases because both master
and slave had the same alias. With user aliases slave can have
different alias than master. Therefore, when generating command
line for slave we need to look up the master's alias.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
commit 7210cef452 'qemu: build command line for virtio input devices'
introduced an error, by checking if input bus type is
VIR_DOMAIN_DISK_BUS_VIRTIO.
Fix it by using the correct bus type for input devices.
Signed-off-by: Farhan Ali <alifm@linux.vnet.ibm.com>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.vnet.ibm.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Commit id '177db487' renamed 'qemuValidateDevicePCISlotsChipsets' to
'qemuDomainValidateDevicePCISlotsChipsets', but didn't adjust comment.
Signed-off-by: Farhan Ali <alifm@linux.vnet.ibm.com>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.vnet.ibm.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Add typedef for the anonymous enum used for the driver features. This
allows the usage of the type in a switch statement and taking
advantage of the compilers feature to detect uncovered cases.
Signed-off-by: Marc Hartmayer <mhartmay@linux.vnet.ibm.com>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.vnet.ibm.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
introduce VIR_DOMAIN_INTERFACE_ADDRESSES_SRC_ARP to get ip address
of VM from the message of netlink RTM_GETNEIGH
Signed-off-by: Chen Hanxiao <chenhanxiao@gmail.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Libvirt provides full path to the backing file since commit
fec8f9c49a. This made qemu create the backend object but did not
delete it. This was fixed for unplug case in 4d83a6722f but not in case
of failure to hotplug the frontend. We'd leave the files behind which
would make memory unusable in case of hugepages.
https://bugzilla.redhat.com/show_bug.cgi?id=1553085
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Having to repeat "./job[1]/" XPath prefix for every single element or
attribute we want to parse is suboptimal. And even more so once we
further extract code from qemuDomainObjPrivateXMLParseJob into separate
functions.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Commit dc567cc22b introduced qemuDomainObjPrivateXMLParseJob, but forgot
to move "./job[1]/@type" parsing into it.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
We read from the agent until seeing a \r\n pair to indicate a completed
reply or event. To avoid memory denial-of-service though, we must have a
size limit on amount of data we buffer. 10 MB is large enough that it
ought to cope with normal agent replies, and small enough that we're not
consuming unreasonable mem.
This is identical to the flaw we had reading from the QEMU monitor
as CVE-2018-5748, so rather embarrassing that we forgot to fix
the agent code at the same time.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Modernize the code by using the clever formatter rather than checking
manually when to format the end of the element.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
The code overwrote the internal job type and then fixed it back. Since
the job type is not accessed in the code this does not make much sense.
Use the temporary value instead.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Since data.count is not a pointer, but an integer,
compare it against an integer value instead of using
the implicit "boolean" conversion that is customarily
used for pointers.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
This time around it's not enough to just pick the latest commit,
because with aed87bb2aa6ed83b49574eb982e3bdd4c36acf17 keycodemapdb
renamed the 'rfb' keycode to 'qnum' and we need to accept the new
name while maintaining backwards compatibility.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Recently, this warning is appearing while libvirt is being compiled:
Function 'qemuAssignDeviceDiskAlias' argument order different:
declaration 'vmdef, def' definition 'def, disk'
This commit change the default declaration for qemuAssignDeviceDiskAlias
specified at src/qemu/qemu_alias.c.
Signed-off-by: Julio Faracco <jcfaracco@gmail.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
The qemu driver registered the helpers from util code, but it will be
necessary to format also some qemu-specific data.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
We've implemented all existing checks, and more, in the new
function, so we can finally drop the old one.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Laine Stump <laine@laine.org>
This change catches an invalid use of the option in our
test suite.
https://bugzilla.redhat.com/show_bug.cgi?id=1483816
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Laine Stump <laine@laine.org>
This change catches an invalid use of the option in our
test suite.
https://bugzilla.redhat.com/show_bug.cgi?id=1483816
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Laine Stump <laine@laine.org>
The existing function is renamed and called from the new one, so
that even while we're in the process of implementing new checks
all the existing ones will be performed.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Laine Stump <laine@laine.org>
In qemuMigrationSrcRun, we already checked for non-NULL mig
and then dereferenced it. It's only possible for mig to be
NULL in the error section.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
This function was introduced in commit 41f5c2ca27 as a way
to probe the same property for multiple devices at once.
Although the resulting representation is very compact, it
doesn't provide any extra features compared to the existing
virQEMUCapsProcessStringFlags() mechanism, which is already
used for pretty much all device properties.
Drop the custom function and datatypes and start using the
standard ones instead.
Note that, in theory, the end result is not identical
because we're no longer probing properties for
virtio-serial-pci
virtio-9p-pci
virtio-rng-pci
virtio-input-host-pci
virtio-keyboard-pci
virtio-mouse-pci
virtio-tablet-pci
However, chances of any of those devices being compiled
into a QEMU binary where
virtio-balloon-pci
virtio-blk-pci
virtio-scsi-pci
virtio-net-pci
virtio-gpu-pci
are compiled out are slim enough that it doesn't make any
difference in practice, as the lack of test suite churn
shows.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
In some cases, we are probing multiple devices for the same
property and setting the corresponding capability if it's
found on any of the devices: when that happens, we can quit
early after finding the first property and avoiding a bunch
of string comparisons.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Commit 4ae59411fa introduced the ability to make probing for
device properties conditional on a capability being set, but
didn't extend the use of this feature to existing devices.
This commit does the last bit of work, which results in a lot
of pointless QMP chatter no longer happening and our test suite
shrinking a fair bit.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
If the user tries to define a domain that has
<controller type='usb' model='none'/>
and also some USB devices, we report an error:
error: internal error: No free USB ports
Which is technically still correct for a domain with no USB ports.
Change it to:
USB is disabled for this domain, but USB devices are present in the domain XML
https://bugzilla.redhat.com/show_bug.cgi?id=1347550
Signed-off-by: Ján Tomko <jtomko@redhat.com>
When trying to destroy a domain (e.g. because we've seen EOF on
the monitor) we try to acquire QEMU_JOB_DESTROY. However, if
max_queued is set in qemu.conf this may fail and since our code
doesn't count on that we will still report domain as active even
though the qemu process is long gone. More specifically, if we've
seen EOF on the monitor, qemuProcessHandleMonitorEOF() is called
which sends MONITOR_EOF job to the event worker pool and
unregisters monitor from the event loop. The worker pool calls
processMonitorEOFEvent() which tries to set job which may fail
due to the limit as described above.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Fix this common typo and assign a value rather than implicitly
type-casted comparison result. Introduced by commit b6a264e855.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
12 bytes in 1 blocks are definitely lost in loss record 188 of 1,145
at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
by 0x5D2CD77: xmlStrndup (in /lib/x86_64-linux-gnu/libxml2.so.2.7.8)
by 0x514E137: virXMLPropString (virxml.c:506)
by 0x234F51: qemuMigrationCookieNetworkXMLParse qemu_migration.c:1001)
by 0x235FF8: qemuMigrationCookieXMLParse (qemu_migration.c:1333)
by 0x236214: qemuMigrationCookieXMLParseStr (qemu_migration.c:1372)
by 0x2365D2: qemuMigrationEatCookie (qemu_migration.c:1456)
by 0x243DBA: qemuMigrationFinish (qemu_migration.c:6381)
by 0x204032: qemuDomainMigrateFinish3 (qemu_driver.c:13228)
by 0x521CCBB: virDomainMigrateFinish3 (libvirt-domain.c:4788)
by 0x1936DE: remoteDispatchDomainMigrateFinish3 (remote.c:4580)
by 0x16DBB1: remoteDispatchDomainMigrateFinish3Helper(remote_dispatch.h:7582)
Signed-off-by: ZhangZijian <zhang.zijian@h3c.com>
This partially reverts 82592551cb.
When migrating a domain, qemuMigrationDstPrepareAny() is called
which eventually calls qemuProcessLaunch(conn = NULL, flags =
VIR_QEMU_PROCESS_START_AUTODESTROY); But the very first thing
that qemuProcessLaunch does is check if AUTODESTROY flag is set
and @conn is not NULL. Well, it is.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
https://bugzilla.redhat.com/show_bug.cgi?id=1494454
If a domain disk is stored on local filesystem (e.g. ext4) but is
not being migrated it is very likely that domain is not able to
run on destination. Regardless of share/cache mode.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
When calling virDomainDefCompatibleDevice to check a new device during
device update, we need to pass the original device which is going to be
updated in addition to the new device. Otherwise, the function can
report false conflicts.
The new argument is currently ignored by virDomainDefCompatibleDevice,
but this will change in the following patch.
https://bugzilla.redhat.com/show_bug.cgi?id=1546971
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Rather than having the caller check, if the input @addrs is NULL
(e.g. priv->usbaddrs), then just return 0. This also removes the
need for ATTRIBUTE_NONNULL which only really helped if someone
passed a NULL as a parameter not if the passed parameter is NULL.
Signed-off-by: John Ferlan <jferlan@redhat.com>
Rather than having the caller check, if the input @addrs is NULL
(e.g. priv->usbaddrs), then just return 0. This also removes the
need for ATTRIBUTE_NONNULL which only really helped if someone
passed a NULL as a parameter not if the passed parameter is NULL.
Signed-off-by: John Ferlan <jferlan@redhat.com>
This flag is only used for tests. Let's instead overload bind syscall
in mocks where it is not done yet.
Signed-off-by: Nikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
Range check in virPortAllocatorSetUsed is not useful anymore
when we manage ports for entire unsigned short range values.
Signed-off-by: Nikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
Range check in virPortAllocatorSetUsed is not useful anymore
when we manage ports for entire unsigned short range values.
Signed-off-by: Nikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
Host tcp4/tcp6 ports is a global resource thus we need to make
port accounting also global or we have issues described in [1] when
port allocator ranges of different instances are overlapped (which
is by default for qemu for example).
Let's have only one global port allocator object that take care
of the entire ports range (0 - 65535) and introduce port range object
for clients to specify desired auto allocation band.
[1] https://www.redhat.com/archives/libvir-list/2017-December/msg00600.html
Signed-off-by: Nikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
Ensure all enum cases are listed in switch statements, or cast away
enum type in places where we don't wish to cover all cases.
Reviewed-by: John Ferlan <jferlan@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
GCC 8 became more fussy about detecting switch
fallthroughs. First it doesn't like it if you have
a fallthrough attribute that is not before a case
statement. e.g.
FOO:
BAR:
WIZZ:
ATTRIBUTE_FALLTHROUGH;
Is unacceptable as there's no final case statement,
so while FOO & BAR are falling through, WIZZ is
not falling through. IOW, GCC wants us to write
FOO:
BAR:
ATTRIBUTE_FALLTHROUGH;
WIZZ:
Second, it will report risk of fallthrough even if you
have a case statement for every single enum value, but
only if the switch is nested inside another switch and
the outer case statement has no final break. This is
is arguably valid because despite the fact that we have
cast from "int" to the enum typedef, nothing guarantees
that the variable we're switching on only contains values
that have corresponding switch labels. e.g.
int domstate = 87539319;
switch ((virDomainState)domstate) {
...
}
will not match enum value, but also not raise any kind
of compiler warning. So it is right to complain about
risk of fallthrough if no default: is present.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The controller model is slightly unusual in that the default value is
-1, not 0. As a result the default value is not covered by any of the
existing enum cases. This in turn means that any switch() statements
that think they have covered all cases, will in fact not match the
default value at all. In the qemuDomainDeviceCalculatePCIConnectFlags()
method this has caused a serious mistake where we fallthrough from the
SCSI controller case, to the VirtioSerial controller case, and from
the USB controller case to the IDE controller case.
By adding explicit enum constant starting at -1, we can ensure switches
remember to handle the default case.
Reviewed-by: John Ferlan <jferlan@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
There's no need to perform checks before conversion, we can just
call virDomainControllerPCIModelNameTypeToString() and check the
results later on.
Since the variables involved are only used for PCI controllers,
we can declare them in the 'case' scope rather than in the
function scope to make everything a bit nicer while at it.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Performing the skip earlier will help us making the function
nicer later on. We also make the condition for the skip a bit
more precise, though that'a more for self-documenting purposes
and doesn't change anything in practice.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
It is very difficult while reading the migration code trying to
understand whether a particular function is being called on the src side
or the dst side, or either. Putting "Src" or "Dst" in the method names will
make this much more obvious. "Any" is used in a few helpers which can be
called from both sides.
Reviewed-by: John Ferlan <jferlan@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
QEMU code does not work well with too big numbers on the JSON monitor so
our monitor code supports sending only numbers up to LLONG_MAX. Avoid a
weird error message by limiting the size of the 'bandwidth' parameter
for block copy.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1532542
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
These APIs are not required anywhere outside the migration code so need
not be exported to the rest of the QEMU driver.
Reviewed-by: John Ferlan <jferlan@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The qemuMigrationPrecreateStorage method needs a connection
to access the storage driver. Instead of passing it around,
open it at time of use.
Reviewed-by: John Ferlan <jferlan@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
There's a few places in startup code paths which pass around a
virConnectPtr which is no longer required. Specifically, the
qemuProcessStart() method now only requires a non-NULL connection if
autodestroy is requested.
Reviewed-by: John Ferlan <jferlan@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
When setting up graphics, we sometimes need to resolve networks,
requiring the caller to pass in a virConnectPtr, except sometimes they
pass in NULL. Use virGetConnectNetwork() to acquire the connection to
the network driver when it is needed.
Reviewed-by: John Ferlan <jferlan@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
During domain startup there are many places where we need to acquire
secrets. Currently code passes around a virConnectPtr, except in the
places where we pass in NULL. So there are a few codepaths where ability
to start guests using secrets will fail. Change to acquire a handle to
the secret driver when needed.
Reviewed-by: John Ferlan <jferlan@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Rather than expecting callers to pass a virConnectPtr into the
virDomainDiskTranslateSourcePool() method, just acquire a connection
to the storage driver when needed.
Reviewed-by: John Ferlan <jferlan@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
There is a long standing hack to pass a virConnectPtr into the
qemuMonitorStartCPUs method, so that when the text monitor prompts
for a disk password, we can lookup virSecretPtr objects. This causes
us to have to pass a virConnectPtr around through countless methods
up the call chain....except some places don't have any virConnectPtr
available so have always just passed NULL. We can finally fix this
disastrous design by using virGetConnectSecret() to open a connection
to the secret driver at time of use.
Reviewed-by: John Ferlan <jferlan@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
This wires up the previously added Chassis strings XML schema to be able to
generate comamnd line args for QEMU. This requires QEMU >= 2.1 release
containing this patch:
SMBIOS: Build aggregate smbios tables and entry point
https://git.qemu.org/?p=qemu.git;a=commit;h=c97294ec1b9e36887e119589d456557d72ab37b5
Signed-off-by: Zhuang Yanying <ann.zhuangyanying@huawei.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
The documentation for the JSON/qapi type 'UnixSocketAddress' states that
the unix socket path field is named 'path'. Unfortunately qemu uses
'socket' in case of the gluster driver (despite documented otherwise).
Add logic which will format the correct fields while keeping support of
the old spelling.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1544325
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
https://bugzilla.redhat.com/show_bug.cgi?id=1515533
We're already checking if IPv4 prefix isn't too long. But we are
not checking if it isn't too short. QEMU supports prefixes longer
than 4 (including). I haven't find anything similar related to
IPv6 in qemu sources.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
The array indexes are formatted if the JSON->commandline translator is
translating an array type. It does not at all depend on this function.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Instead of storing separately whether the feature is enabled
or not and what resizing policy should be used, store both of
them in a single place.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Instead of storing separately whether the feature is enabled
or not and what driver should be used, store both of them in
a single place.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
When no GIC version is specified, we currently default to GIC v2;
however, that's not a great default, since guests will fail to
start if the hardware only supports GIC v3.
Change the behavior so that a sensible default is chosen instead.
That basically means using the same algorithm whether the user
didn't explicitly enable the GIC feature or they explicitly
enabled it but didn't specify any GIC version.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Keep them along with other arch/machine type checks for
features instead of waiting until command line generation
time.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
The compiler can make sure we are handling all features.
While reworking the logic, also change error messages to a more
consistent style.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
We want to perform all feature verification in a single spot, but
some of it (eg. GIC) is currently being performed at command line
generation time, and moving it to PostParse() would cause guests
to disappear. Moving verification to Validate() allows us to
side-step the issue.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
This reverts commit 038eb472a0.
On reflection adding defaults for arbitrary guest XML device config
settings to the qemu.conf is not a sustainable path. Removing the
support for rx/tx queue size so that it doesn't set a bad precedent.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Commit 'f0f2a5ec2' neglected to adjust the if condition to split
out the possibility that the @watchdog is NULL when altering the
message to add detail about the model.
Just split out the condition and use previous/original message, but
with the new message code.
Found by Coverity
Signed-off-by: John Ferlan <jferlan@redhat.com>
The floppy command formatting is special-cased since it does not
directly translate to a single '-device' argument.
Move the code from qemuBuildDiskDriveCommandLine to a new helper
function so that all the related code is together.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
We forgot to free alloced mem when failed to
dup ifname or macaddr.
Also use VIR_STEAL_PTR to simplify codes.
Signed-off-by: Chen Hanxiao <chenhanxiao@gmail.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Several PCI controllers have the same options, and thus
can be handled together.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
This is a hard error, and should be handled as such.
Introduced in 2461476022.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Loadable drivers must never depend on each other. Over time some usage
mistakenly crept in for the storage and network drivers, but now this is
eliminated the syntax-check rules can enforce this separation once more.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The storagePoolLookupByTargetPath() method in the storage driver is used
by the QEMU driver during block migration. If there's a valid use case
for this in the QEMU driver, then external apps likely have similar
needs. Exposing it in the public API removes the direct dependancy from
the QEMU driver to the storage driver.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The virStorageTranslateDiskSourcePool method modifies a virDomainDiskDef
to resolve any storage pool reference. For some reason this was added
into the storage driver code, despite working entirely in terms of the
public APIs. Move it into the domain conf file and rename it to match the
object it modifies.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Currently the QEMU driver will call directly into the network driver
impl to modify resolve the atual type of NICs with type=network. It
has todo this before it has allocated the actual NIC. This introduces
a callback system to allow us to decouple the QEMU driver from the
network driver.
This is a short term step, as it ought to be possible to achieve the
same end goal by simply querying XML via the public network API. The
QEMU code in question though, has no virConnectPtr conveniently
available at this time.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The QEMU driver calls into the network driver to get the first IP
address of the network. This information is readily available via the
formal public API by fetching the XML doc and then parsing it.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Currently the QEMU driver will call directly into the network driver
impl to modify network device bandwidth for interfaces with
type=network. This introduces a callback system to allow us to decouple
the QEMU driver from the network driver.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Currently virt drivers will call directly into the network driver impl
to allocate domain interface devices where type=network. This introduces
a callback system to allow us to decouple the virt drivers from the
network driver.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The QEMU driver loadable module needs to be able to resolve all ELF
symbols it references against libvirt.so. Some of its symbols can only
be resolved against the storage_driver.so loadable module which creates
a hard dependancy between them. By moving the storage file backend
framework into the util directory, this gets included directly in the
libvirt.so library. The actual backend implementations are still done as
loadable modules, so this doesn't re-add deps on gluster libraries.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Refreshing the halted state can cause VM performance issues. Since
s390 is currently the only architecture with a known interest in
the halted state, we're avoiding to call QEMU on other platforms.
Signed-off-by: Viktor Mihajlovski <mihajlov@linux.vnet.ibm.com>
Since it may be possible that the state is unknown in some cases we
should store it as a tristate so that other code using it can determine
whether the state was updated.
Don't extract the halted state into a separate array, but rater access
the vcpu structures directly. We still need to call the vcpu helper to
retrieve the performance statistics though.
https://bugzilla.redhat.com/show_bug.cgi?id=916061
If the QEMU version running is new enough (based on the DUMP_COMPLETED
event), then we can add a 'detach' boolean to the dump-guest-memory
command in order to tell QEMU to run in a thread. This ensures that we
don't lock out other commands while the potentially long running dump
memory is completed.
This allows the usage of a qemuDumpWaitForCompletion which will wait
for the event while the qemuDomainGetJobInfoDumpStats can be used via
qemuDomainGetJobInfo in order to query QEMU to determine how far along
the job is.
Now that we have a true async job, we'll only set the dump_memory_only
flag only when @detach=false; otherwise, we note that the job is a
for stats dump this allows the opposite end for job info to determine
what to copy.
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Add an API to allow fetching the memory only dump statistics
for a job via the qemuDomainGetJobInfo API.
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Add the query-dump API's in order to allow the dump-guest-memory
to be used to monitor progress. This will use the dump stats
extraction helper to fill a return buffer.
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Handle a DUMP_COMPLETED event processing the status, stats, and
error string. Use the @status in order to copy the error that
was generated whilst processing the @stats data. If an error was
provided by QEMU, then use that instead.
If there's no async job, we can just ignore the data.
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
The event will be fired when the domain memory only dump completes.
Fill in a return buffer to store/pass along the dump statistics that
will be eventually shared by a query-dump command. Also pass along
the status of the filling and any possible error received.
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Define the qemuMonitorDumpStats as a new job JobStatsType to handle
being able to get memory dump statistics. For now do nothing with
the new TYPE_MEMDUMP.
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Add a TYPE_SAVEDUMP so that when coalescing stats for a save or
dump we don't needlessly try to get the mirror stats for a migration.
Other conditions can still use MIGRATION and SAVEDUMP interchangably
including usage of the @migStats field to fetch/store the data.
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Convert the stats field in _qemuDomainJobInfo to be a union. This
will allow for the collection of various different types of stats
in the same field.
When starting the async job that will end up being used for stats,
set the @statsType value appropriately. The @mirrorStats are
special and are used with stats.mig in order to generate the
returned job stats for a migration.
Using the NONE should avoid the possibility that some random
async job would try to return stats for migration even though
a migration is not in progress.
For now a migration and a save job will use the same statsType
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Since one of the things in capabilities (info from resctrl updated with data
about caches) can be change on the system by remounting the /sys/fs/resctrl with
different options, the capabilities need to be refreshed. There is a better fix
in the works, but it's going to be way bigger than this (hence the XXX note
there), so for the time being let's workaround this. And in order not to slow
down the domain starting, only get the capabilities if there are any cachetunes.
Relates-to: https://bugzilla.redhat.com/show_bug.cgi?id=1540780
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Add and use qemuProcessEventFree for freeing qemuProcessEvents. This
is less error-prone as the compiler can help us make sure that for
every new enumeration value of qemuProcessEventType the
qemuProcessEventFree function has to be adapted.
All process*Event functions are *only* called by
qemuProcessHandleEvent and this function does the freeing by itself
with qemuProcessEventFree. This means that an explicit freeing of
processEvent->data is no longer required in each process*Event
handler.
The effectiveness of this change is also demonstrated by the fact that
it fixes a memory leak of the panic info data in
qemuProcessHandleGuestPanic.
Reported-by: Wang Dong <dongdwdw@linux.vnet.ibm.com>
Signed-off-by: Bjoern Walk <bwalk@linux.vnet.ibm.com>
Signed-off-by: Marc Hartmayer <mhartmay@linux.vnet.ibm.com>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.vnet.ibm.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Use the return value of virObjectRef directly. This way, it's easier
for another reader to identify the reason why the additional reference
is required.
Signed-off-by: Marc Hartmayer <mhartmay@linux.vnet.ibm.com>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.vnet.ibm.com>
Reviewed-by: Bjoern Walk <bwalk@linux.vnet.ibm.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Add the DUMP_COMPLETED check to the capabilities. This is the
mechanism used to determine whether the dump-guest-memory command
can support the "-detach" option and thus be able to wait on the
event and allow for a query of the progress of the dump.
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Extract out the parts of qemuDomainGetJobStatsInternal that get
the migration stats. We're about to add the ability to get just
dump information.
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Use a switch statement instead of if-else-if statements. Move the
command line building of the iothread attribute into the common path
as the SCSI controller attributes are already validated.
Signed-off-by: Marc Hartmayer <mhartmay@linux.vnet.ibm.com>
Move the SATA controller check from command line building to
controller def validation. This includes copying the SATA
skip check found in qemuBuildSkipController.
Move the qemuCaps checks over to qemuDomainControllerDefValidatePCI.
This requires two test updates in order to set the correct capability
bit for an xml2xml test as well as setting up the similar capability
for the pseries memlocktest.
Excluding the qemuCaps checks, move the remainder of the checks
that validate whether the PCI definition is valid or not into
qemuDomainControllerDefValidatePCI.
Similar to the checking the modelName vs. NAME_NONE, let's make the
ModelNameTypeToString check more generic too within the checking done
in controller validation (with the same ignore certain models.
NB: We need to keep the ModelNameTypeToString fetch in command line
validation since we use it, but at least we can assume it returns
something valid now.
Move the various modelName == NAME_NONE from the command line
generation into domain controller validation. Also rather than
have multiple cases with the same check, let's make the code
more generic, but also note that it was the modelName option
that caused the failure. We also have to be sure not to check
the PCI models that we don't care about.
For the remaining checks in command line building, we can use
the field name in the error message to be more specific about
what causes the failure.
We format the 'chassis' and 'port' properties on the QEMU command
line later on, so we should make sure they've been set.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Move PCI validation checks out of qemu_command into the proper
qemu_domain validation helper.
Since there's a lot to move, we'll start slow by replicating the
pcie-root and pci-root avoidance from qemuBuildSkipController and
the first switch found in qemuBuildControllerDevStr.
Move SCSI validation from qemu_command into qemu_domain.
Rename/reorder the args in qemuCheckSCSIControllerIOThreads
to match the caller as well as fixing up the comments to
remove the previously removed qemuCaps arg.
Modify the SCSI controller switch during command line building
to account for all virDomainControllerModelSCSI types rather
than using the default label.
Move the checks that various attributes are not set on any controller
other than SCSI controller using virtio-scsi model into the common
controller validate checks.
https://bugzilla.redhat.com/show_bug.cgi?id=1461214
Since fec8f9c49a we try to use predictable file names for
'memory-backend-file' objects. But that made us provide full path
to qemu when hot plugging the object while previously we provided
merely a directory. But this makes qemu behave differently. If
qemu sees a path terminated with a directory it calls mkstemp()
and unlinks the file immediately. But if it sees full path it
just calls open(path, O_CREAT ..); and never unlinks the file.
Therefore it's up to libvirt to unlink the file and not leave it
behind.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
In my first approach in 4b480d1076 I overlooked the comment in
qemuMigrationRunIncoming stating that during actual migration the
qemuMigrationRunIncoming does not wait until the migration is complete
but rather offloads that to the Finish phase of migration.
This means that during actual migration qemuProcessRefreshState was
called prior to qemu actually transferring the full state and thus the
queries did not get the correct information. The approach worked only
for restore, where we wait for the migration to finish during qemu
startup.
Fix the issue by calling qemuProcessRefreshState both from
qemuProcessStart if there's no incomming migration and from
qemuMigrationFinish so that the code actually works as expected.
In 2074ef6cd4 and c56cdf259 (and friends) we've added two
attributes to virtio NICs: rx_queue_size and tx_queue_size.
However, sysadmins might want to set these on per-host basis but
don't necessarily have an access to domain XML (e.g. because they
are generated by some other app). So let's expose them under
qemu.conf (the settings from domain XML still take precedence as
they are more specific ones).
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Commit id 'bc444666f' added a check if the returned data
buffer had an error, but failed to adjust the event from
VIR_DOMAIN_BLOCK_JOB_COMPLETED to VIR_DOMAIN_BLOCK_JOB_FAILED
in order to propagate an error such as "File descriptor in bad
state" that may be returned from QEMU when both @offset and
@len are set to 0 such as is the case when performing an async
block job read on a read only filesystem.
Signed-off-by: Jie Wang <wangjie88@huawei.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Use the DEVICE_MISSING error code when helpers fail to find
the requested device. This makes it easier for consumers to
key off the error code rather than the error message.
Signed-off-by: Chen Hanxiao <chenhanxiao@gmail.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Modify OPERATION_FAILED and INTERNAL_ERROR error codes to
use DEVICE_MISSING instead for failures associated with the
inability to find the device. This makes it easier for consumers
to key off the error code rather than the error message.
Signed-off-by: Chen Hanxiao <chenhanxiao@gmail.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Now that the controller model is updated during post parse callback,
this code no longer needs to fetch the model based on the capabilities
and can just return the model directly if the controller is found.
Removal of @qemuCaps cascades through various callers which are now
updated to not pass the capabilities.
Now that post parse processing handles setting the SCSI controller
model, there's no need to call qemuDomainGetSCSIControllerModel to
get the "default controller" when building the command line controller
string or when assigning the spaprvio address since the controller
model value will already be filled in.
During post parse processing, let's force setting the controller
model to default value if not already set for defined controllers
(e.g. the non implicit ones).
If we're going to add a controller to the domain, let's set the
default SCSI model value if we cannot find another SCSI controller
already present.
NB: Requires updating the live output test data since the model
will now be formatted.
Rename and rework qemuDomainSetSCSIControllerModel since we're
really not setting the SCSI controller model. Instead the code
is either returning the existing SCSI controller model value, the
default value based on the capabilities, or -1 with the error set.
Rather than repeat multiple steps in order to find the SCSI
controller model, let's combine them into one helper that will
return either the model from the definition or the default
model based on the capabilities.
This patch adds an extra check/error that the controller
that's being found actually exists. This just clarifies that
the error was because the controller doesn't exist rather
than the more generic error that we were unable to determine
the model from qemuDomainSetSCSIControllerModel when a -1
was passed in and the capabilities were unable to find one.
As it turns out virDomainDeviceFindControllerModel was only ever
called for SCSI controllers using VIR_DOMAIN_CONTROLLER_TYPE_SCSI
as a parameter.
So rename to virDomainDeviceFindSCSIController and rather than
return a model, let's return a virDomainControllerDefPtr to let
the caller reference whatever it wants.
Rather than one function serving two purposes, let's split out the
else condition which is checking whether the model can be used
during command line building based on the capabilities.
Signed-off-by: John Ferlan <jferlan@redhat.com>
During reconnect we need to reconstruct the paths of all cachetunes so that they
get cleaned up when the domain is stopped.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
The virresctrl will use this as well and we need to have that info after restart
to properly clean up /sys/fs/resctrl.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Pointed out during review on one or two places, but it actually appears in lot
more places. So let's be consistent.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
After processing the processEvent->data for a qemuProcessEventHandler
callout, it's expected that the called processEvent->eventType helper
will perform the proper free on the data field. In this case it's
a qemuMonitorEventPanicInfoPtr.
We've been building up to this. This adds support for cputune/cachetune
settings for domains in the QEMU driver. The addition into
qemuProcessSetupVcpu() automatically adds support for hotplug. For hot-unplug
we need to remove the allocation only if all the vCPUs were unplugged. But
since the threads are left running, we can't really do much about it now.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1289368
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
This wires up the previously added OEM strings XML schema to be able to
generate comamnd line args for QEMU. This requires QEMU >= 2.12 release
containing this patch:
commit 2d6dcbf93fb01b4a7f45a93d276d4d74b16392dd
Author: Daniel P. Berrange <berrange@redhat.com>
Date: Sat Oct 28 21:51:36 2017 +0100
smbios: support setting OEM strings table
Reviewed-by: John Ferlan <jferlan@redhat.com>
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
We recently added a generic XHCI USB3 controller to QEMU, and libvirt
supports adding that controller rather than the NEC XHCI USB3
controller, but when auto-adding a USB controller to Q35 domains we
were still adding the vendor-specific NEC controller. This patch
changes to add the generic controller instead, if it's available in
the QEMU binary that will be used.
Signed-off-by: Laine Stump <laine@laine.org>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Whenever a different kernel is booted, some capabilities related to KVM
(such as CPUID bits) may change. We need to refresh the cache to see the
changes.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Daniel P. Berrange <berrange@redhat.com>
qemuDomainDefValidateVideo() (called from qemuDomainDefValidate()) is
just a loop performing various checks on each video device. Rather
than maintaining this separate function, just fold the validations
into qemuDomainDeviceDefValidateVideo(), which is called once for each
video device.
Commit 10c73bf1 fixed a bug that I had introduced back in commit
70249927 - if a vhost-scsi device had no manually assigned PCI
address, one wouldn't be assigned automatically. There was a slight
problem with the logic of the fix though - in the case of domains with
pcie-root (e.g. those with a q35 machinetype),
qemuDomainDeviceCalculatePCIConnectFlags() will attempt to determine
if the host-side PCI device is Express or legacy by examining sysfs
based on the host-side PCI address stored in
hostdev->source.subsys.u.pci.addr, but that part of the union is only
valid for PCI hostdevs, *not* for SCSI hostdevs. So we end up trying
to read sysfs for some probably-non-existent device, which fails, and
the function virPCIDeviceIsPCIExpress() returns failure (-1).
By coincidence, the return value is being examined as a boolean, and
since -1 is true, we still end up assigning the vhost-scsi device to
an Express slot, but that is just by chance (and could fail in the
case that the gibberish in the "hostside PCI address" was the address
of a real device that happened to be legacy PCI).
Since (according to Paolo Bonzini) vhost-scsi devices appear just like
virtio-scsi devices in the guest, they should follow the same rules as
virtio devices when deciding whether they should be placed in an
Express or a legacy slot. That's accomplished in this patch by
returning early with virtioFlags, rather than erroneously using
hostdev->source.subsys.u.pci.addr. It also adds a test case for PCIe
to assure it doesn't get broken in the future.
https://bugzilla.redhat.com/show_bug.cgi?id=1536461
This reverts commit aeda1b8c56.
Problem is that we need mon->lastError to be set because it's
used all over the place. Also, there's nothing wrong with
reporting error if one occurred. I mean, if there's a thread
executing an API and which currently is talking on monitor it
definitely wants the error reported.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
When migrating a shutoff domain (i.e., offline migration), we have no
statistics to report and thus jobInfo will be NULL in
qemuMigrationFinish.
Broken by me in v3.10.0-183-ge8784e7868.
https://bugzilla.redhat.com/show_bug.cgi?id=1536351
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
We read from QEMU until seeing a \r\n pair to indicate a completed reply
or event. To avoid memory denial-of-service though, we must have a size
limit on amount of data we buffer. 10 MB is large enough that it ought
to cope with normal QEMU replies, and small enough that we're not
consuming unreasonable mem.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Commit 7a931a4204 refactored the code and probably forgot to add
this line.
Signed-off-by: Marc Hartmayer <mhartmay@linux.vnet.ibm.com>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.vnet.ibm.com>
Add a check if it's a iSCSI hostdev and if it's not then don't use the
union member 'iscsi'. The segmentation fault occured when accessing
secinfo->type, but this can vary from case to case.
Signed-off-by: Marc Hartmayer <mhartmay@linux.vnet.ibm.com>
Reviewed-by: Bjoern Walk <bwalk@linux.vnet.ibm.com>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.vnet.ibm.com>
Libvirt 3.7.0 and earlier libvirt reported a migration job as completed
immediately after QEMU finished sending migration data at which point
migration was not really complete yet. Commit v3.7.0-29-g3f2d6d829e
fixed this, but caused a regression in reporting statistics for
completed jobs which started reporting the job as still running. This
happened because the completed job statistics including the job status
are copied from the running job before we finally mark it as completed.
Let's make sure QEMU_DOMAIN_JOB_STATUS_COMPLETED is always set in the
completed job info even when the job has not finished yet.
https://bugzilla.redhat.com/show_bug.cgi?id=1523036
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
When reconnecting to a running domain with host-model CPU started by old
libvirt which did not store the actual CPU in the status XML, we need to
ignore the fallback attribute to make sure we can translate the detected
host CPU model to a model which is supported by the running QEMU.
https://bugzilla.redhat.com/show_bug.cgi?id=1532980
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
virSecurityManagerDomainSetPathLabel is used to make a path known
to the security modules, but today is used interchangably for
- paths to files/dirs to be accessed directly
- paths to a dir, but the access will actually be to files therein
Depending on the security module it is important to know which of
these types it will be.
The argument allowSubtree augments the call to the implementations of
DomainSetPathLabel that can - per security module - decide if extra
actions shall be taken.
For now dac/selinux handle this as before, but apparmor will make
use of it to add a wildcard to the path that was passed.
Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
https://bugzilla.redhat.com/show_bug.cgi?id=1527740
Users might use a block device as UEFI VAR store. Or even have
OVMF stored there. Therefore, when starting a domain and separate
mount namespace is used, we have to create all the /dev entries
that are configured for the domain.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Commit id '162efa1a' added support hotplug a redirdev, but
did not add the hot unplug. This patch will add that support
to allow usage of the detach-device --live on the device.
Reviewed-by: John Ferlan <jferlan@redhat.com>
Signed-off-by: Chen Hanxiao <chenhanxiao@gmail.com>
https://bugzilla.redhat.com/show_bug.cgi?id=1528502
So imagine you have /dev/blah symlink which points to /dev/sda.
You attach /dev/blah as disk to your domain. Libvirt correctly
creates the /dev/blah -> /dev/sda symlink in the qemu namespace.
However, then you detach the disk, change the symlink so that it
points to /dev/sdb and tries to attach the disk again. This time,
however, the attach fails (well, qemu attaches wrong disk)
because the code assumes that symlinks don't change. Well they
do.
This is inspired by test fix written by Eduardo Habkost.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
When the -machine pseries,max-cpu-compat=X is supported use
machine parameter instead of -cpu host,compat=X parameter as
that is deprecated now with qemu >= v2.10.
Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1519146
Signed-off-by: Shivaprasad G Bhat <sbhat@linux.vnet.ibm.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Since we have user aliases it may happen that users want to
change it using 'update-device'. Instead of ignoring it silently,
error out loudly. Note that we don't limit the check just for
"ua-" prefixes because users might try to change libvirt
generated aliases too.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
The qemuMonitorJSONMakeCommand can properly handle a NULL string
by using the "S:" parameter instead of "s:", so let's use that
of having in if/else condition that only adds the "s:".
A microcode update can cause the CPUID bits to change; an example
from the past was the update that disabled TSX on several Haswell
and Broadwell machines.
Therefore, place microcode version in the virQEMUCaps struct and
XML, and rebuild the cache if the versions do not match.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
When qemuDomainFindOrCreateSCSIDiskController adds a controller,
let's use the same model as a currently found controller under the
assumption that the reason to add the controller in hotplug is
because virDomainHostdevAssignAddress determined that there were
too many devices on the existing controller, but only assigned a
new controller index and did not add a new controller and we
desire to use the same controller model as any existing controller
and not take a chance that qemuDomainSetSCSIControllerModel would
use a default that may be incompatible.
