- Devel - libvirt List Archives

Re: [Libvir] Authenticate APIs ?
by Richard W.M. Jones 15 Jan '07

15 Jan '07

[Apologies that this is not threaded with the original post] > Following on from the issue of certificate management, is the issue of > authentication. This hasn't been an issue thus far, because Xen has zero > authentication. I'm not planning to make this same mistake with the QEMU > management daemon though - its going to have a secure data transport and > real authentication from day-1. Thus we need to consider how authentication > is exposed at the libvirt client API layer. > > First off, there are many possible authentication approaches: > > - Username + password > - Username + one time key > - Username + password digest > - Kerberos tickets > - x509 certificates > - ...etc I would definitely avoid over-engineering a solution. I suspect that "large corp" users will understand certificate infrastructures -- they probably already use X.509 client certificates to authenticate desktops -- and will be able to manage those. Everyone else will want to use ssh, the model for that being the way cvs allows you to flexibly hand over authentication problems to an external program through setting the $CVS_RSH environment variable. It's so easy to set up ssh to get passwordless remote logins. If they haven't set that up, and they're using libvirt through a command line tool like virsh then they'll get a prompt from ssh to type a password. ssh also has the advantage that it is very widely installed. The only issue is what command to run on the remote system. A simple command line tool which talks to the daemon over a socket might be one option. nc (netcat), gnutls_cli or stunnel might work too. Rich. -- Red Hat UK Ltd. 64 Baker Street, London, W1U 7DF Mobile: +44 7866 314 421 (will change soon)

2 1

[Libvir] Certificate management APIs ?
by Daniel P. Berrange 15 Jan '07

15 Jan '07

I now have the QEMU backend working with full wire encryption using the TLS protocol, and so ready to start thinking about various authentication related issues. - The client needs to have the certificate of the CA in order to validate the signature on the remote server's certificate (aka, just like web browsers need a set of CA certificates) Currently I just have it loading 'cert.pem' out of the current working directory of the app using libvirt. Obviously this is not a real solution. - The client technically should have a certificate revocation list too. Again I currently load this out of current working dir - The server end can optionally require the client to present a certificate too, as its means of authenticating the client. This obviously requires a way of specifying the client certificate and secret key in libvirt when opening the connection. - The first time it connects to a server, the client validates the server's certificate against the CA certificate, and remote hostname. Web browsers will also typically display the certificate to the user and ask them to allow one-time, allow permanently, or reject it. This would require a way to pass the certificate back to the client app during the virConnectOpen call. The above is all related to x509 certificates. So we basically have 5 types of file we need to store / provide to libvirt when opening a connection: - Certificate Authority's certificate - Certificate Authority's certificate revocation list - Client secret key - Client certificate - Trusted server certificates And some form of callback to let the client app validate the server certificate. As a rough stab at an API my thoughts are: typedef enum { VIR_CERT_CA_CERT, VIR_CERT_CA_CRL, VIR_CERT_CLIENT_KEY, VIR_CERT_CLIENT_CERT, } virConnectCertDataType; /** * dataType: one of the virConnectCertDataType constants * data: base64, PEM encoded certificate/key data */ int virConnectAddCertData(int dataType, const char *data); /** * dataType: one of the virConnectCertDataType constants * dataFile: file containing base64, PEM encoded certificate/key data */ int virConnectAddCertDataFile(int dataType, const char *dataFile); Virt-manager would use the latter API to load in its client certificate, CA certs, etc to libvirt prior to opening a connection to a TLS enabled server. This means libvirt doesn't have to make the policy on where to store its client cert data. On the otherhand, we probably want the files to be in a common location for virsh & virt-manager so both can use the same data. On yet another hand, virt-manager will also likely end up using TLS to connect to VNC, so needs access to the files independant on libvirt / virsh for that. So we should probably have these flexible APIs, but recommend that all apps use a pre-defined directory unless they have a particular need not to, eg $HOME/.libvirt/tls/ | +- ca | | | +- cert.pem | +- ca-crl.pem | +- client | | | +- cert.pem | +- key.pem | +- server | +- trusted.pem /** * hostname: canonical name of remote host providing certiifcate * cert: base64, PEM encoded certificate data * * Invoked to let client application decide whether to accept a * server certificate. The certificate wil already have been * validated against the CA cert, and its expiration date, etc * checked. This callback is intended to allow the end user to * accept/reject the certificate. The trusted flag indicates * whether the server is present in the list of known servers. */ typedef int (*virConnectCertificateValidator)(const char *hostname, const char *cert); int virConnectSetCertificateValidator(virConnectCertificateValidator cb) The applications like virt-manager would probably want to present the certificate details to the user for validation, also optionally maintaining a list of previously trusted server certs. 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] Authenticate APIs ?
by Daniel P. Berrange 15 Jan '07

15 Jan '07

