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>

As of QEMU 0.9.1 the -drive argument can be used to configure
all disks, so the QEMU driver can assume it is always available
and drop support for -hda/-cdrom/etc.

Many of the tests need updating because a great many were
running without CAPS_DRIVE set, so using the -hda legacy
syntax.

Fixing the tests uncovered a bug in the argv -> xml
convertor which failed to handle disk with if=floppy.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Check the return value of virCommandSetMaxMemLock when hotplugging VFIO
PCI hostdevs and reject the hotplug if the memory limit can't be set.

If mlock is required either due to use of VFIO hostdevs or due to the
fact that it's enabled it needs to be tweaked prior to adding new memory
or after removing a module. Add a helper to determine when it's
necessary and reuse it both on hotplug and hotunplug.

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

New function qemuDomainGetMlockLimitBytes will now handle the
calculation so that it unifies the logic to one place and allows later
reuse.

Adopt the same names used for virHostdevReAttach*Devices() for
consistency's sake and to make it easier to jump between the two.

No functional changes.

Adopt the same names used for virHostdevPrepare*Devices() for
consistency's sake and to make it easier to jump between the two.

No functional changes.

We have macros for both positive and negative string matching.
Therefore there is no need to use !STREQ or !STRNEQ. At the same
time as we are dropping this, new syntax-check rule is
introduced to make sure we won't introduce it again.
Signed-off-by: NIshmanpreet Kaur Khera <khera.ishman@gmail.com>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Extract the size determination into a separate function and reuse it
across the memory device alignment functions. Since later we will need
to decide the alignment size according to architecture let's pass def to
the functions.

Every single call to qemuDomainEventQueue() uses the following pattern:

    if (event)
        qemuDomainEventQueue(driver, event);

Let's move the check for valid event to qemuDomainEventQueue and
simplify all callers.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Commit 8125113c added code that should remove the disk backend if the
fronted hotplug failed for any reason. The code had a bug though as it
used the disk string for unplug rather than the backend alias. Fix the
code by pre-creating an alias string and using it instead of the disk
string. In cases where qemu does not support QEMU_CAPS_DEVICE, we ignore
the unplug of the backend since we can't really create an alias in that
case.

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

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

When attaching a disk, controller, or rng using an address type ccw
or s390, we need to ensure the support is provided by both the machine.os
and the emulator capabilities (corollary to unconditional setting when
address was not provided for the correct machine.os and emulator.

For an inactive guest, an addition followed by a start would cause the
startup to fail after qemu_command builds the command line and attempts
to start the guest. For an active guest, libvirtd would crash.

Rather than have different usages of STR function in order to determine
whether the domain is s390-ccw or s390-ccw-virtio, make a single API
which will check the machine.os prefix. Then use the function.

Adds a new interface type using UDP sockets, this seems only applicable
to QEMU but have edited tree-wide to support the new interface type.

The interface type required the addition of a "localaddr" (local
address), this then maps into the following xml and qemu call.

<interface type='udp'>
  <mac address='52:54:00:5c:67:56'/>
  <source address='127.0.0.1' port='11112'>
    <local address='127.0.0.1' port='22222'/>
  </source>
  <model type='virtio'/>
  <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/>
</interface>

QEMU call:
	-net socket,udp=127.0.0.1:11112,localaddr=127.0.0.1:22222

Notice the xml "local" entry becomes the "localaddr" for the qemu call.

reference:
http://lists.gnu.org/archive/html/qemu-devel/2011-11/msg00629.htmlSigned-off-by: NJonathan Toppins <jtoppins@cumulusnetworks.com>
Signed-off-by: NJán Tomko <jtomko@redhat.com>

https://bugzilla.redhat.com/show_bug.cgi?id=1226234#c3

If the qemu monitor fails to remove the memory from the guest for
any reason, the auditlog message will incorrectly use the current
actual memory (via virDomainDefGetMemoryActual) instead of the
value we were attempting to reduce to. The result is the 'new-mem'
and 'old-mem' values for the auditlog message would be identical.

This patch creates a local 'newmem' which accounts for the current
memory size minus the memory which is being removed. NB, for the
success case this results in the same value that would be returned
by virDomainDefGetMemoryActual without the need to do the math. This
follows the existing code which would subtract the size for cur_balloon.
Signed-off-by: NLuyao Huang <lhuang@redhat.com>

https://bugzilla.redhat.com/show_bug.cgi?id=1226234#c3

Prior to this patch, after successfully hot plugging memory
the audit log indicated that the update failed, e.g.:

type=VIRT_RESOURCE ... old-mem=1024000 new-mem=1548288 \
exe="/usr/sbin/libvirtd" hostname=? addr=? terminal=pts/2 res=failed

This patch will adjust where virDomainAuditMemory is called to
ensure the proper 'ret' value is used based on success or failure.

Additionally, the audit message should include the size of the
memory we were attempting to change to rather than the current
actual size. On failure to add, the message showed the same value
for old-mem and new-mem.

In order to do this, introduce a 'newmem' local which will compute
the new size based on the oldmem size plus the size of memory we
are about to add. NB: This would be the same as calling the
virDomainDefGetMemoryActual again on success, but avoids the
overhead of recalculating. Plus cur_balloon is already adjusted
by the same value, so this follows that.
Signed-off-by: NLuyao Huang <lhuang@redhat.com>

Commit aa2cc7 modified a previously unnecessary but innocuous check
for interface IP address during interface update incorrectly, causing
all attempted updates (e.g. changing link state) to interfaces of
type='ethernet' for QEMU to fail.

This patch fixes the issue by completely removing the check for IP
address, which is pointless since QEMU doesn't support setting
interface IP addresses from the domain interface XML anyway.
Signed-off-by: NVasiliy Tolstov <v.tolstov@selfip.ru>
Signed-off-by: NLaine Stump <laine@laine.org>

nwfilter uses iptables and ebtables, which only work properly on
tap-based network connections (*not* on macvtap, for example), but we
just ignore any <filterref> elements for other types of networks,
potentially giving users a false sense of security.

This patch checks the network type and fails/logs an error if any
domain <interface> has a <filterref> when the connection isn't using a
tap device.

This resolves:

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