Commit Graph

24963 Commits

Author SHA1 Message Date
Laine Stump
bde3fe5718 news: Add "more PCIe less legacy PCI" to list of new features 2016-12-01 14:13:33 +01:00
Daniel P. Berrange
6e9607bd2a Refresh translations from zanata 2016-12-01 11:54:30 +00:00
Andrea Bolognani
d092ccc40f NEWS: Remove end-of-sentence period
None of the other sentences in the file ends with the period,
and we want to maintain a consistent style.
2016-12-01 12:23:08 +01:00
Eric Farman
655429a0d4 qemu: Prevent detaching SCSI controller used by hostdev
Consider the following XML snippets:

  $ cat scsicontroller.xml
      <controller type='scsi' model='virtio-scsi' index='0'/>
  $ cat scsihostdev.xml
      <hostdev mode='subsystem' type='scsi'>
        <source>
          <adapter name='scsi_host0'/>
          <address bus='0' target='8' unit='1074151456'/>
        </source>
      </hostdev>

If we create a guest that includes the contents of scsihostdev.xml,
but forget the virtio-scsi controller described in scsicontroller.xml,
one is silently created for us.  The same holds true when attaching
a hostdev before the matching virtio-scsi controller.
(See qemuDomainFindOrCreateSCSIDiskController for context.)

Detaching the hostdev, followed by the controller, works well and the
guest behaves appropriately.

If we detach the virtio-scsi controller device first, any associated
hostdevs are detached for us by the underlying virtio-scsi code (this
is fine, since the connection is broken).  But all is not well, as the
guest is unable to receive new virtio-scsi devices (the attach commands
succeed, but devices never appear within the guest), nor even be
shutdown, after this point.

While this is not libvirt's problem, we can prevent falling into this
scenario by checking if a controller is being used by any hostdev
devices.  The same is already done for disk elements today.

Applying this patch and then using the XML snippets from earlier:

  $ virsh detach-device guest_01 scsicontroller.xml
  error: Failed to detach device from scsicontroller.xml
  error: operation failed: device cannot be detached: device is busy

  $ virsh detach-device guest_01 scsihostdev.xml
  Device detached successfully

  $ virsh detach-device guest_01 scsicontroller.xml
  Device detached successfully

Signed-off-by: Eric Farman <farman@linux.vnet.ibm.com>
Reviewed-by: Bjoern Walk <bwalk@linux.vnet.ibm.com>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.vnet.ibm.com>
2016-11-30 17:16:47 -05:00
Laine Stump
70249927b7 qemu: assign VFIO devices to PCIe addresses when appropriate
Although nearly all host devices that are assigned to guests using
VFIO ("<hostdev>" devices in libvirt) are physically PCI Express
devices, until now libvirt's PCI address assignment has always
assigned them addresses on legacy PCI controllers in the guest, even
if the guest's machinetype has a PCIe root bus (e.g. q35 and
aarch64/virt).

This patch tries to assign them to an address on a PCIe controller
instead, when appropriate. First we do some preliminary checks that
might allow setting the flags without doing any extra work, and if
those conditions aren't met (and if libvirt is running privileged so
that it has proper permissions), we perform the (relatively) time
consuming task of reading the device's PCI config to see if it is an
Express device. If this is successful, the connect flags are set based
on the result, but if we aren't able to read the PCI config (most
likely due to the device not being present on the system at the time
of the check) we assume it is (or will be) an Express device, since
that is almost always the case anyway.
2016-11-30 15:41:57 -05:00
Laine Stump
9b0848d523 qemu: propagate virQEMUDriver object to qemuDomainDeviceCalculatePCIConnectFlags
If libvirtd is running unprivileged, it can open a device's PCI config
data in sysfs, but can only read the first 64 bytes. But as part of
determining whether a device is Express or legacy PCI,
qemuDomainDeviceCalculatePCIConnectFlags() will be updated in a future
patch to call virPCIDeviceIsPCIExpress(), which tries to read beyond
the first 64 bytes of the PCI config data and fails with an error log
if the read is unsuccessful.