Following on from the issue of certificate management, is the issue of authentication. This hasn't been an issue thus far, because Xen has zero authentication. I'm not planning to make this same mistake with the QEMU management daemon though - its going to have a secure data transport and real authentication from day-1. Thus we need to consider how authentication is exposed at the libvirt client API layer. First off, there are many possible authentication approaches: - Username + password - Username + one time key - Username + password digest - Kerberos tickets - x509 certificates - ...etc So of these require prompting the user for data (eg username / password), others will pick up their credentials from known sources (eg, the keberos ticket cache file in /tmp/krbXXX), or have to be provided ahead of time as part of the transport layer securit protocol (eg the x509 certificate file). We don't have to consider the latter case, since that's taken care of by the certificate management API - unless we want to figure out a more unified API, but I'm not sure it would be particularly sane. The interesting case from an API point of view is the first, which requires prompting the user for data. This is pretty much the PAM approach, with the added complication that you're in the middle of a network protocol and you may have several wire messages going back & forth, each time requesting more pieces of info. ie you can't possibly gather the neccessary info ahead of time. So we need some form of callback to collect the neccessary auth data. The network protocol equivalent of PAM is SASL. This actually has a number of different types of callback function yuou can register, depending on what sort of data you're prepared to provide as a client - Challenge / response: - const char *challenge - const char *prompt - const char *defresult, - const char **result, - unsigned *len - Password, username, language - const char **result - unsigned *len - AUthentication realm - const char **availrealms, - const char **result There are a few more auth callback types defined in SASL spec, which I've omitted here for brevity. We could map this onto an API something like this: enum { VIR_CONN_AUTH_PASSWORD, VIR_CONN_AUTH_USERNAME, VIR_CONN_AUTH_LANG, VIR_CONN_AUTH_CHALLENGE, VIR_CONN_AUTH_REALM, } virConnectAuthToken; typedef int (virConnectAuthCBSimple)(const char **result, unsigned *len); typedef int (virConnectAuthCBPrompt)(const char *challenge, const char *prompt, const char *defresult, const char *result, unsigned *len); typedef int (virConnetAuthCBRealm)(const char **availrealms, const char *result); typedef struct { int token; union { virConnectAuthCBSimple simple; virConnectAuthCBPrompt prompt; virConnectAuthCBRealm realm; } cb; } virConnectAuthCallback; int virConnectSetAuthCallbacks(virConnectAuthCallback *cbs, int ncbs); Now, of course not everything is going to be SASL based - Xen may well end up using TLS/SSL + HTTP Basic auth. There's a couple of other HTTP related auth protocols too. They are all basically a subset of SASL provides, so the above API ought to be sufficient to serve their auth needs too. Finally, one could simply say, this is all rather complicated, why don't we just use a simple username+password for everything. While this would be nice from a coding POV, I think we need to be forward looking and ensure we're setup to cope with things like Kerberos single-sign-on. This is why I'm looking at SASL for the QEMU authentication process - if you use libsasl.so you're app doesn't even need to know what auth method it is using - the admin can simple create an appropriate config file for sasl, and bingo you're fully kerberized & single sign-on capable. 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] Availability of the Relax-NG schemas for libvirt XML instances
by Daniel Veillard 13 Jan '07

13 Jan '07

As hinted previously in the QEmu thread, I developped a Relax-NG schemas to check the XML instances used to define Domains in libvirt. It's in CVS in the docs directory and also available online at http://libvirt.org/libvirt.rng For those not familiar with Relax-NG there is a nice tutorial and docs at http://relaxng.org/ Libxml2 on which libvirt depends has support for Relax-NG so we could easilly add checking at domain creation time within the library, but I decided to not add this at the moment, at least the schemas need to get more testing itself. The simplest to validate existing XML instances is to use the command line tool of libxml2 named xmllint in the following way: paphio:~/libvirt/tests -> xmllint --noout --relaxng ../docs/libvirt.rng xml2sexprdata/xml2sexpr-disk-drv-blkback.xml xml2sexprdata/xml2sexpr-disk-drv-blkback.xml validates paphio:~/libvirt/tests -> The schemas try to validate content as much as possible, but it's not possible to validate really in a complete fashion, for example to validate an IP address I used the following type: <define name='addrIP'> <data type='string'> <param name="pattern">([0-2]?[0-9]?[0-9]\.){3}[0-2]?[0-9]?[0-9]</param> </data> </define> which will catch '192.618.0.254' as erroneous but not '192.168.0.264' . There is also a number of cases which are structure related but hard to express cleanly in a schemas for example the fact that we may have an emulator description in the device list but that it's should only be allowed in an hvm kind of configuration. Still despite the limitations I found 2 weirdness: - we allow both <os> and <bootloader> blocks to be present, but I think they are redundant, I remember that Xen will ignore the bootloader informations if the os description is there, shouldn't we ban having both in a domain description ? e.g. tests/sexpr2xmldata/sexpr2xml-curmem.xml in the tree I still allowed this in the schemas but this may be wrong. - I though an interface of type ethernet needed a source description, but the output tests/sexpr2xmldata/sexpr2xml-net-routed.xml seems to miss both the source and target of the interface though the device is present in tests/sexpr2xmldata/sexpr2xml-net-routed.sexpr as (dev 'eth3') this probably indicates our conversion from sexpr to xml is lossy there. currently tests/sexpr2xmldata/sexpr2xml-net-routed.xml is the only example from our regression tests which doesn't pass the schemas testing. In general the schemas is both stricter than libvirt itself (as libvirt will only pick the parts of the XML it recognizes and need) and still allows some invalid constructs, I guess it's nearly impossible to make it a one to one match but I hope this can still be useful both for client tools, regression testings, and as another source of documentation. I still need to update the libvirt documentation, the XML page had some omissions and document the availability of the schemas and find its place when doing a 'make install', 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 1

[Libvir] Bug in the virDomainGetInfo() API of libvirt 0.1.9 with Xen 3.0.3
by Philippe Berthault 12 Jan '07

12 Jan '07

The maxMem field of the virDomainInfo structure is given in bytes instead of Kbytes when the domain is 0 (Domain-0). With others domains, the value of maxMem is correct. Exemple with virsh: On a system with 4 GB memory, virsh reports: # virsh dominfo 0 ... Max memory: 4294967292 kB With the same libvirt version 0.1.9 but with an older Xen (not 3.0.3), the maxMem value of Domain-0 is correct.

