Similarly to the DEVICE_DELETED event we will be able to tell when
unplug of certain device types will be rejected by the guest OS. Wire up
the device deletion signalling code to allow handling this.

No need to keep two separate conditions. A slight juggling of return
values is needed to accomodate virDomainObjWaitUntil.

Neither of the callers cares whether the DEVICE_DELETED event isn't
supported or the event was received. Simplify the code and callers by
unifying the two values and changing the return value constants so that
a temporary variable can be omitted.

Callers ignore if this function returns -1 and continue as though the
DEVICE_DELETED event was not received. Since we can't be sure that the
event was not received we should behave as if the event was not
supported and remove the device definition right away. The error
fortunately won't really happen here.

Essentially revert commit 3a6204cb which added these to allow the test
suite to pass without depending on the host system state.

Since commit 4b527c1a we already mock virSCSIDeviceGetSgName, so these
callbacks are useless.

For device hotplug, the new alias ID needs to be checked in the list
rather than using the count of devices. Unplugging a device that is not
last in the array will make further hotplug impossible due to alias
collision.

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

For device hotplug, the new alias ID needs to be checked in the list
rather than using the count of devices. Unplugging a device that is not
last in the array will make further hotplug impossible due to alias
collision.

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

When a hostdev is attached to the guest (and removed from the host),
the order of operations is call qemuHostdevPreparePCIDevices to remove
the device from the host, call qemuSetupHostdevCgroup to setup the cgroups,
and virSecurityManagerSetHostdevLabel to set the labels.

When the device is removed from the guest, the code didn't use the
reverse order leading to possible issues (especially if the path to
the device no longer exists). This patch will move the call to
qemuTeardownHostdevCgroup to prior to reattaching the device to
the host.

When a hostdev is attached to the guest (and removed from the host),
the order of operations is call qemuHostdevPreparePCIDevices to remove
the device from the host, call qemuSetupHostdevCgroup to setup the cgroups,
and virSecurityManagerSetHostdevLabel to set the labels.

When the device is removed from the guest, the code didn't use the
reverse order leading to possible issues (especially if the path to
the device no longer exists). This patch will move the call to
virSecurityManagerRestoreHostdevLabel to prior to reattaching the
device to the host.

In certain cases, we need to assign a hostdevN-style alias in a case
when we don't have a virDomainHostdevDefPtr (instead we have a
virDomainNetDefPtr). Since qemuAssignDeviceHostdevAlias() doesn't use
anything in the virDomainHostdevDef except the alias string itself
anyway, this patch just changes the arguments to pass a pointer to the
alias pointer instead.

We've started to assume support for QEMU_CAPS_DEVICE. Doing so in the
SCSI disk hotplug code allows us to drop a lot of ugly legacy code.

If a user specify network type ethernet, then create it via libvirt and run
script if it provided. After this commit user does not need to
run external script to create tap device or add root permissions to qemu
process.
Signed-off-by: NVasiliy Tolstov <v.tolstov@selfip.ru>

QEMU changed the error message to:

        "Tray of device 'drive-sata0-0-1' is not open"

and they may change the error massage in the future.

This updates the code to not depend on the text from the error message
but only on error itself.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

in commit 81a110, multiqueue for macvtap is enabled but forget
to support hotplugging enabled
Signed-off-by: NShanzhi Yu <shyu@redhat.com>

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

The corresponding chardev must be attached first, otherwise the
the qemu command line won't be complete (missing the host part),

Create a new module qemu_alias.c to handle the qemuAssign*Alias* APIs
and the qemuDomainDeviceAliasIndex

Move function to qemu_interface.c and rename to qemuInterfaceOpenVhostNet
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Create new modules qemu_domain_address.c and qemu_domain_address.h to
contain all the new functions and header data. Additionally move any
supporting static functions.

Make qemuDomainSupportsPCI non static.

Also, move and rename the following:

qemuSetSCSIControllerModel to qemuDomainSetSCSIControllerModel
qemuCollectPCIAddress to qemuDomainCollectPCIAddress
qemuValidateDevicePCISlotsPIIX3 to qemuDomainValidateDevicePCISlotsPIIX3
qemuAssignDevicePCISlots to qemuDomainAssignDevicePCISlots
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Move the misplaced function from qemu_command.c to qemu_interface.c
since it's closer in functionality there and had less to do with building
the command line.

Rename function to qemuInterfaceBridgeConnect and modify callers.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Move the misplaced function from qemu_command.c to qemu_interface.c
since it's closer in functionality there and had less to do with building
the command line.

Rename function to qemuInterfaceDirectConnect and modify callers.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Currently, on hot unplug of PCI devices with VFIO driver for QEMU, libvirt is
trying to restore the host devices to it's previous value (basically a chown
on the previous user/group).

However for devices with VFIO driver, when the device is unbinded it is
removed from the /dev/vfio file system causing the restore label to fail.

