- Devel - libvirt List Archives

[libvirt] Dealing with GCC 6.0
by Martin Kletzander 24 Feb '16

24 Feb '16

So we recently started compiling with gcc 5 and there's a new thing now and we don't build on gcc 6. I know it's just a development build, but it finds new things, like: fdstream.c: In function 'virFDStreamWrite': fdstream.c:390:29: error: logical 'or' of equal expressions [-Werror=logical-op] if (errno == EAGAIN || errno == EWOULDBLOCK) { ^~ fdstream.c: In function 'virFDStreamRead': fdstream.c:440:29: error: logical 'or' of equal expressions [-Werror=logical-op] if (errno == EAGAIN || errno == EWOULDBLOCK) { ^~ and rpc/virnetsshsession.c: In function 'virNetSSHAuthenticateAgent': rpc/virnetsshsession.c:548:56: error: logical 'and' of equal expressions [-Werror=logical-op] if (ret != LIBSSH2_ERROR_AUTHENTICATION_FAILED && ^~ rpc/virnetsshsession.c: In function 'virNetSSHAuthenticatePrivkey': rpc/virnetsshsession.c:676:57: error: logical 'or' of equal expressions [-Werror=logical-op] if (ret == LIBSSH2_ERROR_PUBLICKEY_UNRECOGNIZED || ^~ The first one is prety easy to fix, that's the only place where we use EWOULDBLOCK, we are using only EAGAIN everywhere else. However, the second one is not that easy to change for me as I'm not a libssh expert and moreover, I would like to know other's opinions on how to tackle that. We can disable the logical-op warning, but it might show something that makes sense (really?). Or we can do bunch of very very ugly "#if"s. Anyone care to share an idea? Have a nice day, Martin

3 4

[libvirt] [PATCH v2 0/4] implement vram64 attribute for QXL video device
by Pavel Hrdina 24 Feb '16

24 Feb '16

New in v2: - added patch to always set primary video device as primary - introduced new qemu monitor functions to update vram64 values after QEMU is started only if QEMU supports this parameter Pavel Hrdina (4): domain_conf: always set primary video device as primary docs/formatdomain: rewrite video documentation qemu_capabilities: introduce QEMU_CAPS_QXL(_VGA)_VRAM64 qemu: introduce vram64 attribute for QXL video device docs/formatdomain.html.in | 18 ++++---- docs/schemas/domaincommon.rng | 5 ++ src/conf/domain_conf.c | 40 +++++++++++++--- src/conf/domain_conf.h | 1 + src/qemu/qemu_capabilities.c | 4 ++ src/qemu/qemu_capabilities.h | 2 + src/qemu/qemu_command.c | 32 ++++++++++--- src/qemu/qemu_monitor.c | 35 ++++++++++++++ src/qemu/qemu_monitor.h | 4 ++ src/qemu/qemu_monitor_json.c | 54 ++++++++++++++++++++++ src/qemu/qemu_monitor_json.h | 3 ++ src/qemu/qemu_process.c | 24 ++++++---- tests/qemucapabilitiesdata/caps_1.2.2-1.caps | 2 + tests/qemucapabilitiesdata/caps_1.3.1-1.caps | 2 + tests/qemucapabilitiesdata/caps_1.4.2-1.caps | 2 + tests/qemucapabilitiesdata/caps_1.5.3-1.caps | 2 + tests/qemucapabilitiesdata/caps_1.6.0-1.caps | 2 + tests/qemucapabilitiesdata/caps_1.6.50-1.caps | 2 + tests/qemucapabilitiesdata/caps_2.1.1-1.caps | 2 + tests/qemucapabilitiesdata/caps_2.4.0-1.caps | 2 + tests/qemucapabilitiesdata/caps_2.5.0-1.caps | 2 + tests/qemucapabilitiesdata/caps_2.6.0-1.caps | 2 + ...qemuhotplug-console-compat-2+console-virtio.xml | 2 +- .../qemuxml2argv-console-compat-2.xml | 2 +- .../qemuxml2argv-video-qxl-device-vram64.args | 25 ++++++++++ .../qemuxml2argv-video-qxl-device-vram64.xml | 29 ++++++++++++ .../qemuxml2argv-video-qxl-sec-device-vram64.args | 27 +++++++++++ .../qemuxml2argv-video-qxl-sec-device-vram64.xml | 32 +++++++++++++ .../qemuxml2xmlout-graphics-listen-network.xml | 2 +- .../qemuxml2xmlout-graphics-listen-network2.xml | 2 +- .../qemuxml2xmlout-graphics-sdl-fullscreen.xml | 2 +- .../qemuxml2xmlout-graphics-sdl.xml | 2 +- .../qemuxml2xmlout-graphics-spice-compression.xml | 2 +- .../qemuxml2xmlout-graphics-spice-qxl-vga.xml | 2 +- .../qemuxml2xmlout-graphics-spice-timeout.xml | 2 +- .../qemuxml2xmlout-graphics-spice.xml | 2 +- .../qemuxml2xmlout-graphics-vnc-sasl.xml | 2 +- .../qemuxml2xmlout-graphics-vnc-tls.xml | 2 +- .../qemuxml2xmlout-graphics-vnc-websocket.xml | 2 +- .../qemuxml2xmlout-graphics-vnc.xml | 2 +- .../qemuxml2xmlout-interface-server.xml | 2 +- .../qemuxml2xmlout-net-bandwidth.xml | 2 +- .../qemuxml2xmlout-net-bandwidth2.xml | 2 +- .../qemuxml2xmlout-pci-autoadd-addr.xml | 2 +- .../qemuxml2xmlout-pci-autoadd-idx.xml | 2 +- .../qemuxml2xmlout-pci-bridge.xml | 2 +- .../qemuxml2xmlout-pcie-root-port.xml | 2 +- .../qemuxml2xmlout-pcie-switch-downstream-port.xml | 2 +- .../qemuxml2xmlout-pcie-switch-upstream-port.xml | 2 +- .../qemuxml2xmlout-pcihole64-q35.xml | 2 +- .../qemuxml2xmlout-q35-usb2-multi.xml | 2 +- .../qemuxml2xmlout-q35-usb2-reorder.xml | 2 +- .../qemuxml2xmloutdata/qemuxml2xmlout-q35-usb2.xml | 2 +- tests/qemuxml2xmloutdata/qemuxml2xmlout-q35.xml | 2 +- ...emuxml2xmlout-seclabel-dynamic-none-relabel.xml | 2 +- .../qemuxml2xmlout-serial-spiceport.xml | 2 +- .../qemuxml2xmlout-video-virtio-gpu-device.xml | 2 +- .../qemuxml2xmlout-video-virtio-gpu-virgl.xml | 2 +- 58 files changed, 357 insertions(+), 62 deletions(-) create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-video-qxl-device-vram64.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-video-qxl-device-vram64.xml create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-video-qxl-sec-device-vram64.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-video-qxl-sec-device-vram64.xml -- 2.7.1

2 6

[libvirt] [FOR 1.3.0 PATCH] conf: add net device prefix for Xen
by Jim Fehlig 24 Feb '16

24 Feb '16

In commit d2e5538b1, the libxl driver was changed to copy interface names autogenerated by libxl to the corresponding network def in the domain's virDomainDef object. The copied name is freed when the domain transitions to the shutoff state. But when migrating a domain, the autogenerated name is included in the XML sent to the destination host. It is possible an interface with the same name already exists on the destination host, causing migration to fail. Indeed the Xen project's OSSTEST CI already encountered such a failure. This patch defines another VIR_NET_GENERATED_PREFIX for Xen, allowing the autogenerated names to be excluded when parsing and formatting inactive config. Signed-off-by: Jim Fehlig <jfehlig(a)suse.com> --- This is an alternative approach to Joao's fix for this regression https://www.redhat.com/archives/libvir-list/2015-December/msg00197.html I think it is the same approach used by the qemu driver. My only reservation is that it expands the potential for clashes with user-defined names. I.e. with this change both 'vnet' and 'vif' are reserved prefixes. src/conf/domain_conf.c | 6 ++++-- src/conf/domain_conf.h | 4 ++++ src/libxl/libxl_domain.c | 5 +++-- 3 files changed, 11 insertions(+), 4 deletions(-) diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c index 2f5c0ed..debcf4e 100644 --- a/src/conf/domain_conf.c +++ b/src/conf/domain_conf.c @@ -8428,7 +8428,8 @@ virDomainNetDefParseXML(virDomainXMLOptionPtr xmlopt, ifname = virXMLPropString(cur, "dev"); if (ifname && (flags & VIR_DOMAIN_DEF_PARSE_INACTIVE) && - STRPREFIX(ifname, VIR_NET_GENERATED_PREFIX)) { + (STRPREFIX(ifname, VIR_NET_GENERATED_PREFIX) || + STRPREFIX(ifname, VIR_NET_GENERATED_PREFIX_XEN))) { /* An auto-generated target name, blank it out */ VIR_FREE(ifname); } @@ -19790,7 +19791,8 @@ virDomainNetDefFormat(virBufferPtr buf, virBufferEscapeString(buf, "<backenddomain name='%s'/>\n", def->domain_name); if (def->ifname && !((flags & VIR_DOMAIN_DEF_FORMAT_INACTIVE) && - (STRPREFIX(def->ifname, VIR_NET_GENERATED_PREFIX)))) { + (STRPREFIX(def->ifname, VIR_NET_GENERATED_PREFIX) || + STRPREFIX(def->ifname, VIR_NET_GENERATED_PREFIX_XEN)))) { /* Skip auto-generated target names for inactive config. */ virBufferEscapeString(buf, "<target dev='%s'/>\n", def->ifname); } diff --git a/src/conf/domain_conf.h b/src/conf/domain_conf.h index 90d8e13..d2cc26f 100644 --- a/src/conf/domain_conf.h +++ b/src/conf/domain_conf.h @@ -1085,6 +1085,10 @@ struct _virDomainNetDef { * by libvirt, and cannot be used for a persistent network name. */ # define VIR_NET_GENERATED_PREFIX "vnet" +/* Used for prefix of ifname of any network name generated dynamically + * by libvirt for Xen, and cannot be used for a persistent network name. */ +# define VIR_NET_GENERATED_PREFIX_XEN "vif" + typedef enum { VIR_DOMAIN_CHR_DEVICE_STATE_DEFAULT = 0, VIR_DOMAIN_CHR_DEVICE_STATE_CONNECTED, diff --git a/src/libxl/libxl_domain.c b/src/libxl/libxl_domain.c index ef92974..c5d84a4 100644 --- a/src/libxl/libxl_domain.c +++ b/src/libxl/libxl_domain.c @@ -734,7 +734,7 @@ libxlDomainCleanup(libxlDriverPrivatePtr driver, for (i = 0; i < vm->def->nnets; i++) { virDomainNetDefPtr net = vm->def->nets[i]; - if (STRPREFIX(net->ifname, "vif")) + if (STRPREFIX(net->ifname, VIR_NET_GENERATED_PREFIX_XEN)) VIR_FREE(net->ifname); } } @@ -918,7 +918,8 @@ libxlDomainCreateIfaceNames(virDomainDefPtr def, libxl_domain_config *d_config) if (net->ifname) continue; - ignore_value(virAsprintf(&net->ifname, "vif%d.%d%s", + ignore_value(virAsprintf(&net->ifname, + VIR_NET_GENERATED_PREFIX_XEN "%d.%d%s", def->id, x_nic->devid, suffix)); } } -- 2.6.1

