- Devel - libvirt List Archives

[libvirt] ARMv7 guest PCI support broken in 3.0.0 onwards
by Daniel P. Berrange 25 Mar '17

25 Mar '17

$ cat arm.xml <domain type="qemu"> <name>f22-arm32</name> <uuid>a6bc14fb-585b-40b0-a15b-5e19f26079ba</uuid> <memory>1048576</memory> <currentMemory>1048576</currentMemory> <vcpu>1</vcpu> <os> <type arch="armv7l" machine="virt">hvm</type> <boot dev="hd"/> </os> <clock offset="utc"/> <on_poweroff>destroy</on_poweroff> <on_reboot>restart</on_reboot> <on_crash>restart</on_crash> <devices> <emulator>/usr/bin/qemu-system-arm</emulator> <disk type="file" device="disk"> <driver name="qemu" type="qcow2"/> <source file="/home/berrange/VirtualMachines/demo.qcow2"/> <target dev="sda" bus="scsi"/> </disk> <controller type="scsi" index="0" model="virtio-scsi"/> <interface type="user"> <mac address="52:54:00:87:d4:c0"/> <model type="virtio"/> </interface> <console type="pty"/> </devices> </domain> $ virsh define arm.xml Domain f22-arm32 defined from arm.xml $ virsh start f22-arm32 error: Failed to start domain f22-arm32 error: internal error: qemu unexpectedly closed the monitor: 2017-02-15T09:24:03.967648Z qemu-system-arm: -device ioh3420,port=0x8,chassis=1,id=pci.1,bus=pcie.0,multifunction=on,addr=0x1: MSI is not supported by interrupt controller 2017-02-15T09:24:03.968154Z qemu-system-arm: -device ioh3420,port=0x8,chassis=1,id=pci.1,bus=pcie.0,multifunction=on,addr=0x1: Device initialization failed I've not bisected it other than to find it works in 2.5.0 and is broken in 3.0.0 Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://entangle-photo.org -o- http://search.cpan.org/~danberr/ :|

3 7

[libvirt] [PATCH 0/3] Report block threshold in bulk stats
by Peter Krempa 25 Mar '17

25 Mar '17

This is a follow up to: https://www.redhat.com/archives/libvir-list/2017-March/msg00650.html so that management apps can query the current value. The series needs to be applied on top of the block threshold series. For convenience I've pushed it to the same remote repository as the original series. You can fetch it here: git fetch git://pipo.sk/pipo/libvirt.git block-threshold-1 Peter Krempa (3): util: json: Make function to free JSON values in virHash universal qemu: block: Add code to fetch block node data by node name qemu: stats: Display the block threshold size in bulk stats src/libvirt-domain.c | 4 ++++ src/libvirt_private.syms | 1 + src/qemu/qemu_block.c | 46 +++++++++++++++++++++++++++++++++++++++ src/qemu/qemu_block.h | 3 +++ src/qemu/qemu_driver.c | 51 +++++++++++++++++++++++++++++++++++++++++--- src/qemu/qemu_monitor_json.c | 10 +-------- src/util/virjson.c | 8 +++++++ src/util/virjson.h | 1 + tools/virsh.pod | 3 +++ 9 files changed, 115 insertions(+), 12 deletions(-) -- 2.12.0

2 8

[libvirt] [PATCH v2] qemu: snapshot: Forbid internal snapshots with pflash firmware
by Peter Krempa 25 Mar '17

25 Mar '17

