- Devel - libvirt List Archives

[libvirt] [PATCH] Fix disk device ordering
by Cole Robinson 03 Sep '08

03 Sep '08

When parsing the domain xml, disks are supposed to be rearranged in an alphabetic order based on bus type and target. The reordering code had a flaw though, in that it would always put the first disk it encountered at the head of the list, and had no way of putting new entries in front of it. The attached patch reworks the code to compare the new disk against the current disk entry (rather than the next entry like the existing code). Seems to pass all my tests. Thanks, Cole commit ce3abbb62327672f756848efec7c95275fa797d6 Author: Cole (Work Acct) <crobinso(a)localhost.localdomain> Date: Thu Aug 21 23:04:11 2008 -0400 Fix disk ordering when parsing domain xml. diff --git a/src/domain_conf.c b/src/domain_conf.c index ed6cc8b..3c61039 100644 --- a/src/domain_conf.c +++ b/src/domain_conf.c @@ -1949,25 +1949,27 @@ static virDomainDefPtr virDomainDefParseXML(virConnectPtr conn, goto error; /* Maintain list in sorted order according to target device name */ - if (def->disks == NULL) { - disk->next = def->disks; - def->disks = disk; - } else { - virDomainDiskDefPtr ptr = def->disks; - while (ptr) { - if (ptr->next && STREQ(disk->dst, ptr->next->dst)) { - virDomainReportError(conn, VIR_ERR_INTERNAL_ERROR, - _("duplicate disk target '%s'"), - disk->dst); - goto error; - } - if (!ptr->next || virDomainDiskCompare(disk, ptr->next) < 0) { - disk->next = ptr->next; - ptr->next = disk; - break; - } - ptr = ptr->next; + virDomainDiskDefPtr ptr = def->disks; + virDomainDiskDefPtr *prev = &(def->disks); + while (ptr) { + if (STREQ(disk->dst, ptr->dst)) { + virDomainReportError(conn, VIR_ERR_INTERNAL_ERROR, + _("duplicate disk target '%s'"), + disk->dst); + goto error; + } + if (virDomainDiskCompare(disk, ptr) < 0) { + disk->next = ptr; + *prev = disk; + break; } + prev = &(ptr->next); + ptr = ptr->next; + } + + if (!ptr) { + disk->next = ptr; + *prev = disk; } } VIR_FREE(nodes);

3 3

[libvirt] Does libvirt supports Xen on Solaris?
by atif bajwa 03 Sep '08

03 Sep '08

Hi! Does libvirt supports Xen on Solaris? If so what is version of libvirt and Solaris? Regards, Atif

2 1

[libvirt] [PATCH] Add success output to virsh attach/detach commands
by Cole Robinson 03 Sep '08

03 Sep '08

The virsh attach-* and detach-* commands don't say anything if the operation succeeds, which doesn't seem very polite. The attached adds some simple feedback. Thanks, Cole commit eda28c5de3d367d001ca89ffc969fcc3c0185abb Author: Cole Robinson <crobinso(a)dhcp-100-19-219.bos.redhat.com> Date: Thu Aug 21 17:59:13 2008 -0400 Report success message for virsh attach-* and detach-* diff --git a/src/virsh.c b/src/virsh.c index 67d9658..c22cdc4 100644 --- a/src/virsh.c +++ b/src/virsh.c @@ -4490,6 +4490,8 @@ cmdAttachDevice(vshControl *ctl, const vshCmd *cmd) vshError(ctl, FALSE, _("Failed to attach device from %s"), from); virDomainFree(dom); return FALSE; + } else { + vshPrint(ctl, _("Device attached successfully\n")); } virDomainFree(dom); @@ -4547,6 +4549,8 @@ cmdDetachDevice(vshControl *ctl, const vshCmd *cmd) vshError(ctl, FALSE, _("Failed to detach device from %s"), from); virDomainFree(dom); return FALSE; + } else { + vshPrint(ctl, _("Device detached successfully\n")); } virDomainFree(dom); @@ -4655,8 +4659,11 @@ cmdAttachInterface(vshControl *ctl, const vshCmd *cmd) if (!buf) goto cleanup; strcat(buf, " </interface>\n"); - if (virDomainAttachDevice(dom, buf)) + if (virDomainAttachDevice(dom, buf)) { goto cleanup; + } else { + vshPrint(ctl, _("Interface attached successfully\n")); + } ret = TRUE; @@ -4772,8 +4779,10 @@ cmdDetachInterface(vshControl *ctl, const vshCmd *cmd) ret = virDomainDetachDevice(dom, (char *)xmlBufferContent(xml_buf)); if (ret != 0) ret = FALSE; - else + else { + vshPrint(ctl, _("Interface detached successfully\n")); ret = TRUE; + } cleanup: if (dom) @@ -4939,6 +4948,8 @@ cmdAttachDisk(vshControl *ctl, const vshCmd *cmd) if (virDomainAttachDevice(dom, buf)) goto cleanup; + else + vshPrint(ctl, _("Disk attached successfully\n")); ret = TRUE; @@ -5046,8 +5057,10 @@ cmdDetachDisk(vshControl *ctl, const vshCmd *cmd) ret = virDomainDetachDevice(dom, (char *)xmlBufferContent(xml_buf)); if (ret != 0) ret = FALSE; - else + else { + vshPrint(ctl, _("Disk detached successfully\n")); ret = TRUE; + } cleanup: xmlXPathFreeObject(obj);