3 8

[libvirt] request for wiki account
by Adam Hunt 24 Feb '16

24 Feb '16

I would like to request an account to update the libvirt wiki. first: Adam last: Hunt user: voxadam email: voxadam(a)gmail.com --adam

1 0

[libvirt] [PATCH v3 0/7] migration: add multithread compression
by Nikolay Shirokovskiy 24 Feb '16

24 Feb '16

Add options to turn multithread compression on during migration and to configure its parameters. Changes from v2: 1. Multiple field parameter is used to specify compression methods that should be used during migration. VIR_MIGRATE_COMPRESSED option flag now specifies that default compression methods should be used so we keep backward compatibility. This method is lxbzrle for qemu. 2. Patch that adds monitor commands to configure multithread compression parameters and patch that adds compression options to migrate command are reworked. This series has not patches to configure compression parameters before migration. Do we need it? Also it has not patch to introspect compression methods supported by driver as Jiri suggested because I want to publish this series ealier to check that I'm going in right direction. Eli Qiao (1): qemumonitorjsontest: add test for getting multithread compress params Nikolay Shirokovskiy (4): qemu migration: factor out setting migration option migration: add compress method option qemu migration: add multithread compression options qemu migration: add xbzrle compression options ShaoHe Feng (2): qemu monitor: add multithread compress parameters accessors virsh: add compression options for migration include/libvirt/libvirt-domain.h | 44 ++++++- src/qemu/qemu_domain.c | 4 + src/qemu/qemu_domain.h | 2 + src/qemu/qemu_driver.c | 116 +++++++++++++++++- src/qemu/qemu_migration.c | 256 +++++++++++++++++++-------------------- src/qemu/qemu_migration.h | 24 ++++ src/qemu/qemu_monitor.c | 31 ++++- src/qemu/qemu_monitor.h | 17 +++ src/qemu/qemu_monitor_json.c | 87 +++++++++++++ src/qemu/qemu_monitor_json.h | 5 + src/qemu/qemu_monitor_text.c | 100 +++++++++++++++ src/qemu/qemu_monitor_text.h | 5 + tests/qemumonitorjsontest.c | 53 ++++++++ tools/virsh-domain.c | 84 +++++++++++++ tools/virsh.pod | 25 +++- 15 files changed, 711 insertions(+), 142 deletions(-) -- 1.8.3.1

3 23

[libvirt] [PATCH V2 0/4] libxl: support qemu's network-based block backends
by Jim Fehlig 24 Feb '16

24 Feb '16

xl/libxl already supports qemu's network-based block backends such as nbd and rbd. libvirt has supported configuring network disks for long time too. This series marries the two in the libxl driver and in the xl<->xml converter. Only rbd supported is added in this series. Support for other backends such as nbd and iscsi can be added as a follow-up improvement. Patch 1 is super trivial and contains no functional changes. Patch 2 changes the xl disk configuration produced by the xml->xl converter to use the formal key=value syntax described in xl-disk-configuration.txt. Patch 3 adds support for converting rbd info between xl and xml config formats. Patch 4 adds support for rbd disks in the libxl driver. In V2: Change commit msg, test, and code in patch3 to escape literal backslashes with a backslash. Jim Fehlig (4): xenconfig: replace text 'xm' with 'xl' in xlconfigtest xenconfig: produce key=value disk config syntax in xl formatter xenconfig: support xl<->xml conversion of rbd disk devices libxl: add support for rbd qdisk src/libxl/libxl_conf.c | 192 ++++++++++++++++++++- src/xenconfig/xen_xl.c | 176 +++++++++++++++++-- .../test-disk-positional-parms-full.cfg | 26 +++ .../test-disk-positional-parms-full.xml | 54 ++++++ .../test-disk-positional-parms-partial.cfg | 26 +++ .../test-disk-positional-parms-partial.xml | 54 ++++++ .../test-fullvirt-direct-kernel-boot.cfg | 2 +- tests/xlconfigdata/test-fullvirt-multiusb.cfg | 2 +- tests/xlconfigdata/test-new-disk.cfg | 2 +- tests/xlconfigdata/test-paravirt-cmdline.cfg | 2 +- tests/xlconfigdata/test-paravirt-maxvcpus.cfg | 2 +- tests/xlconfigdata/test-rbd-multihost-noauth.cfg | 26 +++ tests/xlconfigdata/test-rbd-multihost-noauth.xml | 51 ++++++ tests/xlconfigdata/test-spice-features.cfg | 2 +- tests/xlconfigdata/test-spice.cfg | 2 +- tests/xlconfigdata/test-vif-rate.cfg | 2 +- tests/xlconfigtest.c | 37 ++-- 17 files changed, 618 insertions(+), 40 deletions(-) create mode 100644 tests/xlconfigdata/test-disk-positional-parms-full.cfg create mode 100644 tests/xlconfigdata/test-disk-positional-parms-full.xml create mode 100644 tests/xlconfigdata/test-disk-positional-parms-partial.cfg create mode 100644 tests/xlconfigdata/test-disk-positional-parms-partial.xml create mode 100644 tests/xlconfigdata/test-rbd-multihost-noauth.cfg create mode 100644 tests/xlconfigdata/test-rbd-multihost-noauth.xml -- 2.1.4

3 13

[libvirt] [PATCH] rbd: fix 32-bit build
by Eric Blake 23 Feb '16

23 Feb '16

