July 2007 - Devel - libvirt List Archives

[Libvir] XM config <-> XML config
by Arik Raffael Funke 19 Jul '07

19 Jul '07

Hi, I am using Fedora 7 with virt-manager to control my xen domains. I would like to delegate a pci device to one of my domU's. I know how this is done in the XM and sxp config files, but how is it done now? I read that libvirt can convert XM <-> XML and though I could export my current config to XM format, edit it and reimport. How is is done with libvirt? Thanks, Arik

2 3

[Libvir] PATCH: Support input devices in XML format
by Daniel P. Berrange 19 Jul '07

19 Jul '07

This patch is the first step towards supporting USB devices in libvirt XML format. As per the original thread some months back[1], I'm the grouping is being done based on device classes, rather than bus types. So this first patch is actually introducing the concept of 'input' devices. This is best illustrated by examples - PS2 mouse - automatically added when yuou turn on <graphics> in an HVM guest. <input type='mouse' bus='ps2'/> - Xen mouse - automatically added when you turn on <graphics> in a Xen paravirt guest (ie the paravirt input device) <input type='mouse' bus='xen'/> - USB mouse - have to actually ask for this. Not all that useful since its still using relative co-ordinates, but here for completeness. <input type='mouse' bus='usb'/> - USB tablet - have to actually ask for this. Very useful. Windows and Linux can both drive this in absolute co-ordinate mode. <input type='tablet' bus='usb'/> If it possible to omit the 'bus' attribute, in which case it'll automatically set up the device on the most appropriate bus for that type of device. So if you say type='mouse', it'll pick a ps2/xen bus. If you say type='tablet' it'll pick a usb bus. In my previous email[1] I suggested a possible 'model' attribute as well. I since discovered that Xen removed support for the summagraphics tablet completely, so adding a model at this time is a waste of time. We can always choose it add it later if we port to another virt manager here we need to distinguish devices on more than just a (type, bus) pair. As with the previous '<clock/>' element, it is intended that virt-install and virt-manager will automatically add a USB tablet if they you tell them you're installing Windows, or a recent Linux guest. It'll also be possible manally add post-install through the virt-manager UI. For the QEMU driver at least, I intend to make it possible to hot add & remove USB devices. This will appear as impl of virAttach/Detch methods for QEMU at least. Xen doesn't support hot add/remove of USB at this time. Finally, before I actually commit this I think it is well overdue to write some unit tests for the QEMU driver. So I'm going to do a test which chceks XML -> data struct -> QEMU command line, and XML -> data struct -> XML sequences of operations. This should let us exercise all the XML related code in QEMU which is a good start & helpful to avoid regressions. Regards, Dan. [1] http://www.redhat.com/archives/libvir-list/2007-March/msg00205.html -- |=- 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 6

[Libvir] Asynchronous notifications of domain start/stop
by Richard W.M. Jones 19 Jul '07

19 Jul '07

I had some private discussions with a developer who wants to start using libvirt, but requires asynch notifications of domain start/stop (and other stuff, but this will do for the moment). Right now he's using XenStore watches. The alternative of polling didn't look very appealing for him. A rough API for this might look like this: typedef int virEventHandle; /* Register a callback to catch domain start events. */ virEventHandle virEventDomainStart (virConnectPtr, void (*f) (virConnectPtr, int domid)); /* Register a callback to catch domain stop events. */ virEventHandle virEventDomainStop (virConnectPtr, void (*f) (virConnectPtr, int domid)); /* Unregister any type of callback. */ int virEventCancel (virConnectPtr, virEventHandle handle); Implementation -------------- In the Xen case, we can use XenStore watches[1]. Callbacks from XenStore can be translated directly into event callbacks. In the qemu case, the daemon knows when the qemu instances that it manages come and go. In the qemu/remote case, asynch notifications are nominally supported by the protocol, but I haven't really looked at all the implications. Seems like we'd need to use MSG_OOB to signal the client process, and translate the SIGURG signal received into a callback. This is all tricky and Unix-specific though so if you have any better ideas ... We would also need to avoid mixing ordinary request/response with the notifications, which OOB takes care of. Rich. [1] http://wiki.xensource.com/xenwiki/XenBusDriver -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903

4 17

[Libvir] virDomainConfigureDevice?
by Hugh Brock 18 Jul '07

18 Jul '07

I'm looking at ways to replicate xm block-configure at the libvirt level. xm block-configure is useful in that it allows you to change the back device for an HVM guest while the guest is still running; this permits you for example to change the CDROM without shutting down your guest or poking around in xenstore. Thus we can have an "eject" button on cdrom devices in virt-manager (or "eject" and "load" buttons, I guess), which we really need. The issue of course is that xm block-configure is specifically intended for block devices and takes arguments for the back device and the front device (among others). We would naturally prefer to accept a block of XML just as virDomainAttachDevice does and then parse it, determine if the device in question is of a type we can actually edit, determine if the new backdev is appropriate, and so on. None of this seems terribly hard, but before I go implement it, are there obvious pitfalls I'm not thinking? And given that virDomainAttachDevice is not implemented for qemud in libvirt (is it?), how do we handle the non-xen case? Thanks, --Hugh -- Red Hat Virtualization Group http://redhat.com/virtualization Hugh Brock | virt-manager http://virt-manager.org hbrock(a)redhat.com | virtualization library http://libvirt.org