4 4

[libvirt] [PATCH] introducing <source> <name> (for logical storage pools)
by David Lively 03 Sep '08

03 Sep '08

Hi Folks - This small patch is a proposed prerequisite for the storage pool discovery patch I submitted last week. Daniel B proposed having storage pool discovery return a bunch of XML storage <source> elements, rather than full <pool> elements (which contain "target-dependent" details like the local pool name and device or mount path -- things which don't need to be decided unless/until the pool is defined). I like his suggestion a lot, and I think it addresses the final API-definition problem keeping storage pool discovery out of libvirt. But ... it doesn't quite work for logical storage pools because those are created from the <pool> <name> element (which is the same as the volume group name). This patch introduces a new <source> element <name>, which is distinct from the pool name. <name> is used only by the logical storage backend, and represents the volume group name. For convenience and back-compatibility, <source> <name> defaults to the pool name if not specified when the pool is defined, and <pool> <name> defaults to the source name if not specified. There is no requirement that pool and source name be the same, though. While admittedly it seems a little weird, it does allow more flexibility (pool name not tied to vol group name), and allows <source> to fully specify a logical pool source, as it does for the other pool types[*]. Defaulting the source name from the pool name means all existing pool XML definitions continue to work. Defaulting the pool name from the source name is simply a matter of convenience (but perhaps a step too far?) If this is accepted, logical pool discovery can then return a bunch of sources like: <source><name>VolGroup00</name></source> <source><name>VolGroup01</name></source> Please note I'll be on vacation next week (Aug 11-15), so I may not be responding until the following week. Thanks, Dave [*] Well ... almost. Note that directory pools have a similar issue -- the "source" of the pool is given by the <target> <path> -- there's no <source>. I suppose implementing directory pool discovery (for the sake of completeness) means addressing this as well, maybe via some similar mechanism ...

5 16

[libvirt] libvir: Xen error
by mantra UNIX 02 Sep '08

02 Sep '08

Hello everyone, I get the following error when i try to redtart a domain; # virsh list libvir: Xen error : Domain not found: xenUnifiedDomainLookupByID I am using RHEL5.2 on i386, I have searched for the error on web and on RedHat but could not find any. -- Regards, mantra - Instrument of Thought

3 6

[libvirt] Storage LVM volume mounted with filesystem
by Ricardo Tiago 02 Sep '08

02 Sep '08

Hi, I'm quite new to libvirt, and i have a question regarding the storage capabilities in libvirt. I have reading the documentation but i couldn't figure it out if its possible to specify in the LVM volume xml description that i want the new volume to be mounted with a filesystem. I'm using libvirt-0.4.4 My current volume xml is: <volume type="fs"> <name>sl5-root</name> <allocation>0</allocation> <capacity>5000000000</capacity> <target> <path>/tmp/sl5</path> <permissions> <owner>0744</owner> <group>0744</group> <mode>0744</mode> <label>virt_image_t</label> </permissions> </target> </volume> /tmp/sl5 is a ext3 filesystem that i would like to see mounted in the newly create lvm volume. My pool xml: <pool type="logical"> <name>vg1</name> <target> <path>/dev/vg1</path> </target> </pool> Thanks Ricardo

1 0

[libvirt] [PATCH] Set correct device type when parsing input devices
by Cole Robinson 02 Sep '08

02 Sep '08

In virDomainDeviceDefParse, parsing an input device was actually setting it's type as DEVICE_DISK. The attached patch fixes this. Thanks, Cole commit 75150ac2536c427f74875fc563abf2fc06595dda Author: Cole Robinson <crobinso(a)dhcp-100-19-219.bos.redhat.com> Date: Thu Aug 21 13:27:38 2008 -0400 Fix setting input device type in virDomainDeviceDefParse. diff --git a/src/domain_conf.c b/src/domain_conf.c index d482e68..6b23474 100644 --- a/src/domain_conf.c +++ b/src/domain_conf.c @@ -1656,7 +1656,7 @@ virDomainDeviceDefPtr virDomainDeviceDefParse(virConnectPtr conn, if (!(dev->data.net = virDomainNetDefParseXML(conn, node))) goto error; } else if (xmlStrEqual(node->name, BAD_CAST "input")) { - dev->type = VIR_DOMAIN_DEVICE_DISK; + dev->type = VIR_DOMAIN_DEVICE_INPUT; if (!(dev->data.input = virDomainInputDefParseXML(conn, def->os.type, node))) goto error; } else if (xmlStrEqual(node->name, BAD_CAST "sound")) {

4 3

[libvirt] [PATCH] Don't list capabilities entries if emulators can't be accessed
by Cole Robinson 02 Sep '08

02 Sep '08

The patch below fixes capabilities xml generation for the qemu driver if the emulators aren't found in the hardcoded paths. Current behavior will add a <guest> entry for the emulator even if it does not exist, patch fixes this to check that we actually have access. This brings up another issue, that hardcoded paths aren't exactly distro friendly. I'm not really familiar with what options we have to allow specifying these at build time (or something else). Anyone have an idea? Thanks, Cole diff --git a/src/qemu_conf.c b/src/qemu_conf.c index dc9e42a..0328cc1 100644 --- a/src/qemu_conf.c +++ b/src/qemu_conf.c @@ -230,6 +230,10 @@ qemudCapsInitGuest(virCapsPtr caps, virCapsGuestPtr guest; int i; + /* Check for existance of base emulator */ + if (access(info->binary, X_OK) == -1) + return 0; + if ((guest = virCapabilitiesAddGuest(caps, hvm ? "hvm" : "xen", info->arch, @@ -241,9 +245,7 @@ qemudCapsInitGuest(virCapsPtr caps, return -1; if (hvm) { - /* Check for existance of base emulator */ - if (access(info->binary, X_OK) == 0 && - virCapabilitiesAddGuestDomain(guest, + if (virCapabilitiesAddGuestDomain(guest, "qemu", NULL, NULL, @@ -263,6 +265,7 @@ qemudCapsInitGuest(virCapsPtr caps, return -1; if (access("/dev/kvm", F_OK) == 0 && + access("/usr/bin/qemu-kvm", X_OK) == 0 && virCapabilitiesAddGuestDomain(guest, "kvm", "/usr/bin/qemu-kvm",

4 5

[libvirt] Reminder about developer IRC channel
by Daniel P. Berrange 02 Sep '08

02 Sep '08

There're a few new people contributing patches to libvirt recently, so just thought I'd remind people that many of us hang out on IRC. The channel is #virt on irc.oftc.net. If we seem to be ignoring patches[1] you've sent, then do send nag-emails to this list, or say hello on IRC to ask about the status of things (most of us are currently on a European timezone) Regards, Daniel [1] We're not delibrately ignoring them - things just get missed / forgotten / delayed sometimes due to other things we work on. -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

1 0

[libvirt] Libvirt Packaged Linux Distributions
by atif bajwa 02 Sep '08

02 Sep '08

Guys, Can anyone give me list of Linux enterprise editions distributions that are packaged with xyz version of libvirt? Regards, Atif

2 2