The fix is to not restore the label for those PCI devices since they are going
to be teared down anyway.
Signed-off-by: NLudovic Beliveau <ludovic.beliveau@windriver.com>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Move the logic from virDomainDiskDefDstDuplicates into
virDomainDiskDefCheckDuplicateInfo so that we don't have to loop
multiple times through the array of disks. Since the original function
was called in qemuBuildDriveDevStr, it was actually called for every
single disk which was quite wasteful.

Additionally the target uniqueness check needed to be duplicated in
the disk hotplug case, since the disk was inserted into the domain
definition after the device string was formatted and thus
virDomainDiskDefDstDuplicates didn't do anything in that case.

We do the check on VM start, but the user could still hotplug a disk
with a conflicting serial or WWN. Reuse the checker function to fix the
issue.

Target uniqueness check was duplicated in all of the three workers
called from it. Extract it to the parent.

Remove the default case since all cases are covered.

We only support hotplugging SCSI controllers.
The USB and virtio-serial related code was never reachable because
this function was only called for VIR_DOMAIN_CONTROLLER_TYPE_SCSI
controllers.

This reverts commit ee0d97a7 and parts of commits 16db8d2e
and d6d54cd1.

This function calls qemuDomainAttachControllerDevice for SCSI
controllers and reports an error for all other controllers.

Move the error inside qemuDomainAttachControllerDevice and delete this
wrapper.

We increase the limit before plugging in a PCI hostdev or a memory
module because some memory might need to be locked due to eg. VFIO.

Of course we should do the opposite after unplugging a device: this
was already the case for memory modules, but not for PCI hostdevs.

Replace all uses of the qemuDomainRequiresMlock/virProcessSetMaxMemLock
combination with the equivalent qemuDomainAdjustMaxMemLock() call.

when appropriate, of course. If the config for a domain specifies boot
order with <boot dev='blah'/> elements, e.g.:

     <os>
       ...
       <boot dev='hd'/>
       <boot dev='network'/>
     </os>

Then the first disk device in the config will have ",bootindex=1"
appended to its qemu commandline -device options, and the first (and
*only* the first) network interface device will get ",bootindex=2".

However, if the first network interface device is a "hostdev" device
(an SRIOV Virtual Function (VF) being assigned to the domain with
vfio), then the bootindex option will *not* be appended. This happens
because the bootindex=n option corresponding to the order of "<boot
dev='network'/>" is added to the -device for the first network device
when network device commandline args are constructed, but if it's a
hostdev network device, its commandline arg is instead constructed in
the loop for hostdevs.

This patch fixes that omission by noticing (in bootHostdevNet) if the
first network device was a hostdev, and if so passing on the proper
bootindex to the commandline generator for hostdev devices - the
result is that ",bootindex=2" will be properly appended to the first
"network" device in the config even if it is really a hostdev
(including if it is assigned from a libvirt network pool). (note that
this is only the case if there is no <bootmenu enabled='yes'/> element
in the config ("-boot menu-on" in qemu) , since the two are mutually
exclusive - when the bootmenu is enabled, the individual per-device
bootindex options can't be used by qemu, and we revert to using "-boot
order=xyz" instead).

If a greater level of control over boot order is desired (e.g., more
than one network device should be tried, or a network device other
than the first one encountered in the config), then <boot
dev='network'/> in the <os> element should not be used; instead, the
individual device elements in the config should be given a "<boot
order='n'/>

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

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

Ta-da! Now that we know how to open a macvtap device multiple
times, we can finally enable the multiqueue feature. Everything
else is already prepared (e.g. command line generation) from the
previous iteration where the feature was implemented for
TUN/TAP devices.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

When a SCSI disk is hotplugged to a domain that does not have the required
SCSI controller already defined and loaded the following internal error occurs

error: Failed to attach device from scsi_disk.xml
error: internal error: Could not find scsi controller with index 0 required for device

Commit 0260506c added in method qemuBuildDriveDevStr a lookup of the controller
alias. The internal error occurs because in method qemuDomainAttachSCSIDisk
the automatic creation of the potentially missing SCSI controller occurs after
calling qemuBuildDriveDevStr.

This patch reverses the calling sequence.
Signed-off-by: NBoris Fiuczynski <fiuczy@linux.vnet.ibm.com>
Reviewed-by: NBjoern Walk <bwalk@linux.vnet.ibm.com>
Reviewed-by: NStefan Zimmermann <stzi@linux.vnet.ibm.com>

Change CGroup to Cgroup to match other functions in the file.

The function is used everywhere else to check whether the locked
memory limit should be set / updated, and it should be used here
as well.

Moreover, qemuDomainGetMlockLimitBytes() expects the hostdev to
have already been added to the domain definition, but we only do
that at the end of qemuDomainAttachHostPCIDevice(). Work around
the issue by adding the hostdev before adjusting the locked memory
limit and removing it immediately afterwards.

Aggregate the checks of the dimm device into the verification function
rather than having them in the formatter.

Add a function that will aggregate various checks related to memory
hotplug so that they aren't scattered accross various parts of the
code.

The -sdl and -net ...name=XXX arguments were both introduced
in QEMU 0.10, so the QEMU driver can assume they are always
available.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>