- Devel - libvirt List Archives

[libvirt] [PATCH] Use correct pci addresses during interface-detach[v2]
by Nitesh Konkar 19 Feb '16

19 Feb '16

The virsh attach virsh detach interface command fails when both live and config are set and when the interface gets attached to different pci slots on live and config xml respectively. When we attach an interface with both --live and --config, the first time they get the same PCI slots, but the second time onwards it differs and hence the virsh detach-interface --live --config command fails. This patch makes sure that when both --live --config are set , qemuDomainDetachDeviceFlags is called twice, once with config xml and once with live xml. Steps to see the issue: virsh attach-interface --domain DomainName --type network --source default --mac 52:54:00:4b:76:5f --live --config virsh detach-interface --domain DomainName --type network --mac 52:54:00:4b:76:5f --live --config virsh attach-interface --domain DomainName --type network --source default --mac 52:54:00:4b:76:5f --live --config virsh detach-interface --domain DomainName --type network --mac 52:54:00:4b:76:5f --live --config Signed-off-by:nitkon12@linux.vnet.ibm.com --- tools/virsh-domain.c | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/tools/virsh-domain.c b/tools/virsh-domain.c index 62acecb..43c8436 100644 --- a/tools/virsh-domain.c +++ b/tools/virsh-domain.c @@ -10815,7 +10815,7 @@ cmdDetachInterface(vshControl *ctl, const vshCmd *cmd) char buf[64]; int diff_mac; size_t i; - int ret; + int ret, flag_live_config_both = 0; bool functionReturn = false; unsigned int flags = VIR_DOMAIN_AFFECT_CURRENT; bool current = vshCommandOptBool(cmd, "current"); @@ -10830,7 +10830,7 @@ cmdDetachInterface(vshControl *ctl, const vshCmd *cmd) if (config || persistent) flags |= VIR_DOMAIN_AFFECT_CONFIG; - if (live) + if (!(config || persistent) && live) // Only Live flags |= VIR_DOMAIN_AFFECT_LIVE; if (!(dom = virshCommandOptDomain(ctl, cmd, NULL))) @@ -10851,6 +10851,8 @@ cmdDetachInterface(vshControl *ctl, const vshCmd *cmd) else doc = virDomainGetXMLDesc(dom, 0); + forlivexml: + if (!doc) goto cleanup; @@ -10921,6 +10923,14 @@ cmdDetachInterface(vshControl *ctl, const vshCmd *cmd) if (ret != 0) { vshError(ctl, "%s", _("Failed to detach interface")); } else { + if ((config || persistent) && live && flag_live_config_both == 0) {//executed only when live config both in cmd. + doc = virDomainGetXMLDesc(dom, 0); + flag_live_config_both=1; //Need to execute this code only once + flags |= VIR_DOMAIN_AFFECT_LIVE; //set live flag + flags &= (~VIR_DOMAIN_AFFECT_CONFIG ); // need to unset config flag as config xml detach is already done. + mac=NULL; + goto forlivexml; + } vshPrint(ctl, "%s", _("Interface detached successfully\n")); functionReturn = true; } -- 1.8.3.1

1 0

[libvirt] [PATCH v2] admin: Fix memory leak in remoteAdminConnectClose
by Erik Skultety 19 Feb '16

19 Feb '16

When virt-admin is run with valgrind, this kind of output can be obtained: HEAP SUMMARY: in use at exit: 134,589 bytes in 1,031 blocks total heap usage: 2,667 allocs, 1,636 frees, 496,755 bytes allocated 88 bytes in 1 blocks are definitely lost in loss record 82 of 128 at 0x4C2A9C7: calloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) by 0x52F6D1F: virAllocVar (viralloc.c:560) by 0x5350268: virObjectNew (virobject.c:193) by 0x53503E0: virObjectLockableNew (virobject.c:219) by 0x4E3BBCB: virAdmConnectNew (datatypes.c:832) by 0x4E38495: virAdmConnectOpen (libvirt-admin.c:209) by 0x10C541: vshAdmConnect (virt-admin.c:107) by 0x10C7B2: vshAdmReconnect (virt-admin.c:163) by 0x10CC7C: cmdConnect (virt-admin.c:298) by 0x110838: vshCommandRun (vsh.c:1224) by 0x10DFD8: main (virt-admin.c:862) LEAK SUMMARY: definitely lost: 88 bytes in 1 blocks indirectly lost: 0 bytes in 0 blocks possibly lost: 0 bytes in 0 blocks still reachable: 134,501 bytes in 1,030 blocks suppressed: 0 bytes in 0 blocks This is because virNetClientSetCloseCallback was being reinitialized incorrectly. By resetting the callbacks in a proper way, the leak is fixed. --- src/admin/admin_remote.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/admin/admin_remote.c b/src/admin/admin_remote.c index e634fa7..3745b9e 100644 --- a/src/admin/admin_remote.c +++ b/src/admin/admin_remote.c @@ -180,7 +180,9 @@ remoteAdminConnectClose(virAdmConnectPtr conn) goto done; } - virNetClientSetCloseCallback(priv->client, NULL, NULL, NULL); + virNetClientSetCloseCallback(priv->client, NULL, conn->closeCallback, + virObjectFreeCallback); + virNetClientClose(priv->client); rv = 0; -- 2.4.3

