- Devel - libvirt List Archives

[Libvir] [QEMU 1/3] hook up driver methods for inactive domains
by Daniel P. Berrange 30 Aug '06

30 Aug '06

The attached patch prepares the driver method API to support inactive domains. The following methods are hooked up: * virConnectListDefinedDomains * virConnectNumOfDefinedDomains * virDomainDefineXML * virDomainUndefine * virDomainCreate It sets all existing drivers to have NULL in these fields. The existing code in virDomainDefineXML was ripped out since it was found to be more trouble than it was worth - the backend driver needed to repeat most of the logic anyway - so better just to delegate the whole lot. 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] 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