In order to avoid creating a parallel "quiet" version of
virPCIDeviceIsPCIExpress(), this patch passes a virQEMUDriverPtr down
through all the call chains that initialize the
qemuDomainFillDevicePCIConnectFlagsIterData, and saves the driver
pointer with the rest of the iterdata so that it can be used by
qemuDomainDeviceCalculatePCIConnectFlags(). This pointer isn't used
yet, but will be used in an upcoming patch (that detects Express vs
legacy PCI for VFIO assigned devices) to examine driver->privileged.
2016-11-30 15:28:07 -05:00
Laine Stump
bfdc145153 util: new function virPCIDeviceGetConfigPath()
The path to the config file for a PCI device is conventiently stored
in a virPCIDevice object, but that object's contents aren't directly
visible outside of virpci.c, so we need to have an accessor function
for it if anyone needs to look at it.
2016-11-30 15:24:35 -05:00
Laine Stump
e026563f01 util: new function virFileLength()
This new function just calls fstat() (if provided with a valid fd) or
stat() (if fd is -1) and returns st_size (or -1 if there is an
error). We may decide we want this function to be more complex, and
handle things like block devices - this is a placeholder (that works)
for any more complicated function.
2016-11-30 15:18:57 -05:00
Nikos Mavrogiannopoulos
943ddcb712 virt-gnutls.m4: fixed check for gnutls_rnd and gnutls_cipher_encrypt 2016-11-30 14:29:46 +00:00
Boris Fiuczynski
9ee5bd0415 docs: improve release numbering rule for minor numbers
Adding first build of year minor number reset to 0.

Signed-off-by: Boris Fiuczynski <fiuczy@linux.vnet.ibm.com>
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
2016-11-30 15:28:58 +01:00
Jiri Denemark
4d8d7c02d7 cpu: Add alternative feature spellings to CPU map
We can't change feature names for compatibility reasons even if they
contain typos or other software uses different names for the same
features. By adding alternative spellings in our CPU map we at least
allow anyone to grep for them and find the correct libvirt's name.

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-11-30 14:19:40 +01:00
Jiri Denemark
29cabba3d7 cpu: Remove useless comments from CPU map
They didn't really help anything.

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-11-30 14:19:40 +01:00
Ján Tomko
2650d5e1f5 qemu: error out on USB ports out of range
My overly sophisticated address reservation code forgot
to add an error message for user-requested ports out of range.

https://bugzilla.redhat.com/show_bug.cgi?id=1399260
2016-11-30 10:59:01 +01:00
Ján Tomko
a101588921 tests: Fix USB ports in usb-redir-filter
This test case references ports 4 and 5 on the PIIX3 UHCI
controller which only has two.
2016-11-30 10:59:01 +01:00
Christian Ehrhardt
dffdac06c0 virt-aa-helper: fix parsing security labels by introducing VIR_DOMAIN_DEF_PARSE_SKIP_SECLABEL
When virt-aa-helper parses xml content it can fail on security labels.

It fails by requiring to parse active domain content on seclabels that
are not yet filled in.

Testcase with virt-aa-helper on a minimal xml:
 $ cat << EOF > /tmp/test.xml
<domain type='kvm'>
    <name>test-seclabel</name>
    <uuid>12345678-9abc-def1-2345-6789abcdef00</uuid>
    <memory unit='KiB'>1</memory>
    <os><type arch='x86_64'>hvm</type></os>
    <seclabel type='dynamic' model='apparmor' relabel='yes'/>
    <seclabel type='dynamic' model='dac' relabel='yes'/>
</domain>
EOF
 $ /usr/lib/libvirt/virt-aa-helper -d -r -p 0 \
   -u libvirt-12345678-9abc-def1-2345-6789abcdef00 < /tmp/test.xml

Current Result:
 virt-aa-helper: error: could not parse XML
 virt-aa-helper: error: could not get VM definition
Expected Result is a valid apparmor profile

Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com>
Signed-off-by: Guido Günther <agx@sigxcpu.org>
2016-11-30 08:15:57 +01:00
Jiri Denemark
bb738f9fcd docs: Update news
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-11-29 18:45:21 +01:00
Jiri Denemark
939c50c390 Consolidate documentation of virDomainMigrate{,ToURI}{,2,3}
Only the latest APIs are fully documented and the documentation of the
older variants (which are just limited versions of the new APIs anyway)
points to the newest APIs.

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-11-29 16:52:10 +01:00
Jiri Denemark
4e116e9dad Enhance documentation of virDomainMigrateFlags
The enhanced documentation of VIR_MIGRATE_RDMA_PIN_ALL fixes
https://bugzilla.redhat.com/show_bug.cgi?id=1373783

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-11-29 16:48:03 +01:00
Michal Privoznik
fd81eb7c48 daemon: Install virt-guest-shutdown.target properly
When trying to install libvirtd from sources I've noticed the
following failure:

/usr/bin/install: cannot stat 'virt-guest-shutdown.target': No such file or directory
Makefile:2792: recipe for target 'install-init-systemd' failed
make[3]: *** [install-init-systemd] Error 1
make[3]: *** Waiting for unfinished jobs....

The problem is that while other files around that location in
Makefile are firstly generated into the builddir and only after
that installed, virt-guest-shutdown.target file is not generated
at all and should be installed from the srcdir.

