ncpus would be -1 on error and the cleanup for loop would not be skipped
in this case.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
https://bugzilla.redhat.com/show_bug.cgi?id=1522706
If domain is active, but the undefine API was called without the
VIR_DOMAIN_UNDEFINE_KEEP_NVRAM flag set, the following incorrect
error message is produced:
error: Requested operation is not valid: cannot delete inactive domain with nvram
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Move the IDE controller check from command line building to
controller def validation. Also explicitly include the avoidance
check for the implicit IDE controller from qemuBuildSkipController.
Cause the IDE case for command line building to generate a
failure if called to add an IDE since that shouldn't happen
if the Validate code did the right thing.
Move the call to qemuDomainCheckCCWS390AddressSupport from
qemuBuildControllerDevStr to qemuDomainDeviceDefValidateController.
This means we will get the qemuCaps from the driver opaque
variable passed to qemuDomainDeviceDefValidate.
Xen's xl config format has long supported specifying multiple IP
addresses for virtual interfaces. E.g.
vif = [ "ip=10.0.0.1 10.1.1.1 2000::1, ..." ]
Add support for converting multiple IP addresses to/from domXML.
Reviewed-by: Jim Fehlig <jfehlig@suse.com>
vif-* scripts support it for a long time, and expect addresses to be
separated by spaces. Add appropriate support to libxl driver.
Reviewed-by: Jim Fehlig <jfehlig@suse.com>
When reconnecting to a running domain started by old libvirt, which did
not change host-model into a custom CPU definition, we replace the CPU
definition with a specific CPU model from host capabilities. However,
that CPU model may not be supported by the running qemu process. We need
to translate the CPU model to one of the models which libvirt could have
used when starting the domain.
https://bugzilla.redhat.com/show_bug.cgi?id=1521202
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
virQEMUCapsProbeQMPCPUDefinitions is now a small wrapper which fills in
qemuCaps with CPU models fetched by virQEMUCapsFetchCPUDefinitions.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Since we are re-detecting the backing chain after pivoting to the active
block commit target (or block copy target) the disk index needs to be
reset to 0. This is necessary since we move a member of the backing
chain to disk->src but clear indexes only starting from
disk->src->backingStore. The freshly detected images have indexes
starting from 1, but since we've pivoted into an image which was
previously a backing store it would have a non-0 index.
The lookup function would then return the top of the chain for queries
like 'vda[1]' instead of the first backing store.
This problem will not be present once we keep the disk indexes stable.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1519745
Since commit 5e5019bf, we've no longer use
VIR_ERR_AGENT_UNSYNCED anymore.
Mark it as DEPRECATED.
Signed-off-by: Chen Hanxiao <chenhanxiao@gmail.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
virStorageFileReportBrokenChain uses data from the driver private data
pointer to print the user and group. This would lead to a crash in call
paths where we did not initialize the storage backend as recently added
in commit 24e47ee2b9 to qemuDomainDetermineDiskChain.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1522682
Separate the logic of creating devices from their gathering.
Use this new function in qemuDomainNamespaceSetupHostdev and
qemuDomainNamespaceSetupDisk.
This patch pass event error up to the place where we can
use it. Error is passed only for sync blockjob event mode
as we can't use the error in async mode. In async mode we
just pass the event details to the client thru event API
but current blockjob event API can not carry extra parameter.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
The unprivileged libvirtd does not support nwfilter config, by leaves the
driver active. It is supposed to result in all APIs being an effective
no-op, but several APIs rely on driver->nwfilters being non-NULL, or they
will reference a NULL pointer. Rather than adding checks for NULL in many
places, just make sure driver->nwfilters is always initialized.
Reviewed-by: John Ferlan <jferlan@redhat.com>
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
SELinux and DAC drivers already have both functions but they were not
exported as public API of security manager.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
The manual page clearly states that
gettid() is Linux-specific and should not be used in programs
that are intended to be portable.
Unfortunately, it looks like macOS implemented the functionality
and defined SYS_gettid accordingly, only to deprecate syscall()
altogether with 10.12 (Sierra), released last late year.
To avoid compilation errors, call gettid() on Linux only.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrange <berrange@redhat.com>
Clean up the style a bit w/r/t to not using a unary operator on an
integer value that could be zero - compare vs. zero instead.
Set the def->mem_nodes[*].distances to rdist or ldist inside the
if condition - no need to set outside since the value being set
to is what was fetched.
During cleanup, be sure to initialize the ndistances on error and
use the < 0 comparison not the unary one.
==899== 39 bytes in 1 blocks are definitely lost in loss record 732 of 1,003
==899== at 0x4C2AEDF: malloc (vg_replace_malloc.c:299)
==899== by 0x8B68CE7: vasprintf (in /lib64/libc-2.25.so)
==899== by 0x55498D2: virVasprintfInternal (virstring.c:708)
==899== by 0x55499E7: virAsprintfInternal (virstring.c:729)
==899== by 0x2BECFFF0: qemuGetMemoryBackingBasePath (qemu_conf.c:1757)
==899== by 0x2BF23225: qemuStateInitialize (qemu_driver.c:893)
==899== by 0x563073D: virStateInitialize (libvirt.c:770)
==899== by 0x124CC4: daemonRunStateInit (libvirtd.c:834)
==899== by 0x55521CD: virThreadHelper (virthread.c:206)
==899== by 0x88D9686: start_thread (in /lib64/libpthread-2.25.so)
==899== by 0x8BEAEFE: clone (in /lib64/libc-2.25.so)
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
==1277== 8 bytes in 4 blocks are definitely lost in loss record 39 of 131
==1277== at 0x4C2AEDF: malloc (vg_replace_malloc.c:299)
==1277== by 0x68BBBC8: xmlStrndup (in /usr/lib64/libxml2.so.2.9.4)
==1277== by 0x53B1DC2: virXMLPropString (virxml.c:510)
==1277== by 0x53D696A: virDomainDiskBackingStoreParse (domain_conf.c:8639)
==1277== by 0x53DA684: virDomainDiskDefParseXML (domain_conf.c:9590)
==1277== by 0x53F619F: virDomainDefParseXML (domain_conf.c:19233)
==1277== by 0x53F96EE: virDomainDefParseNode (domain_conf.c:20083)
==1277== by 0x53F9540: virDomainDefParse (domain_conf.c:20027)
==1277== by 0x53F95E6: virDomainDefParseFile (domain_conf.c:20053)
==1277== by 0x44D1D4: testCompareDomXML2XMLFiles (testutils.c:1265)
==1277== by 0x42FC7C: testXML2XMLActive (qemuxml2xmltest.c:71)
==1277== by 0x44AD20: virTestRun (testutils.c:180)
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
==861== 3 bytes in 1 blocks are definitely lost in loss record 3 of 168
==861== at 0x4C2AEDF: malloc (vg_replace_malloc.c:299)
==861== by 0x8C7FBC8: xmlStrndup (in /usr/lib64/libxml2.so.2.9.4)
==861== by 0x5DCCDC2: virXMLPropString (virxml.c:510)
==861== by 0x5DF1232: virDomainDiskSourceNetworkParse (domain_conf.c:8445)
==861== by 0x5DF1728: virDomainDiskSourceParse (domain_conf.c:8576)
==861== by 0x5DF41A5: virDomainDiskDefParseXML (domain_conf.c:9238)
==861== by 0x5E1119F: virDomainDefParseXML (domain_conf.c:19233)
==861== by 0x5E146EE: virDomainDefParseNode (domain_conf.c:20083)
==861== by 0x5E14540: virDomainDefParse (domain_conf.c:20027)
==861== by 0x5E145E6: virDomainDefParseFile (domain_conf.c:20053)
==861== by 0x4053CC: testCompareXMLToArgv (qemuxml2argvtest.c:455)
==861== by 0x41F135: virTestRun (testutils.c:180)
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Raw local files do not pass through the backing store detector and thus
the code did not allocate the required backing store terminator for
them. Previously the terminating element would be formatted into the XML
since the default values used for the metadata allowed that. This is a
regression since a693fdba01 which was not detected in the review.
This patch also reverts all the changes in the test files.
Until now we would skip loading of the backing chain for files which
don't support backing chains only when starting up the VM. Move the
check from qemuProcessPrepareHostStorage with some adaptations so that's
always applied.
The graphics code is complex and there are a lot of exceptions and
backward compatible combinations. One of them is the possibility
to configure "spice_auto_unix_socket" in qemu.conf which will convert
all spice graphics with listen type "address" without any address
specified to listen type "socket" when the guest is started.
We don't format this generated socket into migratable XML to make
migration work with older libvirt. However, spice has another
exception that if autoport='no' and there is no port configured
it is converted to listen type "none". Because of this we need
to format autoport='yes' to make sure that the listen type will
be the same as the offline XML.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1511407
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
In status XML, we do not store the QEMU version information, we only
format all the capabilities. We dropped QEMU_CAPS_PCI_MULTIBUS
in commit 5b783379 which was released in libvirt 3.2.0.
Therefore the only way of telling if the already running domain
at the time of daemon restart has been started with a QEMU that does
use 'pci.0' or not on PPC is to look at the pci-root controller's
alias. This is not an option if the domain has a user-specified alias
for the pci-root.
Instead of reintroducing the capability, assume 'pci.0' when we have
no version information. That way the only left broken use case would
be the combination of user aliases and very old QEMU.
Partially reverts commit 3a37af1e4.
https://bugzilla.redhat.com/show_bug.cgi?id=1518148
We do not fill out qemuCaps->arch when parsing status XML.
Use def->os.arch like we do for PPC.
This fixes hotplug after daemon restart for domains that use
a user alias for the implicit pci-root on x86.
https://bugzilla.redhat.com/show_bug.cgi?id=1518148
For some corner cases, virQEMUCapsHasPCIMultiBus depends on the QEMU
version, which is by design not stored in the status XML and therefore
it cannot be fixed for all existing running domains.
Prefer the controller alias read from the status XML when formatting
PCI addresses and only fall back to using virQEMUCapsHasPCIMultiBus
if the alias is a user alias.
This fixes hotplug after daemon restart for domains not using user
aliases.
Partially reverts commit 937f3195.
https://bugzilla.redhat.com/show_bug.cgi?id=1518148
Adjust function descriptions of virQEMUCapsInitCPUModelS390 and
virQEMUCapsInitCPUModel to the changes introduced with
commitID 74fc32a955.
Signed-off-by: Boris Fiuczynski <fiuczy@linux.vnet.ibm.com>
Reviewed-by: Marc Hartmayer <mhartmay@linux.vnet.ibm.com>
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Even though we never format the device on the QEMU command line,
as it's a platform serial device that's not user-instantiable,
we should still make sure it's available before using it.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
All serial devices shoule have an associated capability.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
We should make sure the isa-serial device is available before
formatting it on the QEMU command line.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
All serial devices shoule have an associated capability.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Now that <serial> and <console> on s390/s390x behave a bit more like the
other architectures, remove this extra differentation, and use sclp
console by default for new guests. New virtio consoles can still be
added, and it is actually needed because of the limited number of
instances for sclp and sclplm.
This reverts commit b1c88c1476, whose
reasons are not totally clear.
Signed-off-by: Pino Toscano <ptoscano@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Bjoern Walk <bwalk@linux.vnet.ibm.com>
Introduce specific a target types with two models for the console
devices (sclp and sclplm) used in s390 and s390x guests, so isa-serial
is no more used for them.
This makes <serial> usable on s390 and s390x guests, with at most only
a single sclpconsole and one sclplmconsole devices usable in a single
guest (due to limitations in QEMU, which will enforce already at
runtime).
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1449265
Signed-off-by: Pino Toscano <ptoscano@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
We can finally introduce a specific target model for the pl011 device
used by mach-virt guests, which means isa-serial will no longer show
up to confuse users.
We make sure migration works in both directions by interpreting the
isa-serial target type, or the lack of target type, appropriately
when parsing the guest XML, and skipping the newly-introduced type
when formatting if for migration. We also verify that pl011 is not
used for non-mach-virt guests and add a bunch of test cases.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=151292
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
The existing implementation set the address type for all serial
devices to spapr-vio, which made it impossible to use other devices
such as usb-serial and pci-serial; moreover, some decisions were
made based on the address type rather than the device type.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1512934
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
We can finally introduce a specific target model for the spapr-vty
device used by pSeries guests, which means isa-serial will no longer
show up to confuse users.
We make sure migration works in both directions by interpreting the
isa-serial target type, or the lack of target type, appropriately
when parsing the guest XML, and skipping the newly-introduced type
when formatting if for migration. We also verify that spapr-vty is
not used for non-pSeries guests and add a bunch of test cases.
This commit is best viewed with 'git show -w'.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1511421
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Instead duplicating the capability check for each possible target
model, introduce a small helper that matches the target model with
the corresponding capability and collapse all existing checks into
a single one.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Now that we've created a distinction between target type and target
model, with the latter being the concrete device name, it's time to
switch to formatting the model instead of the type.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Target model and target type must agree for the configuration
to make sense, so check that's actually the case and error out
otherwise.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
This information will be used to select, and store in the guest
configuration in order to guarantee ABI stability, the concrete
(hypervisor-specific) model for serial devices.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Instead of validating each target type / address type combination
separately, create a small helper to perform the matching and
collapse all existing checks into a single one.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Instead of waiting until we get to command line generation, we can
validate the target for a char device much earlier.
Move all the checks out of qemuBuildSerialChrDeviceStr() and into
the new fuction. This will later allow us to validate the target
for platform devices.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Formatting the <target/> element for serial devices will become a
bit more complicated later on, and leaving the fallthrough behavior
there would do nothing but complicate it further.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Make the switch statement type-aware, avoid calling
virDomainChrTargetTypeToString() more than once and check its
return value before using it.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
The function can fail, but none of the caller were accounting
for that.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
We don't need to store the return value since we never modify it.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Move formatting of the <target/> element for char devices out of
virDomainChrDefFormat() and into its own function.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
This attribute was used to decide whether to format the type
attribute of the <target> element, but the logic didn't take into
account all possible cases and as such could lead to unexpected
results. Moreover, it's one more thing to keep track of, and can
easily fall out of sync with other attributes.
Now that we have VIR_DOMAIN_CHR_SERIAL_TARGET_TYPE_NONE, we can
use that value to signal that no specific target type has been
configured for the serial device and as such the attribute should
not be formatted at all. All other values are now formatted.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
This is the first step in getting rid of the assumption that
isa-serial is the default target type for serial devices.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
The devicePostParse() callback is invoked for all devices so that
drivers have a chance to set their own specific values; however,
virDomainDefAddImplicitDevices() runs *after* the devicePostParse()
callbacks have been invoked and can add new devices, in which case
the driver wouldn't have a chance to customize them.
Work around the issue by invoking the devicePostParse() callback
after virDomainDefAddImplicitDevices(), only for the first serial
devices, which might have been added by it. The same was already
happening for the first video device for the very same reason.
This will become important later on, when we will change
virDomainDefAddConsoleCompat() not to set a targetType for
automatically added serial devices.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Having a separate function for char device handling is better than
adding even more code to qemuDomainDeviceDefPostParse().
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Marc Hartmayer <mhartmay@linux.vnet.ibm.com>
https://bugzilla.redhat.com/show_bug.cgi?id=1425757
The blockdev-add code provides a mechanism to sanely provide user
and password-secret arguments for iscsi without placing them on the
command line to be viewable by a 'ps -ef' type command or needing
to create separate -iscsi devices for each disk/volume found.
So modify the iSCSI command line building to check for the presence
of the capability in order properly setup and use the domain master
secret object to encrypt the password in a secret object and alter
the parameters for the command line to utilize.
Modify the xml2argvtest to exhibit the syntax for both disk and
hostdev configurations.
Detect the capability via the query-qmp-schema for blockdev-add
to find the 'password-secret' parameter that will allow the iSCSI
code to use the master secret object to encrypt the secret for an
and only need to provide the object id of the secret on the command
line thus obsfuscating the passphrase.
Rather than picking apart the two pieces we need/want (path, hosts,
and auth)- let's allocate/use a virStorageSourcePtr for iSCSI storage.
The end result is that qemuBuildSCSIiSCSIHostdevDrvStr doesn't need
to "fake" one for the qemuBuildNetworkDriveStr call.
Libvirt prints an error on startup when it is missing host cpu model
information for any queried qemu binary. On s390 we only have host cpu model
information for kvm enabled qemu instances. So when virt type is not kvm, this
is actually not an error on s390.
This patch adds virt type as a parameter to virQEMUCapsInitCPUModelS390, and a
new return code 2 for virQEMUCapsInitCPUModel and virQEMUCapsInitCPUModelS390.
If the virt type is not kvm then we skip printing the scary error message
and return 2 because this case is actually expected behavior. The new return
code is meant to differentiate between the failure case and the case where we
simply expect the cpu model information to be unattainable.
Signed-off-by: Jason J. Herne <jjherne@linux.vnet.ibm.com>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.vnet.ibm.com>
Reviewed-by: Marc Hartmayer <mhartmay@linux.vnet.ibm.com>
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Commit id '5d5c732d7' had an incorrect assignment and was found
by travis build:
storage/storage_driver.c:1668:14: error: equality comparison with extraneous
parentheses [-Werror,-Wparentheses-equality]
if ((obj == virStoragePoolObjListSearch(&driver->pools,
~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Create an API to search through the storage pool objects looking for
a specific truism from a callback API in order to return the specific
storage pool object that is desired.
Create an API to walk the pools->objs[] list in order to perform a
callback function for each element of the objs array that doesn't care
about whether the action succeeds or fails as the desire is to run the
code over every element in the array rather than fail as soon as or if
one fails.
For now it'll just call the virStoragePoolObjUnlock, but a future
adjustment will do something different. Since the new API will check
for a NULL object before the Unlock call, callers no longer need to
check for NULL before calling.
The virStoragePoolObjUnlock is now private/static to virstorageobj.c
with a short term forward reference.
Commit id '36555364' removed the setting of the driver->privileged,
which the udevProcessPCI would need in order to read the PCI device
configs.
Signed-off-by: John Ferlan <jferlan@redhat.com>
Move the setup of the disk attribute to the disk source prepare function
which will allow proper usage with JSON props and move the fallback
(legacy) generating code into the block which is executed with legacy
options.
As a side-effect of this change we can clean up propagation of 'cfg'
into the command generator.
Also it's nice to see that the test output is the same even when the
value is generated in a different place.
Some drive backends allow output of debugging information which can be
configured using properties of the image. Add fields to virStorageSource
which will allow configuring them.
The 'file.password-secret' injection should be used only if we are using
the old formatter. When formatting the source string from the JSON
properties, the property should be added there.
Also drop the comment which refers to stuff that will not be used in
libvirt since -blockdev is the way to go.
Qemu has now an internal mechanism for locking images to fix specific
cases of disk corruption. This requires libvirt to mark the image as
shared so that qemu lifts certain restrictions.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1378242
'share-rw' for the disk device configures qemu to allow concurrent
access to the backing storage.
The capability is checked in various supported disk frontend buses since
it does not make sense to partially backport it.
Creating a snapshot would introduce a possibly unsupported member for
sharing into the backing chain. Add a check to prevent that from
happening.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1511480
Disk sharing between two VMs may corrupt the images if the format driver
does not support it. Check that the user declared use of a supported
storage format when they want to share the disk.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1511480
Storage source format backing a shared device (e.g. running a cluster
filesystem) needs to support the sharing so that metadata are not
corrupted. Add a central function for checking this.
Since we already have such support for libxl all we need is qemu
driver adjustment. And a test case.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
This capability says if qemu is capable of specifying distances
between NUMA nodes on the command line. Unfortunately, there's no
real way to check this and thus we have to go with version check.
QEMU introduced this in 0f203430dd8 (and friend) which was
released in 2.10.0.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
The function returns true/false depending on distance
configuration being present in the domain XML.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
There's no point in checking if numa->mem_nodes[node].ndistances
is set if we check for numa->mem_nodes[node].distances. However,
it makes sense to check if the sibling node (@cellid) caller
passed falls within boundaries.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
When QEMU dies, we read its output stored in a log file and use it for
reporting a hopefully useful error. However, virReportError will trim
the message to (VIR_ERROR_MAX_LENGTH - 1) characters, which means the
end of the log (which likely contains the error message we want to
report) may get lost. We should trim the beginning of the log instead.
https://bugzilla.redhat.com/show_bug.cgi?id=1335534
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
When reading QEMU log for reporting it as an error message, we want to
skip "char device redirected to" line. However, this string is not
printed at the beginning of a line, which means STRPREFIX will never
find it.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Historically we've formatted a lot of the attributes of a disk (disk
geometry, etc) with -drive. Since we use -device now, they should be
formatted there. Extract them to a separate function for keeping
compatibility with SDcards which still use only -drive.
Start this by moving the geometry into a separate function.
When doing block commit we need to allow write for members of the
backing chain so that we can commit the data into them.
qemuDomainDiskChainElementPrepare was used for this which since commit
786d8d91b4 calls qemuDomainNamespaceSetupDisk which has very adverse
side-effects, namely it relabels the nodes to the same label it has in
the main namespace. This was messing up permissions for the commit
operation since its touching various parts of a single backing chain.
Since we are are actually not introducing new images at that point add a
flag for qemuDomainDiskChainElementPrepare which will refrain from
calling to the namespace setup function.
Calls from qemuDomainSnapshotCreateSingleDiskActive and
qemuDomainBlockCopyCommon do introduce new members all calls from
qemuDomainBlockCommit do not, so the calls are anotated accordingly.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1506072
https://bugzilla.redhat.com/show_bug.cgi?id=1434451
Just like in 9324f67a57 we need to put default sata alias
(which is hardcoded to "ide", obvious, right?) onto the command
line instead of the one provided by user.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
This function only queries domain @def. It doesn't change it.
Therefore it should take const pointer.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
The compiler can warn us if we add a value to the
virDomainChrSerialTargetType enumeration but forget to handle
it properly in the code. Let's take advantage of that.
This commit is best viewed with 'git diff -w'.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Add a separate capability for the sclplmconsole device, and check it
specifically instead of using QEMU_CAPS_DEVICE_SCLPCONSOLE for that too.
Signed-off-by: Pino Toscano <ptoscano@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Give a better name to the capability for the sclpconsole device.
Signed-off-by: Pino Toscano <ptoscano@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Up until now we assumed the spapr-vty device would always be
present, which is not very nice. Check for its availability before
using it instead.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Pavel Hrdina <phrdina@redhat.com>
Starting from qemu 2.11, the `-device vmcoreinfo` will create a fw_cfg
entry for a guest to store dump details, necessary to process kernel
dump with KASLR enabled and providing additional kernel details.
In essence, it is similar to -fw_cfg name=etc/vmcoreinfo,file=X but in
this case it is not backed by a file, but collected by QEMU itself.
Since the device is a singleton and shouldn't use additional hardware
resources, it is presented as a <feature> element in the libvirt
domain XML.
The device is arm/x86 only for now (targets that support fw_cfg+dma).
Related to:
https://bugzilla.redhat.com/show_bug.cgi?id=1395248
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Because the cache banks are initialized based on the order in which their
respective directories exist on the filesystem, they can appear in different
order. This is here mainly for tests because the cache directory might have
different order of children nodes and tests would fail otherwise. It should not
be the case with sysfs, but one can never be sure. And this does not take
almost any extra time, mainly because it gets initialized once per driver.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Sometimes the size of the bitmap matters and it might not be guessed correctly
when parsing from some type of input. For example virBitmapNewData() has Byte
granularity, virBitmapNewString() has nibble granularity and so on.
virBitmapParseUnlimited() can be tricked into creating huge bitmap that's not
needed (e.g.: "0-2,^99999999"). This function provides a way to shrink the
bitmap. It is not supposed to free any memory.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Already introduced in the past with 9479642fd3, but then renamed to
virBitmapIntersect by a908e9e45e. This time we'll really use it.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Our bitmaps can be represented as data (raw bytes for which we have
virBitmapNewData() and virBitmapToData()), human representation (list
of numbers in a string for which we have virBitmapParse() and
virBitmapFormat()) and hexadecimal string (for which we have only
virBitmapToString()). So let's add the missing complement for the
last one so that we can parse hexadecimal strings.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Truncate the output so that it is only as big as is needed to fit all
the bits, not all the units from the map. This will be needed in the
future in order to properly format bitmaps for kernel's sysfs files.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
It is literally only a wrapper around virBitmapNewData() and
virBitmapFormat(), only the naming was wrong since it was introduced.
And because we have virBitmap*String functions where the meaning of
the 'String' is constant, this might confuse someone.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
This follows the virBitmapToData() function and, similarly to
virBitmapNewData(), we'll be able to have virBitmapNewString() later
on without name confusion.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
We can't output better memory sizes if we want to be compatible with libvirt
older than the one which introduced /memory/unit, but for new things we can just
output nicer capacity to the user if available. And this function enables that.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Resolve a storage driver crash as a result of a long running
storageVolCreateXML when the virStorageVolPoolRefreshThread is
run as a result of when a storageVolUpload completed and ran the
virStoragePoolObjClearVols without checking if the creation
code was currently processing a buildVol after incrementing
the driver->asyncjob count.
The refreshThread will now check the pool asyncjob count before
attempting to pursue the pool refresh. Adjust the documentation
to describe the condition.
Crash from valgrind is as follows (with a bit of editing):
==21309== Invalid read of size 8
==21309== at 0x153E47AF: storageBackendUpdateVolTargetInfo
==21309== by 0x153E4C30: virStorageBackendUpdateVolInfo
==21309== by 0x153E52DE: virStorageBackendVolRefreshLocal
==21309== by 0x153DE29E: storageVolCreateXML
==21309== by 0x562035B: virStorageVolCreateXML
==21309== by 0x147366: remoteDispatchStorageVolCreateXML
...
==21309== Address 0x2590a720 is 64 bytes inside a block of size 336 free'd
==21309== at 0x4C2F2BB: free
==21309== by 0x54CB9FA: virFree
==21309== by 0x55BC800: virStorageVolDefFree
==21309== by 0x55BF1D8: virStoragePoolObjClearVols
==21309== by 0x153D967E: virStorageVolPoolRefreshThread
...
==21309== Block was alloc'd at
==21309== at 0x4C300A5: calloc
==21309== by 0x54CB483: virAlloc
==21309== by 0x55BDC1F: virStorageVolDefParseXML
==21309== by 0x55BDC1F: virStorageVolDefParseNode
==21309== by 0x55BE5A4: virStorageVolDefParse
==21309== by 0x153DDFF1: storageVolCreateXML
==21309== by 0x562035B: virStorageVolCreateXML
==21309== by 0x147366: remoteDispatchStorageVolCreateXML
...
This is similar to the virDomainQemuMonitorCommand API, it can change
the domain state in a way that libvirt may not understand.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
We put the server into a hash table as we do with the other daemons,
there is no compelling reason why it should have another pointer
dedicated just to the server. Besides, the locking daemon doesn't have
it and virtlogd is essentially a copy paste of virtlockd.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Most of the time it's okay to leave this up to negotiation between
the guest and the host, but in some situations it can be useful to
manually decide the behavior, especially to enforce its availability.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1308743
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Setup everything related to disks in one place rather than calling in
from various places.
The change to ordering of the setup steps is necessary since secrets
need the master key to be present.
In some cases it does not make sense to pursue that the private data
will be allocated (especially when we don't need to put anything in it).
Ensure that the code works without it.
This also fixes few crashes pointed out in
https://bugzilla.redhat.com/show_bug.cgi?id=1510323
If creation of the main JSON object containing the storage portion of a
virStorageSource would fail but we'd allocate the server structure we'd
leak it. Found by coverity.
Return NULL right away in qemuBlockStorageSourceGetBackendProps when an
invalid storage source is presented so that virJSONValueObjectAdd isn't
called with a NULL argument.
Found by coverity.
The terminator would not be parsed properly since the XPath selector was
looking for an populated element, and also the code did not bother
assigning the terminating virStorageSourcePtr to the backingStore
property of the parent.
Some tests would catch it if there wasn't bigger fallout from the change
to backing store termination in a693fdba01. Fix them properly now.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1509110
https://bugzilla.redhat.com/show_bug.cgi?id=1497410
This reverts commit bc8a99ef06.
The vhostuser is not a TAP. Therefore our QoS code is not able to
set any bandwidth. I don't really understand what I was thinking.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
This patch generates a NUMA distance-aware libxl description from the
information extracted from a NUMA distance-aware libvirt XML file.
By default, if no NUMA node distance information is supplied in the
libvirt XML file, this patch uses the distances 10 for local and 20
for remote nodes/sockets.
Signed-off-by: Wim ten Have <wim.ten.have@oracle.com>
Reviewed-by: Jim Fehlig <jfehlig@suse.com>
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
Add support for describing NUMA distances in a domain's <numa> <cell>
XML description.
Below is an example of a 4 node setup:
<cpu>
<numa>
<cell id='0' cpus='0-3' memory='2097152' unit='KiB'>
<distances>
<sibling id='0' value='10'/>
<sibling id='1' value='21'/>
<sibling id='2' value='31'/>
<sibling id='3' value='21'/>
</distances>
</cell>
<cell id='1' cpus='4-7' memory='2097152' unit='KiB'>
<distances>
<sibling id='0' value='21'/>
<sibling id='1' value='10'/>
<sibling id='2' value='21'/>
<sibling id='3' value='31'/>
</distances>
</cell>
<cell id='2' cpus='8-11' memory='2097152' unit='KiB'>
<distances>
<sibling id='0' value='31'/>
<sibling id='1' value='21'/>
<sibling id='2' value='10'/>
<sibling id='3' value='21'/>
</distances>
<cell id='3' cpus='12-15' memory='2097152' unit='KiB'>
<distances>
<sibling id='0' value='21'/>
<sibling id='1' value='31'/>
<sibling id='2' value='21'/>
<sibling id='3' value='10'/>
</distances>
</cell>
</numa>
</cpu>
A <cell> defines a NUMA node. <distances> describes the NUMA distance
from the <cell> to the other NUMA nodes (the <sibling>s). For example,
in above XML description, the distance between NUMA node0 <cell id='0'
...> and NUMA node2 <sibling id='2' ...> is 31.
Valid distance values are '10 <= value <= 255'. A distance value of 10
represents the distance to the node itself. A distance value of 20
represents the default value for remote nodes but other values are
possible depending on the physical topology of the system.
When distances are not fully described, any missing sibling distance
values will default to 10 for local nodes and 20 for remote nodes.
If distance is given for A -> B, then we default B -> A to the same
value instead of 20.
Signed-off-by: Wim ten Have <wim.ten.have@oracle.com>
Reviewed-by: Daniel P. Berrange <berrange@redhat.com>
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
https://bugzilla.redhat.com/show_bug.cgi?id=1434451
When testing user aliases it was discovered that for 440fx
machine type which has default IDE bus builtin, domain cannot
start if IDE controller has the user provided alias. This is
because for 440fx we don't put the IDE controller onto the
command line (since it is builtin) and therefore any device that
is plugged onto the bus must use the default alias.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
libvirt reports a fake NUMA topology in virConnectGetCapabilities
even if built without numactl support. The fake NUMA topology consists
of a single cell representing the host's cpu and memory resources.
Currently this is the case for ARM and s390[x] RPM builds.
A client iterating over NUMA cells obtained via virConnectGetCapabilities
and invoking virNodeGetMemoryStats on them will see an internal failure
"NUMA isn't available on this host" from virNumaGetMaxNode. An example
for such a client is VDSM.
Since the intention seems to be that libvirt always reports at least
a single cell it is necessary to return "fake" node memory statistics
matching the previously reported fake cell in case NUMA isn't supported
on the system.
Signed-off-by: Viktor Mihajlovski <mihajlov@linux.vnet.ibm.com>
Simply add the 5.2 SDK header to the existing unified framework. No
other special handling is needed as there's no API break between
existing 5.1 and the just added 5.2.
There was a recent report of the xen-xl converter not handling
config files missing an ending newline
https://www.redhat.com/archives/libvir-list/2017-October/msg01353.html
Commit 3cc2a9e0 fixed a similar problem when parsing content of a
file but missed parsing in-memory content. But AFAICT, the better
fix is to properly set the end of the content when initializing the
virConfParserCtxt in virConfParse().
This commit reverts the part of 3cc2a9e0 that appends a newline to
files missing it, and fixes setting the end of content when
initializing virConfParserCtxt. A test is also added to check
parsing in-memory content missing an ending newline.
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
Reviewed-by: Daniel P. Berrange <berrange@redhat.com>
In 4f15707202 I've tried to make duplicates detection for
nested /dev mount better. However, I've missed the obvious case
when there are two same mount points. For instance if:
# mount --bind /dev/blah /dev/blah
# mount --bind /dev/blah /dev/blah
Yeah, very unlikely (in qemu driver world) but possible.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Split on the last colon and avoid parsing port if the split remainder
contains the closing square bracket, so that IPv6 addresses are
interpreted correctly.
In some cases management application needs to allocate memory for
qemu upfront and then just let qemu use that. Since we don't want
to expose path for memory-backend-file anywhere in the domain
XML, we can generate predictable paths. In this case:
$memoryBackingDir/libvirt/qemu/$shortName/$alias
where $shortName is result of virDomainDefGetShortName().
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
When removing path where huge pages are call virFileDeleteTree
instead of plain rmdir(). The reason is that in the near future
there's going to be more in the path than just files - some
subdirs. Therefore plain rmdir() is not going to be enough.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
At the same time, move its internals into a separate function so
that they can be reused.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Very soon qemuBuildMemoryBackendStr() is going to use memory cell
aliases. Therefore set one. At the same time, move it a bit
further - if virAsprintf() fails, there's no point in setting
rest of the members.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
In VirtualBox SAS and SCSI are separate controller types whereas libvirt
does not make such distinction. This patch adds support for attaching
the VBOX SAS controllers by mapping the 'lsisas1068' controller model in
libvirt XML to VBOX SAS controller type. If VBOX VM has disks attached
to both SCSI and SAS controller libvirt domain XML will have two
<controller type='scsci'> elements with index and model attributes set
accordingly. In this case, each respective <disk> element must have
<address> element specified to assign it to respective SCSI controller.
This patch adds <address> element to each <disk> device since device
names alone won't adequately reflect the storage device layout in the
VM. With this patch, the ouput produced by dumpxml will faithfully
reproduce the storage layout of the VM if used with define.
Previously any removable storage device without media attached was
omitted from domain XML dump. They're still (rightfully) omitted in
snapshot XML dump but need to be accounted properly to for the device
names to stay in 'sync' between domain and snapshot XML dumps.
Primer the code for further changes:
* move variable declarations to the top of the function
* group together free/release statements
* error check and report VBOX API calls used
If a VBOX VM has e.g. a SATA and SCSI disk attached, the XML generated
by dumpxml used to produce "sda" for both of those disks. This is an
invalid domain XML as libvirt does not allow duplicate device names. To
address this, keep the running total of disks that will use "sd" prefix
for device name and pass it to the vboxGenerateMediumName which no
longer tries to "compute" the value based only on current and max
port and slot values. After this the vboxGetMaxPortSlotValues is not
needed and was deleted.
Both vboxSnapshotGetReadWriteDisks and vboxSnapshotGetReadWriteDisks do
not need to free the def->disks on cleanup because it's being done by
the caller via virDomainSnaphotDefFree
This patch prepares the vboxSnapshotGetReadOnlyDisks and
vboxSnapshotGetReadWriteDisks functions for further changes so that
the code movement does not obstruct the gist of those future changes.
This is done primarily because we'll need to know the type of vbox
storage controller as early as possible and make decisions based on
that info.
With this patch, the vbox driver will no longer attach all supported
storage controllers by default even if no disk devices are associated
with them. Instead, it will attach only those that are implicitly added
by virDomainDefAddImplicitController based on <disk> element or if
explicitly specified via the <controller> element.
Since the VBOX API requires to register an initial VM before proceeding
to attach any remaining devices to it, any failure to attach such
devices should result in automatic cleanup of the initially registered
VM so that the state of VBOX registry remains clean without any leftover
"aborted" VMs in it. Failure to cleanup of such partial VMs results in a
warning log so that actual define error stays on the top of the error
stack.
Libvirt historically stores storage source path including the volume as
one string in the XML, but that is not really flexible enough when
dealing with the fields in the code. Previously we'd store the slash
separating the two as part of the image name. This was fine for gluster
but it's not necessary and does not scale well when converting other
protocols.
Don't store the slash as part of the path. The resulting change from
absolute to relative path within the gluster driver should be okay,
as the root directory is the default when accessing gluster.
Extract the part formatting the basic URI part so that it can be reused
to format JSON backing definitions. Parts specific to the command line
format will remain in qemuBuildNetworkDriveURI. The new function is
called qemuBlockStorageSourceGetURI.
Original implementation used 'SocketAddress' equivalent from qemu for
the disk server field, while qemu documentation specifies
'InetSocketAddress'. The backing store parser uses the correct parsing
function but the formatter used the incorrect one (and also with the
legacy mode enabled which was wrong).
