- Devel - libvirt List Archives

[libvirt] [PATCH] maint: prepare for next release number
by Eric Blake 16 Oct '12

16 Oct '12

Given Daniel's announcement[1], code targetting the next release will be in 1.0.0, not 0.10.3. Changed mechanically with: for f in $(git grep -l '0$.$10\13\b') ; do sed -i -e 's/0$.$10\13/1\10\10/g' $f done [1]https://www.redhat.com/archives/libvir-list/2012-October/msg00403.html * docs/formatdomain.html.in: Use 1.0.0 for next release. * src/interface/interface_backend_udev.c: Likewise. --- Any objections? docs/formatdomain.html.in | 4 ++-- src/interface/interface_backend_udev.c | 20 ++++++++++---------- 2 files changed, 12 insertions(+), 12 deletions(-) diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in index 1ae8cf4..ad8a41b 100644 --- a/docs/formatdomain.html.in +++ b/docs/formatdomain.html.in @@ -989,7 +989,7 @@ The <code>on_lockfailure</code> element (since - 0.10.3) may be used to configure what action should be + 1.0.0) may be used to configure what action should be taken when a lock manager loses resource locks. The following actions are recognized by libvirt, although not all of them need to be supported by individual lock managers. When no action is @@ -2140,7 +2140,7 @@ address on the hosts using the <code>address</code> element. PCI devices on the other hand can only be described by their <code>address</code>. - Since 0.10.3, the <code>source</code> element + Since 1.0.0, the <code>source</code> element of USB devices may contain <code>startupPolicy</code> attribute which can be used to define policy what to do if the specified host USB device is not found. The attribute accepts the following values: diff --git a/src/interface/interface_backend_udev.c b/src/interface/interface_backend_udev.c index 1cb6dfe..0cb344e 100644 --- a/src/interface/interface_backend_udev.c +++ b/src/interface/interface_backend_udev.c @@ -520,16 +520,16 @@ cleanup: static virInterfaceDriver udevIfaceDriver = { "udev", - .open = udevIfaceOpenInterface, /* 0.10.3 */ - .close = udevIfaceCloseInterface, /* 0.10.3 */ - .numOfInterfaces = udevIfaceNumOfInterfaces, /* 0.10.3 */ - .listInterfaces = udevIfaceListInterfaces, /* 0.10.3 */ - .numOfDefinedInterfaces = udevIfaceNumOfDefinedInterfaces, /* 0.10.3 */ - .listDefinedInterfaces = udevIfaceListDefinedInterfaces, /* 0.10.3 */ - .listAllInterfaces = udevIfaceListAllInterfaces, /* 0.10.3 */ - .interfaceLookupByName = udevIfaceLookupByName, /* 0.10.3 */ - .interfaceLookupByMACString = udevIfaceLookupByMACString, /* 0.10.3 */ - .interfaceIsActive = udevIfaceIsActive, /* 0.10.3 */ + .open = udevIfaceOpenInterface, /* 1.0.0 */ + .close = udevIfaceCloseInterface, /* 1.0.0 */ + .numOfInterfaces = udevIfaceNumOfInterfaces, /* 1.0.0 */ + .listInterfaces = udevIfaceListInterfaces, /* 1.0.0 */ + .numOfDefinedInterfaces = udevIfaceNumOfDefinedInterfaces, /* 1.0.0 */ + .listDefinedInterfaces = udevIfaceListDefinedInterfaces, /* 1.0.0 */ + .listAllInterfaces = udevIfaceListAllInterfaces, /* 1.0.0 */ + .interfaceLookupByName = udevIfaceLookupByName, /* 1.0.0 */ + .interfaceLookupByMACString = udevIfaceLookupByMACString, /* 1.0.0 */ + .interfaceIsActive = udevIfaceIsActive, /* 1.0.0 */ }; int -- 1.7.11.7

2 2

[libvirt] [PATCH] maint: fix license on polkit script
by Eric Blake 16 Oct '12

16 Oct '12

As approved here: https://www.redhat.com/archives/libvir-list/2012-October/msg00701.html * daemon/libvirtd.policy.in: Use LGPLv2+ license. --- I'm waiting for an ack on this one - even though the change is only to comments, I am taking due caution to ensure no one was trying to use this in an exact LGPLv2.0 setup, where changing to LGPLv2.1+ to match the rest of libvirt would hurt them. daemon/libvirtd.policy.in | 18 +++++++++++++++--- 1 file changed, 15 insertions(+), 3 deletions(-) diff --git a/daemon/libvirtd.policy.in b/daemon/libvirtd.policy.in index 000c17e..2ec7716 100644 --- a/daemon/libvirtd.policy.in +++ b/daemon/libvirtd.policy.in @@ -6,10 +6,22 @@  <policyconfig> -- 1.7.11.7