%zu is not always synonymous with uint64_t; on 32-bit machines, size_t is only 32 bits. Prefer "%llu"/'unsigned long long' when the variable is under our control, and "%"PRIu64 when we are stuck with 'uint64_t' from RBD. Fixes errors such as: ../../src/storage/storage_backend_rbd.c: In function 'virStorageBackendRBDVolWipe': ../../src/storage/storage_backend_rbd.c:1281:15: error: format '%zu' expects argument of type 'size_t', but argument 8 has type 'uint64_t {aka long long unsigned int}' [-Werror=format=] VIR_DEBUG("Need to wipe %zu bytes from RBD image %s/%s", ^ ../../src/util/virlog.h:90:73: note: in definition of macro 'VIR_DEBUG_INT' virLogMessage(src, VIR_LOG_DEBUG, filename, linenr, funcname, NULL, __VA_ARGS__) ^ ../../src/storage/storage_backend_rbd.c:1281:5: note: in expansion of macro 'VIR_DEBUG' VIR_DEBUG("Need to wipe %zu bytes from RBD image %s/%s", ^ Signed-off-by: Eric Blake <eblake(a)redhat.com> --- Pushing under the build-breaker rule src/storage/storage_backend_rbd.c | 28 +++++++++++++++------------- 1 file changed, 15 insertions(+), 13 deletions(-) diff --git a/src/storage/storage_backend_rbd.c b/src/storage/storage_backend_rbd.c index 0591eec..7d04b39 100644 --- a/src/storage/storage_backend_rbd.c +++ b/src/storage/storage_backend_rbd.c @@ -23,6 +23,7 @@ #include <config.h> +#include <inttypes.h> #include "datatypes.h" #include "virerror.h" #include "storage_backend_rbd.h" @@ -403,7 +404,7 @@ volStorageBackendRBDRefreshVolInfo(virStorageVolDefPtr vol, } VIR_DEBUG("Refreshed RBD image %s/%s (capacity: %llu allocation: %llu " - "obj_size: %zu num_objs: %zu)", + "obj_size: %"PRIu64" num_objs: %"PRIu64")", pool->def->source.name, vol->name, vol->target.capacity, vol->target.allocation, info.obj_size, info.num_objs); @@ -463,7 +464,8 @@ virStorageBackendRBDRefreshPool(virConnectPtr conn, pool->def->available = clusterstat.kb_avail * 1024; pool->def->allocation = poolstat.num_bytes; - VIR_DEBUG("Utilization of RBD pool %s: (kb: %zu kb_avail: %zu num_bytes: %zu)", + VIR_DEBUG("Utilization of RBD pool %s: (kb: %"PRIu64" kb_avail: %"PRIu64 + " num_bytes: %"PRIu64")", pool->def->source.name, clusterstat.kb, clusterstat.kb_avail, poolstat.num_bytes); @@ -1168,8 +1170,8 @@ virStorageBackendRBDVolWipeZero(rbd_image_t image, { int r = -1; int ret = -1; - uint64_t offset = 0; - uint64_t length; + unsigned long long offset = 0; + unsigned long long length; char *writebuf; if (VIR_ALLOC_N(writebuf, info->obj_size * stripe_count) < 0) @@ -1179,13 +1181,13 @@ virStorageBackendRBDVolWipeZero(rbd_image_t image, length = MIN((info->size - offset), (info->obj_size * stripe_count)); if ((r = rbd_write(image, offset, length, writebuf)) < 0) { - virReportSystemError(-r, _("writing %zu bytes failed on " - "RBD image %s at offset %zu"), + virReportSystemError(-r, _("writing %llu bytes failed on " + "RBD image %s at offset %llu"), length, imgname, offset); goto cleanup; } - VIR_DEBUG("Wrote %zu bytes to RBD image %s at offset %zu", + VIR_DEBUG("Wrote %llu bytes to RBD image %s at offset %llu", length, imgname, offset); offset += length; @@ -1207,8 +1209,8 @@ virStorageBackendRBDVolWipeDiscard(rbd_image_t image, { int r = -1; int ret = -1; - uint64_t offset = 0; - uint64_t length; + unsigned long long offset = 0; + unsigned long long length; VIR_DEBUG("Wiping RBD %s volume using discard)", imgname); @@ -1216,13 +1218,13 @@ virStorageBackendRBDVolWipeDiscard(rbd_image_t image, length = MIN((info->size - offset), (info->obj_size * stripe_count)); if ((r = rbd_discard(image, offset, length)) < 0) { - virReportSystemError(-r, _("discarding %zu bytes failed on " - "RBD image %s at offset %zu"), + virReportSystemError(-r, _("discarding %llu bytes failed on " + "RBD image %s at offset %llu"), length, imgname, offset); goto cleanup; } - VIR_DEBUG("Discarded %zu bytes of RBD image %s at offset %zu", + VIR_DEBUG("Discarded %llu bytes of RBD image %s at offset %llu", length, imgname, offset); offset += length; @@ -1278,7 +1280,7 @@ virStorageBackendRBDVolWipe(virConnectPtr conn, goto cleanup; } - VIR_DEBUG("Need to wipe %zu bytes from RBD image %s/%s", + VIR_DEBUG("Need to wipe %"PRIu64" bytes from RBD image %s/%s", info.size, pool->def->source.name, vol->name); switch ((virStorageVolWipeAlgorithm) algorithm) { -- 2.5.0

1 0

[libvirt] Storage backend and RBD improvements
by Wido den Hollander 23 Feb '16

23 Feb '16

This series of patches is mainly focussed on improving the RBD storage pool backend. In the series it fixes a bug in the storage pool driver regarding volume wiping and it also adds the new flag to instruct storage pools to use TRIM for wiping volumes. Afterwards it adds this functionality to the RBD storage pool and in addition it also adds to ability to clone RBD volumes. The original series of patches were reviewed by John Ferlan and this series are revised based on his great feedback. Wido

5 13

[libvirt] [PATCH] libxl: fix bogus indentation from commit fb2bd208
by Jim Fehlig 23 Feb '16

23 Feb '16

Signed-off-by: Jim Fehlig <jfehlig(a)suse.com> --- Found by Ján Tomko while reviewing fb2bd208. Pushing under the trivial rule. src/libxl/libxl_conf.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/libxl/libxl_conf.c b/src/libxl/libxl_conf.c index 5133299..a109bb5 100644 --- a/src/libxl/libxl_conf.c +++ b/src/libxl/libxl_conf.c @@ -1095,7 +1095,7 @@ libxlMakeNetworkDiskSrc(virStorageSourcePtr src, char **srcstr) } if (!(*srcstr = libxlMakeNetworkDiskSrcStr(src, username, secret))) - goto cleanup; + goto cleanup; ret = 0; -- 2.6.1

1 0

[libvirt] [PATCH v7 00/13] qemu: Add quorum support to libvirt
by Matthias Gatto 23 Feb '16

23 Feb '16

The purpose of these patches is to introduce quorum for libvirt I've try to follow this proposal: http://www.redhat.com/archives/libvir-list/2014-May/msg00533.html This feature ask for 5 task: 1) Allow a _virStorageSource to contain more than one backing store. Because all the actual libvirt code use the backingStore field as a pointer and we needs want to change that, I've decide to encapsulate the backingStore field to simplifie the array manipulation. 2) Add the missing field a quorum need in _virStorageSource and the VIR_STORAGE_TYPE_QUORUM and VIR_STORAGE_FILE_QUORUM in their respectives enums. 3) Parse and format the xml Because a quorum allows to have more than one backing store at the same level we need to change virDomainDiskDefFormat and virDomainDiskDefParseXML to call virDomainDiskBackingStoreFormat and virDomainDiskBackingStoreParse in a loop. virDomainDiskBackingStoreFormat and virDomainDiskBackingStoreParse can call themself recursively in a loop because a quorum can contain another quorum 4) Build qemu string As for the xml, we have to call the function which create quorum recursively. But this task have the problem explained here: http://www.redhat.com/archives/libvir-list/2014-October/msg00529.html The _virStorageSource missing some informations that can be passed to a child, and therefore this version of quorum is incomplet. 5) Allow to hotplug/change a disk in a quorum This part is not present in these patches because for this task we have to use blockdev-add, and currently libvirt use device_add for hotpluging that doesn't allow to hotplug quorum childs. V2: -Rebase on master -Add Documentation V3: -Transforme the backingStore field in virStorageSource into an array of pointer instead of a pointer -Modify virStorageSourceSetBackingStore to allow it to expand the backingStore size. V4: -Rebase on master V5: -Rebase on master -patch 1-4/9: use patchs from John Ferlan -patch 4/9: check return of virStorageSourceSetBackingStore -patch 5/9: report type of error on virStorageSourceSetBackingStore v6: -Rebase on master -Remove node-name patch -patch 06/13: Add virStorageSourceIsRAID -patch 10/13: Add virDomainDefHasRAID -patch 11-13/13: Block all unsupported operations v7: -Rebase on master. -Parse unconditionally backing store. -fold qemuBuildRAIDFileSourceStr into qemuBuildRAIDStr. -use 0/-1 return values when failing instead of bool. -virStorageSourceSetBackingStore now free backing store when they are already set. Matthias Gatto (13): virstoragefile: Add virStorageSourceGetBackingStore virstoragefile: Always use virStorageSourceGetBackingStore to get backing store virstoragefile: Add virStorageSourceSetBackingStore virstoragefile: Always use virStorageSourceSetBackingStore to set backing store virstoragefile: change backingStore to backingStores. virstoragefile: Add virStorageSourceIsRAID virstoragefile: Add quorum in virstoragefile domain_conf: Read and Write quorum config qemu: Add quorum support in qemuBuildDriveDevStr domain: Add virDomainDefHasRAID qemu: Forbid blocks operations with quorum qemu: qemuDomainGetBlockInfo quorum support qemu: qemuDiskPathToAlias quorum support docs/formatdomain.html.in | 23 ++++- docs/schemas/domaincommon.rng | 21 +++- docs/schemas/storagecommon.rng | 1 + docs/schemas/storagevol.rng | 1 + src/conf/domain_conf.c | 174 ++++++++++++++++++++++++---------- src/conf/domain_conf.h | 1 + src/conf/storage_conf.c | 23 +++-- src/libvirt_private.syms | 4 + src/qemu/qemu_cgroup.c | 4 +- src/qemu/qemu_command.c | 78 +++++++++++++++ src/qemu/qemu_domain.c | 2 +- src/qemu/qemu_driver.c | 72 ++++++++++---- src/qemu/qemu_migration.c | 1 + src/qemu/qemu_monitor_json.c | 4 +- src/security/security_dac.c | 2 +- src/security/security_selinux.c | 4 +- src/security/virt-aa-helper.c | 2 +- src/storage/storage_backend.c | 24 +++-- src/storage/storage_backend_fs.c | 45 +++++---- src/storage/storage_backend_gluster.c | 11 ++- src/storage/storage_backend_logical.c | 15 ++- src/storage/storage_driver.c | 3 +- src/util/virstoragefile.c | 121 ++++++++++++++++++++--- src/util/virstoragefile.h | 15 ++- tests/virstoragetest.c | 18 ++-- 25 files changed, 518 insertions(+), 151 deletions(-) -- 2.6.2

4 27

[libvirt] [PATCH] Miscellaneous for-loop syntax clean-ups
by Martin Kletzander 23 Feb '16

23 Feb '16

