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.

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

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.

https://bugzilla.redhat.com/show_bug.cgi?id=1447169Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

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

Since domain can have at most one watchdog it simplifies things a
bit. However, since we must be able to set the watchdog action as
well, new monitor command needs to be used.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

Similarly to previous patch, for some types of interface domain
and host are on the same side of RX/TX barrier. In that case, we
need to set up the QoS differently. Well, swapped.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

Alter qemu command line generation in order to possibly add TLS for
a suitably configured domain.

Sample TLS args generated by libvirt -

    -object tls-creds-x509,id=objvirtio-disk0_tls0,dir=/etc/pki/qemu,\
    endpoint=client,verify-peer=yes \
    -drive file.driver=vxhs,file.tls-creds=objvirtio-disk0_tls0,\
    file.vdisk-id=eb90327c-8302-4725-9e1b-4e85ed4dc251,\
    file.server.type=tcp,file.server.host=192.168.0.1,\
    file.server.port=9999,format=raw,if=none,\
    id=drive-virtio-disk0,cache=none \
    -device virtio-blk-pci,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,\
    id=virtio-disk0

Update the qemuxml2argvtest with a couple of examples. One for a
simple case and the other a bit more complex where multiple VxHS disks
are added where at least one uses a VxHS that doesn't require TLS
credentials and thus sets the domain disk source attribute "tls = 'no'".

Update the hotplug to be able to handle processing the tlsAlias whether
it's to add the TLS object when hotplugging a disk or to remove the TLS
object when hot unplugging a disk.  The hot plug/unplug code is largely
generic, but the addition code does make the VXHS specific checks only
because it needs to grab the correct config directory and generate the
object as the command line would do.
Signed-off-by: NAshish Mittal <Ashish.Mittal@veritas.com>
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

When the vcpu is successfully removed libvirt would remove the cgroup.
In cases when removal of the cgroup fails libvirt would report an error.

This does not make much sense, since the vcpu was removed and we can't
really do anything with the cgroup. This patch silences the errors from
cgroup removal.

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

Passing a NULL value for the argument secAlias to the function
qemuDomainGetTLSObjects would cause a segmentation fault in
libvirtd.

Changed code to check before dereferencing a NULL secAlias.
Signed-off-by: NAshish Mittal <ashmit602@gmail.com>

Some operations done to rollback disk image labelling and locking might
overwrite (or clear) the actual error. Remember the original error when
tearing down disk access so that it's not obscured.

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

The helpers allow to simplify restoring original errors in most cases.

There were a few places in our code where the following pattern in 'if'
condition occurred:

if ((foo = bar() < 0))
    do something;

This patch adjusts the conditions to the expected format:

if ((foo = bar()) < 0)
    do something;

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1488192Signed-off-by: NErik Skultety <eskultet@redhat.com>
Reviewed-by: NMartin Kletzander <mkletzan@redhat.com>

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

When updating a virtio enabled vNIC and trying to change either
of rx_queue_size or tx_queue_size success is reported although no
operation is actually performed. Moreover, there's no way how to
change these on the fly. This is due to way we check for changes:
explicitly for each struct member. Therefore it's easy to miss
one.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

A new function virNetDevOpenvswitchUpdateVlan has been created to instruct
OVS of the changes. qemuDomainChangeNet has been modified to handle the
update of the VLAN configuration for a running guest and rely on
virNetDevOpenvswitchUpdateVlan to do the actual update if needed.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

All the pieces are now in place, so we can finally start
using isolation groups to achieve our initial goal, which is
separating hostdevs from emulated PCI devices while keeping
hostdevs that belong to the same host IOMMU group together.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1280542Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NLaine Stump <laine@laine.org>

We will soon need to be able to return a NULL pointer
without the caller considering that an error: to make
it possible, change the return type to int and use
an out parameter for the string instead.

Add some documentation for the function as well.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NLaine Stump <laine@laine.org>