3 7

[Libvir] Question about libvirt integration into RHEL-5
by Philippe Berthault 11 Jan '07

11 Jan '07

Hello, Currently, the libvirt integrated into RHEL-5 beta release is the pretty old 0.1.8 version. Could you confirm that in the first release candidate RHEL-5 RC1 (planned february, 28), the libvirt will be the 0.1.8 version or another one ? Thanks.

3 8

[Libvir] PATCH 0/2: Support QEMU (+KVM) in libvirt
by Daniel P. Berrange 09 Jan '07

09 Jan '07

The following series of (2) patches adds a QEMU driver to libvirt. The first patch provides a daemon for managing QEMU instances, the second provides a driver letting libvirt manage QEMU via the daemon. Basic architecture ------------------ The reason for the daemon architecture is two fold: - At this time, there is no (practical) way to enumerate QEMU instances, or reliably connect to the monitor console of an existing process. There is also no way to determine the guest configuration associated with a daemon. - It is desirable to be able to manage QEMU instances using either an unprivilegd local client, or a remote client. The daemon can provide connectivity via UNIX domain sockets, or IPv4 / IPv6 and layer in suitable authentication / encryption via TLS and/or SASL protocols. Anthony Ligouri is working on patches for QEMU with the goal of addressing the first point. For example, an extra command line argument will cause QEMU to save a PID file and create a UNIX socket for its monitor at a well-defined path. More functionality in the monitor console will allow the guest configuration to be reverse engineered from a running guest. Even with those patches, however, it will still be desirable to have a daemon to provide more flexible connectivity, and to facilitate implementation libvirt APIs which are host (rather than guest) related. Thus I expect that over time we can simply enhance the daemon to take advantage of newer capabilities in the QEMU monitor, but keep the same basic libvirt driver architecture. Considering some of the other hypervisor technologies out there, in particular User Mode Linux, and lhype, it may well become possible to let this QEMU daemon also provide the management of these guests - allowing re-use of the single driver backend in the libvirt client library itself. XML format ---------- As discussed in the previous mail thread, the XML format for describing guests with the QEMU backend is the same structure as that for Xen guests, with following enhancements: - The 'type' attribute on the top level <domain> tag can take one of the values 'qemu', 'kqemu' or 'kvm' instead of 'xen'. This selects between the different virtualization approaches QEMU can provide. - The '<type>' attribute within the <os> block of the XML (for now) is still expected to the 'hvm' (indicating full virtualization), although I'm trying to think of a better name, since its not technically hardware accelerated unless you're using KVM - The '<type>' attribute within the <os> block of the XML can have two optional 'arch' and 'machine' attributes. The former selects the CPU architecture to be emulated; the latter the specific machine to have QEMU emulate (determine those supported by QEMU using 'qemu -M ?'). - The <kernel>, <initrd>, <cmdline> elements can be used to specify an explicit kernel to boot off[1], otherwise it'll do a boot of the cdrom, harddisk / floppy (based on <boot> element). Well,the kernel bits are parsed at least. I've not got around to using them when building the QEMU argv yet. - The disk devices are configured in same way as Xen HVM guests. eg you have to use hda -> hdd, and/or fda -> fdb. Only hdc can be selected as a cdrom device. - The network configuration is work in progress. QEMU has many ways to setup networking. I use the 'type' attribute to select between the different approachs 'user', 'tap', 'server', 'client', 'mcast' mapping them directly onto QEMU command line arguments. You can specify a MAC address as usual too. I need to implement auto-generation of MAC addresses if omitted. Most of them have extra bits of metadata though which I've not figured out appropriate XML for yet. Thus when building the QEMU argv I currently just hardcode 'user' networking. - The QEMU binary is determined automatically based on the requested CPU architecture, defaulting to i686 if non specified. It is possible to override the default binary using the <emulator> element within the <devices> section. This is different to previously discussed, because recent work by Anthony merging VMI + KVM to give paravirt guests means that the <loader> element is best kept to refer to the VMI ROM (or other ROM like files :-) - this is also closer to Xen semantics anyway. Connectivity ------------ The namespace under which all connection URIs come is 'qemud'. Thereafter there are several options. First, two well-known local hypervisor connections - qemud:///session This is a per-user private hypervisor connection. The libvirt daemon and qemu guest processes just run as whatever UNIX user your client app is running. This lets unprivileged users use the qemu driver without needing any kind admin rights. Obviously you can't use KQEMU or KVM accelerators unless the /dev/ device node is chmod/chown'd to give you access. The communication goes over a UNIX domain socket which is mode 0600 created in the abstract namespace at $HOME/.qemud.d/sock. - qemud:///system This is a system-wide privileged hypervisor connection. There is only one of these on any given machine. The libvirt_qemud daemon would be started ahead of time (by an init script), possibly running as root, or maybe under a dedicated system user account (and the KQEMU/KVM devices chown'd to match). The admin would optionally also make it listen on IPv4/6 addrs to allow remote communication. (see next URI example) The local communication goes over one of two possible UNIX domain sockets Both in the abstract namespace under the directory /var/run. The first socket called 'qemud' is mode 0600, so only privileged apps (ie root) can access it, and gives full control capabilities. The other called 'qemud-ro' is mode 0666 and any clients connecting to it will be restricted to only read-only libvirt operations by the server. - qemud://hostname:port/ This lets you connect to a daemon over IPv4 or IPv6. If omitted the port is 8123 (will probably change it). This lets you connect to a system daemon on a remote host - assuming it was configured to listen on IPv4/6 interfaces. Currently there is zero auth or encryption, but I'm planning to make it mandortory to use the TLS protocol - using the GNU TLS library. This will give encryption, and mutual authentication using either x509 certificates or PGP keys & trustdbs or perhaps both :-) Will probably start off by implementing PGP since I understand it better. So if you wanted to remotely manage a server, you'd copy the server's certificate/public key to the client into a well known location. Similarly you'd generate a keypair for the client & copy its public key to the server. Perhaps I'll allow clients without a key to connect in read-only mode. Need to prototype it first and then write up some ideas. Server architecture ------------------- The server is a fairly simple beast. It is single-threaded using non-blocking I/O and poll() for all operations. It will listen on multiple sockets for incoming connections. The protocol used for client-server comms is a very simple binary message format close to the existing libvirt_proxy. Client sends a message, server receives it, performs appropriate operation & sends a reply to the client. The client (ie libvirt driver) blocks after sending its message until it gets a reply. The server does non-blocking reads from the client buffering until it has a single complete message, then processes it and populates the buffer with a reply and does non-blocking writes to send it back to the client. It won't try to read a further message from the client until its sent the entire reply back. ie, it is a totally synchronous message flow - no batching/pipelining of messages. During the time the server is processes a message it is not dealing with any other I/O, but thus far all the operations are very fast to implement, so this isn't a serious issue, and there ways to deal with it if there are operations which turn out to take a long time. I certainly want to avoid multi-threading in the server at all costs! As well as monitoring the client & client sockets, the poll() event loop in the server also captures stdout & stderr from the QEMU processes. Currently we just dump this to stdout of the daemon, but I expect we can log it somewhere. When we start accessing the QEMU monitor there will be another fd in the event loop - ie the pseduo-TTY (or UNIX socket) on which we talk to the monitor. Inactive guests --------------- Guests created using 'virsh create' (or equiv API) are treated as 'transient' domains - ie their config files are not saved to disk. This is consistent with the behaviour in the Xen backend. Guests created using 'virsh define', however, are saved out to disk in $HOME/.qemud.d for the per-user session daemon. The system-wide daemon should use /etc/qemud.d, but currently its still /root/.qemud.d The config files are simply saved as the libvirt XML blob ensuring no data conversion issues. In any case, QEMU doesn't currently have any config file format we can leverage. The list of inactive guests is loaded at startup of the daemon. New config files are expected to be created via the API - files manually created in the directory after initial startup are not seen. Might like to change this later. XML Examples ------------ This is a guest using plain qemu, with x86_64 architecture and a ISA-only (ie no PCI) machine emulation. I was actually running this on a 32-bit host :-) VNC is configured to run on port 5906. QEMU can't automatically choose a VNC port, so if one isn't specified we assign one based on the domain ID. This should be fixed in QEMU.... <domain type='qemu'> <name>demo1</name> <uuid>4dea23b3-1d52-d8f3-2516-782e98a23fa0</uuid> <memory>131072</memory> <vcpu>1</vcpu> <os> <type arch='x86_64' machine='isapc'>hvm</type> </os> <devices> <disk type='file' device='disk'> <source file='/home/berrange/fedora/diskboot.img'/> <target dev='hda'/> </disk> <interface type='user'> <mac address='24:42:53:21:52:45'/> </interface> <graphics type='vnc' port='5906'/> </devices> </domain> A second example, this time using KVM acceleration. Note how I specify a non-default path to QEMU to pick up the KVM build of QEMU. Normally KVM binary will default to /usr/bin/qemu-kvm - this may change depending on how distro packaging of KVM turns out - it may even be merged into regular QEMU binaries. <domain type='kvm'> <name>demo2</name> <uuid>4dea24b3-1d52-d8f3-2516-782e98a23fa0</uuid> <memory>131072</memory> <vcpu>1</vcpu> <os> <type>hvm</type> </os> <devices> <emulator>/home/berrange/usr/kvm-devel/bin/qemu-system-x86_64</emulator> <disk type='file' device='disk'> <source file='/home/berrange/fedora/diskboot.img'/> <target dev='hda'/> </disk> <interface type='user'> <mac address='24:42:53:21:52:45'/> </interface> <graphics type='vnc' port='-1'/> </devices> </domain> Outstanding work ---------------- - TLS support. Need to add TLS encryption & authentication to both the client and server side for IPv4/6 communications. This will obviously add a dependancy on libgnutls.so in libvirt & the daemon. I don't consider this a major problem since every non-trivial network app these days uses TLS. The other possible impl of OpenSSL has GPL-compatability issues, so is not considered. - Change the wire format to use fixed size data types (ie, int8, int16, int32, etc) instead of the size-dependant int/long types. At same time define some rules for the byte ordering. Client must match server ordering ? Server must accept client's desired ordering ? Everyone must use BE regardless of server/client format ? I'm inclined to say client must match server, since it distributes the byte-swapping overhead to all clients and lets the common case of x86->x86 be a no-op. - Add a protocol version message as first option to let use protocol at will later while maintaining compat with older libvirt client libraries. - Improve support for describing the various QEMU network configurations - Finish boot options - boot device order & explicit kernel - Open & use connection to QEMU monitor which will let us implement pause/resume, suspend/restore drivers, and device hotplug / media changes. - Return sensible data for virNodeInfo - will need to have operating system dependant code here - parsing /proc for Linux to determine available RAM & CPU speed. Who knows what for Solaris / BSD ?!? Anyone know of remotely standard ways for doing this. Accurate host memory reporting is the only really critical data item we need. - There is a fair bit of duplicate in various helper functions between the daemon, and various libvirt driver backends. We should probably pull this stuff out into a separate lib/ directoy, build it into a static library and then link that into both libvirt, virsh & the qemud daemon as needed. 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 12

