- Devel - libvirt List Archives

[Libvir] generator.py -- why?
by pvetere＠redhat.com 29 Aug '06

29 Aug '06

Hi all. So, I found a bug in the python bindings that I'd really like to fix, but when I sat down to do so I quickly found myself mired in a swampy mess of code generation: generator.py. :-) Now, I feel compelled to ask -- why don't we just have a static libvirt.py file that is WYSIWYG? The generator.py program alone is longer than the file it generates, and having a static file would not only make the code easier to read, but would also make bug fixing much simpler. But, I'm sure there's got to be a good reason for it. :-) Here's a program that produces the bug I tried to address: import libvirt def get_domain(dom_name): conn = libvirt.openReadOnly(None) domain = conn.lookupByName(dom_name) return domain d = get_domain("mydomain") print d.info() This is a fairly typical "factory" pattern I could imagine people using. The problem is that the connection object falls out of scope after the get_domain routine ends, and is therefore garbage collected. This leaves the "d" domain object with no valid connection, resulting in a "libvir: Xen error : failed Xen syscall ioctl 3166208" error. The simple solution would be for the connection object to pass a reference to itself into each domain object it creates. The domain objects would then maintain the reference until they are destroyed. I valiantly tried to follow the table-based patterns used in generator.py to fix this problem, but I found myself inventing somewhat arbitrary rules just to force the code I wanted it to output. And hence, $SUBJECT. :-) Pete

4 7

[Libvir] [QEMU 0/3] QEMU support for libvirt
by Daniel P. Berrange 28 Aug '06

28 Aug '06

The following series of patches add support for QEMU to libvirt. The patches are: - libvirt-drivers-qemu.patch - hook up methods for inactive domains - libvirt-virsh-qemu.patch - hook up inactive domain methods to virsh - libvirt-backend-qemu.patch - the main QEMU backend The patches will be explained further in each email which follows. NB, the first two patches are ready for inclusion, but the last one needs more error handling, and another audit of the networking code to check in particular buffer sizes. For testing I used Damn Small Linux, and QEMU 0.8.1 from Fedora Core 5 (the one with VNC support) wget http://distro.ibiblio.org/pub/linux/distributions/damnsmall/current/dsl-3.0… Here is a suitable config file: <domain type='qemu'> <name>dsl</name> <uuid>fff64701-45b9-11cb-88e3-afbfe5370493</uuid> <memory>131072</memory> <vcpu>20</vcpu> <devices> <disk type='file' device='cdrom'> <source file='/home/berrange/dsl-3.0.1.iso'/> <target dev='hdc'/> </disk> <graphics type='vnc' port='5906'/> </devices> </domain> An example session with virsh: [berrange@aubergine ~]$ export VIRSH_DEFAULT_CONNECT_URI=qemu:///session [berrange@aubergine ~]$ virsh list Id Name State ---------------------------------- [berrange@aubergine ~]$ virsh define $HOME/dsl.xml Domain dsl defined from /home/berrange/dsl.xml [berrange@aubergine ~]$ virsh list --all Id Name State ---------------------------------- -1 dsl shut off [berrange@aubergine ~]$ virsh dominfo dsl Id: -1 Name: dsl UUID: fff64701-45b9-11cb-88e3-afbfe5370493 OS Type: linux State: shut off CPU(s): 20 Max memory: 131072 kB Used memory: 131072 kB [berrange@aubergine ~]$ virsh start dsl Domain dsl started [berrange@aubergine ~]$ virsh list --all Id Name State ---------------------------------- 1 dsl running [berrange@aubergine ~]$ virsh dumpxml dsl <domain type='qemu' id='1'> <name>dsl</name> <uuid>fff64701-45b9-11cb-88e3-afbfe5370493</uuid> <memory>131072</memory> <vcpu>20</vcpu> <devices> <disk type='file' device='cdrom'> <source file='/home/berrange/dsl-3.0.1.iso'/> <target dev='hdc'/> <readonly/> </disk> <graphics type='vnc' port='5906'/> </devices> </domain> [berrange@aubergine ~]$ virsh destroy dsl Domain dsl destroyed [berrange@aubergine ~]$ virsh list --all Id Name State ---------------------------------- -1 dsl shut off I'm also happy to report that it is also possible to use virt-manager with the QEMU support - just enter qemu:///session as the URI. That said you can't use the VM creation wizard, but it should be easy to hook that up. The fact that virt-manager works without modification is a really great proof of the value of libvirt abstract driver backend API concept - validating the decision not to make a Xen specific API. Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|

1 0

[Libvir] Support graphical console for PV Xen guests
by Jeremy Katz 26 Aug '06

26 Aug '06

With the paravirt framebuffer patches for Xen, we can support having a graphical console for PV as well as HVM guests. The attached adds support to libvirt by breaking out the <graphics> parsing into its own function that can be used by both PV and HVM guests. It also adds support for looking at the appropriate sexpr for the vnc/sdl console for PV guests. One thing that is potentially not okay is that I've changed sexpr_node to take a format string instead of just a const char *, but since it's not public API and doesn't actually change anything for callers I think it should be fine. If not, let me know and I can change it. Jeremy

2 3

[Libvir] RFC: A more convenient 'virsh create' command
by Daniel P. Berrange 26 Aug '06

26 Aug '06

The current implementation of 'virsh create' takes an XML file as its only parameter & creates a domain from this. This is great if you have a suitable XML file already, but if you are just trying to automate some simple tasks from the shell then the need to use XML is a little cumbersome. Thus I was thinking perhaps we could have an alternate way to define a new VM (keep the current XML based way too of course) QEMU for example makes it very easy to launch a new VM: qemu -m 256 -hda /path/to/image.dsk -hdc /path/to/boot.iso Taking inspiration from this syntax we could allow: virsh start -m 256 -hda /path/to/image.dsk -hdc /path/to/boot.iso -name Foo Internally, the 'start' command would simply transform these command line args into the neccessary libvirt XML and then call the normal create functions. Another way would be have a 'genxml' command, which accepted these list of devices / config properties & then printed out appropriate XMl. This could be piped to the regular 'virsh create' command virsh genxml -m 256 -hda /path/to/image.dsk -hdc /path/to/boot.iso \ -name Foo | virsh create - This isn't so critical for Xen, because people are already used to writing config files before creating the domain, but when we get a QEMU backend i think such a convenient method for defining new VMs will be neccessary to encourage users to use virsh instead of manually calling 'qemu'. Even for Xen users it would make shell script easier though :-) Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|

3 5

[Libvir] Allow default hypervisor URI to be set via ENV variable
by Daniel P. Berrange 25 Aug '06

25 Aug '06

When using a non-Xen backend with virsh, it gets pretty tedious always passing '--default test:///some/big/path' - particularly if you're never using Xen on that machine. Thus I figured it would be useful to allow the default Xen URI to be overridden via an environment variable. [berrange@localhost src]$ unset VIRSH_DEFAULT_CONNECT_URI [berrange@localhost src]$ ./virsh list failed to find libvirt_proxy libvir: error : no support for hypervisor lt-virsh: error: failed to connect to the hypervisor [berrange@localhost src]$ export VIRSH_DEFAULT_CONNECT_URI=test:///default [berrange@localhost src]$ ./virsh list Id Name State ---------------------------------- 0 Domain-0 running This will be even more useful when other real hypervisors are available for libvirt. The patch also removes the assumption in virsh that there is >= 1 guest domains - sure Xen always has a Domain-0, but its not guarenteed that other non-Xen HVs have a permanent Domain-0 Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|

2 3

[Libvir] New virt-manager release v0.2.0
by Daniel P. Berrange 25 Aug '06

25 Aug '06

I'm pleased to announce the availabilty of another snapshot / development release of virt-manager, version 0.2.0. The major new capabilities in this release include: * First cut of a wiziard for creating both paravirt & fullyvirt guest VMs. aka the gui equivalent of xenguest-install.py You can find out more about this in the new screenshots section: http://virt-manager.et.redhat.com/screenshots/install.html * An embedded serial console viewer - no need to go to the shell and use 'xm console' anymore. This is actually used for the paravirt guest instllation if your XenU kernel does not support the new VNC framebuffer (not yet in xen-unstable) * Hooked up the config dialog for adjusting vcpus & memory for active domains * Extended RFB protocol handler code to support the 'desktop resize' extensions in the VNC widget - so the graphical console has correct size when the guest switches screen resolutions The tar.gz for the release can be found on the download page: http://virt-manager.et.redhat.com/download.html NB, I'm not providing RPMs in my people.redhat.com YUM repo because we're intending to build this release straight into Fedora rawhide. I'll send a followup message when they're avaiable there. NB-2. there is a dependnacy on the 'xeninst' python library which is a new library built from re-factoring xenguest-install.py You can get this from rawhide in the python-xeninst RPM, or direct from the mercurial repository http://hg.et.redhat.com/virt/applications/xeninst--devel Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|