Checking whether x > 0 before looping over [0..x] items doesn't make sense and multi-line body must have curly brackets around it. Best viewed with '-w'. Signed-off-by: Martin Kletzander <mkletzan(a)redhat.com> --- src/conf/domain_conf.c | 24 +++++++++++++------- src/qemu/qemu_capabilities.c | 30 ++++++++++++------------ src/storage/storage_backend_rbd.c | 48 +++++++++++++++++++-------------------- src/vbox/vbox_common.c | 14 ++++-------- 4 files changed, 58 insertions(+), 58 deletions(-) diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c index 56bd1aa99042..3b15cb46d9ec 100644 --- a/src/conf/domain_conf.c +++ b/src/conf/domain_conf.c @@ -22363,17 +22363,20 @@ virDomainDefFormatInternal(virDomainDefPtr def, goto error; } - for (n = 0; n < def->ngraphics; n++) + for (n = 0; n < def->ngraphics; n++) { if (virDomainGraphicsDefFormat(buf, def->graphics[n], flags) < 0) goto error; + } - for (n = 0; n < def->nsounds; n++) + for (n = 0; n < def->nsounds; n++) { if (virDomainSoundDefFormat(buf, def->sounds[n], flags) < 0) goto error; + } - for (n = 0; n < def->nvideos; n++) + for (n = 0; n < def->nvideos; n++) { if (virDomainVideoDefFormat(buf, def->videos[n], flags) < 0) goto error; + } for (n = 0; n < def->nhostdevs; n++) { /* If parent.type != NONE, this is just a pointer to the @@ -22386,16 +22389,18 @@ virDomainDefFormatInternal(virDomainDefPtr def, } } - for (n = 0; n < def->nredirdevs; n++) + for (n = 0; n < def->nredirdevs; n++) { if (virDomainRedirdevDefFormat(buf, def->redirdevs[n], flags) < 0) goto error; + } if (def->redirfilter) virDomainRedirFilterDefFormat(buf, def->redirfilter); - for (n = 0; n < def->nhubs; n++) + for (n = 0; n < def->nhubs; n++) { if (virDomainHubDefFormat(buf, def->hubs[n], flags) < 0) goto error; + } if (def->watchdog) virDomainWatchdogDefFormat(buf, def->watchdog, flags); @@ -22411,17 +22416,20 @@ virDomainDefFormatInternal(virDomainDefPtr def, if (def->nvram) virDomainNVRAMDefFormat(buf, def->nvram, flags); - for (n = 0; n < def->npanics; n++) + for (n = 0; n < def->npanics; n++) { if (virDomainPanicDefFormat(buf, def->panics[n]) < 0) goto error; + } - for (n = 0; n < def->nshmems; n++) + for (n = 0; n < def->nshmems; n++) { if (virDomainShmemDefFormat(buf, def->shmems[n], flags) < 0) goto error; + } - for (n = 0; n < def->nmems; n++) + for (n = 0; n < def->nmems; n++) { if (virDomainMemoryDefFormat(buf, def->mems[n], flags) < 0) goto error; + } virBufferAdjustIndent(buf, -2); virBufferAddLit(buf, "</devices>\n"); diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c index 3099e344b095..a165ab4be291 100644 --- a/src/qemu/qemu_capabilities.c +++ b/src/qemu/qemu_capabilities.c @@ -2772,23 +2772,21 @@ virQEMUCapsLoadCache(virQEMUCapsPtr qemuCaps, const char *filename, goto cleanup; } VIR_DEBUG("Got flags %d", n); - if (n > 0) { - for (i = 0; i < n; i++) { - int flag; - if (!(str = virXMLPropString(nodes[i], "name"))) { - virReportError(VIR_ERR_INTERNAL_ERROR, "%s", - _("missing flag name in QEMU capabilities cache")); - goto cleanup; - } - flag = virQEMUCapsTypeFromString(str); - if (flag < 0) { - virReportError(VIR_ERR_INTERNAL_ERROR, - _("Unknown qemu capabilities flag %s"), str); - goto cleanup; - } - VIR_FREE(str); - virQEMUCapsSet(qemuCaps, flag); + for (i = 0; i < n; i++) { + int flag; + if (!(str = virXMLPropString(nodes[i], "name"))) { + virReportError(VIR_ERR_INTERNAL_ERROR, "%s", + _("missing flag name in QEMU capabilities cache")); + goto cleanup; + } + flag = virQEMUCapsTypeFromString(str); + if (flag < 0) { + virReportError(VIR_ERR_INTERNAL_ERROR, + _("Unknown qemu capabilities flag %s"), str); + goto cleanup; } + VIR_FREE(str); + virQEMUCapsSet(qemuCaps, flag); } VIR_FREE(nodes); diff --git a/src/storage/storage_backend_rbd.c b/src/storage/storage_backend_rbd.c index 098b7dc5f0d0..0591eecde26d 100644 --- a/src/storage/storage_backend_rbd.c +++ b/src/storage/storage_backend_rbd.c @@ -566,38 +566,36 @@ virStorageBackendRBDCleanupSnapshots(rados_ioctx_t ioctx, VIR_DEBUG("Found %d snapshots for volume %s/%s", snap_count, source->name, vol->name); - if (snap_count > 0) { - for (i = 0; i < snap_count; i++) { - if ((r = rbd_snap_is_protected(image, snaps[i].name, &protected)) < 0) { - virReportSystemError(-r, _("failed to verify if snapshot '%s/%s@%s' is protected"), - source->name, vol->name, - snaps[i].name); - goto cleanup; - } - - if (protected == 1) { - VIR_DEBUG("Snapshot %s/%s@%s is protected needs to be " - "unprotected", source->name, vol->name, - snaps[i].name); - - if ((r = rbd_snap_unprotect(image, snaps[i].name)) < 0) { - virReportSystemError(-r, _("failed to unprotect snapshot '%s/%s@%s'"), - source->name, vol->name, - snaps[i].name); - goto cleanup; - } - } + for (i = 0; i < snap_count; i++) { + if ((r = rbd_snap_is_protected(image, snaps[i].name, &protected)) < 0) { + virReportSystemError(-r, _("failed to verify if snapshot '%s/%s@%s' is protected"), + source->name, vol->name, + snaps[i].name); + goto cleanup; + } - VIR_DEBUG("Removing snapshot %s/%s@%s", source->name, - vol->name, snaps[i].name); + if (protected == 1) { + VIR_DEBUG("Snapshot %s/%s@%s is protected needs to be " + "unprotected", source->name, vol->name, + snaps[i].name); - if ((r = rbd_snap_remove(image, snaps[i].name)) < 0) { - virReportSystemError(-r, _("failed to remove snapshot '%s/%s@%s'"), + if ((r = rbd_snap_unprotect(image, snaps[i].name)) < 0) { + virReportSystemError(-r, _("failed to unprotect snapshot '%s/%s@%s'"), source->name, vol->name, snaps[i].name); goto cleanup; } } + + VIR_DEBUG("Removing snapshot %s/%s@%s", source->name, + vol->name, snaps[i].name); + + if ((r = rbd_snap_remove(image, snaps[i].name)) < 0) { + virReportSystemError(-r, _("failed to remove snapshot '%s/%s@%s'"), + source->name, vol->name, + snaps[i].name); + goto cleanup; + } } ret = 0; diff --git a/src/vbox/vbox_common.c b/src/vbox/vbox_common.c index 067ed97cf1cb..5302d1ce80eb 100644 --- a/src/vbox/vbox_common.c +++ b/src/vbox/vbox_common.c @@ -5541,11 +5541,9 @@ vboxDomainSnapshotGet(vboxGlobalData *data, } cleanup: - if (count > 0) { - for (i = 0; i < count; i++) { - if (snapshots[i] != snapshot) - VBOX_RELEASE(snapshots[i]); - } + for (i = 0; i < count; i++) { + if (snapshots[i] != snapshot) + VBOX_RELEASE(snapshots[i]); } VIR_FREE(snapshots); return snapshot; @@ -6255,10 +6253,8 @@ static int vboxDomainSnapshotListNames(virDomainPtr dom, char **names, ret = nameslen; cleanup: - if (count > 0) { - for (i = 0; i < count; i++) - VBOX_RELEASE(snapshots[i]); - } + for (i = 0; i < count; i++) + VBOX_RELEASE(snapshots[i]); VIR_FREE(snapshots); VBOX_RELEASE(machine); vboxIIDUnalloc(&iid); -- 2.7.1

3 4

[libvirt] [PATCH 0/2] Introduce safewrite_str
by Ján Tomko 23 Feb '16

23 Feb '16

3 7

[libvirt] [PATCH 0/3] Couple of coverity fixes
by Michal Privoznik 23 Feb '16

23 Feb '16

All of these were spotted by coverity tool. Michal Privoznik (3): vbox: Avoid signed and unsigned comparison xen: Check return value of virStringReplace qemuBuildCommandLine: Change the condition for -nographics src/qemu/qemu_command.c | 2 +- src/vbox/vbox_common.c | 8 +++----- src/xenconfig/xen_xl.c | 7 ++++++- 3 files changed, 10 insertions(+), 7 deletions(-) -- 2.4.10

2 6

[libvirt] [PATCH] docs: Try harder to uninstall
by Michal Privoznik 23 Feb '16

23 Feb '16

Imagine you have partially installed libvirt, or maybe you're just running 'make uninstall' from a different version than 'make install' has been ran. One way or another, we are doing plain 'rm' instead of 'rm -f' and thus not trying hard enough when uninstalling. In the rest of our code we stick with -f switch. Do that for docs too. Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- docs/Makefile.am | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/Makefile.am b/docs/Makefile.am index 02eca64..1b4353b 100644 --- a/docs/Makefile.am +++ b/docs/Makefile.am @@ -366,8 +366,8 @@ install-data-local: $(INSTALL_DATA) $(srcdir)/libvirtLogo.png $(DESTDIR)$(pkgdatadir) uninstall-local: - for h in $(apihtml); do rm $(DESTDIR)$(HTML_DIR)/$$h; done - for p in $(apipng); do rm $(DESTDIR)$(HTML_DIR)/$$p; done + for h in $(apihtml); do rm -f $(DESTDIR)$(HTML_DIR)/$$h; done + for p in $(apipng); do rm -f $(DESTDIR)$(HTML_DIR)/$$p; done for f in $(devhelphtml) $(devhelppng) $(devhelpcss); do \ - rm $(DESTDIR)$(DEVHELP_DIR)/$$(basename $$f); \ + rm -f $(DESTDIR)$(DEVHELP_DIR)/$$(basename $$f); \ done -- 2.4.10

2 1

[libvirt] libvirt-guests.sh not correctly working - patch included
by Draget 23 Feb '16

23 Feb '16

Greetings, this mail is sent via CC to ubunutu-devel, because I am not 100% sure if the found formating issue might originate from some ubuntu issue. libvirst-guests.sh on Ubuntu Xenial would not work correctly for me. Only one of the guests would be correctly suspended while the others were killed violently. Package: libvirt-bin Version: 1.3.1-1ubuntu2 /usr/lib/libvirt/libvirt-guests.sh The script writes a list of the VMs it will manage into /usr/lib/libvirt/libvirt-guests but I noticed it was in the format: <url> <vm uuid> <vm uuid> <vm uuid> and only the first VM was handled. After reading through the script and doing some try & error patches, I figured that the correct format should be: <url> <vm uuid> <vm uuid> <vm uuid> i.e. with no new lines. The attached patch makes sure the returned list of VMs does not contain new lines. This fixed the issue. Additionally I would suggest adding an information message on line line 444. Changing: [ -f "$LISTFILE" ] && return 0 to: [ -f "$LISTFILE" ] && echo "No VMs started by libvirt-guests.sh, not doing anything." && return 0 Regards, Michael Gajda

1 0

[libvirt] [PATCH] tests: Fix typo oaque -> opaque
by Andrea Bolognani 23 Feb '16

23 Feb '16