2 2

[libvirt] [PATCH 00/12]
by Daniel P. Berrange 16 Oct '12

16 Oct '12

An update of https://www.redhat.com/archives/libvir-list/2012-August/msg00618.html Mostly this is a rebase to latest GIT. Alot of the questions raised with review last time bogged down on whether the APIs were design in the right way. I think I clarified their intended usage, so hopefully we can do code review this time :-) There are still a few more patches to add on to this - Serialize the tx/rx message queues so we don't loose partially sent/received messages across re-exec() - Make fcntl driver more configurable in its behaviour - Add support for leases based on LVM UUID and SCSI WWN

2 26

[libvirt] [PATCH] conf: add test for boot dev and order
by Martin Kletzander 16 Oct '12

16 Oct '12

Add test for 280b8c9e7c94db1decdca08d169c88554c09fa19. --- .../qemuxml2argv-boot-dev+order.xml | 56 ++++++++++++++++++++++ tests/qemuxml2argvtest.c | 3 ++ 2 files changed, 59 insertions(+) create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-boot-dev+order.xml diff --git a/tests/qemuxml2argvdata/qemuxml2argv-boot-dev+order.xml b/tests/qemuxml2argvdata/qemuxml2argv-boot-dev+order.xml new file mode 100644 index 0000000..ad3d88c --- /dev/null +++ b/tests/qemuxml2argvdata/qemuxml2argv-boot-dev+order.xml @@ -0,0 +1,56 @@ +<domain type='qemu'> + <name>QEMUGuest1</name> + <uuid>c7a5fdbd-edaf-9455-926a-d65c16db1809</uuid> + <memory unit='KiB'>219100</memory> + <currentMemory unit='KiB'>219100</currentMemory> + <vcpu placement='static'>1</vcpu> + <os> + <type arch='i686' machine='pc'>hvm</type> + <boot dev='hd'/> + <boot dev='cdrom'/> + <boot dev='network'/> + </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='cdrom'> + <source file='/root/boot.iso'/> + <target dev='hdc' bus='ide'/> + <readonly/> + <boot order='1'/> + <address type='drive' controller='0' bus='1' target='0' unit='0'/> + </disk> + <disk type='network' device='disk'> + <driver name='qemu' type='raw'/> + <source protocol='sheepdog' name='image'> + <host name='example.org' port='6000'/> + </source> + <target dev='vda' bus='virtio'/> + <boot order='3'/> + </disk> + <disk type='file' device='floppy'> + <driver name='qemu' type='raw'/> + <source file='/dev/null'/> + <target dev='fdb' bus='fdc'/> + <boot order='4'/> + <address type='drive' controller='0' bus='0' target='0' unit='1'/> + </disk> + <controller type='usb' index='0'/> + <controller type='ide' index='0'/> + <controller type='fdc' index='0'/> + <interface type='user'> + <mac address='00:11:22:33:44:55'/> + <model type='virtio'/> + <boot order='2'/> + </interface> + <memballoon model='virtio'/> + </devices> +</domain> diff --git a/tests/qemuxml2argvtest.c b/tests/qemuxml2argvtest.c index 7732ae1..3ecd957 100644 --- a/tests/qemuxml2argvtest.c +++ b/tests/qemuxml2argvtest.c @@ -375,6 +375,9 @@ mymain(void) DO_TEST("boot-menu-disable-drive-bootindex", QEMU_CAPS_BOOT_MENU, QEMU_CAPS_DEVICE, QEMU_CAPS_DRIVE, QEMU_CAPS_BOOTINDEX); + DO_TEST_PARSE_ERROR("boot-dev+order", + QEMU_CAPS_BOOTINDEX, QEMU_CAPS_DRIVE, QEMU_CAPS_DEVICE, + QEMU_CAPS_VIRTIO_BLK_SCSI, QEMU_CAPS_VIRTIO_BLK_SG_IO); DO_TEST("boot-order", QEMU_CAPS_BOOTINDEX, QEMU_CAPS_DRIVE, QEMU_CAPS_DEVICE, QEMU_CAPS_VIRTIO_BLK_SCSI, QEMU_CAPS_VIRTIO_BLK_SG_IO); -- 1.7.12.3

2 2

[libvirt] [RFC][PATCH] change the meaning of vnc port in xml
by Hu Tao 16 Oct '12

16 Oct '12