If the variable store (<nvram>) file is raw qemu can't do a snapshot of it and thus the snapshot would be incomplete. QEMU does no reject such snapshot. Additionally allowing to use a qcow2 variable store backing file would solve this issue but then it would become eligible to become target of the memory dump. Offline internal snapshot would be incomplete too with either storage format since libvirt does not handle the pflash file in this case. Forbid such snapshot so that we can avoid problems. --- Notes: v2: - changed error code to OPERATION_UNSUPPORTED (from CONFIG_UNSUPPORTED) - dropped mention of QEMU from the error message - dropped mentions of OVMF or the firmware itself altoghether, the culprit is the pflash device regardless of the software it contains - mentioned all the stuff in the commit message and comment We also will need to introduce a way to snapshot the pflash for external snapshots which is currently impossible as well, but fortunately does not have inherent drawbacks as internal snapshots. src/qemu/qemu_driver.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index 676295208..202d190b3 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -13873,6 +13873,16 @@ qemuDomainSnapshotPrepare(virConnectPtr conn, goto cleanup; } + /* Internal snapshots don't work with VMs with OVMF loader since qemu does + * not snapshot the variable store */ + if (found_internal && + vm->def->os.loader->type == VIR_DOMAIN_LOADER_TYPE_PFLASH) { + virReportError(VIR_ERR_OPERATION_UNSUPPORTED, "%s", + _("internal snapshots of a VM with pflash based " + "firmware are not supported")); + goto cleanup; + } + /* Alter flags to let later users know what we learned. */ if (external && !active) *flags |= VIR_DOMAIN_SNAPSHOT_CREATE_DISK_ONLY; -- 2.12.1

3 10

[libvirt] [PATCH v3 0/3] qemu: Forbid internal snapshots with pflash-based firmware (OVMF)
by Peter Krempa 24 Mar '17

24 Mar '17

Patches 1 and 2 are new in the series and add an option to override the check so that users can use the feature despite being unsafe. See patch 3/3 for clarification of the motiovation to do this. Peter Krempa (3): virerror: Introduce VIR_ERR_OPERATION_UNSAFE snapshot: Introduce flag VIR_DOMAIN_SNAPSHOT_CREATE_UNSAFE qemu: snapshot: Forbid internal snapshots with pflash firmware include/libvirt/libvirt-domain-snapshot.h | 3 +++ include/libvirt/virterror.h | 1 + src/qemu/qemu_driver.c | 18 +++++++++++++++++- src/util/virerror.c | 5 +++++ tools/virsh-snapshot.c | 6 ++++++ tools/virsh.pod | 6 +++++- 6 files changed, 37 insertions(+), 2 deletions(-) -- 2.12.1

1 4

[libvirt] [PATCH] Revert "qemu: forbid migration with an IOMMU device"
by Ján Tomko 24 Mar '17

24 Mar '17

This reverts commit b7118623ad5a8e6ea75d693881c08873eefa3e28. Migration was implemented by QEMU commit: commit 8cdcf3c1e58d04b6811956d7608efeb66c42d719 Author: Peter Xu <peterx(a)redhat.com> Date: Fri Jan 6 12:06:13 2017 +0800 intel_iommu: allow migration https://bugzilla.redhat.com/show_bug.cgi?id=1433994 --- src/qemu/qemu_migration.c | 6 ------ 1 file changed, 6 deletions(-) diff --git a/src/qemu/qemu_migration.c b/src/qemu/qemu_migration.c index 15ed830..f5711bc 100644 --- a/src/qemu/qemu_migration.c +++ b/src/qemu/qemu_migration.c @@ -2359,12 +2359,6 @@ qemuMigrationIsAllowed(virQEMUDriverPtr driver, _("migration with shmem device is not supported")); return false; } - - if (vm->def->iommu) { - virReportError(VIR_ERR_OPERATION_INVALID, "%s", - _("migration with iommu device is not supported")); - return false; - } } return true; -- 2.10.2

2 2

[libvirt] [PATCH] network: only check for IPv6 RA routes when the network has an IPv6 address
by Laine Stump 24 Mar '17

24 Mar '17

commit 00d28a78 added a check to see if there were any IPv6 routes added by RA (Router Advertisement) via an interface that had accept_ra set to something other than "2". The check was being done unconditionally, but it's only relevant if IPv6 forwarding is going to be turned on, and that will only happen if the network has an IPv6 address. --- src/network/bridge_driver.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/src/network/bridge_driver.c b/src/network/bridge_driver.c index 0336ece..10e8f0e 100644 --- a/src/network/bridge_driver.c +++ b/src/network/bridge_driver.c @@ -2391,10 +2391,9 @@ networkStartNetworkVirtual(virNetworkDriverStatePtr driver, /* If forward.type != NONE, turn on global IP forwarding */ if (network->def->forward.type != VIR_NETWORK_FORWARD_NONE) { - if (!virNetDevIPCheckIPv6Forwarding()) + if (v6present && !virNetDevIPCheckIPv6Forwarding()) goto err3; /* Precise error message already provided */ - if (networkEnableIPForwarding(v4present, v6present) < 0) { virReportSystemError(errno, "%s", _("failed to enable IP forwarding")); -- 2.9.3