No functional changes. --- Pushed under the trivial rule. tests/virhostdevtest.c | 16 ++++++++-------- tests/virpcitest.c | 2 +- 2 files changed, 9 insertions(+), 9 deletions(-) diff --git a/tests/virhostdevtest.c b/tests/virhostdevtest.c index 1b30681..cadb66a 100644 --- a/tests/virhostdevtest.c +++ b/tests/virhostdevtest.c @@ -157,7 +157,7 @@ virHostdevHostSupportsPassthroughKVM(void) # endif static int -testVirHostdevPreparePCIHostdevs_unmanaged(const void *oaque ATTRIBUTE_UNUSED) +testVirHostdevPreparePCIHostdevs_unmanaged(const void *opaque ATTRIBUTE_UNUSED) { int ret = -1; size_t i; @@ -216,7 +216,7 @@ testVirHostdevPreparePCIHostdevs_unmanaged(const void *oaque ATTRIBUTE_UNUSED) } static int -testVirHostdevReAttachPCIHostdevs_unmanaged(const void *oaque ATTRIBUTE_UNUSED) +testVirHostdevReAttachPCIHostdevs_unmanaged(const void *opaque ATTRIBUTE_UNUSED) { int ret = -1; size_t i; @@ -250,7 +250,7 @@ testVirHostdevReAttachPCIHostdevs_unmanaged(const void *oaque ATTRIBUTE_UNUSED) } static int -testVirHostdevPreparePCIHostdevs_managed(const void *oaque ATTRIBUTE_UNUSED) +testVirHostdevPreparePCIHostdevs_managed(const void *opaque ATTRIBUTE_UNUSED) { int ret = -1; size_t i; @@ -296,7 +296,7 @@ testVirHostdevPreparePCIHostdevs_managed(const void *oaque ATTRIBUTE_UNUSED) } static int -testVirHostdevReAttachPCIHostdevs_managed(const void *oaque ATTRIBUTE_UNUSED) +testVirHostdevReAttachPCIHostdevs_managed(const void *opaque ATTRIBUTE_UNUSED) { int ret = -1; size_t i; @@ -328,7 +328,7 @@ testVirHostdevReAttachPCIHostdevs_managed(const void *oaque ATTRIBUTE_UNUSED) } static int -testVirHostdevDetachPCINodeDevice(const void *oaque ATTRIBUTE_UNUSED) +testVirHostdevDetachPCINodeDevice(const void *opaque ATTRIBUTE_UNUSED) { int ret = -1; size_t i; @@ -347,7 +347,7 @@ testVirHostdevDetachPCINodeDevice(const void *oaque ATTRIBUTE_UNUSED) return ret; } static int -testVirHostdevResetPCINodeDevice(const void *oaque ATTRIBUTE_UNUSED) +testVirHostdevResetPCINodeDevice(const void *opaque ATTRIBUTE_UNUSED) { int ret = -1; size_t i; @@ -365,7 +365,7 @@ testVirHostdevResetPCINodeDevice(const void *oaque ATTRIBUTE_UNUSED) } static int -testVirHostdevReAttachPCINodeDevice(const void *oaque ATTRIBUTE_UNUSED) +testVirHostdevReAttachPCINodeDevice(const void *opaque ATTRIBUTE_UNUSED) { int ret = -1; size_t i; @@ -386,7 +386,7 @@ testVirHostdevReAttachPCINodeDevice(const void *oaque ATTRIBUTE_UNUSED) } static int -testVirHostdevUpdateActivePCIHostdevs(const void *oaque ATTRIBUTE_UNUSED) +testVirHostdevUpdateActivePCIHostdevs(const void *opaque ATTRIBUTE_UNUSED) { int ret = -1; int count, count1; diff --git a/tests/virpcitest.c b/tests/virpcitest.c index 6dceef2..dd02b0c 100644 --- a/tests/virpcitest.c +++ b/tests/virpcitest.c @@ -91,7 +91,7 @@ testVirPCIDeviceNew(const void *opaque ATTRIBUTE_UNUSED) } static int -testVirPCIDeviceDetach(const void *oaque ATTRIBUTE_UNUSED) +testVirPCIDeviceDetach(const void *opaque ATTRIBUTE_UNUSED) { int ret = -1; virPCIDevicePtr dev[] = {NULL, NULL, NULL}; -- 2.5.0

1 0

[libvirt] [PATCH 0/3] implement vram64 attribute for QXL video device
by Pavel Hrdina 23 Feb '16

23 Feb '16

Pavel Hrdina (3): qemu_capabilities: introduce QEMU_CAPS_QXL(_VGA)_VRAM64 docs/formatdomain: rewrite video documentation qemu: introduce vram64 attribute for QXL video device docs/formatdomain.html.in | 18 +++++++----- docs/schemas/domaincommon.rng | 5 ++++ src/conf/domain_conf.c | 34 ++++++++++++++++++---- src/conf/domain_conf.h | 1 + src/qemu/qemu_capabilities.c | 4 +++ src/qemu/qemu_capabilities.h | 2 ++ src/qemu/qemu_command.c | 13 +++++++++ src/qemu/qemu_monitor_json.c | 8 +++++ tests/qemucapabilitiesdata/caps_1.2.2-1.caps | 2 ++ tests/qemucapabilitiesdata/caps_1.3.1-1.caps | 2 ++ tests/qemucapabilitiesdata/caps_1.4.2-1.caps | 2 ++ tests/qemucapabilitiesdata/caps_1.5.3-1.caps | 2 ++ tests/qemucapabilitiesdata/caps_1.6.0-1.caps | 2 ++ tests/qemucapabilitiesdata/caps_1.6.50-1.caps | 2 ++ tests/qemucapabilitiesdata/caps_2.1.1-1.caps | 2 ++ tests/qemucapabilitiesdata/caps_2.4.0-1.caps | 2 ++ tests/qemucapabilitiesdata/caps_2.5.0-1.caps | 2 ++ tests/qemucapabilitiesdata/caps_2.6.0-1.caps | 2 ++ .../qemuxml2argv-video-qxl-device-vram64.args | 25 ++++++++++++++++ .../qemuxml2argv-video-qxl-device-vram64.xml | 29 ++++++++++++++++++ .../qemuxml2argv-video-qxl-sec-device-vram64.args | 27 +++++++++++++++++ .../qemuxml2argv-video-qxl-sec-device-vram64.xml | 32 ++++++++++++++++++++ 22 files changed, 204 insertions(+), 14 deletions(-) create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-video-qxl-device-vram64.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-video-qxl-device-vram64.xml create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-video-qxl-sec-device-vram64.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-video-qxl-sec-device-vram64.xml -- 2.7.1

2 7

Re: [libvirt] [PATCH] Fix bug of attaching redirdev device
by Osier Yang 23 Feb '16

23 Feb '16

ping? > >> On 18 Feb 2016, at 16:02, Osier Yang <osier(a)yunify.com> wrote: > >>> RHBZ: https://bugzilla.redhat.com/show_bug.cgi?id=1298070 > >>> > >>> The corresponding chardev must be attached first, otherwise the > >>> the qemu command line won't be complete (missing the host part), > >>> --- > >>> src/qemu/qemu_hotplug.c | 27 ++++++++++++++++++++++----- > >>> 1 file changed, 22 insertions(+), 5 deletions(-) > >>> > >>> diff --git a/src/qemu/qemu_hotplug.c b/src/qemu/qemu_hotplug.c > >>> index ee305e7..5095e31 100644 > >>> --- a/src/qemu/qemu_hotplug.c > >>> +++ b/src/qemu/qemu_hotplug.c > >>> @@ -1381,6 +1381,7 @@ int qemuDomainAttachRedirdevDevice(virQEMUDriverPtr driver, > >>> int ret; > >>> qemuDomainObjPrivatePtr priv = vm->privateData; > >>> virDomainDefPtr def = vm->def; > >>> + char *charAlias = NULL; > >>> char *devstr = NULL; > >>> > >>> if (!virQEMUCapsGet(priv->qemuCaps, QEMU_CAPS_DEVICE)) { > >>> @@ -1391,21 +1392,33 @@ int qemuDomainAttachRedirdevDevice(virQEMUDriverPtr driver, > >>> > >>> if (qemuAssignDeviceRedirdevAlias(vm->def, redirdev, -1) < 0) > >>> goto error; > >>> - if (!(devstr = qemuBuildRedirdevDevStr(def, redirdev, priv->qemuCaps))) > >>> - goto error; > >>> > >>> - if (VIR_REALLOC_N(vm->def->redirdevs, vm->def->nredirdevs+1) < 0) > >>> + if (virAsprintf(&charAlias, "char%s", redirdev->info.alias) < 0) > >>> goto error; > >>> > >>> qemuDomainObjEnterMonitor(driver, vm); > >>> + if (qemuMonitorAttachCharDev(priv->mon, > >>> + charAlias, > >>> + &(redirdev->source.chr)) < 0) { > >>> + ignore_value(qemuDomainObjExitMonitor(driver, vm)); > >>> + goto error; > >>> + } > >>> + VIR_FREE(charAlias); > >>> + > >>> + if (!(devstr = qemuBuildRedirdevDevStr(def, redirdev, priv->qemuCaps))) > >>> + goto rollback; > >>> + > >>> + if (VIR_REALLOC_N(vm->def->redirdevs, vm->def->nredirdevs+1) < 0) > >>> + goto rollback; > >>> + > >>> ret = qemuMonitorAddDevice(priv->mon, devstr); > >>> > >>> if (qemuDomainObjExitMonitor(driver, vm) < 0) > >>> - goto error; > >>> + goto rollback; > >>> > >>> virDomainAuditRedirdev(vm, redirdev, "attach", ret == 0); > >>> if (ret < 0) > >>> - goto error; > >>> + goto rollback; > >>> > >>> vm->def->redirdevs[vm->def->nredirdevs++] = redirdev; > >>> > >>> @@ -1414,9 +1427,13 @@ int qemuDomainAttachRedirdevDevice(virQEMUDriverPtr driver, > >>> return 0; > >>> > >>> error: > >>> + VIR_FREE(charAlias); > >>> VIR_FREE(devstr); > >>> return -1; > >>> > >>> + rollback: > >>> + ignore_value(qemuMonitorDetachCharDev(priv->mon, charAlias)); > >>> + goto error; > >>> } > >>> > >>> static int > >>> -- > >>> 2.1.4 > >>> > >>> -- > >>> libvir-list mailing list > >>> libvir-list(a)redhat.com > >>> https://www.redhat.com/mailman/listinfo/libvir-list >

1 0

[libvirt] Fw: [RFC PATCH 0/2] nodeinfo: PPC64: Fix topology and siblings info on capabilities and nodeinfo
by David Gibson 22 Feb '16

22 Feb '16