Now the vnc port in xml file reflects the REAL port hypervisor will listen on for vnc connection. But vnc ports usually start from 5900, it's common to say 0 for 5900, 1 for 5901, and so on. This patch forbids negative vnc port number in xml, and maps port number below 5900 to 5900+port, but no change to those greater than 5900. --- I have no idea whether this behaviour is sane or not. But my vnc client(vinagre) has the same behaviour, i.e., treats port 0 as 5900, 1 as 5901, but 5900 as 5900, 5901 as 5901. src/conf/domain_conf.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c index 0cea8eb..b3cbc34 100644 --- a/src/conf/domain_conf.c +++ b/src/conf/domain_conf.c @@ -6423,6 +6423,12 @@ virDomainGraphicsDefParseXML(xmlNodePtr node, if (flags & VIR_DOMAIN_XML_INACTIVE) def->data.vnc.port = 0; def->data.vnc.autoport = 1; + } else if (def->data.vnc.port < 0) { + virReportError(VIR_ERR_XML_ERROR, + _("invalid vnc port %s"), port); + goto error; + } else if (def->data.vnc.port < 5900) { + def->data.vnc.port += 5900; } } else { def->data.vnc.port = 0; -- 1.7.10.2

3 2

[libvirt] [PATCH] conf: Fix crash with cleanup
by Martin Kletzander 16 Oct '12

16 Oct '12