2 3

[Libvir] Adding test suite for sexpr<->xml conversions
by Daniel P. Berrange 24 Aug '06

24 Aug '06

Quite a critical bit of the libvirt code is that which converts between SEXPR and XML, and vica-verca. I've broken this code several times when making changes, so it is way overdue to get some unit test coverage in this area. The attached patch adds such coverage - defining two tests xml2sexprtest and sexpr2xmltest. The tests are pretty simple, in the tests/ directory I just have a bunch of xml & sexpr files - one is the fixed input, the other is the expected output. The test just runs the conversion and compares the actual output with the expected output. Currently I've added two example data files - one for paravirt & one for fully-virt. With this patch you can run tests: $ make check make check-TESTS make[1]: Entering directory `/home/berrange/src/xen/libvirt/tests' XML-2-SEXPR PV config ... OK XML-2-SEXPR FV config ... OK PASS: xml2sexprtest SEXPR-2-XML PV config ... OK SEXPR-2-XML FV config ... OK PASS: sexpr2xmltest ================== All 2 tests passed ================== make[1]: Leaving directory `/home/berrange/src/xen/libvirt/tests' I'm shortly about to start on updating the code to deal with new CDROM configuration format for HVM guests in Xen 3.0.3, and so intend to add further test files during this process (and of course make sure I don't break the existing ones :-) Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|

3 8

[Libvir] [Libvirt] Proposal to add 3 functions for VBDs (Virtual Block Devices)
by michel.ponceau＠bull.net 24 Aug '06

24 Aug '06

After the new VCPU functions, we also need Virtual Block Device management equivalent to Xen commands: 'xm block-list', 'xm block-attach', 'xm block-detach'. I propose to add in Libvirt the following 3 functions: /** * virDomainGetVbdevs: * @domain: pointer to domain object, or NULL for Domain0 * @info: pointer to an array of virVbdevInfo structures * @maxinfo: number of structures in info array * * Extract information about virtual block devices of domain, store it in info. * * Returns the number of info filled in case of success, -1 in case of failure. */ int virDomainGetVbdevs(virDomainPtr domain, virVbdevInfoPtr info, int maxinfo) /** * virDomainCreateVbdev: * @domain: pointer to domain object, or NULL for Domain0 * @number: virtual device number * @mode: read-only (VIR_VBDMD_RO), or read/write (VIR_VBDMD_RW) * @bkendID: ID of domain hosting the backend device (usually 0 for domain0) * @bkend: pointer to backend device path * * Create a virtual block device. * * Returns 0 in case of success, -1 in case of failure. */ int virDomainCreateVbdev(virDomainPtr domain, unsigned int number, int mode, int bkendID, char *bkend) /** * virDomainDestroyVbdev: * @domain: pointer to domain object, or NULL for Domain0 * @number: virtual device number * * Destroy a virtual block device. * * Returns 0 in case of success, -1 in case of failure. */ int virDomainDestroyVbdev(virDomainPtr domain, unsigned int number) Structure in libvirt.h: /** * virVbdevInfo: information structure for a Virtual Block Device in a domain */ typedef struct _virVbdevInfo virVbdevInfo; struct _virVbdevInfo { unsigned int number; /* virtual device number */ int state; int evtChn; int ringRef; int bkendID; /* ID of domain hosting the backend device */ char bkend[128]; }; typedef virVbdevInfo *virVbdevInfoPtr; /* Virtual Block Device access modes: read-only or read/write */ #define VIR_VBDMD_RO 0 #define VIR_VBDMD_RW 1

4 5

Re: [Libvir] Semantics for ListDomains/ ListDefinedDomains
by Jim Fehlig 24 Aug '06

24 Aug '06

>>> Gareth S Bestor <bestor(a)us.ibm.com> 08/23/06 8:04 PM >>> > At the *very* worst, is there a way you can pipe an arbitrary xm config > file thru xm and have it spit out what it would have done, without actually > doing it? That could be a reliable fallback migration path perhaps. xm create /path/to/config --dryrun Spits out s-expr last time I checked. Jim

1 0

[Libvir] Release of libvirt-0.1.4
by Daniel Veillard 16 Aug '06

16 Aug '06

Okay, there was a lot of new stuff which accumulated in the last month, it was urgent to push a new release. Available at ftp://libvirt.org/libvirt/ and http://libvirt.org/sources/ * bug fixes: - spec file fix (Mark McLoughlin) - error report problem (with Hugh Brock) - long integer in Python bindings (with Daniel Berrange) - XML generation bug for CDRom (Daniel Berrange) - bug when using number() XPath function (Mark McLoughlin) - fix python detection code - remove duplicate initialization errors (Daniel Berrange) * improvements: - UUID in XML description (Peter Vetere) - proxy code cleanup - virtual CPU and affinity support + virsh support (Michel Ponceau, Philippe Berthault, Daniel Berrange) - port and tty informations for console in XML (Daniel Berrange) - added XML dump to driver and proxy support (Daniel Berrange) - extention of boot options with support for floppy and cdrom (Daniel Berrange) - features block in XML to report/ask PAE, ACPI, APIC for HVM domains (Daniel Berrange) - fail side-effect operations when using read-only connection - large improvements to test driver (Daniel Berrange) * documentation: - spelling (Daniel Berrange) - test driver examples. Thanks to everybody who helped for this release ! Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/

1 0

[Libvir] Re-factor sexpr_uuid method
by Daniel P. Berrange 16 Aug '06

16 Aug '06

The sexpr_uuid method is used to convert from the printable representation of a UUID into the binary format (unsigned char[16]). This patch refactors the main body of the method so that it is usable by other non-XenD driver backends for parsing UUIDs. This new re-factored method will be used by a patch I'll shortly submit for the test driver backend. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|

2 2

[Libvir] Record an error when refusing a read-only operation
by Daniel P. Berrange 16 Aug '06

16 Aug '06

The libvirt.c front-end can be compiled in 'pedantic' mode in which case it explicitly refuses operations with side-effects in read-only connections. When doing so, however, it was not recording any error message so feedback to the user was misleading / obsure. This patch adds an extra error code VIR_ERR_READ_ONLY which is used when an operation is denied due to a read only connection. This patch also passes 'VIR_DRV_OPEN_QUIET' to the 'open' method so tell the XenD driver not complain if it fails to open a HV connection. This is because it was complaining whenever trying to open a test:///default connection. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|

2 2

[Libvir] Major extensio of test backend driver functionality
by Daniel P. Berrange 16 Aug '06

16 Aug '06

Ok, here comes the huge patch for today - a major extension of the test driver backend... As well as the interal hardcoded 'test:///default' hypervisor config you can now provide a path to an arbitrary XML file defining your HV and its domains. An example file to define a moster 128x6GHz CPU box with 128 GB of RAM and two guest domains looks like: <node> <domain file="testdomfv0.xml"/> <domain file="testdomfc4.xml"/> <cpu> <mhz>6000</mhz> <model>i986</model> <active>50</active> <nodes>4</nodes> <sockets>4</sockets> <cores>4</cores> <threads>2</threads> </cpu> <memory>137438953472</memory> </node> The individual domains 'testdomfv0.xml' and 'testdomfc4.xml' are defined using the regular libvirt XML format. The only exception is that the 'type' attribute on the top level '<domain>' tag should be 'test' instead of 'xen' So for example: $ virsh --connect test:///home/berrange/src/xen/libvirt/docs/testnode.xml virsh > nodeinfo CPU model: i986 CPU(s): 50 CPU frequency: 6000 MHz CPU socket(s): 4 Core(s) per socket: 4 Thread(s) per core: 2 NUMA cell(s): 4 Memory size: 137438953472 kB virsh > list Id Name State ---------------------------------- 0 fv0 running 1 fc4 running virsh > dominfo fc4 Id: 1 Name: fc4 UUID: ef861801-45b9-11cb-88e3-afbfe5370493 OS Type: linux State: running CPU(s): 1 CPU time: 1155740835.5s Max memory: 131072 kB Used memory: 131072 kB virsh > Next up, I've written implementations of the set memory, set max memory, set vcpus, dump xml, create linux APIs for the test driver. THe only major areas of functionality lacking in the test driver now are handling of disk and network devices when creating domains, and the VCPU pinning methods. This test backend makes testing the virt-manager application much more reliable - although we still do need some level of testing against a real Xen backend (for example domain creation). Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|

2 2

[Libvir] Add 'setvcpus', 'setmem', 'setmaxmem' to virsh
by Daniel P. Berrange 16 Aug '06

16 Aug '06

The attached patch adds three new commands to virsh: setmem change memory allocation setmaxmem change maximum memory limit setvcpus change number of virtual CPUs It also ensures then when using the 'test' hypervisor driver, it always opens a read-write connection even as non-root. The test hypervisor does not have any distinction between privileged / unprivileged users, so this test for 'uuid == 0' was bogus. Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|

2 1

[Libvir] Flags for CPU / system 'features'
by Daniel P. Berrange 15 Aug '06

15 Aug '06

In the XenD config there are various flags which allow CPU / system features to be enabled / disabled for the guest domain. For example, HVM domains can be created with, or without, PAE, ACPI, APIC. The XenD sexpr contains simple boolean flags for these features within the (image (hvm ....)) block. IMHO, although these 3 particular features may be only be relevant for HVM, it does not make sense to restrict the expression of features to only HVM domains. Thus I propose a top level '<features>' block within the '<domain>' XML doc. This block would contain tags named after each feature to be enabled. Presence of the named tag enables the feature, ommision disables it (thus all features are disabled by default - matching current behaviour). As an example, to enable ACPI, PAE & APIC: <domain type='xen' id='55'> <name>too</name> <uuid>b5d70dd275cdaca517769660b059d8bc</uuid> <os> <type>hvm</type> <loader>/usr/lib/xen/boot/hvmloader</loader> <boot dev='hd'/> </os> <memory>409600</memory> <vcpu>1</vcpu> <on_poweroff>destroy</on_poweroff> <on_reboot>restart</on_reboot> <on_crash>restart</on_crash> <features> <acpi/> <apic/> <pae/> </features> <devices> ...snipped from example.. </devices> </domain> More flags could trivially be added over time. The attached patch implements this proposal. My only thought, is 'features' a good name for this ? Only other name I came up with was 'capabilities' but this is harder to spell :-) Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|

