Check the arability of the options with the current qemu binary,
add them in the varable opt if yes, print a message if not.
Signed-off-by: NMatthias Gatto <matthias.gatto@outscale.com>

Detect if the the qemu binary currently in use support the bps_max option,
If yes add it to the command, if not, just ignore the option.
We don't print error here, because the check for invalide arguments
has alerady been made in qemu_driver.c
Signed-off-by: NMatthias Gatto <matthias.gatto@outscale.com>

Add support for bps_max and friends in the driver part.
In the part checking if a qemu is running, check if the running binary
support bps_max, if not print an error message, if yes add it to
"info" variable
Signed-off-by: NMatthias Gatto <matthias.gatto@outscale.com>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Add the capability to detect if the qemu binary have the capability
to use bps_max and friends
Add a value in the enum virQEMUCapsFlags for the qemu capability.
Set it with virQEMUCapsSet if the binary suport bps_max and they friends.
Signed-off-by: NMatthias Gatto <matthias.gatto@outscale.com>

PowerISA allows processors to run VMs in binary compatibility ("compat")
mode supporting an older version of ISA. QEMU has recently added support to
explicitly denote a VM running in compatibility mode through commit 6d9412ea
& 8dfa3a5e85. Now, a "compat" mode VM can be run by invoking this qemu
commandline on a POWER8 host:  -cpu host,compat=power7.

This patch allows libvirt to exploit cpu mode 'host-model' to describe this
new mode for PowerKVM guests. For example, when a user wants to request a
power7 vm to run in compatibility mode on a Power8 host, this can be
described in XML as follows :

  <cpu mode='host-model'>
    <model>power7</model>
  </cpu>
Signed-off-by: NPrerna Saxena <prerna@linux.vnet.ibm.com>
Signed-off-by: NLi Zhang <zhlcindy@linux.vnet.ibm.com>
Signed-off-by: NPradipta Kr. Banerjee <bpradip@in.ibm.com>
Acked-by: NMichal Privoznik <mprivozn@redhat.com>

This adds support for PowerPC Little Endian architecture.,
and allows libvirt to spawn VMs based on 'ppc64le' architecture.
Signed-off-by: NPradipta Kr. Banerjee <bpradip@in.ibm.com>
Signed-off-by: NPrerna Saxena <prerna@linux.vnet.ibm.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

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

As of b6d4dad1 (1.2.5) libvirt keeps track if domain disks have been
frozen. However, this falls into that set of information which don't
survive domain restart. Therefore, we need to clear the flag upon some
state transitions. Moreover, once we clear the flag we must update the
status file too.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Extending the iothread disk support from pci to pci and ccw.
Signed-off-by: NBoris Fiuczynski <fiuczy@linux.vnet.ibm.com>
Reviewed-by: NViktor Mihajlovski <mihajlov@linux.vnet.ibm.com>
Reviewed-by: NChristian Borntraeger <borntraeger@de.ibm.com>

Finding the right type of disk should check for virtio as bus and
pci as device address type.
Signed-off-by: NBoris Fiuczynski <fiuczy@linux.vnet.ibm.com>
Reviewed-by: NViktor Mihajlovski <mihajlov@linux.vnet.ibm.com>

This is a reaction to Michal's fix [1] for non-NUMA systems that also
splits out conf/ out of util/ because libvirt_util shouldn't require
libvirt_conf if it is the other way around.  This particular use case
worked, but we're trying to avoid it as mentioned [2], many times.

The only functions from virnuma.c that needed numatune_conf were
virDomainNumatuneNodesetIsAvailable() and virNumaSetupMemoryPolicy().
The first one should be in numatune_conf as it works with
virDomainNumatune, the second one just needs nodeset and mode, both of
which can be passed without the need of numatune_conf.

Apart from fixing that, this patch also fixes recently added
code (between commits d2460f85^..5c851562) that doesn't support
non-contiguous nodesets.  It uses new function
virNumaNodesetIsAvailable(), which doesn't need a stub as it doesn't use
any libnuma functions, to check if every specified nodeset is available.

[1] https://www.redhat.com/archives/libvir-list/2014-November/msg00118.html
[2] http://www.redhat.com/archives/libvir-list/2011-June/msg01040.htmlSigned-off-by: NMartin Kletzander <mkletzan@redhat.com>