2 1

[libvirt] [PATCH 00/19] Fix saving/setting/restoring SR-IOV VF MAC address
by Laine Stump 24 Mar '17

24 Mar '17

There are multiple bugs filed against both libvirt and the kernel related to incorrect restoration of MAC addresses for SR-IOV VFs, both when used via VFIO device assignment and when used for macvtap passthrough mode https://bugzilla.redhat.com/1415609 - libvirt https://bugzilla.redhat.com/1341248 - kernel (igb) https://bugzilla.redhat.com/1415609 - kernel (ixgbe) https://bugzilla.redhat.com/1302166 - kernel (mlx, fixed) Beyond that, there are other problems with incorrect setting and restoration of VF MAC addresses that don't have their own bug reports (although they may be partially described in the comments of the BZes mentioned above). This patch series attempts (and I hope succeeds!) to fix all of these problems, which can be summarized in these three points: * The VF's own MAC address was not being set prior to using it for macvtap passthrough mode. Instead, due to serious misconception on my part, the "admin MAC" for that VF was set in the PF. The problem is that the admin MAC isn't put into use on the VF immediately; rather it is unused until the next time the VF driver is initialized (on either the host or in a guest) so setting it had no practical effect, meaning that the macvtap device's MAC didn't match the MAC of the VF device it was attached to - this meant that traffic wouldn't pass unless the device was in promiscuous mode (and apparently it was back when the code was changed to behave this way?). * The VF's own MAC address was never restored after it had been used (for both VFIO device assignment and for macvtap passthrough mode). Only the "admin MAC" address (which, again, won't take effect until/unless the VF driver is reloaded/reinitialized) was restored. * If the original admin MAC was 00:00:00:00:00:00, libvirt would save that, then attempt to restore it when the guest was finished with the device, but for some/many SRIOV-capable net drivers, an all 0 MAC is not allowed to be set (even though that is its initial value). This would result in the MAC not being changed (of course, since this is the admin MAC, that didn't actually matter, but the combination of the error message and the VF's own MAC still being set to the value used by the guest, users mistakenly believed this was the source of networking problems (e.g. when the guest moved to another host, but the old host still had an interface showing its MAC address). There are lots of details in the patches. 01 - 07 just clean up and slightly modify some existing utility functions. 08 - 11 define some functions to save/restore netdev MAC/vlan settings, and 12-14 change the existing setup/teardown code for macvtap and hostdev to use the new functions, then 15 and 17-19 modify their behavior further, while 16 just removes functions that are no longer used. In the end, the VF's own MAC *and* admin MAC are saved for all SRIOV VFs when we begin using a VF, and the VF's MAC is restored when finished. Since the admin MAC doesn't actually have any immediate practical effect, we don't concern ourselves with assuring it is restored in all cases (in particular, when use use the VF for VFIO assignment, we only restore the VF's MAC, but not the admin MAC during teardown, and when using the VF for macvtap passthrough we avoid restoring the admin MAC because that would unnecessarily turn on the "administratively set" flag in the PF driver (described in the commit log for one of these patches). I might decide to fix the former later, but for now it just unnecessarily complicates the code for no real gain). Laine Stump (19): util: permit querying a VF MAC address or VLAN tag by itself util: remove unused args from virNetDevSetVfConfig() util: use cleanup label consistently in virHostdevNetConfigReplace() util: eliminate useless local variable util: make virMacAddrParse more versatile util: change virPCIGetNetName() to not return error if device has no net name util: make virPCIGetDeviceAddressFromSysfsLink() public util: new function virPCIDeviceRebind() util: new internal function to permit silent failure of virNetDevSetMAC() util: new function virNetDevPFGetVF() util: new functions virNetDev(Save|Read|Set)NetConfig() util: use new virNetDev*NetConfig() functions for macvtap setup/teardown util: use new virNetDev*NetConfig() functions for hostdev setup/teardown util: replace virHostdevNetConfigReplace with ...(Save|Set)NetConfig() util: save hostdev network device config before unbinding from host driver util: after hostdev assignment, restore VF MAC address via setting admin MAC util: remove unused functions from virnetdev.c util: if setting admin MAC to 00:00:00:00:00:00 fails, try 02:00:00:00:00:00 util: try *really* hard to set the MAC address of an SRIOV VF src/libvirt_private.syms | 10 +- src/util/virhostdev.c | 171 ++++++-- src/util/virmacaddr.c | 2 +- src/util/virnetdev.c | 937 +++++++++++++++++++++++++++++++------------- src/util/virnetdev.h | 25 ++ src/util/virnetdevmacvlan.c | 45 ++- src/util/virpci.c | 65 ++- src/util/virpci.h | 4 + 8 files changed, 933 insertions(+), 326 deletions(-) -- 2.9.3