2 2

[Libvir] Fix handling of HVM boot parameters
by Daniel P. Berrange 15 Aug '06

15 Aug '06

Jeremy mentioned that it looked like libvirt wasn't able to create an HVM domain configured to boot off cdrom, so I took a closer look at the code and indeed the code dealing with <boot> section was both incomplete, and just plain broken. Incomplete in so much as it never included details of the ISO file backing the CDROM, and broken in so much as it was doing string comparisons against the wrong variables. Digging further found lots more work relating to creation of HVM domains so I've had a go at writing a patch to resolve matters. * Parsing of UUID from SEXPR assumed that the UUID fetched would always have four '-' in the usual places. Well, when you run 'dumpxml' from virsh the <uuid> element has the UUID encoded without any '-' chars. If you feed this back into 'virsh create' and then once again run 'dumpxml' parsing will fail & libvirt throws errors. So this patch allows for parsing of UUID's without '-'. * The XML document size was limited to 1k - we just 'malloc(1000)'. While this was enough for common cases, if someone creates lots of disk or network devices this would overflow and libvirt return an error. So I increased it to 4k which ought to be enough for forseeable future - in any case my previous patch to fetch XML via the proxy is limited to 4k in size too. Now onto the fine details... When converting SEXPR into XML current code is doing the following: (boot a) -> <boot dev='/dev/fd0'/> (boot c) -> <boot dev='hda'/> (boot d) -> <boot dev='/dev/cdrom'/> This is rather inconsistent - the 'hda' is intended to map to an entry in <devices> block. The '/dev/fd0' and '/dev/cdrom' entries did not map to anything. Meanwhile, when converting from XML to SXEXPR it is doing the following <boot dev='hda'/> -> (boot a) <boot dev='hdd'/> -> (boot d) <boot dev='*'/> -> (boot c) Obviously this sucks because these processes should be matching each other. Secondly, the (image (hvm....)) SEXPR has three entries for defining the ISO / disk image file backing the CDROM / Floppy devices. These were just being ignored, rather than turned into <disk> entries within the <devices> block. Similarly there was no way to express a <disk> entry for CDROM/Floppy in the XML when creating a domain. The upshot of all this is that although the last release of libvirt included HVM support it was basically unusable for domain creation unless you were using HD to boot. The XML returned was also incorrect. Now the good news. Since it was sooo broken, we can fix without worrying about XML compatability since there is no way any application could be relying on it in its current state. Now before I discuss the solution, one final point. The Xen IOMMU model allows specifiying the boot device in terms of 'a', 'c', 'd' which has the meaning: a - first connected floppy device c - first connected harddrive d - first connected cdrom In particular it does *not* allow for expressing boot device in terms of an explicit disk device - you can't say boot off 'hdb' or 'hdc'. So the current libvirt code which tries to fake such semantics is doomed to failure. This isn't really too bad IMHO - VMware has these same semantics, so does QEMU and so do normal bare metal BIOS This in the patch I have attached I have implemented the following mapping: (boot a) <-> <boot dev='fd'/> (boot c) <-> <boot dev='hd'/> (boot d) <-> <boot dev='cdrom'/> The other part of the patch is to deal with definition of the floppy and cdrom device backing files. For this I have done the following: (image (hvm (fda /root/diskboot.img))) <devices> <disk type='file'> <source file='/root/diskboot.img'/> <target dev='fda'/> </disk> </devices> And similar for 'fdb'. Then for cdroms: (image (hvm (cdrom /root/image.iso))) <devices> <disk type='file'> <source file='/root/image.iso'/> <target dev='cdrom'/> </disk> </devices> The patch has a little bit of logic such that when converting the <devices> block backinto an SEXPR it filters out the disk entries with a dev of 'fda', 'fdb' and 'cdrom' since they need to end up in a different part of the SEXPR. Finally, although PV guests automatically get a serial console created for them (and i don't think you can turn it off), HVM guests need to have a serial console explicitly requested. Since I recently added support in the DumpXML method for including details of serial console like this: <devices> <console tty="/dev/pts/5"/> </devices> I decided to leverage this same structure when creating HVM domains. So if you have: <devices> <console/> </devices> Then the SEXPR sent to XenD will include (image (hvm (serial pty))) Which enables allocation of PseudoTTY for the HVM's serial console. I have tested that with this patch I can successfully create a HVM domain which boots off a floppy, harddrive or cdrom. Furthermore if you then dump the XML of this domain,the XML you get back will match the XML you fed in (with the obvious exception of domain ID, and the Pseudo TTY path). If you have been monitoring xen-devel mailing lists you'll be aware that in 3.0.3 the way CDROM devices are configured is changing: http://lists.xensource.com/archives/html/xen-devel/2006-08/msg00369.html Although the patch attached does not support the config outlined in that mail, I'm pretty confident that a small incremental patch will be able to support it without breaking compatability with the changes I've outlined in this mail. The only tricky bit will be that we need to detect whether libvirt is running against a 3.0.2 or 3.0.3 version of XenD to decide how to convert XML -> SEXPR & vica verca. Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|

4 16

[Libvir] Guest Identification
by Juan Walker 11 Aug '06

11 Aug '06

Hi, I'm trying to find a good way to correlate a domain to the machine it's running on. Can I use libvir or some other method on a domU to get some information that uniquely identifies it? Perhaps something that I can get from the XML running on dom0? I'm thinking of using the MAC address because I imagine that those things should be unique at least per hypervisor, but I'm not sure if that would work across physical boxes. The solution would be to use libvir to get the list of domains and then get the xml which includes the mac address. Then every domain on my network would hit a server and report its mac address, and then I could make a tree that links the dom0's to the domU's. I'm wondering if there's a better way to do this. Any suggestions would be greatly appreciated. Thanks for your help.

3 4

[Libvir] Patch to fix duplicate pause/destroy/shutdown calls
by Daniel P. Berrange 10 Aug '06

10 Aug '06

I spent a while chasing an issue where running 'virsh destroy foo' on an HVM domain would result in an error being returned by the HV ioctl. What I eventually discovered is that the code was doing a destroy op via XenD and then also doing it via the hypervisor backend. It didn't typically show as a problem for PV domains because it seems they took longer to destroy - so were still around by the time the HV destroy was was called. I tracked this issue down to the main dispatch methods in src/libvirt.c which would indeed call both the XenD and HV driver backends for pause destroy & shutdown methods. The patch attached simply returns as soon as one of the driver methods returns a success return code. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|

1 0

[Libvir] Add port number to <graphics> tag
by Daniel P. Berrange 09 Aug '06

09 Aug '06

We recently added the '<graphics>' tag to the XML description for HVM machines. Any apps using this info though would have to hardcode the assumption that Xen's QEMU listens on Domain-ID + 5900. Hardcoding the port numbers in the first place is already a really questionable decision, so we should avoid that propagating out to application code. Thus, the attached patch changes: <graphics type="vnc"/> So that it now looks like <graphics type="vnc" port="5905"/> The hardcoded 'Domain-ID + 5900' craziness is now at least isolated in libvirt, so provided apps take the port number from the XML they will be immune from changes in port numbering scheme. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|

3 15

[Libvir] Here the patch for virtual CPU functions.
by Philippe Berthault 07 Aug '06

07 Aug '06