[Libvir] Get info with libvirt from a remote Xen dom0
by Jordi Prats 09 Jan '07

09 Jan '07

Hi, On the function: virConnectPtr virConnectOpenReadOnly (const char * name) name is unused. Is planned any use for it? I'm particullay interested on obtaining information from a remote machine. I'm trying to provide HA between dom0, so this way is a dom0 chashes another dom0 will create every vm from the othe node. Example: dom0.1 have vm01 and vm02 dom0.2 have vm03 and vm04 Then if dom0.1 goes down, dom0.2 will have vm01,vm02,vm03 and vm04 I'm pretending to use libvirt as a abstraction layer to operate this Xen cluster. Thanks, -- ...................................................................... __ / / Jordi Prats Català C E / S / C A Departament de Sistemes /_/ Centre de Supercomputació de Catalunya Gran Capità, 2-4 (Edifici Nexus) · 08034 Barcelona T. 93 205 6464 · F. 93 205 6979 · jprats(a)cesca.es ...................................................................... pgp:0x5D0D1321 ......................................................................

2 1

[Libvir] XML format for QEMU / KVM driver
by Daniel P. Berrange 03 Jan '07

03 Jan '07

Since KVM is the new "shiny thing" in the virtualization world for Linux I figure its time to resurrect & finish the prototype QEMU backend I started developing for libvirt. Thanks to the design of KVM, it ought to be possible to support KVM & QEMU in a single driver with near-zero extra effort to add the bits for KVM support. There's a couple of interesting decisions wrt additions in the XML format describing guests. 1. QEMU can be built with several different CPU accelerators, eg KQEMU, QVM86 or KVM. These are only available if the guest CPU matches the host CPU architecture though. 2. QEMU can emulate many different CPU types. x86, x86_64, mips, sparc, ppc, arm, etc 3. QEMU can emulate many different different 'machine' types, for each CPU type. eg for x86 cpus: $ qemu -M ? Supported machines are: pc Standard PC (default) isapc ISA-only PC Some of these options are activated by specifying a particular command line flag, eg -M for machine type. Others require you to use a different qemu binary, eg 'qemu-system-arm', 'qemu-system-ppc' instead of 'qemu'. QEMU is basically a fully-virt solution, so XML description for the <os> block would be superficically similar to Xen HVM support, in that it will typically try to boot the kernel found in the MBR of the first harddisk (unless you specify an alternate boot device). Unlike Xen HVM support, it can also have an explicit kernel, initrd & arguments specified via command line. The other difference is that Xen has a separater binary for the loader, vs device model - QEMU/KVM does it all in one binary. So, my initial thoughts are: 1. Use the <type> element within the <os> block to describe the CPU accelerator to use, accepting the values 'qemu', 'kvm', 'kqemu' or 'qvm86'. 2. For CPU architecture, there are a couple of choices a) Add an 'arch' attribute to the <type> element to select between x86, ppc, sparc, etc. b) Add an <arch> element within the <os> block to switch between architectures. c) Just use the <loader> element to point to the QEMU binary matching the desired architecture. d) Use the <emulator> element within the <devices> section to point to the QEMU binary matching the desired architecture. e) Option a) and also allow use of <loader> to override the default QEMU binary to use f) Option b) and also allow use of <loader> to override the default QEMU binary to use g) Option a) and also allow use of <emulator> within the <devices> block to override the default QEMU binary to use h) Option b) and also allow use of <emulator> within the <devices> block to override the default QEMU binary to use At this time, i'm leaning towards either option e). This would give examples like * Using PPC with regular non-accelerated QEMU <os> <type arch="ppc">qemu</type> </os> * Using non-accelerated QEMU, and guest architecture matching the host <os> <type>qemu</type> </os> * Using accelerated KVM <os> <type>kvm</type> </os> * Using accelerated KVM, but with an alernate binary <os> <type>kvm</type> <loader>/home/berrange/work/kvm-devel/qemu-kvm</loader> </os> 3. For machine type, again there are a couple of options: a) Add a 'machine' attribute to the <type> element b) Add a <machine> element within the <os> block For this I think we should just follow same scheme that we use to specify architecture. So I'd lean towards a) * Using PPC with a Mac-99 machine: <os> <type arch="ppc" machine="mac99">qemu</type> </os> * Using non-accelerated QEMU, and guest architecture matching the host, and a non-PCI machine: <os> <type machine="isapc">qemu</type> </os> All the other bits of XML like disk/network/console configuration are pretty straightforward, following very similar structure to Xen. So there isn't really much interesting stuff to discuss there. 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 6