Sorry, accidentally sent to just Andrea the first time around, resending... Begin forwarded message: Date: Mon, 22 Feb 2016 16:53:15 +1100 From: David Gibson <dgibson(a)redhat.com> To: Andrea Bolognani <abologna(a)redhat.com> Subject: Re: [libvirt] [RFC PATCH 0/2] nodeinfo: PPC64: Fix topology and siblings info on capabilities and nodeinfo On Fri, 19 Feb 2016 17:40:31 +0100 Andrea Bolognani <abologna(a)redhat.com> wrote: > On Tue, 2016-02-16 at 13:04 +1100, David Gibson wrote: > > > So the information don't seem to add up: we claim that the > > > host has 160 online CPUs, but the NUMA topology only contains > > > information about 5 of them per each node, so 20 in total. > > > > > > That's of course because Linux only provides us with topology > > > information for online CPUs, but KVM on ppc64 wants secondary > > > threads to be offline in the host. The secondary threads are > > > still used to schedule guest threads, so reporting 160 online > > > CPUs is correct for the purpose of planning the number of > > > guests based on the capacity of the host; the problem is that > > > the detailed NUMA topology doesn't match with that. > > > > Yeah, that's rather unfortunate. We do want to list all the threads in > > the capabilities, I think, since they're capable of running vcpus. > > There's a problem with that, though, that I didn't think about > when writing the original message. See below. > > > > The new information is more complete than it was before, and > > > this series certainly would help users make better guest > > > allocation choices. On the other hand, it doesn't really solve > > > the problem of nodeinfo and capabilities disagreeing with each > > > other, and pushes the NUMA topology reported by libvirt a > > > little farther from the one reported by the kernel. > > > > Uh.. I don't really see how nodeinfo and capabilities disagree here. > > Because nodeinfo tell us that the host has 160 online CPUs, while > capabilities tell us that only 40 CPUs are actually online. Hmm, ok. I guess the question is what does "online" mean in the context of a libvirt client. It used to be that "online in host" and "able to run vcpus" were the same thing, but now they're not. > Just to clarify, since the naming is not very explicit: nodeinfo > reports *online* CPUs only, and each <cpu> element in capabilities > is supposed to represent an *online* CPU. Offline CPUs are not > listed or counted anywhere. Ok. > > Now how the topology differs from the kernel. > > Because the kernel reports physical information, so online CPUs > that are in the same physical core (as evidenced by the core_id > value) are counted as siblings regardless of the subcore > configuration. Yeah.. I'll have a chat to Ben and/or Paul and see if they think that's the right choice for the kernel. > > > It may also break some assumptions, eg. CPU 0 and 4 both have > > > the same value for 'core_id', so I'd expect them to be among > > > each other's 'siblings', but they no longer are. > > > > Ah, yes, that's wrong. With this setup the core_id should be set to > > the id of the subcore's first thread, rather than the physical core's > > first thread. > > This would be a pretty wild departure from what the kernel is > exposing to userspace. If that's more meaningful for libvirt's clients than the kernel information, I don't think that's necessarily a problem. > > > I have a different proposal: since we're already altering the > > > NUMA topology information reported by the kernel by counting > > > secondary threads as online, we might as well go all the way > > > and rebuild the entire NUMA topology as if they were. > > > > > > So the capabilities XML when subcores-per-core=1 would look > > > like: > > > > > > <cells num='4'> > > > <cell id='0'> > > > <memory unit='KiB'>67108864</memory> > > > <pages unit='KiB' size='64'>1048576</pages> > > > <pages unit='KiB' size='16384'>0</pages> > > > <distances> > > > <sibling id='0' value='10'/> > > > <sibling id='1' value='20'/> > > > <sibling id='16' value='40'/> > > > <sibling id='17' value='40'/> > > > </distances> > > > <cpus num='10'> > > > <cpu id='0' socket_id='0' core_id='32' subcore_id='0' siblings='0-7'/> > > > > I don't think adding a subcore_id is a good idea. Because it's only > > ever likely to mean something on ppc64, tools are qlikely to just > > ignore it and use the core_id. > > Fair enough, and something we definitely need to take into account. > > > Most of the time that will be wrong: > > behaviorally subcores act like cores in almost all regards. > > > > That could be worked around by instead having core_id give the subcore > > address and adding a new "supercore_id" or "core_group_id" or something. > > Well, those would be just as likely to be ignored by tools as > subcore_id and capacity, wouldn't they? :) Yes, but it means when they ignore those and look at "core_id" they'll get the subcore id, not the physical core id, which is probably what they actually wanted. Those few (if any) tools that really, truly, need the physical core information get to look at supercore or whatever. > > But frankly, I don't think there's actually much point exposing the > > physical topology in addition to the logical (subcore) topology. Yes, > > subcores will have different performance characteristics to real cores > > which will be relevant in some situations. But if you're manually > > setting the host's subcore mode then you're already into the realm of > > manually tweaking parameters based on knowledge of your system and > > workload. Basically I don't see anything upper layers would do with > > the subcore vs. core information that isn't likely to be overriden by > > manual tweaks in any case where you're setting the subcore mode at all. > > > > Bear in mind that now that we have dynamic split core merged, I'm not > > sure there are *any* realistic use cases for using manual subcore > > splitting. > > As far as I know, and of course correct me if I'm wrong, dynamic split > cores are a way to avoid heavy performance drops when the host is Not so much heavy performance drops per se. What it's really about is mitigating the case where the system is overcommited in terms of number of virtual cores, but not in terms of number of virtual threads. Without dynamic split core the system will make more use of the host's threading capabilities, with it, it will do a much better job. > overcommitted, but it has some overhead of its own because of the need > to split the core when entering KVM and restoring the previous > configuration when exiting it. Hmm.. I guess there would be a little extra latency on entering and exiting the guest. I don't know if it's at all significant compared to the already substantial cost of entering/leaving the guest. > Splitting cores manually, on the other hand, is less flexible but > gives the admin complete control over resource allocations and has > no overhead, which makes it critical for fine performance tuning. Well.. except manual splitting can only be done system wide an only do, whereas dynamic split-core can do it per-core which might allow it to better match the workload. > So unless my understanding is off, I believe we need to expose the > topology in a way that enables both use cases. Well, that would be ideal, certainly. > > So, as noted, I actually prefer Shivaprasad's original approach of > > treating subcores as cores. The implementation of that does need some > > adjustment as noted above, basically treating subcores as cores even > > more universally than the current patches do. > > > > Basically I see manually setting the subcores-per-core as telling the > > system you want it treated as having more cores. So libvirt shouldn't > > decide it knows better and report physical cores instead. > > It's not really a case of libvirt thinking it knows better, it's more > a case of the kernel always reporting information about the physical > topology and x86 not having AFAIK any configuration where physical > and logical topology disagree, whereas that's the case on ppc64 as > soon as you split a core. Hmm. I'm not entirely sure what point you're making there. > > Tangentially related is the question of how to deal with threads which > > are offline in the host but can be used for vcpus, which appears with > > or without subcores. > > This is exactly the issue I was thinking about at the beginning of > the message: if I see a <cpu> element that means the CPU is online, > and I expect to be able to pin a vCPU to it, but that would no > longer be the case if we started adding <cpu> elements for CPUs > that are offline in the host - any attempt to pin vCPUs to such > CPUs would fail. Ah, good point. That sounds like a case for the "capacity" property then. > > I have no very strong opinion between the options of (1) adding <cpu> > > entries for the offline threads (whose siblings should be set based on > > the subcore) or (2) adding a capacity tag to the online threads > > indicating that you can put more vcpus on them that the host online > > thread count indicates. > > > > (1) is more likely to do the right thing with existing tools, but (2) > > is more accurately expressive. > > I kinda think it would be the other way around, as I expect existing > tools to make some of the assumptions described above. > > So after discussing for a while with Shivaprasad on IRC, reading > your reply and thinking about it some more, I'm starting to think > that we should report the same information as the kernel whenever > possible, and enhance it with hints such as capacity for tools > and admins, but carefully avoid being too clever for our own good. Well, I'm tempted to say that ship has sailed for libvirt.. :p. But I don't disagree. > We can paper over most of the differences between x86 and ppc64, > but not all of them, I believe. Documentation is key here, and > there's definitely room for improvement both when it comes to > reasonable assumptions and ppc64 specific quirks - this is > something I'm planning to address. > > So my proposal is to drop patch 1/2 entirely and rework patch 2/2 > to just add the capacity attribute (maybe with a more descriptive > name?), without touching the list of siblings or any other > information retrieved from the kernel. > > Cheers. > > -- > Andrea Bolognani > Software Engineer - Virtualization Team -- David Gibson <dgibson(a)redhat.com> Senior Software Engineer, Virtualization, Red Hat -- David Gibson <dgibson(a)redhat.com> Senior Software Engineer, Virtualization, Red Hat

1 0

Re: [libvirt] kvm: "warning: host doesn't support requested feature: CPUID.01H:ECX.x2apic [bit 21]"
by Eduardo Habkost 22 Feb '16

22 Feb '16

(CCing libvir-list) On Sat, Feb 20, 2016 at 04:00:30AM -0500, Paolo Bonzini wrote: > ----- Original Message ----- > > From: "Jan Kiszka" <jan.kiszka(a)web.de> > > To: "Eduardo Habkost" <ehabkost(a)redhat.com>, "Paolo Bonzini" <pbonzini(a)redhat.com> > > Cc: "qemu-devel" <qemu-devel(a)nongnu.org>, "kvm" <kvm(a)vger.kernel.org> > > Sent: Saturday, February 20, 2016 9:09:32 AM > > Subject: kvm: "warning: host doesn't support requested feature: CPUID.01H:ECX.x2apic [bit 21]" > > > > Hi all, > > > > I suppose 5120901a37 introduced this: qemu with kernel_irqchip=off now > > generates these warnings, one per VCPU, during QEMU startup. Is the plan > > to live with them until we finally have x2APIC emulation in userspace > > (ie. also MSR vmexiting to there), or should we otherwise avoid it? > > I think it's a bug, x2apic should be auto-suppressed with kernel_irqchip=off. My first reaction is to dislike the idea of adding yet another variable that affects the results of CPU models. But considering that we are moving towards a design where libvirt must not assume or query any low-level detail from CPU models at all, maybe this won't be harmful. -- Eduardo

1 0

[libvirt] [PATCH] qemu: add support for LSI SAS1068 (aka MPT Fusion) SCSI controller
by Paolo Bonzini 22 Feb '16

22 Feb '16