The patch (vcpus.diff) is joined with this mail. To apply the patch, untar the libvirt-0.1.3.tar.gz archive (if not already done). Then in libvirt-0.1.3 directory, do ./configure --prefix=/usr if not already done, and after this: patch -p1 < vcpus.diff make make install From the initial patch of Michel Ponceau (not delivered), I've just modify the virDomainGetVcpus function and added some useful macro for bit manipulation in cpu bit maps. TODO: These vcpus functions permits to dynamically change the vcpu/cpu relation after the domain has been started but nothing has been done regarding static cpus attribution in the XML configuration file of a domain. Philippe Berthault. --- libvirt-0.1.3/include/libvirt/libvirt.h 2006-07-11 18:05:07.000000000 +0200 +++ libvirt-0.1.3.with_vcpus/include/libvirt/libvirt.h 2006-08-02 16:42:51.000000000 +0200 @@ -289,6 +289,106 @@ const char **names, int maxnames); int virDomainCreate (virDomainPtr domain); +/////////////////////////////////////////////////////////////////////////// + +/** + * virVcpuInfo: structure for information about a virtual CPU in a domain. + */ + +typedef enum { + VIR_VCPU_OFFLINE = 0, /* the virtual CPU is offline */ + VIR_VCPU_RUNNING = 1, /* the virtual CPU is running */ + VIR_VCPU_BLOCKED = 2, /* the virtual CPU is blocked on resource */ +} virVcpuState; + +typedef struct _virVcpuInfo virVcpuInfo; +struct _virVcpuInfo { + unsigned int number; /* virtual CPU number */ + int state; /* value from virVcpuState */ + unsigned long long cpuTime; /* CPU time used, in nanoseconds */ + int cpu; /* real CPU number, or -1 if offline */ +}; +typedef virVcpuInfo *virVcpuInfoPtr; + +int virDomainSetVcpus (virDomainPtr domain, + unsigned int nvcpus); + +int virDomainPinVcpu (virDomainPtr domain, + unsigned int vcpu, + unsigned char *cpumap, + int maplen); + +/** + * USE_CPU: + * @cpumap: pointer to a bit map of real CPUs (in 8-bit bytes) (IN/OUT) + * @cpu: the physical CPU number + * + * This macro is to be used in conjonction with virDomainPinVcpu() API. + * USE_CPU macro set the bit (CPU usable) of the related cpu in cpumap. + */ + +#define USE_CPU(cpumap,cpu) (cpumap[(cpu)/8] |= (1<<((cpu)%8))) + +/** + * UNUSE_CPU: + * @cpumap: pointer to a bit map of real CPUs (in 8-bit bytes) (IN/OUT) + * @cpu: the physical CPU number + * + * This macro is to be used in conjonction with virDomainPinVcpu() API. + * USE_CPU macro reset the bit (CPU not usable) of the related cpu in cpumap. + */ + +#define UNUSE_CPU(cpumap,cpu) (cpumap[(cpu)/8] &= ~(1<<((cpu)%8))) + +int virDomainGetVcpus (virDomainPtr domain, + virVcpuInfoPtr info, + int maxinfo, + unsigned char *cpumaps, + int maplen); + +/** + * CPU_USABLE: + * @cpumaps: pointer to an array of cpumap (in 8-bit bytes) (IN) + * @maplen: the length (in bytes) of one cpumap + * @vcpu: the virtual CPU number + * @cpu: the physical CPU number + * + * This macro is to be used in conjonction with virDomainGetVcpus() API. + * CPU_USABLE macro returns a non zero value (true) if the cpu + * is usable by the vcpu, and 0 otherwise. + */ + +#define CPU_USABLE(cpumaps,maplen,vcpu,cpu) \ + (cpumaps[((vcpu)*(maplen))+((cpu)/8)] & (1<<((cpu)%8))) + +/** + * COPY_CPUMAP: + * @cpumaps: pointer to an array of cpumap (in 8-bit bytes) (IN) + * @maplen: the length (in bytes) of one cpumap + * @vcpu: the virtual CPU number + * @cpumap: pointer to a cpumap (in 8-bit bytes) (OUT) + * This cpumap must be previously allocated by the caller (ie: malloc(maplen)) + * + * This macro is to be used in conjonction with virDomainGetVcpus() and + * virDomainPinVcpu() APIs. COPY_CPUMAP macro extract the cpumap of the specified + * vcpu from cpumaps array and copy it into cpumap to be used later by virDomainPinVcpu() API. + */ +#define COPY_CPUMAP(cpumaps,maplen,vcpu,cpumap) \ + memcpy(cpumap, &(cpumaps[(vcpu)*(maplen)]), (maplen)) + + +/** + * GET_CPUMAP: + * @cpumaps: pointer to an array of cpumap (in 8-bit bytes) (IN) + * @maplen: the length (in bytes) of one cpumap + * @vcpu: the virtual CPU number + * + * This macro is to be used in conjonction with virDomainGetVcpus() and + * virDomainPinVcpu() APIs. GET_CPUMAP macro returns a pointer to the cpumap + * of the specified vcpu from cpumaps array. + */ +#define GET_CPUMAP(cpumaps,maplen,vcpu) &(cpumaps[(vcpu)*(maplen)]) + #ifdef __cplusplus } --- libvirt-0.1.3/src/xen_internal.h 2006-07-03 17:09:24.000000000 +0200 +++ libvirt-0.1.3.with_vcpus/src/xen_internal.h 2006-08-02 16:53:42.000000000 +0200 @@ -44,6 +44,18 @@ unsigned long memory); int xenHypervisorCheckID (virConnectPtr conn, int id); +int xenHypervisorSetVcpus (virDomainPtr domain, + unsigned int nvcpus); +int xenHypervisorPinVcpu (virDomainPtr domain, + unsigned int vcpu, + unsigned char *cpumap, + int maplen); +int xenHypervisorGetVcpus (virDomainPtr domain, + virVcpuInfoPtr info, + int maxinfo, + unsigned char *cpumaps, + int maplen); + #ifdef __cplusplus } #endif --- libvirt-0.1.3/src/xen_internal.c 2006-07-03 17:09:24.000000000 +0200 +++ libvirt-0.1.3.with_vcpus/src/xen_internal.c 2006-08-03 13:52:28.000000000 +0200 @@ -18,7 +18,7 @@ #include <fcntl.h> #include <sys/mman.h> #include <sys/ioctl.h> - +#include <limits.h> #include <stdint.h> /* required for dom0_getdomaininfo_t */ @@ -838,4 +838,138 @@ return (0); } +/////////////////////////////////////////////////////////////////////////////// + +/** + * xenHypervisorSetVcpus: + * @domain: pointer to domain object + * @nvcpus: the new number of virtual CPUs for this domain + * + * Dynamically change the number of virtual CPUs used by the domain. + * + * Returns 0 in case of success, -1 in case of failure. + */ + +int +xenHypervisorSetVcpus(virDomainPtr domain, unsigned int nvcpus) +{ + dom0_op_t op; + + if ((domain == NULL) || (domain->conn == NULL) || (domain->conn->handle < 0) + || (nvcpus < 1)) + return (-1); + op.cmd = DOM0_MAX_VCPUS; + op.u.max_vcpus.domain = (domid_t) domain->handle; + op.u.max_vcpus.max = nvcpus; + if (xenHypervisorDoOp(domain->conn->handle, &op) < 0) + return (-1); + return 0; +} + +/** + * xenHypervisorPinVcpu: + * @domain: pointer to domain object + * @vcpu: virtual CPU number + * @cpumap: pointer to a bit map of real CPUs (in 8-bit bytes) + * @maplen: length of cpumap in bytes + * + * Dynamically change the real CPUs which can be allocated to a virtual CPU. + * + * Returns 0 in case of success, -1 in case of failure. + */ + +int +xenHypervisorPinVcpu(virDomainPtr domain, unsigned int vcpu, + unsigned char *cpumap, int maplen) +{ + dom0_op_t op; + uint64_t *pm = (uint64_t *)&op.u.setvcpuaffinity.cpumap; + int j; + + if ((domain == NULL) || (domain->conn == NULL) || (domain->conn->handle < 0) + || (cpumap == NULL) || (maplen < 1) || (maplen > (int)sizeof(cpumap_t)) + || (sizeof(cpumap_t) & 7)) + return (-1); + op.cmd = DOM0_SETVCPUAFFINITY; + op.u.setvcpuaffinity.domain = (domid_t) domain->handle; + op.u.setvcpuaffinity.vcpu = vcpu; + memset(pm, 0, sizeof(cpumap_t)); + for (j = 0; j < maplen; j++) + *(pm + (j / 8)) |= cpumap[j] << (8 * (j & 7)); + if (xenHypervisorDoOp(domain->conn->handle, &op) < 0) + return (-1); + return 0; +} +/** + * virDomainGetVcpus: + * @domain: pointer to domain object, or NULL for Domain0 + * @info: pointer to an array of virVcpuInfo structures (OUT) + * @maxinfo: number of structures in info array + * @cpumaps: pointer to an bit map of real CPUs for all vcpus of this domain (in 8-bit bytes) (OUT) + * If cpumaps is NULL, then no cupmap information is returned by the API. + * It's assumed there is <maxinfo> cpumap in cpumaps array. + * The memory allocated to cpumaps must be (maxinfo * maplen) bytes + * (ie: calloc(maxinfo, maplen)). + * One cpumap inside cpumaps has the format described in virDomainPinVcpu() API. + * @maplen: number of bytes in one cpumap, from 1 up to size of CPU map in + * underlying virtualization system (Xen...). + * + * Extract information about virtual CPUs of domain, store it in info array + * and also in cpumaps if this pointer is'nt NULL. + * + * Returns the number of info filled in case of success, -1 in case of failure. + */ +int +xenHypervisorGetVcpus(virDomainPtr domain, virVcpuInfoPtr info, int maxinfo, + unsigned char *cpumaps, int maplen) +{ + dom0_op_t op; + uint64_t *pm = (uint64_t *)&op.u.getvcpuinfo.cpumap; + virVcpuInfoPtr ipt; + int nbinfo, mapl, i; + unsigned char *cpumap; + int vcpu, cpu; + + if ((domain == NULL) || (domain->conn == NULL) || (domain->conn->handle < 0) + || (info == NULL) || (maxinfo < 1) + || (sizeof(cpumap_t) & 7)) + return (-1); + if (cpumaps != NULL && maplen < 1) + return -1; + + /* first get the number of virtual CPUs in this domain */ + op.cmd = DOM0_GETDOMAININFO; + op.u.getdomaininfo.domain = (domid_t) domain->handle; + if (xenHypervisorDoOp(domain->conn->handle, &op) < 0) + return (-1); + nbinfo = (int)op.u.getdomaininfo.max_vcpu_id + 1; + if (nbinfo > maxinfo) nbinfo = maxinfo; + + if (cpumaps != NULL) + memset(cpumaps, 0, maxinfo * maplen); + + op.cmd = DOM0_GETVCPUINFO; + for (i=0, ipt=info; i < nbinfo; i++, ipt++) { + vcpu = op.u.getvcpuinfo.vcpu = i; + if (xenHypervisorDoOp(domain->conn->handle, &op) < 0) + return (-1); + ipt->number = i; + if (op.u.getvcpuinfo.online) { + if (op.u.getvcpuinfo.running) ipt->state = VIR_VCPU_RUNNING; + if (op.u.getvcpuinfo.blocked) ipt->state = VIR_VCPU_BLOCKED; + } + else ipt->state = VIR_VCPU_OFFLINE; + ipt->cpuTime = op.u.getvcpuinfo.cpu_time; + ipt->cpu = op.u.getvcpuinfo.online ? (int)op.u.getvcpuinfo.cpu : -1; + if (cpumaps != NULL && vcpu >= 0 && vcpu < maxinfo) { + cpumap = (unsigned char *)GET_CPUMAP(cpumaps, maplen, vcpu); + mapl = (maplen > (int)sizeof(cpumap_t)) ? (int)sizeof(cpumap_t) : maplen; + for (cpu = 0; cpu < (mapl * CHAR_BIT); cpu++) { + if (*pm & ((uint64_t)1<<cpu)) + USE_CPU(cpumap, cpu); + } + } + } + return nbinfo; +} --- libvirt-0.1.3/src/libvirt.c 2006-07-03 17:09:24.000000000 +0200 +++ libvirt-0.1.3.with_vcpus/src/libvirt.c 2006-08-02 15:30:29.000000000 +0200 @@ -1648,4 +1648,126 @@ return(-1); } +/////////////////////////////////////////////////////////////////////////// +/** + * virDomainSetVcpus: + * @domain: pointer to domain object, or NULL for Domain0 + * @nvcpus: the new number of virtual CPUs for this domain + * + * Dynamically change the number of virtual CPUs used by the domain. + * Note that this call may fail if the underlying virtualization hypervisor + * does not support it or if growing the number is arbitrary limited. + * This function requires priviledged access to the hypervisor. + * + * Returns 0 in case of success, -1 in case of failure. + */ + +int +virDomainSetVcpus(virDomainPtr domain, unsigned int nvcpus) +{ + if (domain == NULL) { + TODO + return (-1); + } + if (!VIR_IS_CONNECTED_DOMAIN(domain)) { + virLibDomainError(domain, VIR_ERR_INVALID_DOMAIN, __FUNCTION__); + return (-1); + } + if (domain->conn->flags & VIR_CONNECT_RO) + return (-1); + if (nvcpus < 1) { + virLibDomainError(domain, VIR_ERR_INVALID_ARG, __FUNCTION__); + return (-1); + } +// if (xenHypervisorSetVcpus(domain, nvcpus) == 0) +// return 0; + return xenDaemonDomainSetVcpus(domain, nvcpus); +} + +/** + * virDomainPinVcpu: + * @domain: pointer to domain object, or NULL for Domain0 + * @vcpu: virtual CPU number + * @cpumap: pointer to a bit map of real CPUs (in 8-bit bytes) (IN) + * Each bit set to 1 means that corresponding CPU is usable. + * Bytes are stored in little-endian order: CPU0-7, 8-15... + * In each byte, lowest CPU number is least significant bit. + * @maplen: number of bytes in cpumap, from 1 up to size of CPU map in + * underlying virtualization system (Xen...). + * If maplen < size, missing bytes are set to zero. + * If maplen > size, failure code is returned. + * + * Dynamically change the real CPUs which can be allocated to a virtual CPU. + * This function requires priviledged access to the hypervisor. + * + * Returns 0 in case of success, -1 in case of failure. + */ +int +virDomainPinVcpu(virDomainPtr domain, unsigned int vcpu, + unsigned char *cpumap, int maplen) +{ + if (domain == NULL) { + TODO + return (-1); + } + if (!VIR_IS_CONNECTED_DOMAIN(domain)) { + virLibDomainError(domain, VIR_ERR_INVALID_DOMAIN, __FUNCTION__); + return (-1); + } + if (domain->conn->flags & VIR_CONNECT_RO) + return (-1); + if ((vcpu < 1) || (cpumap == NULL) || (maplen < 1)) { + virLibDomainError(domain, VIR_ERR_INVALID_ARG, __FUNCTION__); + return (-1); + } + if (xenHypervisorPinVcpu(domain, vcpu, cpumap, maplen) == 0) + return 0; + return (-1); //xenDaemonDomainPinVcpu(domain, vcpu, cpumap, maplen); +} + +/** + * virDomainGetVcpus: + * @domain: pointer to domain object, or NULL for Domain0 + * @info: pointer to an array of virVcpuInfo structures (OUT) + * @maxinfo: number of structures in info array + * @cpumaps: pointer to an bit map of real CPUs for all vcpus of this domain (in 8-bit bytes) (OUT) + * If cpumaps is NULL, then no cupmap information is returned by the API. + * It's assumed there is <maxinfo> cpumap in cpumaps array. + * The memory allocated to cpumaps must be (maxinfo * maplen) bytes + * (ie: calloc(maxinfo, maplen)). + * One cpumap inside cpumaps has the format described in virDomainPinVcpu() API. + * @maplen: number of bytes in one cpumap, from 1 up to size of CPU map in + * underlying virtualization system (Xen...). + * + * Extract information about virtual CPUs of domain, store it in info array + * and also in cpumaps if this pointer is'nt NULL. + * + * Returns the number of info filled in case of success, -1 in case of failure. + */ +int +virDomainGetVcpus(virDomainPtr domain, virVcpuInfoPtr info, int maxinfo, + unsigned char *cpumaps, int maplen) +{ + int ret; + + if (domain == NULL) { + TODO + return (-1); + } + if (!VIR_IS_CONNECTED_DOMAIN(domain)) { + virLibDomainError(domain, VIR_ERR_INVALID_DOMAIN, __FUNCTION__); + return (-1); + } + if ((info == NULL) || (maxinfo < 1)) { + virLibDomainError(domain, VIR_ERR_INVALID_ARG, __FUNCTION__); + return (-1); + } + if (cpumaps != NULL && maplen < 1) { + virLibDomainError(domain, VIR_ERR_INVALID_ARG, __FUNCTION__); + return (-1); + } + ret = xenHypervisorGetVcpus(domain, info, maxinfo, cpumaps, maplen); + if (ret != -1) return ret; + return xenDaemonDomainGetVcpus(domain, info, maxinfo, cpumaps, maplen); +} --- libvirt-0.1.3/src/xend_internal.h 2006-07-10 12:24:05.000000000 +0200 +++ libvirt-0.1.3.with_vcpus/src/xend_internal.h 2006-08-02 16:54:27.000000000 +0200 @@ -631,6 +631,18 @@ unsigned long xenDaemonDomainGetMaxMemory(virDomainPtr domain); char **xenDaemonListDomainsOld(virConnectPtr xend); +int xenDaemonDomainSetVcpus (virDomainPtr domain, + int vcpus); +int xenDaemonDomainPinVcpu (virDomainPtr domain, + unsigned int vcpu, + unsigned char *cpumap, + int maplen); +int xenDaemonDomainGetVcpus (virDomainPtr domain, + virVcpuInfoPtr info, + int maxinfo, + unsigned char *cpumaps, + int maplen); + #ifdef __cplusplus } #endif --- libvirt-0.1.3/src/libvirt_sym.version 2006-05-29 18:19:30.000000000 +0200 +++ libvirt-0.1.3.with_vcpus/src/libvirt_sym.version 2006-08-02 15:26:56.000000000 +0200 @@ -47,5 +47,9 @@ virConnResetLastError; virDefaultErrorFunc; virNodeGetInfo; + + virDomainSetVcpus; + virDomainPinVcpu; + virDomainGetVcpus; local: *; }; --- libvirt-0.1.3/src/xend_internal.c 2006-07-10 16:41:54.000000000 +0200 +++ libvirt-0.1.3.with_vcpus/src/xend_internal.c 2006-08-02 16:48:24.000000000 +0200 @@ -2429,6 +2429,156 @@ free(name); return (NULL); } +/////////////////////////////////////////////////////////////////////////// + +/** + * xenDaemonDomainSetVcpus: + * @domain: pointer to domain object + * @nvcpus: the new number of virtual CPUs for this domain + * + * Dynamically change the number of virtual CPUs used by the domain. + * + * Returns 0 for success; -1 (with errno) on error + */ +int +xenDaemonDomainSetVcpus(virDomainPtr domain, int vcpus) +{ + char buf[16]; + + if ((domain == NULL) || (domain->conn == NULL) || (domain->name == NULL) + || (vcpus < 1)) { + virXendError((domain ? domain->conn : NULL), VIR_ERR_INVALID_ARG, + __FUNCTION__); + return (-1); + } + snprintf(buf, sizeof(buf), "%d", vcpus); + return xend_op(domain->conn, domain->name, "op", "set_vcpus", "vcpus", + buf, NULL); +} + +/** + * xenDaemonDomainPinCpu: + * @domain: pointer to domain object + * @vcpu: virtual CPU number + * @cpumap: pointer to a bit map of real CPUs (in 8-bit bytes) + * @maplen: length of cpumap in bytes + * + * Dynamically change the real CPUs which can be allocated to a virtual CPU. + * + * Returns 0 for success; -1 (with errno) on error + */ +int +xenDaemonDomainPinVcpu(virDomainPtr domain, unsigned int vcpu, + unsigned char *cpumap, int maplen) +{ + char buf[16], mapstr[sizeof(cpumap_t) * 64] = "["; + int i, j; + + if ((domain == NULL) || (domain->conn == NULL) || (domain->name == NULL) + || (cpumap == NULL) || (maplen < 1) || (maplen > (int)sizeof(cpumap_t))) { + virXendError((domain ? domain->conn : NULL), VIR_ERR_INVALID_ARG, + __FUNCTION__); + return (-1); + } + + /* from bit map, build character string of mapped CPU numbers */ + for (i = 0; i < maplen; i++) for (j = 0; j < 8; j++) + if (cpumap[i] & (1 << j)) { + sprintf(buf, "%d,", (8 * i) + j); + strcat(mapstr, buf); + } + mapstr[strlen(mapstr) - 1] = ']'; + snprintf(buf, sizeof(buf), "%d", vcpu); + return xend_op(domain->conn, domain->name, "op", "pincpu", "vcpu", buf, + "cpumap", mapstr, NULL); +} + +/** + * virDomainGetVcpus: + * @domain: pointer to domain object, or NULL for Domain0 + * @info: pointer to an array of virVcpuInfo structures (OUT) + * @maxinfo: number of structures in info array + * @cpumaps: pointer to an bit map of real CPUs for all vcpus of this domain (in 8-bit bytes) (OUT) + * If cpumaps is NULL, then no cupmap information is returned by the API. + * It's assumed there is <maxinfo> cpumap in cpumaps array. + * The memory allocated to cpumaps must be (maxinfo * maplen) bytes + * (ie: calloc(maxinfo, maplen)). + * One cpumap inside cpumaps has the format described in virDomainPinVcpu() API. + * @maplen: number of bytes in one cpumap, from 1 up to size of CPU map in + * underlying virtualization system (Xen...). + * + * Extract information about virtual CPUs of domain, store it in info array + * and also in cpumaps if this pointer is'nt NULL. + * + * Returns the number of info filled in case of success, -1 in case of failure. + */ +int +xenDaemonDomainGetVcpus(virDomainPtr domain, virVcpuInfoPtr info, int maxinfo, + unsigned char *cpumaps, int maplen) +{ + struct sexpr *root, *s, *t; + virVcpuInfoPtr ipt = info; + int nbinfo = 0, oln; + unsigned char *cpumap; + int vcpu, cpu; + + if ((domain == NULL) || (domain->conn == NULL) || (domain->name == NULL) + || (info == NULL) || (maxinfo < 1)) { + virXendError((domain ? domain->conn : NULL), VIR_ERR_INVALID_ARG, + __FUNCTION__); + return (-1); + } + if (cpumaps != NULL && maplen < 1) { + virXendError((domain ? domain->conn : NULL), VIR_ERR_INVALID_ARG, + __FUNCTION__); + return (-1); + } + root = sexpr_get(domain->conn, "/xend/domain/%s?op=vcpuinfo", domain->name); + if (root == NULL) + return (-1); + + if (cpumaps != NULL) + memset(cpumaps, 0, maxinfo * maplen); + + /* scan the sexprs from "(vcpu (number x)...)" and get parameter values */ + for (s = root; s->kind == SEXPR_CONS; s = s->cdr) + if ((s->car->kind == SEXPR_CONS) && + (s->car->car->kind == SEXPR_VALUE) && + !strcmp(s->car->car->value, "vcpu")) { + t = s->car; + vcpu = ipt->number = sexpr_int(t, "vcpu/number"); + if (oln = sexpr_int(t, "vcpu/online")) { + if (sexpr_int(t, "vcpu/running")) ipt->state = VIR_VCPU_RUNNING; + if (sexpr_int(t, "vcpu/blocked")) ipt->state = VIR_VCPU_BLOCKED; + } + else ipt->state = VIR_VCPU_OFFLINE; + ipt->cpuTime = sexpr_float(t, "vcpu/cpu_time") * 1000000000; + ipt->cpu = oln ? sexpr_int(t, "vcpu/cpu") : -1; + + if (cpumaps != NULL && vcpu >= 0 && vcpu < maxinfo) { + cpumap = (unsigned char *)GET_CPUMAP(cpumaps, maplen, vcpu); + /* get sexpr from "(cpumap (x y z...))" and convert values to bitmap */ + for (t = t->cdr; t->kind == SEXPR_CONS; t = t->cdr) + if ((t->car->kind == SEXPR_CONS) && + (t->car->car->kind == SEXPR_VALUE) && + !strcmp(t->car->car->value, "cpumap") && + (t->car->cdr->kind == SEXPR_CONS)) { + for (t = t->car->cdr->car; t->kind == SEXPR_CONS; t = t->cdr) + if (t->car->kind == SEXPR_VALUE) { + cpu = strtol(t->car->value, NULL, 0); + if (cpu >= 0) + USE_CPU(cpumap, cpu); + } + break; + } + } + + if (++nbinfo == maxinfo) break; + ipt++; + } + sexpr_free(root); + return nbinfo; +} /** * xenDaemonLookupByUUID:

3 9

[Libvir] New (last ?) virtual cpu functions proposal
by Philippe Berthault 03 Aug '06

03 Aug '06

Here the new virtual cpu functions proposal. What do you think about it ? /** * *virVcpuInfo*: structure for information about a virtual CPU in a domain. */ typedef enum { VIR_VCPU_OFFLINE = 0, /* the virtual CPU is offline */ VIR_VCPU_RUNNING = 1, /* the virtual CPU is running */ VIR_VCPU_BLOCKED = 2, /* the virtual CPU is blocked on resource */ *} virVcpuState*; typedef struct _virVcpuInfo virVcpuInfo; struct _virVcpuInfo { unsigned int number; /* virtual CPU number */ int state; /* value from virVcpuState */ unsigned long long cpuTime; /* CPU time used, in nanoseconds */ int cpu; /* real CPU number, or -1 if offline */ }; typedef virVcpuInfo **virVcpuInfoPtr*; /** * *virDomainSetVcpus*: * @*domain*: pointer to domain object, or NULL for Domain0 * @*nvcpus*: the new number of virtual CPUs for this domain * * Dynamically change the number of virtual CPUs used by the domain. * Note that this call may fail if the underlying virtualization hypervisor * does not support it or if growing the number is arbitrary limited. * This function requires priviledged access to the hypervisor. * * Returns 0 in case of success, -1 in case of failure. */ int *virDomainSetVcpus* (virDomainPtr domain, unsigned int nvcpus); /** * *virDomainPinVcpu*: * @*domain*: pointer to domain object, or NULL for Domain0 * @*vcpu*: virtual CPU number * @*cpumap*: pointer to a bit map of real CPUs (in 8-bit bytes). * Each bit set to 1 means that corresponding CPU is usable. * Bytes are stored in little-endian order: CPU0-7, 8-15... * In each byte, lowest CPU number is least significant bit. * @*maplen*: number of bytes in cpumap, from 1 up to size of CPU map in * underlying virtualization system (Xen...). * If maplen < size, missing bytes are set to zero. * If maplen > size, failure code is returned. * * Dynamically change the real CPUs which can be allocated to a virtual CPU. * This function requires priviledged access to the hypervisor. * * Returns 0 in case of success, -1 in case of failure. */ int *virDomainPinVcpu* (virDomainPtr domain, unsigned int vcpu, unsigned char *cpumap, int maplen); /* Macros for bit manipulation in cpumap */ #define *USE_CPU*(cpumap,cpu) (cpumap[(cpu)/8] |= (1<<((cpu)%8))) #define *UNUSE_CPU*(cpumap,cpu) (cpumap[(cpu)/8] &= ~(1<<((cpu)%8))) /** * *virDomainGetVcpus*: * @*domain*: pointer to domain object, or NULL for Domain0 * @*info*: pointer to an array of virVcpuInfo structures * @*maxinfo*: number of structures in info array * @*cpumaps*: pointer to a bit map of real CPUs for all vcpus of this domain. * If cpumaps is NULL, then no cpumap information is returned by the API. * It's assumed there is <maxinfo> cpumap in cpumaps. * The memory allocated to cpumaps must be (maxinfo * maplen) bytes. * One cpumap inside cupmaps have the format described in virDomainPinVcpu API. * @*maplen*: number of bytes in one cpumap, from 1 up to size of CPU map in * underlying virtualization system (Xen...). * * Extract information about virtual CPUs of domain, store it in info array. * * Returns the number of info filled in case of success, -1 in case of failure. */ int *virDomainGetVcpus* (virDomainPtr domain, virVcpuInfoPtr info, int maxinfo, unsigned char *cpumaps, /* may be NULL */ int maplen); /* Macros for bit testing in cpumaps */ #define *CPU_USABLE*(cpumaps,maplen,vcpu,cpu) \ (cpumaps[((vcpu)*(maplen))+((cpu)/8)] & (1<<((cpu)%8))) /* * Macro for copying the cpumap of a vcpu from cupmaps inside a standalone cpumap. * This macro is useful in case of using virDomainPinVcpu() after virDomainGetVcpus(). * cpumap must be previously allocated. */ #define *COPY_CPUMAP*(cpumaps,maplen,vcpu,cpumap) \ memcpy(cpumap, &(cpumaps[(vcpu)*(maplen)]), (maplen))