2 2

[libvirt] VMware driver: SessionIsActive API / Sessions.ValidateSession permission
by Richard W.M. Jones 18 Feb '16

18 Feb '16

The VMware driver currently calls the SessionIsActive API, which requires the vCenter Sessions.ValidateSession permission. https://libvirt.org/git/?p=libvirt.git;a=blob;f=src/esx/esx_vi.c;h=af822b14… This causes a problem that you have to give this permission to any libvirt client accessing VMware, and you have to give it from the very top level of vCenter, all the way down through the Cluster, Folder, hypervisor levels. This has caused a bit of pushback from virt-v2v users who consider that the SessionIsActive API is an "admin" API which they don't want to give out to roles using v2v. Is calling SessionIsActive necessary? From my (very limited) understanding, it seems as if we might use 'SessionManager. currentSession' property instead, which doesn't require admin permissions. Actually the code [see link above] already does this when ctx->hasSessionIsActive is false, but that doesn't apply to modern vCenter. See also https://libvirt.org/git/?p=libvirt.git;a=commitdiff;h=5699034b65afd49d91dff… which doesn't really explain why this was added. Also, why is it even necessary to check if the session is active here? Shouldn't we just log in unconditionally? Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org

2 4

[libvirt] [PATCH v2 0/5] Add virtio-gpu & virgl support
by Marc-André Lureau 18 Feb '16

18 Feb '16

The following series allow using virtio-gpu and virgl if qemu support it. Ths Spice bits are not yet in qemu 2.5, but should make it in 2.6 and I added the RFC patches that are expected to not change much. v1->v2: addressing Ján Tomko review - update accel2d/accel3d to be tristate and fix its usage - use a single QEMU_CAPS_DEVICE_VIRTIO_GPU cap for -device virtio-gpu-* & virtio-vga - remove qemu legacy, -vga support or command line parsing - add xml2xml tests - squash xml2argvtests with their respecitve feature addition commits - update libvirt version in doc - update commit messages Marc-André Lureau (5): Replace support{2d,3d} with accel{2d,3d} domain: replace bool accel{2d,3d} with a tristate qemu: add virtio video device qemu: add virtio-gpu virgl support RFC qemu: add spice opengl support docs/formatdomain.html.in | 11 +- docs/schemas/domaincommon.rng | 6 + src/conf/domain_conf.c | 84 +- src/conf/domain_conf.h | 6 +- src/qemu/qemu_capabilities.c | 12 + src/qemu/qemu_capabilities.h | 3 + src/qemu/qemu_command.c | 40 +- src/vbox/vbox_common.c | 18 +- src/vz/vz_sdk.c | 2 +- tests/qemucapabilitiesdata/caps_1.2.2-1.replies | 22 +- tests/qemucapabilitiesdata/caps_1.3.1-1.replies | 22 +- tests/qemucapabilitiesdata/caps_1.4.2-1.replies | 22 +- tests/qemucapabilitiesdata/caps_1.5.3-1.replies | 22 +- tests/qemucapabilitiesdata/caps_1.6.0-1.replies | 22 +- tests/qemucapabilitiesdata/caps_1.6.50-1.replies | 22 +- tests/qemucapabilitiesdata/caps_2.1.1-1.replies | 22 +- tests/qemucapabilitiesdata/caps_2.4.0-1.caps | 1 + tests/qemucapabilitiesdata/caps_2.4.0-1.replies | 95 +- tests/qemucapabilitiesdata/caps_2.5.0-1.caps | 168 + tests/qemucapabilitiesdata/caps_2.5.0-1.replies | 4043 ++++++++++++++++++++ tests/qemucapabilitiestest.c | 1 + .../qemuxml2argv-video-virtio-gpu-device.args | 23 + .../qemuxml2argv-video-virtio-gpu-device.xml | 31 + .../qemuxml2argv-video-virtio-gpu-spice-gl.args | 23 + .../qemuxml2argv-video-virtio-gpu-spice-gl.xml | 36 + .../qemuxml2argv-video-virtio-gpu-virgl.args | 23 + .../qemuxml2argv-video-virtio-gpu-virgl.xml | 33 + tests/qemuxml2argvtest.c | 14 + tests/qemuxml2xmltest.c | 4 + 29 files changed, 4732 insertions(+), 99 deletions(-) create mode 100644 tests/qemucapabilitiesdata/caps_2.5.0-1.caps create mode 100644 tests/qemucapabilitiesdata/caps_2.5.0-1.replies create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-video-virtio-gpu-device.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-video-virtio-gpu-device.xml create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-video-virtio-gpu-spice-gl.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-video-virtio-gpu-spice-gl.xml create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-video-virtio-gpu-virgl.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-video-virtio-gpu-virgl.xml -- 2.5.0