4 7

[Libvir] [PATCH] cleanup of virDeviceMode
by Daniel Veillard 18 Jul '07

18 Jul '07

Since this was raised yesterday about the purity of the libvirt API w.r.t. Xen specifics, we don't actually use the virDeviceMode nor have any possible use for them at the API level since basically this kind of informations is always rovided as part of an XML and never as an int/enum. So I propose to just remove them from the headers and API, I don't see how an application could use the enum but maybe I missed one, in which case please tell me :-) 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/

2 2

[Libvir] [PATCH 0/2] virDomainMigrate (for discussion only!)
by Richard W.M. Jones 18 Jul '07

18 Jul '07

This is a patch which adds virDomainMigrate. It is incomplete (only supports Xen, no remote support, no qemu support), but I hope you'll look at the proposed interface and discuss the parameters. More in the following two emails. Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903

6 40

[Libvir] Initial OpenVZ Support Patches
by Shuveb Hussain 17 Jul '07

17 Jul '07

Hi, Here are the OpenVZ support patches. The .c and .h files go into src/ This is being released in the spirit of releasing early. Only the basic stuff is done and development is continuing. What works: * Getting number of active/inactive domains * Listing active/inactive domains * Creating a domain that has been already defined (using OpenVZ tools) * Shutdown, start, reboot * configure.in has a new switch --with-openvz(on by default), use --without-openvz to switch it off. After I get feedback, I will work on it and add other features later on. There is no need for any OpenVZ tools code. Just the OpenVZ kernel and tools need to be installed. This code depends on the OpenVZ tool binaries. Differences from QEMU/Xen: * ID and name are same * Not possible to create temporary domains and do away with them. Creating a domain will involve untarring a template cache and bringing it up. * No readonly access. OpenVZ tools need root access. There are other design issues to be discussed. These issues spring from the fact that OpenVZ is very different from Xen/QEMU. I will discuss these issues in further mails. Here is a sample session transcript: shuveb@debian-openvz:~/libvirt$ sudo src/virsh -c openvz:///system Welcome to lt-virsh, the virtualization interactive terminal. Type: 'help' for help with commands 'quit' to quit virsh # list Id Name State ---------------------------------- 101 101 running 102 102 running 103 103 running virsh # shutdown 101 Domain 101 is being shutdown virsh # list Id Name State ---------------------------------- 102 102 running 103 103 running virsh # list --all Id Name State ---------------------------------- 102 102 running 103 103 running - 101 shut off virsh # start 101 Domain 101 started virsh # list Id Name State ---------------------------------- 101 101 running 102 102 running 103 103 running virsh # Thanks and Regards, -- Shuveb Hussain Unix is very user friendly. It is just a little choosy about who its friends are http://www.binarykarma.com

3 5

[Libvir] PATCH: Specify BIOS clock offset for HVM
by Daniel P. Berrange 17 Jul '07

17 Jul '07

The attached patch introduces a new XML element for specifying information about the guest (BIOS) clock. For Xen HVM, and QEMU / KVM guests this is used to specifyc whether the guest clock should be in UTC, or localtime. The latter is useful for Windows which likes the BIOS to be localtime, while the former is useful for all other operating systems. The former is of course the default - so no change in existing semantics. The <clock> element currently takes a single attribute 'offset'. This is either 'utc' or 'localtime', but if we port to VMWare, it will also allow an arbitrary numeric offset as well as these special constants. <clock offset='utc'/> Or <clock offset='localtime'/> It may later also be desirable to add a 'sync=[yes|no]' attribute to specify whether the HV tries to keep the clock in sync with the HV while it is running. VMWare has this concept, and so does Xen paravirt - though Xen paravirt sets it via /proc/sys/xen/independant_wallclock inside the guest and AFAICT doesn't (yet) expose it to the guest config in Dom0. Anyway, my patch implements use of utc/localtime offsets for Xen, and QEMU drivers. I've tested to verify that -localtime gets passed to the QEMU process as appropriate. 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] Regarding Libvirt & VirtManager
by Paulev 16 Jul '07

16 Jul '07

Hi All, I'm curious to know if LibVirt & VirtManager is being developed only by RedHat employees only. If not, what is the process for developers who wish to contribute to these projects. Also, I'd like to know how and by whom decisions are made for new features to be included in these projects. Thanks, Evan

2 1

[Libvir] OCaml binding 0.3.0.0 released
by Richard W.M. Jones 14 Jul '07

14 Jul '07

http://et.redhat.com/~rjones/ocaml-libvirt/ Adds: * virConnectGetHostname (as Libvirt.Connect.get_hostname) * virConnectGetURI (as Libvirt.Connect.get_uri) and full support for virterror, including all the internal fields. See: http://et.redhat.com/~rjones/ocaml-libvirt/html/Libvirt.Virterror.html Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903

1 1