[Libvir] Release of libvirt-0.1.10
by Daniel Veillard 20 Dec '06

20 Dec '06

A couple of bug fixes and significant improvements have accumulated since the last release one month ago, so it's time to push a new one. Available from ftp://libvirt.org/libvirt/ * more localizations * bug fixes: - VCPU info breakages on xen 3.0.3 - xenDaemonListDomains buffer overflow (Daniel Berrange) - reference count bug when creating Xen domains (Daniel Berrange). * improvements: - support graphic framebuffer for Xen paravirt (Daniel Berrange) - VNC listen IP range support (Daniel Berrange) - support for default Xen config files and inactive domains of 3.0.4 (Daniel Berrange). Thanks to Dan and everybody who helped by reporting bugs ! 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] Fix handling of config files with duplicate named guests
by Daniel P. Berrange 19 Dec '06

19 Dec '06

The code for managing config files in /etc/xen assumed that the filename of the config matched the name of the guest defined inside. One might thing this a reasonable assumption, but in the wild I've had reports from users whom have various config files for the same guest, but with different settings. This caused some really wierd behaviour in the current code base. virt-manager display would alternate displaying each config upon refresh! Now, our API requires that there is only one config per name, so we can't expose this to the UI. The attached patch, thus simply detects when we have more than one config with same named guest, and hides the duplicates. The way it does this is to change the way we cache configs. Previously we had a single hash table mapping relative filenames to virConfPtr objects, with the implicit assumption that relative filename == guest name. With the attached patch we now maintain two hash tables. The first maps fully qualified pathnames to virConfPtr objects, the second maps guest names to the first filename found for that name. Thus when querying details for a guest, we first resolve the guest name to its filename, and then lookup the virConfPtr object associated with this filename. This isn't perfect, but its a hell of alot better than current code, so I want to commit it as is and figure out more improvement later. There is no ABI issue here, so we can iterate over impl at will. 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 4

