The private data of a virStorageSource which is backing an iSCSI hostdev
may be NULL if no authentication is present. The code handling the
hotplug would attempt to extract the authentication info stored in
'secinfo' without checking if it is allocated which resulted in a crash.

Here we opt the easy way to check if srcPriv is not NULL so that we
don't duplicate all the logic which selects whether the disk source has
a secret.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1597550Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

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

When updating a live device users might pass different alias than
the one the device has. Currently, this is silently ignored which
goes against our behaviour for other parts of the device where we
explicitly allow only certain changes and error out loudly on
anything else.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

Mediated devices of model 'vfio-ccw' are using CCW addresses, so make
sure to call the correct address preparation code for the model.
Reviewed-by: NShalini Chellathurai Saroja <shalini@linux.ibm.com>
Reviewed-by: NBoris Fiuczynski <fiuczy@linux.ibm.com>
Signed-off-by: NBjoern Walk <bwalk@linux.ibm.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

Remove the callbacks that the nwfilter driver registers with the domain
object config layer. Instead make the current helper methods call into
the public API for creating/deleting nwfilter bindings.
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

VMs with hardcoded platform network devices are forced to use old
style '-net nic' command line config. Current we use qemu's vlan
option to hook this with the '-netdev' host side of things.

However since qemu 1.2 there is '-net nic,netdev=X' option for
explicitly referencing a netdev ID, which is more inline with
typical VM commandlines, so let's switch to that
Signed-off-by: NCole Robinson <crobinso@redhat.com>

And replace all calls with virObjectEventStateQueue such that:

    qemuDomainEventQueue(driver, event);

becomes:

    virObjectEventStateQueue(driver->domainEventState, event);

And remove NULL checking from all callers.
Signed-off-by: NAnya Harter <aharter@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>
Signed-off-by: NJán Tomko <jtomko@redhat.com>

Replace instances where we previously called virGetLastError just to
either get the code or to check if an error exists with
virGetLastErrorCode to avoid a validity pre-check.
Signed-off-by: NRamy Elkest <ramyelkest@gmail.com>
Reviewed-by: NErik Skultety <eskultet@redhat.com>

Now that we have one place that sets up all disk-related objects to
qemuBlockStorageSourceAttachDataPtr we can easily reuse the data in the
command-line formatter by implementing a worker which will convert the
data.

A huge advantage is that it will be way easier to integrate this with
-blockdev later on.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Introduce a new setup function for all the related configuration and
move the setup and attachment of the PR code.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Create a new "Prepare" function and move the drive add code into the new
helpers. This will eventually allow to simplify and unify the attaching
code for use with blockdev at the same time as providing compatibility
with older qemus.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Emphasize that it's for the 'drive' part of the disk.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Replace access via wrapper by direct call to monitor API.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Add code that will handle the managed persistent reservations object
separately from the unmanaged one. There is only one managed object so
handling it with disks is awkward and does not scale well when backing
chains come into view.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Also since we don't do any conditional formatting, fix the comment for
the function.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Everything is contained in the virStorageSourceStructure.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

We need to check if TLS is enabled as the variable is a tristate.
Currently we'd setup TLS even if it was explicitly turned off.
Thankfully TLS for disks was only used with the vxhs protocol so hardly
anybody would ever be able to hit the problem.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJiri Denemark <jdenemar@redhat.com>

Disks are client-only so we don't need to have this variable. We also
always pass false for 'isListen' to qemuBuildTLSx509BackendProps for all
disk-related code-paths so the 'tlsVerify' is ignored anyways.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Note that it's okay to pass NULL to qemuDomainDelTLSObjects in
qemuDomainAddTLSObjects as the tls-creds-x509 object was either not
created or qemu crashed.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

The function adds the object of a certain type. Change the name so that
we make room for the generic function.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

The function generates JSON properties rather than a string so rename
it.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Callers should generate the alias separately.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

No callers are using it.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

'secinfo' is present also for migrations. Delete the misleading comment.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Setting up the 'secinfo' for the TLS private key password also generates
the given alias, so we don't need to generate another one.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Move the TLS object alias setup earlier. Also make sure that the alias
is not overwritten on hotplug.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Some callers will not need to generate the alias again.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

For some reason the function returned an error if secAlias was not
passed in. It's not an error, in fact it's desired.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Using 'haveTLS' to do this is pointless if the alias is not set.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Now that we remember the alias we've used to attach the secret objects
we should reuse them rather than trying to infer them from the disk
configuration.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

The function checks whether the storage source requires authentication
secret setup. Rename it accordingly.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

https://bugzilla.redhat.com/show_bug.cgi?id=1291851Signed-off-by: NJán Tomko <jtomko@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

Allow hotplugging the vsock device.

https://bugzilla.redhat.com/show_bug.cgi?id=1291851Signed-off-by: NJán Tomko <jtomko@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

In commit 8bebb2b7 I've refactored how the detach of disk with a
managed persistent reservations object is handled. After the commit if
any disk with a managed PR object would be removed libvirt would also
attempt to remove the shared 'pr-manager-helper' object potentially used
by other disks.

Thankfully this should not have practical impact as qemu should reject
deletion of the object if it was still used and the rest of the code is
correct.

Fix this by removing the disk from the definition earlier and checking
if the shared/managed pr-manager-helper object is still needed.

This basically splits the detach code for the managed PR object from the
unmanaged ones. The same separation will follow for the attachment code
as well as it greatly simplifies -blockdev support for this.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>