3 36

[libvirt] [PATCH] qemu: Fix typo in __QEMU_CAPSPRIV_H_ALLOW__
by Andrea Bolognani 23 Mar '17

23 Mar '17

--- Pushed as trivial. src/qemu/qemu_capabilities.c | 2 +- src/qemu/qemu_capspriv.h | 2 +- tests/cputest.c | 4 ++-- tests/qemucapabilitiestest.c | 2 +- tests/qemucapsprobe.c | 2 +- tests/qemucpumock.c | 4 ++-- tests/qemuxml2argvtest.c | 4 ++-- tests/testutilsqemu.c | 2 +- 8 files changed, 11 insertions(+), 11 deletions(-) diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c index 60ed31e..8bd39c7 100644 --- a/src/qemu/qemu_capabilities.c +++ b/src/qemu/qemu_capabilities.c @@ -44,7 +44,7 @@ #include "virstring.h" #include "qemu_hostdev.h" #include "qemu_domain.h" -#define __QEMU_CAPSRIV_H_ALLOW__ +#define __QEMU_CAPSPRIV_H_ALLOW__ #include "qemu_capspriv.h" #include <fcntl.h> diff --git a/src/qemu/qemu_capspriv.h b/src/qemu/qemu_capspriv.h index ee29b8b..61ccd45 100644 --- a/src/qemu/qemu_capspriv.h +++ b/src/qemu/qemu_capspriv.h @@ -21,7 +21,7 @@ * Author: Pavel Fedin <p.fedin(a)samsung.com> */ -#ifndef __QEMU_CAPSRIV_H_ALLOW__ +#ifndef __QEMU_CAPSPRIV_H_ALLOW__ # error "qemu_capspriv.h may only be included by qemu_capabilities.c or test suites" #endif diff --git a/tests/cputest.c b/tests/cputest.c index 5e205c5..917b1a3 100644 --- a/tests/cputest.c +++ b/tests/cputest.c @@ -43,9 +43,9 @@ #if WITH_QEMU && WITH_YAJL # include "testutilsqemu.h" # include "qemumonitortestutils.h" -# define __QEMU_CAPSRIV_H_ALLOW__ +# define __QEMU_CAPSPRIV_H_ALLOW__ # include "qemu/qemu_capspriv.h" -# undef __QEMU_CAPSRIV_H_ALLOW__ +# undef __QEMU_CAPSPRIV_H_ALLOW__ #endif #define VIR_FROM_THIS VIR_FROM_CPU diff --git a/tests/qemucapabilitiestest.c b/tests/qemucapabilitiestest.c index 2152e80..2918ff4 100644 --- a/tests/qemucapabilitiestest.c +++ b/tests/qemucapabilitiestest.c @@ -22,7 +22,7 @@ #include "testutils.h" #include "testutilsqemu.h" #include "qemumonitortestutils.h" -#define __QEMU_CAPSRIV_H_ALLOW__ +#define __QEMU_CAPSPRIV_H_ALLOW__ #include "qemu/qemu_capspriv.h" #define VIR_FROM_THIS VIR_FROM_NONE diff --git a/tests/qemucapsprobe.c b/tests/qemucapsprobe.c index fb9f3e9..561c5d7 100644 --- a/tests/qemucapsprobe.c +++ b/tests/qemucapsprobe.c @@ -24,7 +24,7 @@ #include "internal.h" #include "virthread.h" #include "qemu/qemu_capabilities.h" -#define __QEMU_CAPSRIV_H_ALLOW__ 1 +#define __QEMU_CAPSPRIV_H_ALLOW__ 1 #include "qemu/qemu_capspriv.h" #define VIR_FROM_THIS VIR_FROM_NONE diff --git a/tests/qemucpumock.c b/tests/qemucpumock.c index 2c1d24d..f0a113f 100644 --- a/tests/qemucpumock.c +++ b/tests/qemucpumock.c @@ -18,9 +18,9 @@ #include "internal.h" #include "qemu/qemu_capabilities.h" -#define __QEMU_CAPSRIV_H_ALLOW__ +#define __QEMU_CAPSPRIV_H_ALLOW__ #include "qemu/qemu_capspriv.h" -#undef __QEMU_CAPSRIV_H_ALLOW__ +#undef __QEMU_CAPSPRIV_H_ALLOW__ virCPUDefPtr diff --git a/tests/qemuxml2argvtest.c b/tests/qemuxml2argvtest.c index 64e14af..ec73ac7 100644 --- a/tests/qemuxml2argvtest.c +++ b/tests/qemuxml2argvtest.c @@ -27,9 +27,9 @@ # include "storage/storage_driver.h" # include "virmock.h" -# define __QEMU_CAPSRIV_H_ALLOW__ +# define __QEMU_CAPSPRIV_H_ALLOW__ # include "qemu/qemu_capspriv.h" -# undef __QEMU_CAPSRIV_H_ALLOW__ +# undef __QEMU_CAPSPRIV_H_ALLOW__ # include "testutilsqemu.h" diff --git a/tests/testutilsqemu.c b/tests/testutilsqemu.c index 026b73e..4cc482d 100644 --- a/tests/testutilsqemu.c +++ b/tests/testutilsqemu.c @@ -8,7 +8,7 @@ # include "cpu_conf.h" # include "qemu/qemu_driver.h" # include "qemu/qemu_domain.h" -# define __QEMU_CAPSRIV_H_ALLOW__ +# define __QEMU_CAPSPRIV_H_ALLOW__ # include "qemu/qemu_capspriv.h" # include "virstring.h" -- 2.7.4