3 5

[Libvir] Newbie questions!
by Rodrigo Lord 03 Aug '06

03 Aug '06

Hello! I`m trying o use libvirt (or libvir?) what`s the difference? (this is the first question!) So, I compiled libvirt and libvir on my ia64 system(debian sarge 3.1) and download the code exemple of the website http://libvirt.org named info1.c To compile I used: "gcc -o test_dom0 test_dom0.c -lvirt" and ok. But when I try to run, shows the error below: peso@debian-ia64:~/test_libvirt$ ./test_dom0 libvir: error : no support for hypervisor Xen Failed to connect to hypervisor I tryied too to compile using: "gcc -o test_dom0 test_dom0.c -lvir" but doesn`t work too: peso@debian-ia64:~/test_libvirt$ ./test_dom0 Failed to find Domain 0 Thanks!

1 0

[Libvir] Re: Virtual CPU functions
by Philippe Berthault 03 Aug '06

03 Aug '06

I've tried to illustrate an exemple of virDomainGetVcpus API with a 2 dimensional cpumaps array. If you are agree with this, I can modify the patch of Michel Ponceau in this sense before the end of this week. I've proposed the virDomainGetCpus API to be in accordance with the virDomainPinVcpu which is per vpcu and not per domain as virDomainGetVcpus API. The virDomainPinVcpu API is'nt symmetrical with virDomainGetVcpus and must be called N times to perform the CPU mapping of a domain which isn't very satisfying. Another complaint against the virDomainPinVcpu versus virDomainGetVcpus API is that the cpumap parameter hasn't the same meaning in these two APIs. This point requires to duplicate macro for bit manipulations on these maps. Philippe Berthault ______________________________________________________________________ virConnectPtr pConn; virDomainPtr pDomain; virNodeInfo nodeInfo; virDomainInfo domInfo; virVcpuInfoPtr pVcpuInfos; int nbPhysCpus; unsigned char *cpuMaps[]; /* 1st dimension = per virtual cpu, 2nd dimension = per physical cpu */ int oneCpuMapLen; int vcpu, cpu; #define CPU_USABLE(maps,vcpu,cpu) (maps[vcpu][((cpu) / 8)] & (1 >> ((cpu) % 8))) ... virNodeGetInfo(pConn, &nodeInfo); nbPhysCpus = nodeInfo.cpus; /* ? or ? */ nbPhysCpus = nodeInfo.nodes * nodeInfo.sockets * nodeInfo.cores * nodeInfo.threads; virDomainGetInfo(pDomain, &domInfo); pVcpuInfos = malloc(sizeof(virVcpuInfo)*domInfo.nrVirtCpu); oneCpuMapLen = (nbPhysCpus + 7) / 8; cpuMaps = calloc(domInfo.nrVirtCpu, oneCpuMapLen); virDomainGetVcpus(pDomain, pVcpuInfos, domInfo.nrVirtCpu, cpuMaps, oneCpuMapLen); for (vcpu = 0; vcpu < domInfo.nrVirtCpu; vcpu++) { for (cpu = 0; cpu < nbPhysCpus; cpu++) { int byteCpu = cpu / 8; int bitCpu = cpu % 8; int mask = 1 >> bitCpu; /* lowest CPU number is least significant bit as M.Ponceau said */ int cpuUsable = cpuMaps[vcpu][byteCpu] & mask; ... /* or */ int cpuUsable = CPU_USABLE(cpuMaps, vcpu, cpu); ... if (cpuUsable) { printf("The physical cpu #%d is usable by virtual cpu #%d of domain #%s\n", cpu, vcpu, virDomainGetName(pDomain)); } } } ______________________________________________________________________

