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>
==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>
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.
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>
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>
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>
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>
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.
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
