- Devel - libvirt List Archives

[Libvir] Proposal for virtual devices
by michel.ponceau＠bull.net 07 Sep '06

07 Sep '06

I previously made a proposal for block devices. It was rejected because it was VBD-specific and Xen-specific. Here is a proposal for transparent interface with Xen or other. The virtual device attributes (VDA) are transferred from/to application without considering their meaning, except backend domain, previously requested to be the name for user, while it is the ID for Xen. typedef struct virVDA { /* virtual device attribute */ char name[16]; char value[64]; } virVDA; int virDomainGetVdevs(virDomainPtr domain, char *type, virVDA *attr, int maxattr); * @type: pointer to device type, "disk", "network" ... * @attr: pointer to an array of virVDA structures * @maxattr: number of structures in attr array * Return: (number of VDAs per device)<<16 + (number of devices), if success; * -1 if failure. For "disk" type, Xen provides the following VDA names: "virtual-device" (virtual device number) "backend-id" (backend domain ID) "state" "backend" (backend device or file) "ring-ref" "event-channel" This function changes "backend-id" to "bkdom-name" and translates value ID into name. int virDomainCreateVdev(virDomainPtr domain, char *type, virVDA *attr, int nbattr); * @type: pointer to device type, "disk", "network" ... * @attr: pointer to an array of virVDA structures * @nbattr: number of structures in attr array For "disk" type, Xen requires the following VDA names: "uname" (backend device, value either "phy:<>" or "file:<>" "dev" (virtual device number) "mode" (value "ro" for read-only, or "rw" for read/write) "backend" (backend domain ID) This function translates "backend" user value (name) into ID. int virDomainDestroyVdev(virDomainPtr domain, char *type, char *ref); * @type: pointer to device type, "disk", "network" ... * @ref: pointer to virtual device reference (number for Xen...)

2 1

[Libvir] libvirt-0.1.5 release
by Daniel Veillard 05 Sep '06

05 Sep '06

With the recent Xen hypervisor breakage, I think it was urgent to push a new release for testing even if some parts are still in development and not finished. So expect a new release in a couple of weeks. In the meantime 0.1.5 is available at: ftp://libvirt.org/libvirt/ * Support for new hypercalls change in Xen changeset 86d26e6ec89b * bug fixes: - virParseUUID() was wrong, netwoking for paravirt guests (Daniel Berrange) - virsh on non-existent domains (Daniel Berrange) - string cast bug when handling error in python (Pete Vetere) - HTTP 500 xend error code handling (Pete Vetere and Daniel Berrange) * improvements: - test suite for SEXPR <-> XML format conversions (Daniel Berrange) - virsh output regression suite (Daniel Berrange) - new environ variable VIRSH_DEFAULT_CONNECT_URI for the default URI when connecting (Daniel Berrange) - graphical console support for paravirt guests (Jeremy Katz) - parsing of simple Xen config files (with Daniel Berrange) - early work on defined (not running) domains (Daniel Berrange) - virsh output improvement (Daniel Berrange) Thanks for everyone who helped out, please check that everything is working with the new hypervisor code, I could not test all entry points, I am on the road ! 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] [Patch 3/4]: Xen inactive domains: stop xend/xs/xen using inactive domains
by Daniel P. Berrange 04 Sep '06

04 Sep '06

The existing xend, xs, xen, proxy driver backends all assume that if they're given a virDomainPtr object, the handle member is non-zero (ie its a running domain). With the addition of inactive domain support this assumption is no longer value. Thus this patch modifies all these drivers, so that if the handle is -1, then they return without doing any work. This lets the operation be correctly delegated to the new driver for inactive domains. In addition, the XenD driver assumed that if XenD returns a 404 when looking up a domain based on its name, this was a fatal error condition. Since inative domains are not known to XenD, this assumption is also now false. The attached patch modifies xend_internal so that if a 404 is returned, the error is not propagated to the libvirt error handlers. Instead the methods in question simply return -1, and control continues to the new backend for managing inactive domains. 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] [Patch 2/4]: Xen inactive domains: hash file
by Daniel P. Berrange 04 Sep '06

04 Sep '06

The management of inactive domains uses the hashtable APIs for managing its list of config files. In doing so it needed some extra capabilities. This patch adds 3 new routines: - virHashForEach - iterate over all values in the hashtable invoking a callback for each one. Modifying the hashtable from the callback is forbidden, or bad stuff will happen. - virHashRemoteSet - iterate over all values in the hashtable invoking a callback for each one. If the callback returns non zero, the element will be removed. - virHashSearch - iterate over all values in the hashtable invoking a callback for each one. The first entry for which the callback returnbs non-zero will be returned. 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] [Patch 1/4] Xen inactive domains: config file APIs
by Daniel P. Berrange 04 Sep '06

04 Sep '06

This patch adds an extra API to the config file management API. This API lets you add a new config parameter to the file. Previously you could only modify existing values, not define extra ones. It also exposes an API for creating a new empty config file record, which is needed if you're creating a brand new config file, rathre than processing an existing one. 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] [Pach 4/4]: Xen inactive domains: new XM driver
by Daniel P. Berrange 04 Sep '06

