- Devel - libvirt List Archives

[libvirt] [PATCH] Fix parsing of 'info chardev' line endings
by Matthew Booth 07 Jan '10

07 Jan '10

This change makes the 'info chardev' parser ignore any trailing whitespace on a line. This fixes a specific problem handling a '\r\n' line ending. * src/qemu/qemu_monitor_text.c: Ignore trailing whitespace in 'info chardev' output. --- src/qemu/qemu_monitor_text.c | 26 +++++++++++++++++--------- 1 files changed, 17 insertions(+), 9 deletions(-) diff --git a/src/qemu/qemu_monitor_text.c b/src/qemu/qemu_monitor_text.c index 0cb9ea6..4fd8c4a 100644 --- a/src/qemu/qemu_monitor_text.c +++ b/src/qemu/qemu_monitor_text.c @@ -1622,15 +1622,26 @@ int qemuMonitorTextGetPtyPaths(qemuMonitorPtr mon, goto cleanup; } - char *pos = reply; /* The current start of searching */ - char *end = pos + strlen(reply); /* The end of the reply string */ + char *pos; /* The current start of searching */ + char *next = reply; /* The start of the next line */ char *eol; /* The character which ends the current line */ + char *end = reply + strlen(reply); /* The end of the reply string */ + + while (next) { + pos = next; - while (pos < end) { /* Split the output into lines */ eol = memchr(pos, '\n', end - pos); - if (eol == NULL) + if (eol == NULL) { eol = end; + next = NULL; + } else { + next = eol + 1; + } + + /* Ignore all whitespace immediately before eol */ + while (eol > pos && c_isspace(*(eol-1))) + eol -= 1; /* Look for 'filename=pty:' */ #define NEEDLE "filename=pty:" @@ -1638,13 +1649,13 @@ int qemuMonitorTextGetPtyPaths(qemuMonitorPtr mon, /* If it's not there we can ignore this line */ if (!needle) - goto next; + continue; /* id is everthing from the beginning of the line to the ':' * find ':' and turn it into a terminator */ char *colon = memchr(pos, ':', needle - pos); if (colon == NULL) - goto next; + continue; *colon = '\0'; char *id = pos; @@ -1664,9 +1675,6 @@ int qemuMonitorTextGetPtyPaths(qemuMonitorPtr mon, goto cleanup; } #undef NEEDLE - - next: - pos = eol + 1; } ret = 0; -- 1.6.5.2

3 2

[libvirt] iptables rules location
by Mihamina Rakotomandimby 06 Jan '10

06 Jan '10

Manao ahoana, Hello, Bonjour, When starting libvirt there are some iptables rules setup. I would like to know where are they stored (and the filename, I use ubuntu package, need to 'find' or 'locate'). Misaotra, Thanks, Merci. -- Architecte Informatique chez Blueline/Gulfsat: Administration Systeme, Recherche & Developpement +261 34 29 155 34 / +261 33 11 207 36

2 1

[libvirt] [PATCH] vbox_tmpl.c: avoid NULL deref upon vboxDomainCreateXML failure
by Jim Meyering 06 Jan '10

06 Jan '10

Similar to others, >From 5dcb4d95a351cb6fa32ebaafb96756275e1079e2 Mon Sep 17 00:00:00 2001 From: Jim Meyering <meyering(a)redhat.com> Date: Wed, 16 Dec 2009 13:56:57 +0100 Subject: [PATCH] vbox_tmpl.c: avoid NULL deref upon vboxDomainCreateXML failure * src/vbox/vbox_tmpl.c (vboxDomainCreateXML): Don't call vboxDomainUndefine on a NULL "dom". --- src/vbox/vbox_tmpl.c | 16 +++++----------- 1 files changed, 5 insertions(+), 11 deletions(-) diff --git a/src/vbox/vbox_tmpl.c b/src/vbox/vbox_tmpl.c index d6b681c..ba70053 100644 --- a/src/vbox/vbox_tmpl.c +++ b/src/vbox/vbox_tmpl.c @@ -990,8 +990,6 @@ cleanup: static virDomainPtr vboxDomainCreateXML(virConnectPtr conn, const char *xml, unsigned int flags ATTRIBUTE_UNUSED) { - virDomainPtr dom = NULL; - /* VirtualBox currently doesn't have support for running * virtual machines without actually defining them and thus * for time being just define new machine and start it. @@ -1000,17 +998,13 @@ static virDomainPtr vboxDomainCreateXML(virConnectPtr conn, const char *xml, * change this behaviour to the expected one. */ - dom = vboxDomainDefineXML(conn, xml); - if (dom) { - if (vboxDomainCreate(dom) < 0) - goto cleanup; - } else { - goto cleanup; - } + virDomainPtr dom = vboxDomainDefineXML(conn, xml); + if (dom == NULL) + return NULL; - return dom; + if (0 < vboxDomainCreate(dom)) + return dom; -cleanup: vboxDomainUndefine(dom); return NULL; } -- 1.6.6.rc2.275.g51e2d

2 7

[libvirt] [PATCH] qemu_driver.c: remove useless, warning-provoking test
by Jim Meyering 06 Jan '10

06 Jan '10

Tools like coverity and maybe clang notice that we dereference uri_out, and then (later) test whether uri_out is NULL. Obviously one or the other must go. Presuming that we will always pass a non-NULL uri_out arg to this function, I chose to mark that parameter as ATTRIBUTE_NONNULL. I removed the unnecessary test, too. If anyone is concerned that a non-NULL (non-literal) value will be passed, I can also add an assertion. >From 6ce3a9656d978b37d866f55606bc5031ad8e6b2f Mon Sep 17 00:00:00 2001 From: Jim Meyering <meyering(a)redhat.com> Date: Tue, 5 Jan 2010 16:32:11 +0100 Subject: [PATCH] qemu_driver.c: remove useless, warning-provoking test * src/qemu/qemu_driver.c (qemudDomainMigratePrepare2): Remove useless test of always-non-NULL uri_out parameter. Use ATTRIBUTE_NONNULL to inform tools. --- src/qemu/qemu_driver.c | 6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index 4639478..daa6f94 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -1,7 +1,7 @@ /* * driver.c: core driver methods for managing qemu guests * - * Copyright (C) 2006, 2007, 2008, 2009 Red Hat, Inc. + * Copyright (C) 2006, 2007, 2008, 2009, 2010 Red Hat, Inc. * Copyright (C) 2006 Daniel P. Berrange * * This library is free software; you can redistribute it and/or @@ -6961,7 +6961,7 @@ cleanup: * * This starts an empty VM listening on a TCP port. */ -static int +static int ATTRIBUTE_NONNULL (5) qemudDomainMigratePrepare2 (virConnectPtr dconn, char **cookie ATTRIBUTE_UNUSED, int *cookielen ATTRIBUTE_UNUSED, @@ -7068,7 +7068,7 @@ qemudDomainMigratePrepare2 (virConnectPtr dconn, } } - if (uri_out && *uri_out) + if (*uri_out) VIR_DEBUG("Generated uri_out=%s", *uri_out); /* Parse the domain XML. */ -- 1.6.6.387.g2649b1

2 2

[libvirt] [PATCH] qemu_driver.c: avoid NULL dereference upon disk-op failure
by Jim Meyering 06 Jan '10

06 Jan '10

The local, "cgroup" is initialized to NULL, and may still have that value when the code below is reached. That would provoke a NULL-dereference in virCgroupDenyDevicePath. >From c1caed370a7b2eae2e964a6059b014530143075c Mon Sep 17 00:00:00 2001 From: Jim Meyering <meyering(a)redhat.com> Date: Wed, 16 Dec 2009 14:15:50 +0100 Subject: [PATCH] qemu_driver.c: avoid NULL dereference upon disk-op failure * src/qemu/qemu_driver.c (qemudDomainAttachDevice): Call virCgroupDenyDevicePath only if cgroup is non-NULL. --- src/qemu/qemu_driver.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index 9ef6c35..81afecf 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -5485,7 +5485,7 @@ static int qemudDomainAttachDevice(virDomainPtr dom, virDomainDiskDeviceTypeToString(dev->data.disk->device)); /* Fallthrough */ } - if (ret != 0) { + if (ret != 0 && cgroup) { virCgroupDenyDevicePath(cgroup, dev->data.disk->src); } -- 1.6.6.rc2.275.g51e2d

2 2

[libvirt] Migration with non-shared storage
by Kenneth Nagin 06 Jan '10

06 Jan '10

Support for live migration between hosts that do not share storage was added to qemu-kvm release 0.12.1. It supports two flags: -b migration without shared storage with full disk copy -i migration without shared storage with incremental copy (same base image shared between source and destination). I suggest adding these flags to virDomainMigrate. If I'm not mistaken qemuMonitorTextMigrate is the function that actually invokes the kvm monitor. Thus, it would be necessary to pass the flags to qemuMonitorTextMigrate.. But qemuMonitorTextMigrate does not have a flag input parameter. I think the least disruptive way to support the new flags is use the existing "background" parameter to pass the flags. Of course this would require some changes to the upstream functions that are invoked for migration. What do you think? Kenneth Nagin

1 0

[libvirt] [PATCH] openvz_conf.c: don't dereference NULL upon failure
by Jim Meyering 05 Jan '10

05 Jan '10

"dom" is set to NULL within the while loop: virDomainObjUnlock(dom); dom = NULL; If on a subsequent iteration something fails, we goto "cleanup" or "no_memory", both of which have us run this code: fclose(fp); virDomainObjUnref(dom); return -1; And the virDomainObjUnref function would dereference "dom". >From 3971ff17c7e9f1ddbc443d48b86fe6ba60a2d4a0 Mon Sep 17 00:00:00 2001 From: Jim Meyering <meyering(a)redhat.com> Date: Tue, 15 Dec 2009 16:16:57 +0100 Subject: [PATCH] openvz_conf.c: don't dereference NULL upon failure * src/openvz/openvz_conf.c (openvzLoadDomains): Avoid NULL deref of "dom". --- src/openvz/openvz_conf.c | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/src/openvz/openvz_conf.c b/src/openvz/openvz_conf.c index 7e9abbf..43bbaf2 100644 --- a/src/openvz/openvz_conf.c +++ b/src/openvz/openvz_conf.c @@ -535,7 +535,8 @@ int openvzLoadDomains(struct openvz_driver *driver) { cleanup: fclose(fp); - virDomainObjUnref(dom); + if (dom) + virDomainObjUnref(dom); return -1; } -- 1.6.6.rc2.275.g51e2d

2 2

[libvirt] [PATCH 0/3] Block assignment of PCI devices below non-ACS capable switch
by Jiri Denemark 05 Jan '10

05 Jan '10

Hi. This is a patchset for blocking assignment of PCI devices below non-ACS capable switch. In case user still wants to assign such device even though it might not be safe, she can specify permissive='yes' attribute for <hostdev>. Special thanks to Chris L. who created a standalone program the PCI check. This code is a port of that check to libvirt. Jiri Denemark (3): Tests for ACS in PCIe switches New 'permissive' attribute for hostdev Use pciDeviceIsAssignable in qemu driver docs/schemas/domain.rng | 8 +++ src/conf/domain_conf.c | 14 ++++- src/conf/domain_conf.h | 1 + src/libvirt_private.syms | 3 + src/qemu/qemu_driver.c | 9 +++- src/util/pci.c | 147 ++++++++++++++++++++++++++++++++++++++++++++++ src/util/pci.h | 7 ++ 7 files changed, 186 insertions(+), 3 deletions(-)

5 12

Re: [libvirt] New libvirt API for domain memory statistics reporting (V3)
by Thomas Treutner 04 Jan '10

04 Jan '10

On Wednesday 23 December 2009 19:42:20 Adam Litke wrote: > Attached to this email are two patches: > > memstats-kernel-2.6.32-rc5.patch: > Applies to 2.6.32-rc5 which should be a capable-enough kernel for > testing and development. > > memstats-qemu-0.12.1.patch: > Applies to qemu-0.12.1 which can be found here: > http://mirrors.igsobe.com/nongnu/qemu/qemu-0.12.1.tar.gz > Unfortunately, it is not trivial for me to port this work to 0.11.0 so > you will have to find a resolution to your BIOS woes first and then use > this version. Who knows, it might already be fixed in 0.12.1. I tried with qemu-*kvm*-0.12.1.1, no memstats yet, but dynamically setting the amount of memory now doesn't work at all. I'll try to isolate the problem, I suspect it comes from qemu-kvm-0.12.1.1. I can't use qemu-0.12.1: $ ./configure --enable-kvm --disable-xen #error Missing KVM capability KVM_CAP_DESTROY_MEMORY_REGION_WORKS NOTE: To enable KVM support, update your kernel to 2.6.29+ or install recent kvm-kmod from http://sourceforge.net/projects/kvm. ERROR ERROR: User requested feature kvm ERROR: configure was not able to find it ERROR $ uname -r 2.6.32.2 $ modinfo kvm_amd ... vermagic: 2.6.32.2 SMP mod_unload modversions .... kr,tom

2 1

[libvirt] [PATCH 0/12] Standardized device addressing & SCSI controller/disk hotplug
by Daniel P. Berrange 04 Jan '10

04 Jan '10

This patch series is a combination of series done by Wolfgang Mauerer to support proper SCSI drive hotplug and new work by myself to introduce generic addressing for all devices. Wolfgang's most recent posting was http://www.redhat.com/archives/libvir-list/2009-November/msg00574.html http://www.redhat.com/archives/libvir-list/2009-November/msg00701.html When testing that series I came across a few minor issues, but more importantly it made me realize how important it is that we introduce explicit device addressing in our XML format. Wolfgang's series had added new element for SCSI controllers, with PCI address info about the controller <controller type='ide' index='0'> <address domain='0x0000' bus='0x00' slot='0x01' function='0x1'/> </controller> And had also extended the <disk> element to include a SCSI controller name, and bus/unit ID. eg <disk> ... <controller name="<identifier>" pci_addr="<addr>" bus="<number>" unit="<number>"/> </disk> I then remembered that for support NIC/VirtIO/hostdev disk unplug Mark M had previously added PCI address information to the internal XML state files for <interface>, <disk> and <hostdev> elements. All of these places using PCI addresses suffered from the fact that we only knew the addresses of devices we'd hotplug and had no idea of addresses of devices present at boot time. A further issue with the addition of <controller> to the <disk> element, is that not all disk types have a concept of a controller. For example, every VirtIO disk is in fact a full PCI device, so having a <controller> element in <disk> is not meaningful for VirtIO. The solution that I believe solves all our problems, is to add a generic <address> element to every single device. This address element contains info about how the device is associated with the logical parent device. There will be three types of address in this series of patches, though we could imagine adding more later. - PCI address - domain, bus, slot, function - USB address - bus, device - Drive address - controller, bus, unit Anything that is a PCI device will obviously use PCI addresses. - PCI: sound, audio, video, all virtio, watchdog, disk controllers - USB: all usb devices - Drive: SCSI, IDE & Floppy disks, but *not* VirtIO/Xen disks Xen paravirt devices aren't really covered in this scheme. I could imagine adding a fourth address type for Xen. This would in fact let us handle driver domains - ie a backend outside dom0. I won't deal with Xen in this series though. The XML for each address type looks like <address type='pci' mode='static' domain='0x0000' bus='0x1e' slot='0x07' function='0x0'/> <address type='usb' mode='dynamic' bus='007' dev='003'/> <address type='drive' mode='dynamic' controller='1' bus='0' unit='5'/> The 'mode' attribute for any of them is allowed to be either 'static' or 'dynamic'. A static address is one specified by the end user when defining the XML, while a dynamic address is one automatically chosen by libvirt/QEMU every time a guest boots. The idea of static addresses is to allow management apps to guarentee that PCI device & drive numbering never changes. This series does not actually implement static addressing for PCI yet, because it requires that we change the way we generate QEMU command line arguments. It does do static addressing for disks. libvirt itself will auto-assign all drive addresses, and QEMU will auto-assign PCI adresses in dynamic mode. When starting a guest VM we run 'info pci' to get a list of PCI vendor/product IDs and matching PCI addresses. We then attempt to match those up with the devices we specified to QEMU. It sounds nasty, but it actually works fairly well. This means we also now make it possible to hotunplug any device, even those the VM was initially booted with There are two ways I can envisage mgmt apps using this address functionality - Boot a guest with no addresses specified, grab the XML and change all 'dynamic' attrs to 'static' and then define the persistent config with this. The addresses will then be unchanged forever more - Explicitly give a full list of addresses the very first time a guest is created. There is one small issue with all this, we need to know every PCI device in the guest. It turns out there are a handful of devices in QEMU we don't represent in XML yet - Virtio balloon device - Virtio console (this is easy to address with matt's patches) - ISA bridge - USB controller - Some kind of PCI bridge (not clear what this is, it has PCI ID 8086:7113 If an management application is to be able to fully control static PCI addressing, we need to represent these somehow, so apps can give them addresses. Technically we could get away with not representing the ISA/PCI bridge since QEMU always gives them the first PCI slot no matter what. Still need the VirtIO & USB devices dealt with. Finally, here is an example of a guest running with a huge number of devices. Notice how we've auto-detected the PCI address of every device, and every disk. In particular notice how VirtiO disks got the PCI address, while SCSI disks got the drive address. <domain type='kvm' id='2'> <name>plain</name> <uuid>c7a1edbd-edaf-9455-926a-d65c16db1809</uuid> <memory>219200</memory> <currentMemory>219136</currentMemory> <vcpu>1</vcpu> <os> <type arch='i686' machine='pc-0.11'>hvm</type> <kernel>/home/berrange/vmlinuz-PAE</kernel> <initrd>/home/berrange/initrd-PAE.img</initrd> <boot dev='hd'/> </os> <features> <acpi/> </features> <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='file' device='disk'> <driver name='qemu' type='qcow2'/> <source file='/home/berrange/VirtualMachines/plain.qcow'/> <target dev='vda' bus='virtio'/> <address type='pci' mode='dynamic' domain='0x0000' bus='0x00' slot='0x0b' function='0x0'/> </disk> <disk type='file' device='cdrom'> <source file='/home/berrange/gpxe.iso'/> <target dev='hdc' bus='ide'/> <readonly/> <address type='drive' mode='dynamic' controller='0' bus='1' unit='0'/> </disk> <disk type='file' device='disk'> <source file='/home/berrange/output.img'/> <target dev='sda' bus='scsi'/> <address type='drive' mode='dynamic' controller='0' bus='0' unit='0'/> </disk> <disk type='file' device='disk'> <source file='/home/berrange/output.img'/> <target dev='sdd' bus='scsi'/> <address type='drive' mode='dynamic' controller='0' bus='0' unit='3'/> </disk> <disk type='file' device='disk'> <source file='/home/berrange/output.img'/> <target dev='sdf' bus='scsi'/> <address type='drive' mode='dynamic' controller='0' bus='0' unit='5'/> </disk> <controller type='scsi' index='0'> <address type='pci' mode='dynamic' domain='0x0000' bus='0x00' slot='0x0a' function='0x0'/> </controller> <controller type='ide' index='0'> <address type='pci' mode='dynamic' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/> </controller> <controller type='fdc' index='0'/> <interface type='user'> <mac address='52:54:00:5b:ef:21'/> <model type='ne2k_pci'/> <address type='pci' mode='dynamic' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> </interface> <interface type='user'> <mac address='52:54:00:1c:dc:98'/> <model type='virtio'/> <address type='pci' mode='dynamic' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> </interface> <interface type='user'> <mac address='52:54:00:f7:c5:0e'/> <model type='e1000'/> <address type='pci' mode='dynamic' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/> </interface> <interface type='user'> <mac address='52:54:00:56:6c:55'/> <model type='pcnet'/> <address type='pci' mode='dynamic' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/> </interface> <interface type='user'> <mac address='52:54:00:ca:0d:58'/> <model type='rtl8139'/> <address type='pci' mode='dynamic' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/> </interface> <serial type='pty'> <source path='/dev/pts/5'/> <target port='0'/> </serial> <console type='pty' tty='/dev/pts/5'> <source path='/dev/pts/5'/> <target port='0'/> </console> <input type='mouse' bus='ps2'/> <graphics type='vnc' port='5900' autoport='yes'/> <sound model='ac97'> <address type='pci' mode='dynamic' domain='0x0000' bus='0x00' slot='0x08' function='0x0'/> </sound> <sound model='es1370'> <address type='pci' mode='dynamic' domain='0x0000' bus='0x00' slot='0x09' function='0x0'/> </sound> <video> <model type='cirrus' vram='9216' heads='1'/> <address type='pci' mode='dynamic' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> </video> <watchdog model='i6300esb' action='reset'> <address type='pci' mode='dynamic' domain='0x0000' bus='0x00' slot='0x0c' function='0x0'/> </watchdog> </devices> <seclabel type='dynamic' model='selinux'> <label>system_u:system_r:svirt_t:s0:c181,c286</label> <imagelabel>system_u:object_r:svirt_image_t:s0:c181,c286</imagelabel> </seclabel> </domain> Daniel

4 34