[Libvir] XM config <-> XML config
by Arik Raffael Funke
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
17 years, 1 month
[Libvir] PATCH: Support input devices in XML format
by Daniel P. Berrange
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 -=|
17 years, 1 month
[Libvir] Asynchronous notifications of domain start/stop
by Richard W.M. Jones
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
17 years, 1 month
[Libvir] virDomainConfigureDevice?
by Hugh Brock
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
17 years, 1 month
[Libvir] [PATCH] cleanup of virDeviceMode
by Daniel Veillard
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/
17 years, 1 month
[Libvir] [PATCH 0/2] virDomainMigrate (for discussion only!)
by Richard W.M. Jones
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
17 years, 1 month
[Libvir] Initial OpenVZ Support Patches
by Shuveb Hussain
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
17 years, 1 month
[Libvir] PATCH: Specify BIOS clock offset for HVM
by Daniel P. Berrange
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 -=|
17 years, 1 month
[Libvir] Regarding Libvirt & VirtManager
by Paulev
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
17 years, 1 month
