If user defines a virtio channel with UNIX socket backend and doesn't
care about the path for the socket (e.g. qemu-agent channel), we still
generate it into the persistent XML.  Moreover when then user renames
the domain, due to its persistent socket path saved into the per-domain
directory, it will not start.  So let's forget about old generated paths
and also stop putting them into the persistent definition.

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

Just recently, qemu forbade specifying format for sourceless
disks (qemu commit 39c4ae941ed992a3bb5). It kind of makes sense.
If there's no file to open, why specify its format. Anyway, I
have a domain like this:

    <disk type='file' device='cdrom'>
      <driver name='qemu' type='raw'/>
      <target dev='hda' bus='ide'/>
      <readonly/>
      <address type='drive' controller='0' bus='0' target='0' unit='0'/>
    </disk>

and obviously I am unable to start it. Therefore, a fix on our
side is needed too.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

For completeness, use the VIR_TRISTATE_SWITCH_ABSENT for data.file.append
comparisons. Commit ids '70ffa02f' and '53a15aed' just went with the non
zero comparison.

By default, QEMU truncates serial file on open. Sometimes, it could be weird -
for example, when we are trying to investigate some event, which occured several
restarts ago. This patch adds an ability to preserve previous content.
Signed-off-by: NDmitry Mishin <dim@virtuozzo.com>

MemLock is already used in other modules and, while still an
abbreviation, is not ambiguous.

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>

For the multiqueue on macvtaps we are going to need to open
the device multiple times. Currently, this is not supported.
Rework the function, so that upper layers can be reworked too.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

So yet again one of integer arguments that we use as a boolean.
Since the argument count of the function is unbearably long
enough, lets turn those booleans into flags.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Finalize the refactor by adding the 'virDomainDefGetVCpusMax' getter and
reusing it accross libvirt.

The new helper will simplify checking whether the domain config contains
inactive vCPUs.

To support further refactors replace all write access to def->maxvcpus
with a accessor function.

<input type='passthrough' bus='virtio'>
  <source evdev='/dev/input/event1234'/>
</input>

results in:

-device virtio-input-host-pci,id=input0,evdev=/dev/input/event1234

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

Add xml for the new virtio-input-host-pci device:
<input type='passthrough' bus='virtio'>
  <source evdev='/dev/input/event1234'/>
</input>

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

Add support for these qemu devices:
virtio-mouse-{pci,device}
virtio-keyboard-{pci,device}
virtio-tablet-{pci,device}

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

Check if virtio-gpu provides virgl option, and add qemu command line
formatter.

It is enabled with the existing accel3d attribute:
<model type='virtio' heads='1'>
 <acceleration accel3d='yes'/>
</model>
Signed-off-by: NMarc-André Lureau <marcandre.lureau@gmail.com>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

qemu 2.5 provides virtio video device.  It can be used with -device
virtio-vga for primary devices, or -device virtio-gpu for non-vga
devices. However, only the primary device (VGA) is supported with this
patch.

Reference:
https://bugzilla.redhat.com/show_bug.cgi?id=1195176Signed-off-by: NMarc-André Lureau <marcandre.lureau@gmail.com>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

'model' attribute was added to a panic device but only one panic
device is allowed. This patch changes panic device presence
from 'optional' to 'zeroOrMore'.

Panic device type used depends on 'model' attribute.

If no model is specified then device type depends on hypervisor
and guest arch. 'pseries' model is used for pSeries guest and
'isa' model is used in other cases.

XML:
<devices>
  <panic model='hyperv'/>
</devices>

QEMU command line:
qemu -cpu <cpu_model>,hv_crash

like I440FX by moving the condition into qemuDomainMachineHasBuiltinIDE
and adding more machines.

Reference: http://bugs.debian.org/805189

This removes a duplication of the logic used to decide whether
the memory locking limit should be set.

Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Make callers of qemuBuildCommandLine responsible for providing the URI
which should be passed as a parameter for -incoming.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Move the code from qemuBuildCommandLine into dedicated functions.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Prepare the command line generator for the possibility that in some
configurations the target NUMA node info will be missing.

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.

Since we already make sure before that the domain configuration is
valid we may execute it always at the cost of doing 0 iterations of the
for loop.

This patch will simplify later refactor as it will avoid whitespace
changes.

Make the function usable so that -1 can be passed to it as cell ID so
that we can later enable memory hotplug on non-NUMA guests for certain
architectures.

The previous commit

  commit 4e8993a2
  Author: Daniel P. Berrange <berrange@redhat.com>
  Date:   Mon Nov 9 16:20:08 2015 +0000

    qemu: assume various QEMU 0.10 features are always available

Added broken handling of -sdl. Instead of duplicating existing
SDL handling code, just ensure it is invoked in the right
scenarios.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

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.10.0 the -vga argument was introduced, so the
QEMU driver can assume it is always available.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

As of QEMU 0.10.0 the -drive format= parameter was added,
so the QEMU driver can assume it is always available.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

As of QEMU 0.10.0, the -drive cache option stopped using
the on/off value names, so the QEMU driver can assume
use of the new value names.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Since we require QEMU 0.12.0, we can assume that QEMU supports
all of the fd, tcp, unix and exec migration protocols.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

We have twice previously attempted to remove Xenner
support

  commit de9be0ab
  Author: Daniel P. Berrange <berrange@redhat.com>
  Date:   Wed Aug 22 17:29:01 2012 +0100

    Remove xenner support

  commit 92572c3d
  Author: Ján Tomko <jtomko@redhat.com>
  Date:   Wed Feb 18 16:33:50 2015 +0100

    Remove code handling the QEMU_CAPS_DOMID capability

This change really does remove the last traces of it
in the capabilities handling code
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

The -uuid arg was added in QEMU 0.10.0, so the QEMU driver can
assume it is always available.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>