Since there was a valid note to patch 43b67f2e about the best spot to
check for bandwidth set call while having libvirt daemon run in session
mode, this patch reverts previous changes dealing with bandwith
(also reverts adding variable @cfg in qemuDomainGetNumaParameters which
 does not have any use at the moment, but getting and unreferencing
 driver's config) in qemu_driver.c and qemu_command.c. There will be
another patch in the series which introduces the fix itself.

==404== 232 bytes in 1 blocks are definitely lost in loss record 669 of 758
==404==    at 0x4C2B934: calloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==404==    by 0x52A2BF3: virAlloc (viralloc.c:144)
==404==    by 0x1D49AD70: qemuMigrationCookieAddStatistics (qemu_migration.c:554)
==404==    by 0x1D49AD70: qemuMigrationBakeCookie (qemu_migration.c:1228)
==404==    by 0x1D4A43B8: qemuMigrationFinish (qemu_migration.c:5002)
==404==    by 0x1D4C9339: qemuDomainMigrateFinish3Params (qemu_driver.c:11526)

Introduced by commit 5d6fb963

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

Users might want to update startupPolicy via the
virDomainUpdateDeviceFlags API too. This patch
implements the feature on config layer.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Domain memory elements such as max_balloon and cur_balloon are
implemented as 'unsigned long long', whereas the 'memory' element
in NUMA cells is implemented as 'unsigned int'.

Use the same data type (unsigned long long) for 'memory' element
in NUMA cells.
Signed-off-by: NPrerna Saxena <prerna@linux.vnet.ibm.com>

In qemuMigrationFinish mig->nbd can not be initialized by
qemuMigrationEatCookie without the QEMU_MIGRATION_COOKIE_NBD flag.
That causes qemuMigrationStopNBDServer to return early without
stopping the NBD server properly.
Signed-off-by: NWeiwei Li <nuonuoli@tencent.com>
Signed-off-by: NJán Tomko <jtomko@redhat.com>

There was no check for 'nodeset' attribute in numatune-related
elements.  This patch adds validation that any nodeset specified does
not exceed maximum host node.
Signed-off-by: NChen Fan <chen.fan.fnst@cn.fujitsu.com>

When one domain is being undefined and at the same time started, for
example, there is a possibility of a rare problem occuring.

 - Thread 1 does virDomainUndefine(), has the lock, checks that the
   domain is active and because it's not, calls
   virDomainObjListRemove().

 - Thread 2 does virDomainCreate() and tries to lock the domain.

 - Thread 1 needs to lock domain list in order to remove the domain from
   it, but must unlock domain first (proper order is to lock domain list
   first and the domain itself second).

 - Thread 2 grabs the lock, starts the domain and releases the lock.

 - Thread 1 grabs the lock and removes the domain from list.

With this patch:

 - qemuDomainRemoveInactive() creates a QEMU_JOB_MODIFY if that's
   possible, but since it must remove the domain from list either way,
   it continues even when starting the job failed.

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

Before:
  $ virsh blkiotune dummy --device-read-bytes-sec /dev/sda,-1
  error: Unable to change blkio parameters
  error: invalid argument: unable to parse blkio device
  'device_read_bytes_sec' '/dev/sda,-1'

After:
  $ virsh blkiotune dummy --device-read-bytes-sec /dev/sda,-1
  error: Unable to change blkio parameters
  error: invalid argument: invalid value '-1' for parameter
  'device_read_bytes_sec' of device '/dev/sda'

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

When daemon is killed right in the middle of probing a qemu binary for
its capabilities, the qemu process is left running.  Next time the
daemon is starting, it cannot start the probing qemu process because the
one that's already running does have the pidfile flock()'d.
Reported-by: NWang Yufei <james.wangyufei@huawei.com>
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

Particularly in qemuBuildNumaArgStr(), there was a need for the advice
due to memory backing, which needs to know the nodeset it will be pinned
to.  With newer qemu this caused the following error when starting
domain:

  error: internal error: Advice from numad is needed in case of
  automatic numa placement

even when starting perfectly valid domain, e.g.:

  ...
  <vcpu placement='auto'>4</vcpu>
  <numatune>
    <memory mode='strict' placement='auto'/>
  </numatune>
  <cpu>
    <numa>
      <cell id='0' cpus='0' memory='524288'/>
      <cell id='1' cpus='1' memory='524288'/>
    </numa>
  </cpu>
  ...

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

Hotplugging and hotunplugging char devices is only supported through
'-device' and the check for device capability should be independently.

Coverity also complains about 'tmpChr->info.alias' could be NULL and we
are dereferencing it but it somehow only in this case don't recognize
that the value is set by 'qemuAssignDeviceChrAlias' so it's clearly
false positive. Add sa_assert to make coverity happy.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

commit 3e1e16aa (Use a port from the
migration range for NBD as well) changed ndb port allocation from
remotePorts to migrationPorts, but did not change the port releasing
process, which makes an error when migrating several times (above 64):
error: internal error: Unable to find an unused port in range
'migration' (49152-49215)

https://bugzilla.redhat.com/show_bug.cgi?id=1159245Signed-off-by: NWeiwei Li <nuonuoli@tencent.com>
Signed-off-by: NJán Tomko <jtomko@redhat.com>

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

https://bugzilla.redhat.com/show_bug.cgi?id=1140981 reports that
the qemu-kvm shipped as part of RHEL 7.0 intentionally[1] cripples
block jobs by removing the 'block-stream' QMP command, while still
leaving 'block-job-cancel' as an unusable no-op.  Meanwhile, we
already had existing code that checked whether block jobs were
completely missing (such as qemu 0.15), old style (cancel is
synchronous, and all commands spelled with '_'), or new style
(cancel is asynchronous, and all commands spelled with '-'), and
used that three-way probe to give decent error messages.  At the
time that code was added, all existing qemu versions fell in one
of three buckets, and the code was using the presence of
'block-job-cancel' as the witness of which of the three buckets.
But now that RHEL qemu has shipped with intentionally crippled
'block-stream', we have a fourth bucket, which results in ugly
error messages when trying 'virsh blockpull':

 error: Requested operation is not valid: Command 'block-stream' is not found

In reality, the fourth bucket should be treated the same as the
first bucket (no block job support); we can do that by realizing
that no existing build of qemu has working block-stream while
lacking block-job-cancel, so it is easiest to change our witness
to the command that starts a job rather than ends one.  We still
act correctly regarding command spelling and whether cancel is
asynchronous.  And on crippled RHEL builds, we now get the desired:

 error: unsupported configuration: block jobs not supported with this qemu binary

[1] The intentional cripple is limited to qemu-kvm of RHEL; when using
qemu-kvm-rhev of RHEV, block job functionality is supported.  Don't ask
me to explain the "why" behind it all - I'm just dealing with fallout
from someone else's decision.

* src/qemu/qemu_capabilities.h (QEMU_CAPS_BLOCKJOB_SYNC): Tweak comment.
* src/qemu/qemu_capabilities.c (virQEMUCapsCommands): Look for stream
rather than cancel when determining the flavor of block jobs supported.
Signed-off-by: NEric Blake <eblake@redhat.com>

Now that all offenders have been cleaned, turn on a syntax-check
rule to prevent future offenders.

* cfg.mk (sc_prohibit_static_zero_init): New rule.
* src/qemu/qemu_driver.c (qemuDomainBlockJobImpl): Avoid false
positive.
Signed-off-by: NEric Blake <eblake@redhat.com>

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

As part of attach processing, assign the device aliases by calling
qemuAssignDeviceAliases during qemuDomainQemuAttach once all the devices
are found after the qemuParseCommandLinePid processing.

This will alleviate a symptom that caused a libvirtd crash during an
attempted device detach.

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

If the QEMU_CAPS_DEVICE is set, then ensure the host device alias has
been properly set before making the calls to detach the device

If the QEMU_CAPS_DEVICE is set, then ensure the chr device alias has
been properly set before making the calls to detach the device

If the QEMU_CAPS_DEVICE is set, then ensure the host device alias has
been properly set before making the calls to detach the device

If the QEMU_CAPS_DEVICE is set, then ensure the disk device alias has
been properly set in prior to making the calls to detach the device.

In qemuDomainDetachControllerDevice if the info.alias already exists
a call to qemuAssignDeviceControllerAlias would overwrite the existing
so avoid this possibility.

Not every error message from qemu-ga has to have the 'class' field
filled out. For instance, I've seen this error message lately:

  qemuAgentCheckError:1047 : unable to execute QEMU agent command \
  {"execute":"guest-set-time"}: \
  {"error":{"desc":"Invalid parameter type, expected: integer"}}

However, this got translated into rather generic error message:

  internal error: unable to execute QEMU agent command
  'guest-set-time': unknown QEMU command error

So we've dropped better error message in favor of a generic one.
This is due to our code which expects 'class' which is not
present here.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

This patch adds functionality to processNicRxFilterChangedEvent().
The old and new multicast lists are compared and the filters in
the macvtap are programmed to match the guest's filters.
Signed-off-by: NTony Krowiak <akrowiak@linux.vnet.ibm.com>

https://bugzilla.redhat.com/show_bug.cgi?id=956506 documents that
given a domain where an internal snapshot parent has an external
snapshot child, we lacked a safety check when trying to use the
--children-only option to snapshot-delete:

$ virsh start dom
$ virsh snapshot-create-as dom internal
$ virsh snapshot-create-as dom external --disk-only
$ virsh snapshot-delete dom external
error: Failed to delete snapshot external
error: unsupported configuration: deletion of 1 external disk snapshots not supported yet
$ virsh snapshot-delete dom internal --children
error: Failed to delete snapshot internal
error: unsupported configuration: deletion of 1 external disk snapshots not supported yet
$ virsh snapshot-delete dom internal --children-only
Domain snapshot internal children deleted

While I'd still like to see patches that actually do proper external
snapshot deletion, we should at least fix the inconsistency in the
meantime.  With this patch:

$ virsh snapshot-delete dom internal --children-only
error: Failed to delete snapshot internal
error: unsupported configuration: deletion of 1 external disk snapshots not supported yet

* src/qemu/qemu_driver.c (qemuDomainSnapshotDelete): Fix condition.
Signed-off-by: NEric Blake <eblake@redhat.com>

To prepare for introducing a single global driver, rename the
virDriver struct to virHypervisorDriver and the registration
API to virRegisterHypervisorDriver()

Tuning NUMA or network interface parameters requires root
privileges to manage cgroups. Thus an attempt to set some of these
parameters in session mode on a running domain should be invalid
followed by an error. An example might be memory tuning which raises
an error in such case.

The following behavior in session mode will be present after applying
this patch:

  Tuning  |      SET      |   GET  |
----------|---------------|--------|
NUMA      | shut off only | always |
Memory    |     never     | never  |
Interface |     never     | always |

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

Also consider whitespace only strings returned from the hook as empty
result.

The documentation for the restore hook states that returning an empty
XML is equivalent with copying the input. There was a bug in the code
checking the returned string by checking the string instead of the
contents. Use the new helper to check if the string is empty.

Commit 4882618e added the code that
requests driver cfg, but forgot to unref it.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

virt-manager on Fedora sets up i686 hosts with "/usr/bin/qemu-kvm" emulator,
which in turn unconditionally execs qemu-system-x86_64 querying capabilities
then fails:

Error launching details: invalid argument: architecture from emulator 'x86_64' doesn't match given architecture 'i686'

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/engine.py", line 748, in _show_vm_helper
    details = self._get_details_dialog(uri, vm.get_connkey())
  File "/usr/share/virt-manager/virtManager/engine.py", line 726, in _get_details_dialog
    obj = vmmDetails(conn.get_vm(connkey))
  File "/usr/share/virt-manager/virtManager/details.py", line 399, in __init__
    self.init_details()
  File "/usr/share/virt-manager/virtManager/details.py", line 784, in init_details
    domcaps = self.vm.get_domain_capabilities()
  File "/usr/share/virt-manager/virtManager/domain.py", line 518, in get_domain_capabilities
    self.get_xmlobj().os.machine, self.get_xmlobj().type)
  File "/usr/lib/python2.7/site-packages/libvirt.py", line 3492, in getDomainCapabilities
    if ret is None: raise libvirtError ('virConnectGetDomainCapabilities() failed', conn=self)
libvirtError: invalid argument: architecture from emulator 'x86_64' doesn't match given architecture 'i686'

Journal:

Oct 16 21:08:26 goatlord.localdomain libvirtd[1530]: invalid argument: architecture from emulator 'x86_64' doesn't match given architecture 'i686'