This does nothing more than adding the new device and capability. The device is present since QEMU 2.6.0. Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com> --- src/qemu/qemu_capabilities.c | 2 + src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_command.c | 13 ++++++- .../qemuxml2argv-disk-scsi-mptsas1068.args | 27 +++++++++++++ .../qemuxml2argv-disk-scsi-mptsas1068.xml | 36 ++++++++++++++++++ tests/qemuxml2argvtest.c | 4 ++ .../qemuxml2xmlout-disk-scsi-mptsas1068.xml | 44 ++++++++++++++++++++++ tests/qemuxml2xmltest.c | 4 ++ 8 files changed, 130 insertions(+), 1 deletion(-) create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-disk-scsi-mptsas1068.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-disk-scsi-mptsas1068.xml create mode 100644 tests/qemuxml2xmloutdata/qemuxml2xmlout-disk-scsi-mptsas1068.xml diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c index 3099e34..2b953ea 100644 --- a/src/qemu/qemu_capabilities.c +++ b/src/qemu/qemu_capabilities.c @@ -314,6 +314,7 @@ VIR_ENUM_IMPL(virQEMUCaps, QEMU_CAPS_LAST, "vserport-change-event", /* 210 */ "virtio-balloon-pci.deflate-on-oom", + "mptsas1068", ); @@ -1567,6 +1568,7 @@ struct virQEMUCapsStringFlags virQEMUCapsObjectTypes[] = { { "virtio-tablet-pci", QEMU_CAPS_VIRTIO_TABLET }, { "virtio-input-host-device", QEMU_CAPS_VIRTIO_INPUT_HOST }, { "virtio-input-host-pci", QEMU_CAPS_VIRTIO_INPUT_HOST }, + { "mptsas1068", QEMU_CAPS_SCSI_MPTSAS1068 }, }; static struct virQEMUCapsStringFlags virQEMUCapsObjectPropsVirtioBalloon[] = { diff --git a/src/qemu/qemu_capabilities.h b/src/qemu/qemu_capabilities.h index e5353de..b73c529 100644 --- a/src/qemu/qemu_capabilities.h +++ b/src/qemu/qemu_capabilities.h @@ -343,6 +343,7 @@ typedef enum { QEMU_CAPS_VSERPORT_CHANGE, /* VSERPORT_CHANGE event */ QEMU_CAPS_VIRTIO_BALLOON_AUTODEFLATE, /* virtio-balloon-{device,pci,ccw}. * deflate-on-oom */ + QEMU_CAPS_SCSI_MPTSAS1068, /* -device mptsas1068 */ QEMU_CAPS_LAST /* this must always be the last item */ } virQEMUCapsFlags; diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c index d7f19f3..4d4d65e 100644 --- a/src/qemu/qemu_command.c +++ b/src/qemu/qemu_command.c @@ -872,11 +872,19 @@ qemuSetSCSIControllerModel(virDomainDefPtr def, case VIR_DOMAIN_CONTROLLER_MODEL_SCSI_IBMVSCSI: /*TODO: need checking work here if necessary */ break; + case VIR_DOMAIN_CONTROLLER_MODEL_SCSI_LSISAS1068: + if (!virQEMUCapsGet(qemuCaps, QEMU_CAPS_SCSI_MPTSAS1068)) { + virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s", + _("This QEMU doesn't support " + "the LSI SAS1068 (MPT Fusion) controller")); + return -1; + } + break; case VIR_DOMAIN_CONTROLLER_MODEL_SCSI_LSISAS1078: if (!virQEMUCapsGet(qemuCaps, QEMU_CAPS_SCSI_MEGASAS)) { virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s", _("This QEMU doesn't support " - "the LSI SAS1078 controller")); + "the LSI SAS1078 (MegaRAID) controller")); return -1; } break; @@ -4753,6 +4761,9 @@ qemuBuildControllerDevStr(virDomainDefPtr domainDef, case VIR_DOMAIN_CONTROLLER_MODEL_SCSI_IBMVSCSI: virBufferAddLit(&buf, "spapr-vscsi"); break; + case VIR_DOMAIN_CONTROLLER_MODEL_SCSI_LSISAS1068: + virBufferAddLit(&buf, "mptsas1068"); + break; case VIR_DOMAIN_CONTROLLER_MODEL_SCSI_LSISAS1078: virBufferAddLit(&buf, "megasas"); break; diff --git a/tests/qemuxml2argvdata/qemuxml2argv-disk-scsi-mptsas1068.args b/tests/qemuxml2argvdata/qemuxml2argv-disk-scsi-mptsas1068.args new file mode 100644 index 0000000..bdfc1af --- /dev/null +++ b/tests/qemuxml2argvdata/qemuxml2argv-disk-scsi-mptsas1068.args @@ -0,0 +1,27 @@ +LC_ALL=C \ +PATH=/bin \ +HOME=/home/test \ +USER=test \ +LOGNAME=test \ +QEMU_AUDIO_DRV=none \ +/usr/bin/qemu \ +-name QEMUGuest1 \ +-S \ +-M pc \ +-m 214 \ +-smp 1 \ +-uuid c7a5fdbd-edaf-9455-926a-d65c16db1809 \ +-nographic \ +-nodefconfig \ +-nodefaults \ +-monitor unix:/tmp/test-monitor,server,nowait \ +-no-acpi \ +-boot c \ +-device mptsas1068,id=scsi0,bus=pci.0,addr=0x3 \ +-usb \ +-drive file=/dev/HostVG/QEMUGuest1,format=raw,if=none,id=drive-ide0-0-0 \ +-device ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0 \ +-drive file=/tmp/scsidisk.img,format=raw,if=none,id=drive-scsi0-0-4-0 \ +-device scsi-disk,bus=scsi0.0,channel=0,scsi-id=4,lun=0,drive=drive-scsi0-0-4-0,\ +id=scsi0-0-4-0,wwn=0x5000c50015ea71ac \ +-device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x4 diff --git a/tests/qemuxml2argvdata/qemuxml2argv-disk-scsi-mptsas1068.xml b/tests/qemuxml2argvdata/qemuxml2argv-disk-scsi-mptsas1068.xml new file mode 100644 index 0000000..b817b69 --- /dev/null +++ b/tests/qemuxml2argvdata/qemuxml2argv-disk-scsi-mptsas1068.xml @@ -0,0 +1,36 @@ +<domain type='qemu'> + <name>QEMUGuest1</name> + <uuid>c7a5fdbd-edaf-9455-926a-d65c16db1809</uuid> + <memory unit='KiB'>219136</memory> + <currentMemory unit='KiB'>219136</currentMemory> + <vcpu placement='static'>1</vcpu> + <os> + <type arch='i686' machine='pc'>hvm</type> + <boot dev='hd'/> + </os> + <clock offset='utc'/> + <on_poweroff>destroy</on_poweroff> + <on_reboot>restart</on_reboot> + <on_crash>destroy</on_crash> + <devices> + <emulator>/usr/bin/qemu</emulator> + <disk type='block' device='disk'> + <source dev='/dev/HostVG/QEMUGuest1'/> + <target dev='hda' bus='ide'/> + <address type='drive' controller='0' bus='0' target='0' unit='0'/> + </disk> + <disk type='file' device='disk'> + <source file='/tmp/scsidisk.img'/> + <target dev='sda' bus='scsi'/> + <address type='drive' controller='0' bus='0' target='4' unit='0'/> + <wwn>5000c50015ea71ac</wwn> + </disk> + <controller type='ide' index='0'/> + <controller type='scsi' index='0' model='lsisas1068'/> + <controller type='usb' index='0'/> + <controller type='pci' index='0' model='pci-root'/> + <input type='mouse' bus='ps2'/> + <input type='keyboard' bus='ps2'/> + <memballoon model='virtio'/> + </devices> +</domain> diff --git a/tests/qemuxml2argvtest.c b/tests/qemuxml2argvtest.c index 3c7693b..b5d92c4 100644 --- a/tests/qemuxml2argvtest.c +++ b/tests/qemuxml2argvtest.c @@ -865,6 +865,10 @@ mymain(void) DO_TEST("disk-scsi-megasas", QEMU_CAPS_NODEFCONFIG, QEMU_CAPS_SCSI_MEGASAS); + DO_TEST("disk-scsi-mptsas1068", + QEMU_CAPS_NODEFCONFIG, + QEMU_CAPS_SCSI_MPTSAS1068, + QEMU_CAPS_SCSI_DISK_WWN); DO_TEST("disk-sata-device", QEMU_CAPS_NODEFCONFIG, QEMU_CAPS_ICH9_AHCI); DO_TEST("disk-aio", diff --git a/tests/qemuxml2xmloutdata/qemuxml2xmlout-disk-scsi-mptsas1068.xml b/tests/qemuxml2xmloutdata/qemuxml2xmlout-disk-scsi-mptsas1068.xml new file mode 100644 index 0000000..a88b63a --- /dev/null +++ b/tests/qemuxml2xmloutdata/qemuxml2xmlout-disk-scsi-mptsas1068.xml @@ -0,0 +1,44 @@ +<domain type='qemu'> + <name>QEMUGuest1</name> + <uuid>c7a5fdbd-edaf-9455-926a-d65c16db1809</uuid> + <memory unit='KiB'>219136</memory> + <currentMemory unit='KiB'>219136</currentMemory> + <vcpu placement='static'>1</vcpu> + <os> + <type arch='i686' machine='pc'>hvm</type> + <boot dev='hd'/> + </os> + <clock offset='utc'/> + <on_poweroff>destroy</on_poweroff> + <on_reboot>restart</on_reboot> + <on_crash>destroy</on_crash> + <devices> + <emulator>/usr/bin/qemu</emulator> + <disk type='block' device='disk'> + <source dev='/dev/HostVG/QEMUGuest1'/> + <target dev='hda' bus='ide'/> + <address type='drive' controller='0' bus='0' target='0' unit='0'/> + </disk> + <disk type='file' device='disk'> + <source file='/tmp/scsidisk.img'/> + <target dev='sda' bus='scsi'/> + <wwn>5000c50015ea71ac</wwn> + <address type='drive' controller='0' bus='0' target='4' unit='0'/> + </disk> + <controller type='ide' index='0'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/> + </controller> + <controller type='scsi' index='0' model='lsisas1068'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> + </controller> + <controller type='usb' index='0'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x2'/> + </controller> + <controller type='pci' index='0' model='pci-root'/> + <input type='mouse' bus='ps2'/> + <input type='keyboard' bus='ps2'/> + <memballoon model='virtio'> + <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> + </memballoon> + </devices> +</domain> diff --git a/tests/qemuxml2xmltest.c b/tests/qemuxml2xmltest.c index d9550cc..d7d10f6 100644 --- a/tests/qemuxml2xmltest.c +++ b/tests/qemuxml2xmltest.c @@ -415,6 +415,10 @@ mymain(void) DO_TEST_FULL("disk-scsi-megasas", WHEN_ACTIVE, QEMU_CAPS_NODEFCONFIG, QEMU_CAPS_SCSI_MEGASAS); + DO_TEST_FULL("disk-scsi-mptsas1068", WHEN_ACTIVE, + QEMU_CAPS_NODEFCONFIG, + QEMU_CAPS_SCSI_MPTSAS1068, + QEMU_CAPS_SCSI_DISK_WWN); DO_TEST("disk-mirror-old"); DO_TEST_FULL("disk-mirror", WHEN_ACTIVE, NONE); DO_TEST_FULL("disk-mirror", WHEN_INACTIVE, NONE); -- 2.5.0

3 4

[libvirt] [PATCH] Fix bug of attaching redirdev device
by Osier Yang 22 Feb '16

22 Feb '16

RHBZ: https://bugzilla.redhat.com/show_bug.cgi?id=1298070 The corresponding chardev must be attached first, otherwise the the qemu command line won't be complete (missing the host part), --- src/qemu/qemu_hotplug.c | 27 ++++++++++++++++++++++----- 1 file changed, 22 insertions(+), 5 deletions(-) diff --git a/src/qemu/qemu_hotplug.c b/src/qemu/qemu_hotplug.c index ee305e7..5095e31 100644 --- a/src/qemu/qemu_hotplug.c +++ b/src/qemu/qemu_hotplug.c @@ -1381,6 +1381,7 @@ int qemuDomainAttachRedirdevDevice(virQEMUDriverPtr driver, int ret; qemuDomainObjPrivatePtr priv = vm->privateData; virDomainDefPtr def = vm->def; + char *charAlias = NULL; char *devstr = NULL; if (!virQEMUCapsGet(priv->qemuCaps, QEMU_CAPS_DEVICE)) { @@ -1391,21 +1392,33 @@ int qemuDomainAttachRedirdevDevice(virQEMUDriverPtr driver, if (qemuAssignDeviceRedirdevAlias(vm->def, redirdev, -1) < 0) goto error; - if (!(devstr = qemuBuildRedirdevDevStr(def, redirdev, priv->qemuCaps))) - goto error; - if (VIR_REALLOC_N(vm->def->redirdevs, vm->def->nredirdevs+1) < 0) + if (virAsprintf(&charAlias, "char%s", redirdev->info.alias) < 0) goto error; qemuDomainObjEnterMonitor(driver, vm); + if (qemuMonitorAttachCharDev(priv->mon, + charAlias, + &(redirdev->source.chr)) < 0) { + ignore_value(qemuDomainObjExitMonitor(driver, vm)); + goto error; + } + VIR_FREE(charAlias); + + if (!(devstr = qemuBuildRedirdevDevStr(def, redirdev, priv->qemuCaps))) + goto rollback; + + if (VIR_REALLOC_N(vm->def->redirdevs, vm->def->nredirdevs+1) < 0) + goto rollback; + ret = qemuMonitorAddDevice(priv->mon, devstr); if (qemuDomainObjExitMonitor(driver, vm) < 0) - goto error; + goto rollback; virDomainAuditRedirdev(vm, redirdev, "attach", ret == 0); if (ret < 0) - goto error; + goto rollback; vm->def->redirdevs[vm->def->nredirdevs++] = redirdev; @@ -1414,9 +1427,13 @@ int qemuDomainAttachRedirdevDevice(virQEMUDriverPtr driver, return 0; error: + VIR_FREE(charAlias); VIR_FREE(devstr); return -1; + rollback: + ignore_value(qemuMonitorDetachCharDev(priv->mon, charAlias)); + goto error; } static int -- 2.1.4

2 2

[libvirt] [PATCH v2 0/9] PCI hostdev refactoring
by Andrea Bolognani 22 Feb '16

22 Feb '16

Changes in v2: * Internal functions operate on a single device, don't pass around device lists for no reason * Use virHostdev prefix for internal functions * Split off style adjustments and comments updated to separate patches See the cover letter for v1[1] for details about the series. Cheers. [1] https://www.redhat.com/archives/libvir-list/2016-January/msg00835.html Andrea Bolognani (9): hostdev: Add virHostdevOnlyReattachPCIDevice() hostdev: Use common reattach code to rollback prepare errors hostdev: Use common reattach code in virHostdevPCINodeDeviceReAttach() hostdev: Add virHostdevOnlyDetachPCIDevice() hostdev: Use common detach code in virHostdevPCINodeDeviceDetach() hostdev: Minor style adjustments hostdev: Update comments pci: Phase out virPCIDeviceReattachInit() pci: Add debug messages when unbinding from stub driver src/libvirt_private.syms | 1 - src/util/virhostdev.c | 385 ++++++++++++++++++++++++++++++----------------- src/util/virpci.c | 30 ++-- src/util/virpci.h | 1 - tests/virpcitest.c | 5 +- 5 files changed, 272 insertions(+), 150 deletions(-) -- 2.5.0

2 29

[libvirt] About the vfio error when using SR-IOV
by Xiao Ma (xima2) 22 Feb '16

22 Feb '16

Hi, All I want to use the SR-IOV of intel 82576 NIC. I enabled IOMMU and VT-d and SR-IOV in BIOS. And enabled VT-d in kernel. The OS information is bellow: [root@host3 nova]# cat /etc/redhat-release CentOS Linux release 7.1.1503 (Core) [root@host3 nova]# uname -an Linux host3.localdomain 3.10.0-229.el7.x86_64 #1 SMP Fri Mar 6 11:36:42 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux [root@host3 nova]# rpm -qa|grep qemu libvirt-daemon-driver-qemu-1.2.8-16.el7.x86_64 qemu-kvm-1.5.3-86.el7.x86_64 qemu-kvm-common-1.5.3-86.el7.x86_64 ipxe-roms-qemu-20130517-6.gitc4bce43.el7.noarch qemu-img-1.5.3-86.el7.x86_64 [root@host3 nova]# rpm -qa|grep libvirt libvirt-daemon-1.2.8-16.el7.x86_64 libvirt-daemon-driver-nwfilter-1.2.8-16.el7.x86_64 libvirt-python-1.2.8-7.el7.x86_64 libvirt-daemon-driver-storage-1.2.8-16.el7.x86_64 libvirt-daemon-driver-qemu-1.2.8-16.el7.x86_64 libvirt-daemon-config-nwfilter-1.2.8-16.el7.x86_64 libvirt-daemon-driver-secret-1.2.8-16.el7.x86_64 libvirt-daemon-driver-interface-1.2.8-16.el7.x86_64 libvirt-client-1.2.8-16.el7.x86_64 libvirt-glib-0.1.7-3.el7.x86_64 libvirt-daemon-driver-network-1.2.8-16.el7.x86_64 libvirt-daemon-driver-nodedev-1.2.8-16.el7.x86_64 libvirt-daemon-kvm-1.2.8-16.el7.x86_64 And I can see the vf of the NIC after ‘ echo '7' > /sys/class/net/ens1f1/device/sriov_numvfs ' [root@host3 VTS2.1-demo]# lspci |grep -i ethernet 08:00.0 Ethernet controller: QLogic Corp. 10GbE Converged Network Adapter (TCP/IP Networking) (rev 02) 08:00.1 Ethernet controller: QLogic Corp. 10GbE Converged Network Adapter (TCP/IP Networking) (rev 02) 0f:00.0 Ethernet controller: Intel Corporation 82576 Gigabit Network Connection (rev 01) 0f:00.1 Ethernet controller: Intel Corporation 82576 Gigabit Network Connection (rev 01) 10:10.1 Ethernet controller: Intel Corporation 82576 Virtual Function (rev 01) 10:10.3 Ethernet controller: Intel Corporation 82576 Virtual Function (rev 01) 10:10.5 Ethernet controller: Intel Corporation 82576 Virtual Function (rev 01) 10:10.7 Ethernet controller: Intel Corporation 82576 Virtual Function (rev 01) 10:11.1 Ethernet controller: Intel Corporation 82576 Virtual Function (rev 01) 10:11.3 Ethernet controller: Intel Corporation 82576 Virtual Function (rev 01) 10:11.5 Ethernet controller: Intel Corporation 82576 Virtual Function (rev 01) I configured the interface as bellow in XML: <interface type="hostdev" managed="yes"> <mac address="fa:16:3e:f7:57:5f"/> <source> <address type="pci" domain="0x0000" bus="0x10" slot="0x10" function="0x3"/> </source> <vlan> <tag id="1000"/> </vlan> </interface> But the error output when I boot one vm: [root@host3 VTS2.1-demo]# virsh create vtc.demo.xml error: Failed to create domain from vtc.demo.xml error: internal error: early end of file from monitor: possible problem: 2016-02-22T07:38:42.169035Z qemu-kvm: -device vfio-pci,host=10:10.3,id=hostdev0,bus=pci.0,addr=0x3: vfio: error, group 17 is not viable, please ensure all devices within the iommu_group are bound to their vfio bus driver. 2016-02-22T07:38:42.169215Z qemu-kvm: -device vfio-pci,host=10:10.3,id=hostdev0,bus=pci.0,addr=0x3: vfio: failed to get group 17 2016-02-22T07:38:42.169233Z qemu-kvm: -device vfio-pci,host=10:10.3,id=hostdev0,bus=pci.0,addr=0x3: Device initialization failed. 2016-02-22T07:38:42.169248Z qemu-kvm: -device vfio-pci,host=10:10.3,id=hostdev0,bus=pci.0,addr=0x3: Device 'vfio-pci' could not be initialized Could you please help to solve it? Looking forward for your reply. Thanks.

3 2

[libvirt] [PATCH] cmdNetworkUpdate: Prefer VSH_EXCLUSIVE_OPTIONS over if-else tree
by Michal Privoznik 22 Feb '16

22 Feb '16

We have macros that check and reject mutually exclusive parameters to our commands. Use those instead of if-else tree. Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com> --- tools/virsh-network.c | 21 ++++++++------------- 1 file changed, 8 insertions(+), 13 deletions(-) diff --git a/tools/virsh-network.c b/tools/virsh-network.c index 1ae206a..d0bd7a3 100644 --- a/tools/virsh-network.c +++ b/tools/virsh-network.c @@ -907,9 +907,12 @@ cmdNetworkUpdate(vshControl *ctl, const vshCmd *cmd) bool current = vshCommandOptBool(cmd, "current"); bool config = vshCommandOptBool(cmd, "config"); bool live = vshCommandOptBool(cmd, "live"); - unsigned int flags = 0; + unsigned int flags = VIR_NETWORK_UPDATE_AFFECT_CURRENT; const char *affected; + VSH_EXCLUSIVE_OPTIONS_VAR(current, live); + VSH_EXCLUSIVE_OPTIONS_VAR(current, config); + if (!(network = virshCommandOptNetwork(ctl, cmd, NULL))) return false; @@ -962,18 +965,10 @@ cmdNetworkUpdate(vshControl *ctl, const vshCmd *cmd) xml = xmlFromFile; } - if (current) { - if (live || config) { - vshError(ctl, "%s", _("--current must be specified exclusively")); - goto cleanup; - } - flags |= VIR_NETWORK_UPDATE_AFFECT_CURRENT; - } else { - if (config) - flags |= VIR_NETWORK_UPDATE_AFFECT_CONFIG; - if (live) - flags |= VIR_NETWORK_UPDATE_AFFECT_LIVE; - } + if (config) + flags |= VIR_NETWORK_UPDATE_AFFECT_CONFIG; + if (live) + flags |= VIR_NETWORK_UPDATE_AFFECT_LIVE; if (virNetworkUpdate(network, command, section, parentIndex, xml, flags) < 0) { -- 2.4.10

2 3