This was introduced in 01079727.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2016-11-29 16:31:52 +01:00
Jiri Denemark
0355de2e77 qemuProcessReconnect: Avoid relabeling images after migration
Restarting libvirtd on the source host at the end of migration when a
domain is already running on the destination would cause image labels to
be reset effectively killing the domain. Commit e8d0166e1d fixed similar
issue on the destination host, but kept the source always resetting the
labels, which was mostly correct except for the specific case handled by
this patch.

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

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-11-29 12:37:04 +01:00
Jiri Denemark
ee3ea86b37 qemu: Report tunnelled post-copy migration as unsupported
Post-copy migration needs bi-directional communication between the
source and the destination QEMU processes, which is not supported by
tunnelled migration.

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

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-11-29 12:31:25 +01:00
Chen Hanxiao
17879605fe storage_backend_rbd: check the return value of rados_conf_set
We had a lot of rados_conf_set and check works.
Use helper virStorageBackendRBDRADOSConfSet for them.

Signed-off-by: Chen Hanxiao <chenhanxiao@gmail.com>
2016-11-28 07:51:08 -05:00
Peter Krempa
b87a11340f qemu: capabilities: Don't partially reprope caps on process reconnect
Thanks to the complex capability caching code virQEMUCapsProbeQMP was
never called when we were starting a new qemu VM. On the other hand,
when we are reconnecting to the qemu process we reload the capability
list from the status XML file. This means that the flag preventing the
function being called was not set and thus we partially reprobed some of
the capabilities.

The recent addition of CPU hotplug clears the
QEMU_CAPS_QUERY_HOTPLUGGABLE_CPUS if the machine does not support it.
The partial re-probe on reconnect results into attempting to call the
unsupported command and then killing the VM.

Remove the partial reprobe and depend on the stored capabilities. If it
will be necessary to reprobe the capabilities in the future, we should
do a full reprobe rather than this partial one.
2016-11-28 10:02:36 +01:00
Jiri Denemark
a1adfb0f06 qemu: Add support for unavailable-features
QEMU 2.8.0 adds support for unavailable-features in
query-cpu-definitions reply. The unavailable-features array lists CPU
features which prevent a corresponding CPU model from being usable on
current host. It can only be used when all the unavailable features are
disabled. Empty array means the CPU model can be used without
modifications.

We can use unavailable-features for providing CPU model usability info
in domain capabilities XML:

    <domainCapabilities>
      ...
      <cpu>
        <mode name='host-passthrough' supported='yes'/>
        <mode name='host-model' supported='yes'>
          <model fallback='allow'>Skylake-Client</model>
          ...
        </mode>
        <mode name='custom' supported='yes'>
          <model usable='yes'>qemu64</model>
          <model usable='yes'>qemu32</model>
          <model usable='no'>phenom</model>
          <model usable='yes'>pentium3</model>
          <model usable='yes'>pentium2</model>
          <model usable='yes'>pentium</model>
          <model usable='yes'>n270</model>
          <model usable='yes'>kvm64</model>
          <model usable='yes'>kvm32</model>
          <model usable='yes'>coreduo</model>
          <model usable='yes'>core2duo</model>
          <model usable='no'>athlon</model>
          <model usable='yes'>Westmere</model>
          <model usable='yes'>Skylake-Client</model>
          ...
        </mode>
      </cpu>
      ...
    </domainCapabilities>

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-11-28 09:11:22 +01:00
Jiri Denemark
fe66e2fffe tests: Add QEMU 2.8.0 domain capabilities tests
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-11-28 09:11:22 +01:00
Jiri Denemark
047e7dd9ec tests: Add QEMU 2.8.0 capabilities data
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-11-28 09:11:15 +01:00
Jiri Denemark
0237f1ceb6 tests: Update capabilities for QEMU 2.7.0
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-11-25 21:00:19 +01:00
Jiri Denemark
0d2c389fad tests: Update capabilities for QEMU 2.6.0 (ppc64le)
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-11-25 20:59:57 +01:00
Jiri Denemark
f8b7b075b6 tests: Update capabilities for QEMU 2.6.0 (aarch64, GICv3)
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-11-25 20:59:34 +01:00
Jiri Denemark
73411a7ff1 qemu: Avoid reporting "host" as a supported CPU model
"host" CPU model is supported by a special host-passthrough CPU mode and
users is not allowed to specify this model directly with custom mode.
Thus we should not advertise "host" CPU model in domain capabilities.
This worked well on architectures for which libvirt provides a list of
supported CPU models in cpu_map.xml (since "host" is not in the list).
But we need to explicitly filter "host" model out for all other
architectures.

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-11-25 20:59:19 +01:00
Jiri Denemark
451dc19353 tests: Update capabilities for QEMU 2.6.0 (aarch64, GICv2)
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-11-25 20:34:27 +01:00
Jiri Denemark
e6bad6b63d tests: Update capabilities for QEMU 2.6.0
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-11-25 20:34:27 +01:00
Jiri Denemark
ca6b026303 tests: Update capabilities for QEMU 2.5.0
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-11-25 20:34:27 +01:00
Jiri Denemark
f9b754c29a tests: Update capabilities for QEMU 2.4.0
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-11-25 20:34:27 +01:00
Jiri Denemark
d5a6521013 tests: Update capabilities for QEMU 2.1.1
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-11-25 20:34:27 +01:00
Jiri Denemark
58c7620cdc tests: Update capabilities for QEMU 1.7.0
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-11-25 20:34:27 +01:00
Jiri Denemark
c0bf82b6ab tests: Update capabilities for QEMU 1.6.0
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-11-25 20:34:27 +01:00
Jiri Denemark
cbe19bf006 tests: Update capabilities for QEMU 1.5.3
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-11-25 20:34:27 +01:00
Jiri Denemark
58ed524966 tests: Update capabilities for QEMU 1.4.2
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-11-25 20:34:27 +01:00
Jiri Denemark
0ba2b9d33d tests: Update capabilities for QEMU 1.3.1
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-11-25 20:34:27 +01:00
Jiri Denemark
79b898e319 tests: Update capabilities for QEMU 1.2.2
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-11-25 20:34:27 +01:00
Jiri Denemark
7bf6f345e0 qemu: Probe CPU models for KVM and TCG
CPU models (and especially some additional details which we will start
probing for later) differ depending on the accelerator. Thus we need to
call query-cpu-definitions in both KVM and TCG mode to get all data we
want.