3 6

[Libvir] Virtual CPUs functions
by Philippe Berthault 01 Aug '06

01 Aug '06

Hello, I'm working on the vpcu patch of Michel Ponceau because he is in vacation for a long time. Michel has proposed to add 3 APIs to libvirt: - virDomainSetVcpus - virDomainPinVcpu - virDomainGetVcpus I've seen in libvirt mail archives that there was a problem with the virDomainGetVcpus API because the virCpuInfo structure contains a CPU map for only 256 physical CPUs. Your proposition to remove cpumap field from virCpuInfo structure and add it as parameter to the virDomainGetVcpus API isn't valid for the following reason: The virDomainGetVcpus API fills an array of virCpuInfo structures (one virCpuInfo for one VCPU) but cpumap is for one VCPU, not for all VCPUs at whole. Your proposition can work only if cpumap is a array of array of characters and if maplen is also an array of integers. This is very complicated solution and not elegant. I've also seen that you make a mistake in your proposition because you compute the cpuMapLen from the number of virtual CPUs but the cpumap is related to physical CPUs, not virtual CPUs. So, in conclusion, I propose, as you, to remove cpumap field of the virCpuInfo structure but to add an API to retrieve the CPU map of one VCPU. Such API would be: int virDomainGetCpus(virDomainPtr domain, unsigned int vcpu, unsigned char *cpumap, int maplen); The name is ...GetCpus (not 'Vcpus') because this API get the physical CPU map, not the virtual CPU map. Regards, Philippe Berthault.

2 1

Réf. : Re: [Libvir] Re: Proposal : add 3 functions to Libvirt API, for virtual CPUs
by jean-paul.pigache＠bull.net 31 Jul '06

31 Jul '06