There was a crash possible when both <boot dev... and <boot order... were specified due to virDomainDefParseBootXML() erroring out before setting *tmp (which was free'd in cleanup). As a fix, I created this cleanup that uses one pointer for all the temporary stored XPath strings and values, plus this pointer is correctly initialized to NULL. --- src/conf/domain_conf.c | 21 ++++++++++----------- 1 file changed, 10 insertions(+), 11 deletions(-) diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c index 0cea8eb..f0c5d50 100644 --- a/src/conf/domain_conf.c +++ b/src/conf/domain_conf.c @@ -8242,8 +8242,7 @@ virDomainDefParseBootXML(xmlXPathContextPtr ctxt, { xmlNodePtr *nodes = NULL; int i, n; - char *bootstr, *tmp; - char *useserial = NULL; + char *tmp = NULL; int ret = -1; unsigned long deviceBoot, serialPorts; @@ -8290,23 +8289,23 @@ virDomainDefParseBootXML(xmlXPathContextPtr ctxt, def->os.bootDevs[0] = VIR_DOMAIN_BOOT_DISK; } - bootstr = virXPathString("string(./os/bootmenu[1]/@enable)", ctxt); - if (bootstr) { - def->os.bootmenu = virDomainBootMenuTypeFromString(bootstr); + tmp = virXPathString("string(./os/bootmenu[1]/@enable)", ctxt); + if (tmp) { + def->os.bootmenu = virDomainBootMenuTypeFromString(tmp); if (def->os.bootmenu <= 0) { /* In order not to break misconfigured machines, this * should not emit an error, but rather set the bootmenu * to disabled */ VIR_WARN("disabling bootmenu due to unknown option '%s'", - bootstr); + tmp); def->os.bootmenu = VIR_DOMAIN_BOOT_MENU_DISABLED; } - VIR_FREE(bootstr); + VIR_FREE(tmp); } - useserial = virXPathString("string(./os/bios[1]/@useserial)", ctxt); - if (useserial) { - if (STREQ(useserial, "yes")) { + tmp = virXPathString("string(./os/bios[1]/@useserial)", ctxt); + if (tmp) { + if (STREQ(tmp, "yes")) { if (virXPathULong("count(./devices/serial)", ctxt, &serialPorts) < 0) { virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s", @@ -8318,6 +8317,7 @@ virDomainDefParseBootXML(xmlXPathContextPtr ctxt, } else { def->os.bios.useserial = VIR_DOMAIN_BIOS_USESERIAL_NO; } + VIR_FREE(tmp); } tmp = virXPathString("string(./os/bios[1]/@rebootTimeout)", ctxt); @@ -8339,7 +8339,6 @@ virDomainDefParseBootXML(xmlXPathContextPtr ctxt, cleanup: VIR_FREE(tmp); - VIR_FREE(useserial); VIR_FREE(nodes); return ret; } -- 1.7.12.3

3 4

[libvirt] Problems using netdev_del+netdev_add w/o corresponding device_del+device_add
by Laine Stump 16 Oct '12

16 Oct '12

I am attempting to enhance libvirt's virDomainUpdateDeviceFlags() API to support changing "just about anything" about the host side of a PCI network device without actually detaching the PCI device from the guest. Here is a patch I sent to the libvirt mailing list that I had thought would accomplish this task: https://www.redhat.com/archives/libvir-list/2012-October/msg00546.html I am using qemu-kvm-1.2-0.1.20120806git3e430569.fc17.x86_64 on Fedora 17 for my testing. Since the host side and guest side are created (and deleted) with separate monitor commands ("netdev_(add|del)" vs. "device_(add|del)", we had thought that it would be possible to use netdev_del to disconnect everything from the host side, [*not disconnect the guest side*], then create a new tap device and connect it with netdev_add(). And, actually, the netdev_del+netdev_add sequence does complete without error; unfortunately, no traffic is visible on the tap device (looking from the host with tcpdump). When I modify the patch above to also include the device_del and device_add monitor calls (with a 3 second delay in between to allow for the guest's PCI detach to complete), then the device does work properly. Of course in this case (1) the guest sees the device completely disappear for a period, then reappear, which is more disruption than I want, and (2) because qemu has no asynchronous event to notify libvirt when the guest's PCI detach has actually completed, I have to stick in an arbitrary call to sleep() which is generally *way* too long, but may be too short in some cases of extremely high load. The only comment I got from IRC on Friday afternoon (I know - not a good time to be looking for people) was that they would be "surprised if it did work". So, I have the following questions: 1) Should this work? If it's supposed to work now: 2) can you give hints (aside from watching the qemu monitor commands and responses with stap) on what I might need to change, or how to further debug my problem within qemu? (I'm pretty well convinced that the libvirt code is doing the tap device creation/etc correctly). 3) alternately can you verify that this is a known bug? Is fixing it on anyone's todo list? If it's not supposed to work now: 4) Does it sound like a reasonable thing for qemu to support? 5) Is there some other formal way to request addition of this functionality (aside from figuring it out myself and posting a patch)? ******************************************** For reference, here is the sequence of qemu monitor commands sent by libvirt to fully detach, then fully reattach a network device. Note that fd is a newly opened TAP device. Also note the 3 second interval between the netdev_del and the next command: 96.671 > 0x7f8e20000c90 {"execute":"device_del","arguments":{"id":"net0"},"id":"libvirt-25"} 96.673 < 0x7f8e20000c90 {"return": {}, "id": "libvirt-25"} 96.674 > 0x7f8e20000c90 {"execute":"netdev_del","arguments":{"id":"hostnet0"},"id":"libvirt-26"} 96.695 < 0x7f8e20000c90 {"return": {}, "id": "libvirt-26"} 99.777 > 0x7f8e20000c90 {"execute":"getfd","arguments":{"fdname":"fd-net0"},"id":"libvirt-27"} (fd=27) 99.777 < 0x7f8e20000c90 {"return": {}, "id": "libvirt-27"} 99.778 > 0x7f8e20000c90 {"execute":"netdev_add","arguments":{"type":"tap","fd":"fd-net0","id":"hostnet0"},"id":"libvirt-28"} 99.778 < 0x7f8e20000c90 {"return": {}, "id": "libvirt-28"} 99.779 > 0x7f8e20000c90 {"execute":"device_add","arguments":{"driver":"virtio-net-pci","netdev":"hostnet0","id":"net0","mac":"52:54:00:d8:bd:b9","bus":"pci.0","addr":"0x4"},"id":"libvirt-29"} 99.780 < 0x7f8e20000c90 {"return": {}, "id": "libvirt-29"} After this sequence is done, the guest network device is fully functioning. Here is the sequence sent to disconnect only the host side, then reconnect it with a new tap device. (although the fd is the same, this is because the old tap device had already been closed, so the number is just being used - the same thing happens when doing sequential full detach/attach cycles, and they all work with no problems): 168.750 > 0x7f8e20000c90 {"execute":"netdev_del","arguments":{"id":"hostnet0"},"id":"libvirt-30"} 168.762 < 0x7f8e20000c90 {"return": {}, "id": "libvirt-30"} 168.800 > 0x7f8e20000c90 {"execute":"getfd","arguments":{"fdname":"fd-net0"},"id":"libvirt-31"} (fd=27) 168.801 < 0x7f8e20000c90 {"return": {}, "id": "libvirt-31"} 168.801 > 0x7f8e20000c90 {"execute":"netdev_add","arguments":{"type":"tap","fd":"fd-net0","id":"hostnet0"},"id":"libvirt-32"} 168.802 < 0x7f8e20000c90 {"return": {}, "id": "libvirt-32"} 168.802 > 0x7f8e20000c90 {"execute":"set_link","arguments":{"name":"net0","up":true},"id":"libvirt-33"} 168.803 < 0x7f8e20000c90 {"return": {}, "id": "libvirt-33"} After this sequence is done, everything about the network device *appears* normal on both the guest and host (at least the things I know to look at), but no traffic from the host shows up in a tcpdump of the interface on the guest, and no traffic from the guest shows up in a tcpdump of the tap device on the host. Oh - the extra "set_link" command at the end is because I noticed that the flags shown in ifconfig in the guest switched from: UP BROADCAST RUNNING MULTICAST to UP BROADCAST MULTICAST when reconnecting in this way, so I was hoping that forcing the interface up would solve my problems. It didn't :-/ (Another note: I also tried adding a delay after the netdev_del, and that also did nothing.)

4 7

[libvirt] [PATCHv2 0/9] New API to retrieve host node CPU map
by Viktor Mihajlovski 16 Oct '12

16 Oct '12

V2 Changes: Added python binding for virNodeGetCPUMapFlags. Removed RFC stanza. --- Viktor Mihajlovski (9): virNodeGetCPUMapFlags: Define public API. virNodeGetCPUMapFlags: Define driver API. virNodeGetCPUMapFlags: Implement public API. virNodeGetCPUMapFlags: Implement wire protocol. libvirt.h.in: Add new cpumap macro VIR_CPU_USED virNodeGetCPUMapFlags: Implement virsh support. virNodeGetCPUMapFlags: Implement support function in nodeinfo virNodeGetCPUMapFlags: Implement driver support virNodeGetCPUMapFlags: Add python binding daemon/remote.c | 44 ++++++++++++++++++++++++++++++ include/libvirt/libvirt.h.in | 28 ++++++++++++++++--- python/generator.py | 1 + python/libvirt-override-api.xml | 6 ++++ python/libvirt-override.c | 56 +++++++++++++++++++++++++++++++++++++++ src/driver.h | 7 +++++ src/libvirt.c | 56 +++++++++++++++++++++++++++++++++++++++ src/libvirt_private.syms | 1 + src/libvirt_public.syms | 5 +++ src/nodeinfo.c | 49 ++++++++++++++++++++++++++++++++++ src/nodeinfo.h | 6 ++++ src/qemu/qemu_driver.c | 1 + src/remote/remote_driver.c | 49 ++++++++++++++++++++++++++++++++++ src/remote/remote_protocol.x | 13 ++++++++- src/remote_protocol-structs | 12 ++++++++ src/test/test_driver.c | 30 +++++++++++++++++++++ tools/virsh-host.c | 41 ++++++++++++++++++++++++++++ tools/virsh.pod | 5 +++ 18 files changed, 405 insertions(+), 5 deletions(-)

1 9

[libvirt] [PATCH] spec: Add runtime requirement for libssh2
by Peter Krempa 16 Oct '12

16 Oct '12

libssh2 unfortunately doesn't support symbol versioning so RPM can't figure out what version is needed for the currently installed libvirt package. This patch adds a runtime requirement, so that the correct version of libssh2 can be installed along with libvirt. --- libvirt.spec.in | 1 + 1 file changed, 1 insertion(+) diff --git a/libvirt.spec.in b/libvirt.spec.in index 75623eb..bc6a1af 100644 --- a/libvirt.spec.in +++ b/libvirt.spec.in @@ -500,6 +500,7 @@ BuildRequires: libcap-ng-devel >= 0.5.0 %if %{with_phyp} || %{with_libssh2_transport} %if %{with_libssh2_transport} BuildRequires: libssh2-devel >= 1.3.0 +Requires: libssh2 >= 1.3.0 %else BuildRequires: libssh2-devel %endif -- 1.7.12.3

2 1

[libvirt] [PATCH] selinux: Use raw contexts 2
by Martin Kletzander 16 Oct '12

16 Oct '12

In commit 9674f2c637114fa6ac0680fe5658a41a62bb34a8, I forgot to change selabel_lookup with the other functions, so this one-liner does exactly that. --- src/security/security_selinux.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/security/security_selinux.c b/src/security/security_selinux.c index 10135ed..e6fba21 100644 --- a/src/security/security_selinux.c +++ b/src/security/security_selinux.c @@ -861,7 +861,7 @@ getContext(const char *newpath, mode_t mode, security_context_t *fcon) if (handle == NULL) return -1; - ret = selabel_lookup(handle, fcon, newpath, mode); + ret = selabel_lookup_raw(handle, fcon, newpath, mode); selabel_close(handle); return ret; #else -- 1.7.12.3

2 2