The only remaining user of qemuMonitorGetMigrationCapability is our test
suite. Let's replace qemuMonitorGetMigrationCapability with
qemuMonitorGetMigrationCapabilities there and drop the unused function.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

All calls to qemuMonitorGetMigrationCapability in QEMU driver are
replaced with qemuMigrationCapsGet.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

Each time we need to check whether a given migration capability is
supported by QEMU, we call query-migrate-capabilities QMP command and
lookup the capability in the returned list. Asking for the list of
supported capabilities once when we connect to QEMU and storing the
result in a bitmap is much better and we don't need to enter a monitor
just to check whether a migration capability is supported.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

The new function is called qemuProcessInitMonitor and it will enter/exit
the monitor so that the caller doesn't have to deal with this.

The goal of this patch is to simplify the code in qemuConnectMonitor
which would otherwise be a bit hairy after the following patch.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

Rather than a forward linked list, let's use the virHashTable in
order to manage the objsName data.

Requires numerous changes from List to Object management similar to
many other drivers/vir*obj.c modules

Modify the allocation to be a real RWLockable object and add the
various RWLock{Read|Write} and RWUnlock calls to process the list
of interfaces.

Since the virStorageEncryptionPtr encryption; is a member of
 _virStorageSource it really should be allowed to be a subelement
of the disk <source> for various disk formats:

   Source{File|Dir|Block|Volume}
   SourceProtocol{RBD|ISCSI|NBD|Gluster|Simple|HTTP}

NB: Simple includes sheepdog, ftp, ftps, tftp

That way we can set up to allow the <encryption> element to be
formatted within the disk source, but we still need to be wary
from whence the element was read - see keep track and when it
comes to format the data, ensure it's written in the correct place.

Modify the qemuxml2argvtest to add a parse failure when there is an
<encryption> as a child of <disk> *and* an <encryption> as a child
of <source>.

The virschematest will read the new test files and validate from a
RNG viewpoint things are fine.

Since the virStorageAuthDefPtr auth; is a member of _virStorageSource
it really should be allowed to be a subelement of the disk <source>
for the RBD and iSCSI prototcols. That way we can set up to allow
the <auth> element to be formatted within the disk source.

Since we've allowed the <auth> to be a child of <disk>, we'll need
to keep track of how it was read so that when writing out we'll know
whether to format as child of <disk> or <source>. For the argv2xml
parsing, let's format under <source> as a preference. Do not allow
<auth> to be both a child of <disk> and <source>.

Modify the qemuxml2argvtest to add a parse failure when there is an
<auth> as a child of <disk> *and* an <auth> as a child of <source>.

Add tests to validate that if the <auth> was found in <source>, then
the resulting xml2xml and xml2arg works just fine.  The two new .args
file are exact copies of the non "-source" version of the file.

The virschematest will read the new test files and validate from a
RNG viewpoint things are fine

Update the virstoragefile, virstoragetest, and args2xml file to show
the "preference" to place <auth> as a child of <source>.

Since the encryption information can also be disk source specific
move it from qemuDomainDiskPrivate to qemuDomainStorageSourcePrivate

Since the last allocated element from qemuDomainDiskPrivate is
removed, that means we no longer need qemuDomainDiskPrivateDispose.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>

Since the secret information is really virStorageSource specific
piece of data, let's manage the privateData from there instead of
at the Disk level.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>

Add the object definition and helpers to store security-related private
data for virStorageSources.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>

Introduce the bare necessities to add privateData to _virStorageSource.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>

When commit id 'da86c6c2' added support for diskPriv->encinfo in
qemuDomainSecretDiskPrepare a change to qemuDomainSecretDiskDestroy
to was missed. Although qemuDomainDiskPrivateDispose probably would
do the trick.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

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

When creating new /dev for domain ran in namespace we try to
preserve all sub-mounts of /dev. Well, not quite all. For
instance if /dev/foo/bar and /dev/foo are both mount points, only
/dev/foo needs preserving. /dev/foo/bar is preserved with it too.
Now, to identify such cases like this one STRPREFIX() is used.
That is not good enough. While it works for [/dev/foo/bar;
/dev/foo] case, it fails for [/dev/prefix; /dev/prefix2] where
the strings share the same prefix but are in fact two different
paths. The solution is to use STRSKIP().
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NErik Skultety <eskultet@redhat.com>

This function is going to make decisions based on the features
set per each driver. For that we need the virDomainXMLOption
object.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

In the future, some aliases might be already parsed therefore we
should avoid overwriting them.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Let's move all the virAsprintf()-s into separate functions for
better structure of the code. Later, when somebody wants to
generate a device alias, all they need is to expose the function.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

We have a special function for assigning aliases to RNG devices.
Use that instead of plain virAsprintf().
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

It looks like the error message was copied from virsh, because
that's where we have @ctl. Nevertheless, it's @flags which is
invalid, not @ctl.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Apart from killing a lot of code this also "implements" authentication
and encryption for USB disks.

Get rid of the first copy of the mess.

This horrible piece of spaghetti code is copy-past(ae)d in the SCSI and
USB disk hotplug code with minimal changes. Extract it for further
reuse.

Some messages deal with the disk itself thus using the disk target is
better than using the disk source name which can be NULL in some cases.

The check if the disk is empty is wrong and would spuriously reject NBD
sources. Remove it.

The code can't fail so having error handling is pointless.

Move the space after the colon.

Back in the times of using 'pci_del', unplugging a device without
a PCI address was not wired up.

After completely removing support for qemu without QEMU_CAPS_DEVICE,
aliases are used to uniquely identify devices in all cases.

Remove the pointless validation of data that was already present
in the domain definition.

There is no point in iterating over all devices if none of them
could possibly match.

Allow unplugging USB and virtio USB devices.

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

For both virtio input devices and USB input devices.

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

A function that builds the -device string for input devices.

Move assignment of input device alias into a separate function,
for reuse on hotplug.

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

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

There are two more cases where we set an S390/CCW/PCI address
type based on the machine type.

Reuse qemuDomainEnsureVirtioAddress to reduce repetition.

Split out the common code responsible for reserving/assigning
PCI/CCW addresses for virtio disks into a helper function
for reuse by other virtio devices.

Let it be reused in qemu_domain_address.

We pass the source.file to qemuCheckCCWS390AddressSupport for
the purpose of reporting an error message without actually checking
that the rng device is of type VIR_DOMAIN_RNG_BACKEND_RANDOM.

Change it to a hardcoded "rng" string, which also avoids
referring to the device by a host-side attribute.

After a successful attach, the device address has already been set.
Remove the pointless assignment.

Introduce virDomainAuditInput and use it to log the evdev passed
to the guest.