Tests in tests/domaincapstest.c are temporarily switched to TCG to avoid
having to squash even more stuff into this single patch. They will all
be switched back later in separate commits.

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-11-25 20:34:27 +01:00
Jiri Denemark
7c95619cb1 qemu: Introduce virQEMUCapsFormatCPUModels
This patch moves the CPU models formatting code from
virQEMUCapsFormatCache into a separate function.

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-11-25 20:34:26 +01:00
Jiri Denemark
1bdcd7a4ee qemu: Introduce virQEMUCapsLoadCPUModels
This patch moves the CPU models parsing code from virQEMUCapsLoadCache
into a separate function.

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-11-25 20:34:26 +01:00
Jiri Denemark
f9d57f2b57 qemu: Refresh caps in virQEMUCapsCacheLookupByArch
The function just returned cached capabilities without checking whether
they are still valid. We should check that and refresh the capabilities
to make sure we don't return stale data. In other words, we should do
what all other lookup functions do.

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-11-25 20:34:26 +01:00
Jiri Denemark
72e5aa4e1e qemu: Refactor virQEMUCapsCacheLookup
The function is made a little bit more readable and the code which
refreshes cached capabilities if they are not valid any more was moved
into a separate function (virQEMUCapsCacheValidate) so that it can be
reused in other places.

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-11-25 20:34:26 +01:00
Jiri Denemark
cd51b90fbf qemu: Don't return unusable virttype in domain capabilities
If a user asked for a KVM domain capabilities when KVM is not available,
we would happily return data we got when probing through TCG and
pretended they were relevant for KVM. Let's just report KVM is not
supported to avoid confusion.

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-11-25 20:34:26 +01:00
Jiri Denemark
8f55eef246 qemu: Use saner defaults for domain capabilities
When domain capabilities were introduced we did not have enough data to
decide whether KVM works on the host or not and thus working legacy/VFIO
device assignment was used as a witness. Now that we know whether KVM
was enabled when probing QEMU capabilities (and thus we know it's
working), we can use this knowledge to provide better default value for
virttype.

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-11-25 20:34:26 +01:00
Jiri Denemark
d87df9bd39 qemu: Discard caps cache when KVM availability changes
Since some may depend on the accelerator used when probing QEMU the
cache becomes invalid when KVM becomes available or if it is not
available anymore.

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-11-25 20:34:26 +01:00
Jiri Denemark
25ba9c31f5 qemu: Enable KVM when probing capabilities
CPU related capabilities may differ depending on accelerator used when
probing. Let's use KVM if available when probing QEMU and fall back to
TCG. The created capabilities already contain all we need to distinguish
whether KVM or TCG was used:

    - KVM was used when probing capabilities:
        QEMU_CAPS_KVM is set
        QEMU_CAPS_ENABLE_KVM is not set

    - TCG was used and QEMU supports KVM, but it failed (e.g., missing
      kernel module or wrong /dev/kvm permissions)
        QEMU_CAPS_KVM is not set
        QEMU_CAPS_ENABLE_KVM is set

    - KVM was not used and QEMU does not support it
        QEMU_CAPS_KVM is not set
        QEMU_CAPS_ENABLE_KVM is not set

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-11-25 20:34:26 +01:00