These XMLs live in a separate directory, there's no need for them
to have a special prefix in addition. It also doesn't play nicely
with ':e' completion in Vim, finding proper file based on
qemuxml2argvtest.c is also needlessly complicated.

The files were renamed using the following commands. From
qemuxml2argvdata:

  for i in qemuxml2argv-*.xml; do mv $i ${i#qemuxml2argv-}; done

and then (to fix broken symlinks) from qemuxml2argvdata and
qemuxml2xmloutdata:

  for i in $(find . -xtype l); do \
      ln -sf $(readlink $i | sed 's/qemuxml2argv-//') $i;
  done
Signed-off-by: NMichal 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 a693fdba which was not detected in the review.

This patch also reverts all the changes in the test files.

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 3a37af1e.

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

The 'wiremode' attribute exists in a couple of Xen XML files, but no code has
ever parsed that value. It was later added to the RNG schema too, again despite
there not being any code which parses it.
Reviewed-by: NJim Fehlig <jfehlig@suse.com>
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

The libxlxml2domconfigdata directory was not covered in the RNG schema
tests. This hid a few bugs in both the libxl XML files and the RNG
schema itself.
Reviewed-by: NJim Fehlig <jfehlig@suse.com>
Signed-off-by: NDaniel P. Berrange <berrange@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: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NPavel Hrdina <phrdina@redhat.com>

All serial devices shoule have an associated capability.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NPavel 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: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NPavel Hrdina <phrdina@redhat.com>

All serial devices shoule have an associated capability.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NPavel 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 b1c88c14, whose
reasons are not totally clear.
Signed-off-by: NPino Toscano <ptoscano@redhat.com>
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NBjoern 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=1449265Signed-off-by: NPino Toscano <ptoscano@redhat.com>
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NPavel 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=151292Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NPavel 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=1512934Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NPavel 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=1511421Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NPavel Hrdina <phrdina@redhat.com>

Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NPavel 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: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NPavel Hrdina <phrdina@redhat.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.

Since it's not longer used to shuttle the @secinfo, let's remove
the private hostdev completely.

Now that we're moved the object into virstorageobj, let's make the
code use the lockable object.

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.

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.

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

Some test cases have the backend tag inside wrong interfaces. The backend xml
tag does not support <interface type='user|direct|hostdev'>. So this commit
changes some network types inside the interfaces that have backend defined.
Signed-off-by: NJulio Faracco <jcfaracco@gmail.com>

Since we already have such support for libxl all we need is qemu
driver adjustment. And a test case.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NJohn 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: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

That's a disk frontend attribute. Move the code to a separate function
since it's non-trivial and call it from the frontend attribute
formatter.

Move together sections which are conditionaly executed depending on
whether -device will be used together with the -drive.

Since we don't pack symlinks we cannot have recursive loops in them.  Since we
need one directory to be in tests/vircaps2xmldata/linux-caches/, instead of
creating a symlink, just move the files in that directory and adjust tests.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NDaniel P. Berrange <berrange@redhat.com>

https://bugzilla.redhat.com/show_bug.cgi?id=1434451

Just like in 9324f67a we need to put default pci-root
alias onto the command line instead of the one provided by user.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

https://bugzilla.redhat.com/show_bug.cgi?id=1434451

Just like in 9324f67a 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: NMichal Privoznik <mprivozn@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: NPino Toscano <ptoscano@redhat.com>
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>

Give a better name to the capability for the sclpconsole device.
Signed-off-by: NPino Toscano <ptoscano@redhat.com>
Reviewed-by: NAndrea 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: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NPavel 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=1395248Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com>