4 16

[libvirt] [PATCH] admin: Fix memory leak in remoteAdminConnectClose
by Erik Skultety 18 Feb '16

18 Feb '16

When virt-admin is run with valgrind, this kind of output can be obtained: HEAP SUMMARY: in use at exit: 134,589 bytes in 1,031 blocks total heap usage: 2,667 allocs, 1,636 frees, 496,755 bytes allocated 88 bytes in 1 blocks are definitely lost in loss record 82 of 128 at 0x4C2A9C7: calloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) by 0x52F6D1F: virAllocVar (viralloc.c:560) by 0x5350268: virObjectNew (virobject.c:193) by 0x53503E0: virObjectLockableNew (virobject.c:219) by 0x4E3BBCB: virAdmConnectNew (datatypes.c:832) by 0x4E38495: virAdmConnectOpen (libvirt-admin.c:209) by 0x10C541: vshAdmConnect (virt-admin.c:107) by 0x10C7B2: vshAdmReconnect (virt-admin.c:163) by 0x10CC7C: cmdConnect (virt-admin.c:298) by 0x110838: vshCommandRun (vsh.c:1224) by 0x10DFD8: main (virt-admin.c:862) LEAK SUMMARY: definitely lost: 88 bytes in 1 blocks indirectly lost: 0 bytes in 0 blocks possibly lost: 0 bytes in 0 blocks still reachable: 134,501 bytes in 1,030 blocks suppressed: 0 bytes in 0 blocks This is because virNetClientSetCloseCallback was being reinitialized incorrectly. By resetting the callbacks in a proper way, the leak itself is fixed, however we should still dispose of the client object properly by issuing virObjectUnref on it. --- src/admin/admin_remote.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/src/admin/admin_remote.c b/src/admin/admin_remote.c index e634fa7..e174e88 100644 --- a/src/admin/admin_remote.c +++ b/src/admin/admin_remote.c @@ -180,7 +180,11 @@ remoteAdminConnectClose(virAdmConnectPtr conn) goto done; } - virNetClientSetCloseCallback(priv->client, NULL, NULL, NULL); + virNetClientSetCloseCallback(priv->client, NULL, conn->closeCallback, + virObjectFreeCallback); + virNetClientClose(priv->client); + virObjectUnref(priv->client); + priv->client = NULL; rv = 0; -- 2.4.3

1 1

[libvirt] Libvirtd and OSX... with QEMU
by Justin Clift 18 Feb '16

18 Feb '16

Heyas, Interestingly on OSX, starting libvirtd (1.3.1) indicates it can see the installed QEMU. However, it crashes out shortly afterwards with a weird error: 2016-01-17 22:02:17.159+0000: 18446744073709551615: error : virEventPollRunOnce:648 : Unable to poll on file handles: Bad file descriptor Does anyone know what that might be about, and/or how to capture more meaningful info? :) Regards and best wishes, Justin Clift

2 6

[libvirt] [PATCH v2 00/10] Reorganizing qemu_command.c continued
by John Ferlan 18 Feb '16

18 Feb '16

v1: http://www.redhat.com/archives/libvir-list/2016-February/msg00804.html v2 changes: Patch 1 makes changes as requested from review. Patches 2-7 are v1's 4-10 take a different approach by creating qemuBuildXXXXCommandLine helper routines. Patches 8-10 are new, but follow the others... John Ferlan (10): qemu: Make basic upfront checks before create command qemu: Rename qemuBuildMachineArgStr qemu: Rename qemuBuildCpuArgStr to qemuBuildCpuCommandLine qemu: Introduce qemuBuildMemCommandLine qemu: Rename qemuBuildSmpArgStr to qemuBuildSmpCommandLine qemu: Introduce qemuBuildIOThreadCommandLine qemu: Introduce qemuBuildNumaCommandLine qemu: Introduce qemuBuildSmbiosCommandLine qemu: Introduce qemuBuildSgaCommandLine qemu: Introduce qemuBuildMonitorCommandLine src/qemu/qemu_command.c | 740 ++++++++++++++++++++++++++++-------------------- 1 file changed, 434 insertions(+), 306 deletions(-) -- 2.5.0