1 0

[libvirt] [PATCH] qemu: forbid migration with an IOMMU device
by Ján Tomko 23 Mar '17

23 Mar '17

https://bugzilla.redhat.com/show_bug.cgi?id=1433994 --- src/qemu/qemu_migration.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/src/qemu/qemu_migration.c b/src/qemu/qemu_migration.c index f5711bc..15ed830 100644 --- a/src/qemu/qemu_migration.c +++ b/src/qemu/qemu_migration.c @@ -2359,6 +2359,12 @@ qemuMigrationIsAllowed(virQEMUDriverPtr driver, _("migration with shmem device is not supported")); return false; } + + if (vm->def->iommu) { + virReportError(VIR_ERR_OPERATION_INVALID, "%s", + _("migration with iommu device is not supported")); + return false; + } } return true; -- 2.10.2

2 1

[libvirt] [PATCH v3 0/7] Add TLS support for migration
by John Ferlan 23 Mar '17

23 Mar '17

v2: http://www.redhat.com/archives/libvir-list/2017-February/msg01374.html NB: Parts of the original series were split out, patches posted, ACK'd, and committed separately, see: http://www.redhat.com/archives/libvir-list/2017-March/msg00037.html Changes since v2: First and foremost after some gentle encouragement and lots of hours cursing at no one in particular, I was finally able to configure a couple of nested host guests, create a guest on each, and actually migrate that guest without TLS back and forth between the two nested hosts. Suffice to say there are dribs and drabs of "howto"'s that help, but it is quite a confusing setup and I was certainly left wondering how customers do this. OK beyond paying someone set things up for them! Now that I had the basics, the next task was creating the TLS environment. MANY more curse words uttered, including some I didn't know I knew, but I was actually able to test the changes in my environment. Suffice to say it's "somewhat confusing" because the TLS environment that QEMU expects (ok, the filenames) differ slightly than those that a libvirt TLS environment would expects. What really got frustrating is that all I'd get back is the following error message after 'migrate' started on the client and after the server was essentially waiting for the migration: error: operation failed: migration job: unexpectedly failed Turns out that I was missing the '/etc/pki/qemu/client-cert.pem' and '/etc/pki/qemu/client-key.pem' files, but got no message. Of course I did have something in my /etc/pki/libvirt directory, but of course those weren't being used. Still my brain wasn't exactly telling me that. The other piece I was missing was the "details" about when "tls-hostname" must be provided. In the previous patches, I would search on "fd" or "spec" in spec->dest.host.protocol; however, that wasn't quite right. What I needed to search on was MIGRATION_DEST_CONNECT_HOST or MIGRATION_DEST_FD in spec->destType (and _CONNECT_HOST only because it turns into _FD 'eventually'). Anyway, so happy days are here again and I can now liberally celebrate St Patrick's Day (not that I wasn't going to before, but now moreso!). Beyond the above description from my testing the real "key" behind all of this is ensuring that the 'right' QEMU bits are installed by fetching the "tls-creds" via qemuMonitorGetMigrationParams and as long as *something* is returned, then we are assured that we can proceed. This relates to QEMU commit '4af245dc3' (after v2.9.0-rc0) which sets a default for tls-creds and more importantly for our purposes allows us to "clear" the tls-creds and tls-hostname migration parameters by passing a "" (empty string). With that in place the rest of the logic falls into place with regard to qemuMigrationCheckSetupTLS ensuring that TLS for migration is available for libvirt to use. Once we know we can use TLS, we'll use qemuMigrationAddTLSObjects to add the "secret" and "tls-creds-x509" objects to the domain for either server (target) or client (source). Doing this also required an adjustment to the existing code to allow the Async monitor usage. Once those objects are created, we'll set the "tls-creds" and "tls-hostname" parameters appropriate. If TLS isn't being used, we'll be sure to clear them. This is only made tricky by needing to ensure the qemu that's running can support setting them to "", hence the qemuMigrationCheckTLSCreds prior to that clearing. If this wasn't done, older QEMU would be less than pleased to find "" in tls-creds and tls-hostname. Finally when the migration is successful, call qemuMigrationDeconstructTLS (naming credit goes to my wife!). Failures will call just qemuMigrationResetTLS in order to achieve the same call; however, for those paths we do not still have the original 'tlsAlias' and 'secAlias' available, so we have to recreate it on the fly' Have I won the prize for the longest cover letter yet? John Ferlan (7): qemu: Create #define for TLS configuration setup. conf: Introduce migrate_tls_x509_cert_dir Add new migration flag VIR_MIGRATE_TLS qemu: Add TLS params to _qemuMonitorMigrationParams qemu: Add job for qemuDomain{Add|Del}TLSObjects qemu: Set up the migrate TLS objects for target qemu: Set up the migration TLS objects for source include/libvirt/libvirt-domain.h | 8 + src/qemu/libvirtd_qemu.aug | 5 + src/qemu/qemu.conf | 37 ++++ src/qemu/qemu_conf.c | 45 ++-- src/qemu/qemu_conf.h | 4 + src/qemu/qemu_domain.c | 7 +- src/qemu/qemu_domain.h | 91 ++++---- src/qemu/qemu_driver.c | 4 +- src/qemu/qemu_hotplug.c | 24 ++- src/qemu/qemu_hotplug.h | 2 + src/qemu/qemu_migration.c | 423 ++++++++++++++++++++++++++++++++++++- src/qemu/qemu_migration.h | 9 +- src/qemu/qemu_monitor.c | 11 +- src/qemu/qemu_monitor.h | 3 + src/qemu/qemu_monitor_json.c | 28 +++ src/qemu/test_libvirtd_qemu.aug.in | 3 + tests/qemumonitorjsontest.c | 25 ++- tools/virsh-domain.c | 7 + 18 files changed, 668 insertions(+), 68 deletions(-) -- 2.9.3

2 23