I hope I will find a way to post the patches prepared by Michel Ponceau before the end of the week. Jean-Paul "Daniel P. Berrange" <berrange(a)redhat.com> Envoyé par : libvir-list-bounces(a)redhat.com 29/07/2006 09:35 Veuillez répondre à "Daniel P. Berrange" Pour : Jim Fehlig <jfehlig(a)novell.com> cc : libvir-list(a)redhat.com Objet : Re: [Libvir] Re: Proposal : add 3 functions to Libvirt API, for virtual CPUs On Fri, Jul 28, 2006 at 03:18:17PM -0600, Jim Fehlig wrote: > Has any progress been made on this proposal? I don't see anything in > current CVS. This functionality would be useful for Xen-CIM project. IIRC Michel Ponceau might have started on some prototype code, but he didn't post it to the list yet & is apparently on vacation for another couple of weeks (according to his email auto-responder). If no one else has started work on it in the meantime, I'm planning to get working on it when I return from vacation Aug 4th since I also need it for the virt-manager application. Regards, Dan. > michel.ponceau(a)bull.net wrote: > > > >Corrections on proposal: > >1) PinVcpus > >Replace: > > * @cpumap: pointer to a bit map of real CPUs (format in virVcpuInfo) > >* @maplen: length of cpumap, in 8-bit bytes > >by: > > * @cpumap: pointer to a bit map of real CPUs (in 8-bit bytes). > > * Each bit set to 1 means that corresponding CPU is usable. > > * Bytes are stored in little-endian order: CPU0-7, 8-15... > > * In each byte, lowest CPU number is least significant bit. > > * @maplen: number of bytes in cpumap, from 1 up to size of CPU map in > > * underlying virtualization system (Xen...). > > * If maplen < size, missing bytes are set to zero. > > * If maplen > size, failure code is returned. > > > >2) GetVcpu > >Add 4rth argument: > > * @maplen: number of bytes in cpumap field of virVcpuInfo > >virDomainGetVcpus(virDomainPtr domain, virVcpuInfoPtr info, int > >maxinfo, int maplen) > > > >3) Structure VcpuInfo > >Suppress: #define VIR_MAX_CPUS 256 > >Replace: > > unsigned char cpumap[VIR_MAX_CPUS/8]; /* Bit map of usable real CPUs. > >by: > > unsigned char cpumap[]; /* Bit map of usable real CPUs. > > Variable length: it may be less or greater than size of CPU > >map in > > underlying virtualization system (Xen...). > > > >4) Accessor macros: to be defined later. > > > >Veuillez répondre à veillard(a)redhat.com > > > >Pour : michel.ponceau(a)bull.net > >cc : libvir-list(a)redhat.com > >Objet : Re: Proposal : add 3 functions to Libvirt API, for > >virtual CPUs > > > >On Fri, Jun 30, 2006 at 04:00:45PM +0200, michel.ponceau(a)bull.net wrote: > >> For our administration, we need the following actions, while concerned > >> domain is running: > >> 1) Change the number of virtual CPUs. > >> 2) Change the pinning (affinity) of a virtual CPU on real CPUs. > >> 3) Get detailed information for each virtual CPU. > >> Currently there is no Libvirt function provided for that. We suggest to > >> add the following 3 functions (in libvirt.c): > >> /** > >> * virDomainSetVcpus: > >> * @domain: pointer to domain object, or NULL for Domain0 > >> * @nvcpus: the new number of virtual CPUs for this domain > >> * > >> * Dynamically change the number of virtual CPUs used by the domain. > >> * Note that this call may fail if the underlying virtualization > >> hypervisor > >> * does not support it or if growing the number is arbitrary limited. > >> * This function requires priviledged access to the hypervisor. > >> * > >> * Returns 0 in case of success, -1 in case of failure. > >> */ > >> int virDomainSetVcpus(virDomainPtr domain, unsigned int nvcpus) > > > > okay > > > >> /** > >> * virDomainPinVcpu: > >> * @domain: pointer to domain object, or NULL for Domain0 > >> * @vcpu: virtual CPU number > >> * @cpumap: pointer to a bit map of real CPUs (format in virVcpuInfo) > >> * @maplen: length of cpumap, in 8-bit bytes > >> * > >> * Dynamically change the real CPUs which can be allocated to a virtual > >> CPU. > >> * This function requires priviledged access to the hypervisor. > >> * > >> * Returns 0 in case of success, -1 in case of failure. > >> */ > >> int virDomainPinVcpu(virDomainPtr domain, unsigned int vcpu, > >> unsigned char *cpumap, int maplen) > > > > Can you explain more clearly what is the format of cpumap ? An example > >would be welcome, and that would be needed for the doc and maybe testing. > >What would happen if maplen is < or > than the number of CPU divided > >by 8 ? > > > >> /** > >> * virDomainGetVcpus: > >> * @domain: pointer to domain object, or NULL for Domain0 > >> * @info: pointer to an array of virVcpuInfo structures > >> * @maxinfo: number of structures in info array > >> * > >> * Extract information about virtual CPUs of a domain, store it in info > >> array. > >> * > >> * Returns the number of info filled in case of success, -1 in case of > >> failure. > >> */ > >> int virDomainGetVcpus(virDomainPtr domain, virVcpuInfoPtr info, int > >> maxinfo) > > > > Hum ... now the problem with that API entry point is that we 'burn' the > >maximum 256 processors in the ABI, i.e. if we ever need to go past 256 > >client and servers need to be recompiled. Maybe this is not a real problem > >in practice but that's annoying. Is there existing APIs doing this kind > >of things (in POSIX for example), and what hard limit did they use ? > > Maybe > > int virDomainGetVcpusNr(virDomainPtr domain, int nr, virVcpuInfoPtr info, > > int maxCPU); > >Where the maxCPU is defined by the client as the number of real CPU > >it defined in its virVcpuInfoPtr and then an iteration over the virtual > >CPU defined in the domain is possible too. > >Of course if the domain uses many virtual CPUs this would become expensive > >but somehow I don't see that being the common use, I would rather guess > >the domains created use a few CPUs even if instantiated on a very > >large machine. > >This > > > > > >> with the following structure (in libvirt.h): > >> /** > >> * virVcpuInfo: structure for information about a virtual CPU in a > >domain. > >> */ > >> #define VIR_MAX_CPUS 256 > > > > Hum, there is already NUMA machines with more than 256 processors, > >it's annoying to define an API limit when you know it is already > >breakable. > > > >> typedef enum { > >> VIR_VCPU_OFFLINE = 0, /* the virtual CPU is offline */ > >> VIR_VCPU_RUNNING = 1, /* the virtual CPU is running */ > >> VIR_VCPU_BLOCKED = 2, /* the virtual CPU is blocked on > >resource > >> */ > >> } virVcpuState; > >> > >> typedef struct _virVcpuInfo virVcpuInfo; > >> struct _virVcpuInfo { > >> unsigned int number; /* virtual CPU number */ > >> int state; /* value from virVcpuState */ > >> unsigned long long cpuTime; /* CPU time used, in nanoseconds */ > >> int cpu; /* real CPU number, or -1 if offline */ > >> unsigned char cpumap[VIR_MAX_CPUS/8]; /* Bit map of usable real > >CPUs. > >> Each bit set to 1 means that corresponding CPU is > >usable. > >> Bytes are stored in little-endian order: CPU0-7, 8-15... > >> In each byte, lowest CPU number is least significant > >bit > >> */ > >> }; > >> typedef virVcpuInfo *virVcpuInfoPtr; > > > > Hum, maybe some accessors should be provided in the API, letting the > >client > >code handle access and having to take care of indianness issues > >doesn't feel > >very nice. Something like the FD_CLR/FD_ISSET/FD_SET/FD_ZERO equivalents > >when using the select() POSIx call. > > > >> I have successfully tried those functions via Xen hypervisor, except > >for > >> the first (SetVcpus) where hypervisor operation DOM0_MAX_VCPUS fails > >> (maybe it is not possible on a running domain ?). That function was > >> successful via Xen daemon. > > > >Maybe that operation requires more than one hypervisor call to > >actually enable > >the processors. The simpler would be to look at the code in xend about > >what's > >needed there, maybe the kernel need to be made aware of that and I > >would expect > >this to be a xenstore operation. > >At least we know we can fallback to xend if the hypervisor call > >doesn't work > >directly. > >I don't know if virDomainGetVcpus should really be mutated into > >virDomainGetVcpusNr, I would certainly like to be able to keep that API > >extensible for more than 256 CPUs. Maybe I'm just too cautious there, > > > > I would really like feedback from others on this issue ! > >In the meantime sending the current set of patches you developped could > >allow to look closely at the 2 calls that I feel okay with. > > > > thanks and sorry it took so long ! > > > >Daniel > > > >-- > >Daniel Veillard | Red Hat http://redhat.com/ > >veillard(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ > >http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ > > > >------------------------------------------------------------------------ > > > >-- > >Libvir-list mailing list > >Libvir-list(a)redhat.com > >https://www.redhat.com/mailman/listinfo/libvir-list > > > > -- > Libvir-list mailing list > Libvir-list(a)redhat.com > https://www.redhat.com/mailman/listinfo/libvir-list -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| -- Libvir-list mailing list Libvir-list(a)redhat.com https://www.redhat.com/mailman/listinfo/libvir-list

1 0