3 22

[libvirt] [PATCHv3 0/2] notify about reverting to a snapshot
by Dmitry Andreev 18 Feb '16

18 Feb '16

Reverting to snapshot may change domain configuration but there will be no events about that. Lack of the event become a problem for virt-manager https://bugzilla.redhat.com/show_bug.cgi?id=1081148 This patch-set introduces new event and emits it in qemuDomainRevertToSnapshot. v3: [2/2] event is emited only in the case when stopped domain is reverted to a stopped domain. Dmitry Andreev (2): Introduce new VIR_DOMAIN_EVENT_DEFINED_FROM_SNAPSHOT sub-event qemu: emit 'defined' event after reverted to snapshot without state changes examples/object-events/event-test.c | 2 ++ include/libvirt/libvirt-domain.h | 1 + src/qemu/qemu_driver.c | 8 +++++++- tools/virsh-domain.c | 3 ++- 4 files changed, 12 insertions(+), 2 deletions(-) -- 1.8.3.1

3 5

[libvirt] [PATCH] qemu: cgroup: fix cgroup permission logic
by Bjoern Walk 18 Feb '16

18 Feb '16

Fix logic error introduced in commit d6c91b3c which essentially broke starting any domain. Signed-off-by: Bjoern Walk <bwalk(a)linux.vnet.ibm.com> --- src/qemu/qemu_cgroup.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/qemu/qemu_cgroup.c b/src/qemu/qemu_cgroup.c index 53642a1..f3c5fbb 100644 --- a/src/qemu/qemu_cgroup.c +++ b/src/qemu/qemu_cgroup.c @@ -65,7 +65,7 @@ qemuSetupImagePathCgroup(virDomainObjPtr vm, if (!virCgroupHasController(priv->cgroup, VIR_CGROUP_CONTROLLER_DEVICES)) return 0; - if (readonly) + if (!readonly) perms |= VIR_CGROUP_DEVICE_WRITE; VIR_DEBUG("Allow path %s, perms: %s", -- 2.3.0

2 1

[libvirt] [PATCH v2] virsh: Remove <backingStore> when changing cdrom media source
by Peter Krempa 18 Feb '16

18 Feb '16

Since the code is changing the source image path by modifying the existing XML snippet the <backingStore> stays in place. As <backingStore> is relevant to the <source> part of the image, the update of that part makes the element invalid. CD/floppy images usually don't have a backing chain and the element is currently ignored though but it might start being used in the future so let's start behaving correctly. Drop the <backingStore> subtree once we want to update the XML. Before this patch, you'd get: $ virsh change-media --eject --print-xml 10 hdc <disk type="file" device="cdrom"> <driver name="qemu" type="qcow2"/> <backingStore type="file" index="1"> <format type="qcow2"/> <source file="/var/lib/libvirt/images/vm.1436949097"/> <backingStore/> </backingStore> <target dev="hdc" bus="ide"/> ... </disk> After: $ virsh change-media --eject --print-xml 10 hdc <disk type="file" device="cdrom"> <driver name="qemu" type="qcow2"/> <target dev="hdc" bus="ide"/> ... </disk> --- Notes: v2: - adapted to new version of code - fixed use after free from previous version - added more text to commit message tools/virsh-domain.c | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/tools/virsh-domain.c b/tools/virsh-domain.c index bf65a60..83edb21 100644 --- a/tools/virsh-domain.c +++ b/tools/virsh-domain.c @@ -11052,6 +11052,7 @@ virshUpdateDiskXML(xmlNodePtr disk_node, { xmlNodePtr tmp = NULL; xmlNodePtr source = NULL; + xmlNodePtr backingStore = NULL; xmlNodePtr target_node = NULL; xmlNodePtr text_node = NULL; char *device_type = NULL; @@ -11092,13 +11093,22 @@ virshUpdateDiskXML(xmlNodePtr disk_node, if (xmlStrEqual(tmp->name, BAD_CAST "target")) target_node = tmp; + if (xmlStrEqual(tmp->name, BAD_CAST "backingStore")) + backingStore = tmp; + /* * We've found all we needed. */ - if (source && target_node) + if (source && target_node && backingStore) break; } + /* drop the <backingStore> subtree since it would become invalid */ + if (backingStore) { + xmlUnlinkNode(backingStore); + xmlFreeNode(backingStore); + } + if (type == VIRSH_UPDATE_DISK_XML_EJECT) { if (!source) { vshError(NULL, _("The disk device '%s' doesn't have media"), target); -- 2.6.2

2 1