04 Sep '06

This patch adds a new driver xm_internal.c which manages inactive domains whose config files are found in /etc/xen. On certain operations the driver will scan /etc/xen for new domains - the scanning is throttled to only occur at most every 10 seconds. When scanning any new domains are loaded into memory, and any domains deleted off disk are removed. This driver can start new domains, define domains, get/set memory, max memory, vcpus, can dump XML, and list inactive domains. The list of inactive domains is filtered to remove any domains which are running. This driver is still work in progress. There is more work needed to report error exact conditions via libvirt error APIs, and the code for serializing from XML -> XM config file is not yet complete. The code for serializing from XM config files into XML is pretty much complete although needs more testing. All the APIs can be tested via the commands added to virsh for inactive domains last week. eg list --inactive, start, define, undefine I'll post another update of this patch tomorrow which should be more complete 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] [Patch 0/4] Xen inactive domain
by Daniel P. Berrange 04 Sep '06

04 Sep '06

The following series of patches add support for managing inactive domains with Xen. Based on DV's recent xm config file reader, it processes all domains in /etc/xen (skipping known bogus files, xmexmaple*, xend-config.sxp). It can do all the operations you'd expect for managing inactive domains. Create a new domain, start a domain, list domains, delete a domain, change cpu / memory, get XML for domain. The impact on existing driver backends is very small - the only place which needed changing is the XenD code which lookups existing domains - making it be quiet if it get s a 404 error from XenD - this is to be expected if the domain is inactive. 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] Semantics for ListDomains/ ListDefinedDomains
by Daniel P. Berrange 03 Sep '06

03 Sep '06

So I was thinking a little about lifecycle support for passive domains in libvirt and wanted to clarify the intended semantics of the two methods: virConnectListDomains virConnectListDefinedDomains Am I correct in thinking that virConnectListDefinedDomains will list a domain if-and-only-if its state == 'shutoff', and that virConnectListDomains will list a domain if-and-only-if its state != 'shutoff' ie, when I start a defined domain with 'virDomainCreate', it will be removed from the 'ListDefinedDomains' set and added to the 'ListDomains' set. Likewise when shutting down it'll move back the other way. Or will the virConnectListDefinedDomains call always list a domain with a config file, even if it is running ? I realize this is a little hypothetical since XenD doesn't have lifecycle management yet, but it matters to the test backend, and any potential QEMU / UML backend, and the future XenD XML-RPC 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 -=|

4 9

[Libvir] Libvirt / Xen incompatible versions.
by Michel Gauthier 01 Sep '06

01 Sep '06

We've just installed the last advanced version of Xen on our IA64 platform. Unfortunatly, the build of the 0.1.4 version of libvirt with this version of Xen is not successful. The C header file of Xen /usr/include/xen/dom0_ops.h used by libvirt in xen_internal.c has been modified. The dom0_getdomaininfo_t structure is no more decared in this header file. Are you aware of this problem? What is the latest version of Xen on which libvirt has been successfully built and tested? Thanks.

2 1

[Libvir] [QEMU 3/3] the qemu driver & daemon
by Daniel P. Berrange 31 Aug '06

31 Aug '06

Attached is the patch for the qemu driver & daemon process Since there is no scalable way to determine active standalone QEMU instances, or access their monitor connection, the backend implements a management daemon - called 'qemud' - which takes care of managing the complete lifecycle of QEMU virtual machines. The libvirt driver is a thin shim which talks to qemud via a UNIX domain socket - the wire protocol is modelled after the protocol used for libvirt_proxy, but obviously contains alot more functions since its full read/write, not just read-only. There is intended to be one qemud instance per UNIX user - the so called 'session' instance, and optionally one system global instance runing as root (or a system daemon account?) - the so called 'system' instance. When using libvirt, the URIs for each are 'qemu:///session' and 'qemu:///system' respectively. The UNIX socket for session instances is $HOME/.qemud and is chmod 0700 - no support is provided for users connecting to each other's instances. Although we could trivially extend to create a read-only socket $HOME/.qemud-ro if desired. The system instance is currently not finished but intended to run in /var/run/qemud or some such. The backend code is in src/qemu_internal.h, src/qemu_internal.c, the daemon code is in qemud/* with qemud/protocol.h defining the network wire protocol. This latter header file is also included by src/qemu_internal.c - qemud.c - the main daemon management code - handles all network I/O and forking / cleanup of QEMU processes. The implementation is poll() based & completely non-blocking. All requests/replies from a single client are, however, serialized. - dispatch.c - takes care of serializing/de-serializing requests/replies from/to libvirt - called from qemud.c when a complete message is available. - driver.c - the implementation of each request from libvirt - called from dispatch.c - config.c - manages reading & writing of XML files for inactive domains in the $HOME/.qemud.d/*.xml. Also takes care of generating a suitable command line for execing qemu. In terms of hardware, there is support for - harddisk - floppy, cdrom, harddisk - graphics - VNC - memory - virtual CPUs In particular no support for - networking - sound - non-native CPU types - boot order But its enough to demonstrate the practice. 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