We use hostdev->info frequently enough that having
a shorter name for it makes the code more readable.
We will also be adding even more uses later on.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NLaine Stump <laine@laine.org>

Combine and "clean up" a bit two places that are removing the vport

vcpu 0 must be always enabled and non-hotpluggable, thus you can't
modify it using the vcpu hotplug APIs. Disallow it so that users can't
create invalid configurations.

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

Part of the condition was reverted so no value update was propagated
through.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1414627Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

It was added in commit 6c2e4c38
so that Coverity would not complain about passing -1 to
qemuDomainDetachThisHostDevice(), but the function in question
has changed since and so the annotation doesn't apply anymore.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NPavel Hrdina <phrdina@redhat.com>

Change the settings from qemuDomainUpdateDeviceLive() as otherwise the
call would succeed even though nothing has changed.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1414627Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

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

It may happen that a domain is started without any huge pages.
However, user might try to attach a DIMM module later. DIMM
backed by huge pages (why would somebody want to mix regular and
huge pages is beyond me). Therefore we have to create the dir if
we haven't done so far.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

Use ATTRIBUTE_FALLTHROUGH, introduced by commit
5d84f596, instead of comments to
indicate that the fall through is an intentional behavior.
Signed-off-by: NMarc Hartmayer <mhartmay@linux.vnet.ibm.com>
Reviewed-by: NBoris Fiuczynski <fiuczy@linux.vnet.ibm.com>
Reviewed-by: NBjoern Walk <bwalk@linux.vnet.ibm.com>

The virDomainUSBAddressEnsure returns 0 or -1, so commit id 'de325472'
checking for 1 like qemuDomainAttachChrDeviceAssignAddr was wrong.
Signed-off-by: NShivaprasad G Bhat <sbhat@linux.vnet.ibm.com>

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

Currently, any attempt to change MTU on an interface that is
plugged to a running domain is silently ignored. We should either
do what's asked or error out. Well, we can update the host side
of the interface, but we cannot change 'host_mtu' attribute for
the virtio-net device. Therefore we have to error out.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NLaine Stump <laine@laine.org>

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

While implementing MTU (572eda12 and friends), I've forgotten
to actually set MTU on the host NIC in case of hotplug. We
correctly tell qemu on the monitor what the MTU should be, but we
are not actually setting it on the host NIC.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NLaine Stump <laine@laine.org>

When adding the aliased serial stub console, the structure wasn't
properly allocated (VIR_ALLOC instead of virDomainChrDefNew) which then
resulted in SIGSEGV in virDomainChrSourceIsEqual during a serial device
coldplug.

https://bugzilla.redhat.com/show_bug.cgi?id=1434278Signed-off-by: NErik Skultety <eskultet@redhat.com>

This reverts commit 2841e675.

It turns out that adding the host_mtu field to the PCI capabilities in
the guest bumps the length of PCI capabilities beyond the 32 byte
boundary, so the virtio-net device gets 64 bytes of ioport space
instead of 32, which offsets the address of all the other following
devices. Migration doesn't work very well when the location and length
of PCI capabilities of devices is changed between source and
destination.

This means that we need to make sure that the absence/presence of
host_mtu on the qemu commandline always matches between source and
destination, which means that we need to make setting of host_mtu an
opt-in thing (it can't happen automatically when the bridge being used
has a non-default MTU, which is what commit 2841e675 implemented).

I do want to re-implement this feature with an <mtu auto='on'/>
setting, but probably won't backport that to any stable branches, so
I'm first reverting the original commit, and that revert can be pushed
to the few releases that have been made since the original (3.1.0 -
3.3.0)

Resolves: https://bugzilla.redhat.com/1449346

Only set releaseaddr to true after the address has been
reserved successfully.

https://bugzilla.redhat.com/show_bug.cgi?id=1452581Reviewed-by: NJohn Ferlan <jferlan@redhat.com>