[Libvir] Still can't run a simple python test libvirt !
by Omer Khalid 19 Dec '06

19 Dec '06

Hi, I am still unable to run my simple libvirt test! I checked out the code from libvirt cvs and following the instructions till 'make install'. It all went well. So then I ran my simply python test, as shown here (http://www.libvirt.org/python.html) It keeps on giving me the following error. [root@lcgctb9 libvirt]# python testLibvirt.py Traceback (most recent call last): File "testLibvirt.py", line 1, in ? import virt ImportError: No module named virt I have verified that the library is linked by the following: [root@lcgctb9 libvirt]# pkg-config libvirt --libs -L/usr/local/lib -lvirt -lxenstore [root@lcgctb9 libvirt]# pkg-config --variable=prefix libvirt /usr/local I really appreciate your help! Regards Omer -- --------------------------------------------------------------- CERN – European Organization for Nuclear Research Information Technology Department CH-1211 Geneva 23 Phone: +41 (0) 22 767 7996 Fax: +41 (0) 22 767 4900 E-mail : Omer.Khalid(a)cern.ch Homepage: http://cern.ch/Omer.Khalid

2 4

[Libvir] [PATCH] Inactive domain management for Xen 3.0.4
by Daniel P. Berrange 13 Dec '06

13 Dec '06

So, my previous set of patches for inactive domain management deal with the problem for Xen 3.0.3 or earlier. In 3.0.4 we now have lifecycle management support, which means we no longer need to scan /etc/xen config files if running against a new XenD. We choose between Xend & scanning /etc/xen files based on the condition 'xendConfigVersion >= 3'. The attached patch adds 5 new entry points to xend_internal.c xenDaemonListDefinedDomains xenDaemonNumOfDefinedDomains xenDaemonDomainCreate xenDaemonDomainDefineXML xenDaemonDomainUndefine These let you enumerate inactive domains, define new ones, delete old ones. Secondly, the patch modifies a number of existing methods to work against inactive domains too. Previously they'd unconditionally pass if the domain id was < 0. Now, if xendConfigVersion is >= 3, then they will know that XenD supports inactive domains & thus work for inactive guests too. xenDaemonDomainGetMaxMemory xenDaemonDomainSetMaxMemory xenDaemonDomainSetMemory xenDaemonDomainGetInfo xenDaemonDomainSetVcpus xenDaemonDomainDumpXML The methods for setting mem,max memory & vcpu count all required further bug fixes to Xend which have been sent upstream & hopefully merged soon. Finally, the patch changes the xendConfigVersion to be lookedup just once when initially connecting to XenD. Since we need this version info very frequently now, it was causing too much unnneccessary overload calling it every time. internal.h | 1 xend_internal.c | 270 +++++++++++++++++++++++++++++++++++++++++++++----------- xend_internal.h | 8 + xm_internal.c | 9 - 4 files changed, 227 insertions(+), 61 deletions(-) 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] Libvirt Build problems
by Omer Khalid 13 Dec '06

13 Dec '06

Hi, I am trying to build libvirt on SL4 (kernal = 2.6.12.6-xen3_12.1_rhel4.1). I tried both snapshot tar ball and the cvs checked out version. With the tar ball, after running the ./configure script, make file is created. But make file fails and complains the following: libvirt.c:24:16: xs.h: No such file or directory In file included from libvirt.c:28: xen_internal.h:15:26: xen/dom0_ops.h: No such file or directory make[2]: *** [libvirt.lo] Error 1 make[2]: Leaving directory `/root/virtualization/libvirt2/libvirt-0.1.9/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/root/virtualization/libvirt2/libvirt-0.1.9' make: *** [all] Error 2 While with the cvs version, the script ./autogen.sh fails to create a make file. I am running Python 2.3.4 and gcc version 3.4.6 20060404 (Red Hat 3.4.6-3). Any help would be much appreciated. Best Regards Omer -- --------------------------------------------------------------- CERN – European Organization for Nuclear Research Information Technology Department CH-1211 Geneva 23 Phone: +41 (0) 22 767 7996 Fax: +41 (0) 22 767 4900 E-mail : Omer.Khalid(a)cern.ch

2 8

[Libvir] Update XML -> SEXPR conversion for new PVFB syntax
by Daniel P. Berrange 13 Dec '06

13 Dec '06

Previously I sent a patch to handle parsing of the new PVFB syntax. This patch provides the counterpart - generating the new syntax when creating paravirt guests. We only enable the new style syntax if using xendConfigVersion 3 or later (ie, 3.0.4), and only for PV guests. HVM and older PV guests still use old style syntax. In this I also added support for vnclisten & vncpasswd parameters mapped to the 'listen' and 'passwd' attributes on the XML <graphics> tag. 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] [PATCH] Support parsing of new SEXPR for PVFB
by Daniel P. Berrange 05 Dec '06

05 Dec '06

The paravirt framebuffer patches for Xen finally got merged into upstream xen-devel. In doing so, however, the syntax of the SEXPR for configuring them changed completely. The existing framebuffer suppoirt in libvirt thus only works with the 3.0.3 tree + PVFB patches. For 3.0.4 we need to work with the new scheme. Fortunately, in 3.0.4 the xend_config_version flag is bumped from 2 -> 3, so we have an easy value to hook off. The attached patch thus adds support for parsing an SEXPR looking like (device (vfb (vncunused 1) (vnclisten 127.0.0.1) (vncpasswd 123456) (type vnc) ) ) And generating the <graphics type='vnc' port='5903'/> XML tag to match. (A later patch will add support for the reverse direction) 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] Release of libvirt-0.1.9
by Daniel Veillard 29 Nov '06

29 Nov '06

A lot of improvement and bug fixes have accumulated in the last month, so it was clearly time for a new release: ftp://libvirt.org/libvirt/libvirt-0.1.9.tar.gz * python bindings: release interpeter lock when calling C (Daniel Berrange) * don't raise HTTP error when looking informations for a domain * some refactoring to use the driver for all entry points * better error reporting (Daniel Berrange) * fix OS reporting when running as non-root * provide XML parsing errors * extension of the test framework (Daniel Berrange) * fix the reconnect regression test * python bindings: Domain instances now link to the Connect to avoid garbage collection and disconnect * separate the notion of maximum memory and current use at the XML level * Fix a memory leak (Daniel Berrange) * add support for shareable drives * add support for non-bridge style networking configs for guests(Daniel Berrange) * python bindings: fix unsigned long marshalling (Daniel Berrange) * new config APIs virConfNew() and virConfSetValue() to build configs from scratch * hot plug device support based on Michel Ponceau patch * added support for inactive domains, new APIs, various associated cleanup (Daniel Berrange) * special device model for HVM guests (Daniel Berrange) * add API to dump core of domains (but requires a patched xend) * pygrub bootloader informations take over <os> informations * updated the localization strings thanks to everybody who helped for this new release, with bug reports or patches ! 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] vif-nat network setup
by Tomas Kouba 23 Nov '06

23 Nov '06

Hello, is it possible to setup a NAT-ed network with libvir? My dom0 is configured so that it does a router for domUs and it also does NAT for domUs. I can set this up manually but now I would like to install some other domUs automatically with virt-install. I see that it uses libvir to create new domain from the XML description so it should be easy to add some option that would configure the XML, but I cannot find if the XML supports NAT setup. If I try 'virsh dumpxml' when the domU runs I get this: Unimplemented block at xend_internal.c:1667 <domain type='xen' id='1'> <name>ce</name> <uuid>400be3cf7cedc1d388de8796a85daff1</uuid> <os> <type>linux</type> <kernel>/boot/vmlinuz-2.6.18-prep</kernel> <initrd>/boot/initrd-2.6.18-prep.img</initrd> <root>/dev/sda1</root> <cmdline>fastboot ro root=/dev/sda1</cmdline> </os> <memory>131072</memory> <vcpu>1</vcpu> <on_poweroff>destroy</on_poweroff> <on_reboot>restart</on_reboot> <on_crash>restart</on_crash> <devices>  <console tty='/dev/pts/2'/> </devices> </domain> Thanks for any answer. -- Tomas Kouba

3 3

[Libvir] virDomainDump() API (equivalent to xm dump) in libvirt?
by Lon Hohberger 22 Nov '06

22 Nov '06

There's already one for saving live domains: int virDomainSave(virDomainPtr domain, const char *to); Why not use a similar API for a function which does the equivalent of 'xm dump' ? int virDomainDump(virDomainPtr domain, const char *to, int flags); Create a kernel dump of the domain in the path contained in *to. This API must fail if the domain is not in a panicked/crashed state. If you set the lowest-bit in flags, however, you can override this behavior: if the lowest bit is set, the domain will first be crashed (similar to SysRq-C) - then a dump will be taken from that. Why? In the event that a cluster node needs to fence a Xen domain (or other management tools, to be sure), we could use the API to generate a core of the domain (if it panicked) to help debug the problem prior to restarting the domain. The 'crash-before-dump' bit is just something someone might want to use at some point; I don't think it is absolutely necessary - but it doesn't hurt anything either. -- Lon

4 12

Re: [Libvir] Patch to attach/detach virtual devices on a running domain
by michel.ponceau＠bull.net 21 Nov '06

21 Nov '06

There is a bug in GetNetworkID(): return(ret) with ret=list[i], after free(list). It leads to process abort on free(xref) in caller XMLDevID(). I corrected this by replacing: ret = list[i]; by: ret = malloc(16); if (ret != NULL) strcpy(ret, list[i]); Our tests were successful afterwards. Daniel Veillard <veillard(a)redhat.com> 20/11/2006 16:50 Veuillez répondre à veillard Pour : michel.ponceau(a)bull.net cc : libvir-list(a)redhat.com Objet : Re: [Libvir] Patch to attach/detach virtual devices on a running domain On Thu, Nov 16, 2006 at 12:19:13PM -0500, Daniel Veillard wrote: > On Tue, Nov 14, 2006 at 10:05:47AM -0500, Daniel Veillard wrote: > > 5/ virDomainXMLDevID does direct acces to xs_directory() and xs_read(), > > that's not proper it should not call xenStore directly that need to > > be cleaned up, define one high level function exported from > > xs_internal.[ch] and call that but no direct access should be done > > that leads to unmaintainable code. > > That still need to be isolated, I added a TODO in src/xml.c to this effect. Okay I have done it, as a new function xenStoreDomainGetNetworkID() from xs_internal.[ch] Could you check out the version from CVS and verify I didn't added any regression ? thanks, 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 1

[Libvir] Patch to attach/detach virtual devices on a running domain
by michel.ponceau＠bull.net 20 Nov '06

20 Nov '06

This patch adds to Libvirt-0.1.8 the two functions described in my preceding mail. It has been tested in our Bull environment. Michel Ponceau 02/10/2006 17:27 Pour : libvir-list(a)redhat.com cc : Objet : Proposal for virtual devices described in XML Proposal modified after comments from Daniel P. Berrange: /* Create a virtual device attachment to backend */ int virDomainAttachDevice(virDomainPtr domain, char *xml); /* Destroy a virtual device attachment to backend */ int virDomainDetachDevice(virDomainPtr domain, char *xml); /* @domain: pointer to domain object * @xml: pointer to XML description of one device * Returns 0 in case of success, -1 in case of failure. */ The XML is in same form as the part of domain description for a single device, either <disk.../disk> or <interface.../interface>. In Detach function, the device is identified by its target name for "disk", and its MAC address for "interface". When the MAC address has not been assigned by Libvirt user at device creation, it must be retrieved from Xen using virDomainGetXMLDesc function.

3 4

[Libvir] [PATCH 0/6] Inactive domain support
by Daniel P. Berrange 16 Nov '06

16 Nov '06

The following series of patches is an update of my previous patches for supporting inactive domains in libvirt. A rough highlight of changes since last time: - Can override /etc/xen by setting LIBVIRT_XM_CONFIG_DIR env variable for people who move it to non-standard location - Several memory corruption bugs in config file refresh were solved - Fixed booting with paravirt framebuffer + grub - Added support for new APIs to python binding - Removed logic for supressing 404 errors (already merged earlier) - More complete device handling support (now creates network devices) Previous posting was here: http://www.redhat.com/archives/libvir-list/2006-September/msg00003.html 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 23

[Libvir] Request and proposition about hardware capabilities in virNodeInfo
by Philippe Berthault 16 Nov '06

16 Nov '06

Hello, To administrate virtual machines by using livbvirt, we need to known if the underlying hardware platform supports hvm (Intel-VT or AMD-V) or not. Currently, this information is returned by the "xm info" command of Xen in the "xen_caps" line but there is no equivalent in libvirt. So we propose to add this information in libvirt API. There is three possibilities for doing that: 1) Add one or several fields in the virNodeInfo structure returned by the virNodeGetInfo() function. These fields would be either strings such as strings returned by "xm info" or either bit fields with one bit per hardware capability. 2) Add one or several specific functions returning a boolean value for each hardware capability we want to test. 3) Add a specific function which returns either a bit fields of all the hardware capabilities or a structure such as virNodeInfo but far more complete. The problem with the proposition #1 is that the size of the virNodeInfo structure is changed. This implies for all libvirt users to recompile their programs linked with libvirt to avoid a 'core dump' at the execution. This is the reason why propositions 2 and 3 exist. NB: On an IA32 system, we can check flags in /proc/cpuinfo but on an IA64 platform with Montecito processors, there is no information about hardware capabilities in /proc/cpuinfo and the only way to known if the hardware supports hvm is by using the 'xm info' command. What is your opinion about these propositions ? Regards.

3 3

Re: [Libvir] Patch to attach/detach virtual devices on a running domain
by michel.ponceau＠bull.net 15 Nov '06

15 Nov '06

I cannot see the bug in virParseXMLDevice. The 'error' label sequence is ended by 'goto cleanup', and 'cleanup' sequence calls xmlFreeDoc(xml). Is it not the way to free the xmlDocPtr object 'xml'? Maybe I should reverse the sequence order to be more clear, as follows: + goto cleanup; +error: + free(buf.content); + buf.content = NULL; +cleanup: + if (xml != NULL) + xmlFreeDoc(xml); + return buf.content; "Daniel P. Berrange" <berrange(a)redhat.com> 14/11/2006 19:36 Veuillez répondre à "Daniel P. Berrange" Pour : michel.ponceau(a)bull.net cc : libvir-list(a)redhat.com Objet : Re: [Libvir] Patch to attach/detach virtual devices on a running domain On Tue, Nov 14, 2006 at 03:34:05PM +0100, michel.ponceau(a)bull.net wrote: > This patch adds to Libvirt-0.1.8 the two functions described in my > preceding mail. It has been tested in our Bull environment. This looks good to me - only one small bug I see - in the virParseXMLDevice function there is a memory leak. If you take 'goto errror' path through the function, then the xmlDocPtr object will never be free'd. Thanks for taking the time to implement all this ! 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] [PATCH] Fixed integer wraparound in python binding
by Daniel P. Berrange 15 Nov '06

15 Nov '06

The attached patch fixes a problem with integrate wraparound in the python bindings. THe problem is thus: - the memory & max-memory fields in the virDomainInfo struct are of type 'unsigned long'. - The python bindings, however, then stick this into a python 'Int' which is signed. Now, on 64-bit this is not an issue. For DomU guests on 32-bit it is not an issue either, but for Dom0 XenD sets the max-memory field to be 2^32-1 whcih causes wraparound when converting to python int. This patch simply switches the python binding over to using a python Long which is 64 bits on all platforms. 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