[Libvir] Capabilities XML format
by Mark McLoughlin
Hey,
Just a few brief comments after using it:
- <os_type>xen<os_type> is equivalent to <os><type>linux</type></os>,
which is pretty confusing. Sounds to me like we should deprecate
the latter and move to "xen" everywhere for this.
- We have <host><arch>x86_64</arch></host> and
<guest><arch name="x86_64"/></guest>. I can see why we did that,
but it seems odd to me to have different syntaxes for <arch>
depending on its context.
- I'm not sure how interesting the stuff in <guest><arch> is ... how
were we envisaging these bits being used?
- It's a pain to have to parse XML to discover whether e.g. you can
run a 64 bit guest. I'd much prefer to see the kind of API I'm
using here:
http://www.gnome.org/~markmc/code/test-caps.py
e.g.
caps = cnx.getCapabilities()
supports_x86_64 = False
for guest in caps.guests:
if guest.arch == "x86_64":
supports_x86_64 = True
Cheers,
Mark.
17 years, 8 months
[Libvir] [RFC] Life-cycle Management of the domain
by Saori Fukuta
Hi all,
I've been thinking about a way to change the hardware allocation on the
Life-cycle. And I have some idea. Can I hear your comments about this?
1. Necessity of function
These are conceivable cases of changing hardware allocation.
CASE A: Dynamic change
change the allocation dynamically
-> change the hardware allocation for now,
and next time, start by the allocation before it changes.
(example of use)
At night, change the hardware allocation.
Next morning rebooting, return it.
CASE B: Static change
change the allocation statically
-> do not change the hardware allocation for now,
but set the allocation for starting next.
(example of use)
Next time, want to start by the value that set before.
CASE C: Permanent change
change the allocation permanently
-> change the hardware allocation,
and start next time with the same setting.
(example of use)
want to start by same value permanently.
The current situation of virsh command with Xen.
CASE A / CASE B / CASE C
virsh setmem x x o
virsh setmaxmem x x o
virsh setvcpus o x x
virsh vcpupin o x x
And I find that the value on Xenstore is used for starting the domain
next time.
2. Change of command
We need to add 3 options to the virsh command of changing allocation
for CASE A, B, and C. So I propose the following options.
option name
--dynamic ... dynamic change option (default) for CASE A
--static ... static change option for CASE B
--perm ... permanent change option for CASE C
If no option is specified, the Default option("--dynamic") will be chosen.
(example)
Example of changing the memory allocation 256MB to 512MB.
# virsh dominfo Domain-A | grep "Used memory"
Used memory: 256000 kB
CASE A: Dynamic change
# virsh setmem Domain-A 512000
or
# virsh setmem Domain-A 512000 --dynamic
# virsh dominfo Domain-A | grep "Used memory"
Used memory: 512000 kB
CASE B: Static change
# virsh setmem Domain-A 512000 --static
# virsh dominfo Domain-A | grep "Used memory"
Used memory: 256000 kB
CASE C: Permanent change
# virsh setmem Domain-A 512000 --perm
# virsh dominfo Domain-A | grep "Used memory"
Used memory: 512000 kB
3. Summary of the ways
Xen does not provide these cases. So I propose that we start the domain
by a file for libvirt.
3.1 When starting the domain first time,
copy a file from config.sxp(/etc/xen config file) to virt.sxp(libvirt).
(image)
+--- Xend ---+ +-- libvirt --+
+--------+ l config.sxp -------> virt.sxp l +--------+
lDomain-Al +------------+ copy +-------------+ lDomain-Al
lmem=256 l lmem=256 l
+--------+ ----------------------------------> +--------+
"virsh start Domain-A"
3.2 When starting the domain,
if they have virt.sxp(libvirt) define that file.
(image)
Step.1 value of the domain before start.
+--- Xend --------------------+
l +-Xenstore-+ +-config.sxp-+ l
before l l mem=256 l l mem=256 l l
+--------+ l +----------+ +------------+ l
lDomain-Al +-----------------------------+
lmem=256 l
+--------+ ---------------------------------> continue Step.2
Step.2 define the value of virt.sxp.
+--- Xend ---------------------+
l +-Xenstore-+ +-config.sxp-+ l
+----> mem=512 l -> mem=512 l l
define l l +----------+ +------------+ l
l +------------------------------+
l
+--- l --------+
l +- l --------+
before l l mem=512 l l
+--------+ l +-virt.sxp-+ l
lDomain-Al +--- libvirt --+
lmem=256 l
+--------+ ---------------------------------> continue Step.3
Step.3 start the domain and copy a file from config.sxp to virt.sxp.
+--- Xend ---------------------+
l +-Xenstore-+ +-config.sxp-+ l
l l mem=512 l l mem=512 l l
l +--- l ----+ +----- l ----+ l
+----- l ------------- l ------+
l l +--- libvirt --+
l l copy l +-virt.sxp-+ l
l +-------------> mem=256 l l
before l l +----------+ l
+--------+ l start +--------+ +--------------+
lDomain-Al +------------>lDomain-Al
lmem=256 l lmem=512 l
+--------+ -------------------> +--------+
"virsh start Domain-A"
3.3 When changing the allocation statically or permanently,
write the change into virt.sxp.
(When changing the allocation dynamically, do nothing)
CASE A: Dynamic change
(image)
+--- Xend --------------------+ ll next start
l +-Xenstore-+ +-config.sxp-+ l ll
l l mem=512 l l mem=512 l l ll
l +----------+ +------------+ l ll
+-----------------------------+ ll
+--- libvirt --+ ll
l +-virt.sxp-+ l ll
before l l mem=256 l l after ll
+--------+ l +----------+ l +--------+ ll +--------+
lDomain-Al +--------------+ lDomain-Al ll lDomain-Al
lmem=256 l lmem=512 l ll lmem=256 l
+--------+ -------------------------------> +--------+ ll +--------+
"virsh setmem Domain-A 512000" ll
(state transition matrix)
+-------------------------------------------------------------+
operational procedure Xend libvirt
Xenstore config.sxp virt.sxp
+-------------------------------------------------------------+
1.start the domain mem=X, mem=X --->mem=X(create file)
2.change the allocation mem=Y, mem=Y mem=X(no change)
mem X to Y dynamically
3.stop the domain mem=Y, mem=Y mem=X
4.start the domain <------- <-----------define value
mem=X, mem=X --->mem=X(create file)
5.delete the domain del del delete file
+-------------------------------------------------------------+
CASE B: Static change
(image)
+--- Xend --------------------+ ll next start
l +-Xenstore-+ +-config.sxp-+ l ll
l l mem=256 l l mem=256 l l ll
l +----------+ +------------+ l ll
+-----------------------------+ ll
+--- libvirt --+ ll
l +-virt.sxp-+ l ll
before l l mem=512 l l after ll
+--------+ l +----------+ l +--------+ ll +--------+
lDomain-Al +--------------+ lDomain-Al ll lDomain-Al
lmem=256 l lmem=256 l ll lmem=512 l
+--------+ -------------------------------> +--------+ ll +--------+
"virsh setmem Domain-A 512000 --static" ll
(state transition matrix)
+-------------------------------------------------------------+
operational procedure Xend libvirt
Xenstore config.sxp virt.sxp
+-------------------------------------------------------------+
1.start the domain mem=X, mem=X --->mem=X(create file)
2.change the allocation mem=X, mem=Y mem=Y(change to Y)
mem X to Y statically
3.stop the domain mem=X, mem=X mem=Y
4.start the domain <------- <-----------define value
mem=Y, mem=Y --->mem=Y(create file)
5.delete the domain del del delete file
+-------------------------------------------------------------+
CASE C: Permanent change
(image)
+--- Xend --------------------+ ll next start
l +-Xenstore-+ +-config.sxp-+ l ll
l l mem=512 l l mem=512 l l ll
l +----------+ +------------+ l ll
+-----------------------------+ ll
+--- libvirt --+ ll
l +-virt.sxp-+ l ll
before l l mem=512 l l after ll
+--------+ l +----------+ l +--------+ ll +--------+
lDomain-Al +--------------+ lDomain-Al ll lDomain-Al
lmem=256 l lmem=512 l ll lmem=512 l
+--------+ -------------------------------> +--------+ ll +--------+
"virsh setmem Domain-A 512000 --perm" ll
(state transition matrix)
+-------------------------------------------------------------+
operational procedure Xend libvirt
Xenstore config.sxp virt.sxp
+-------------------------------------------------------------+
1.start the domain mem=X, mem=X --->mem=X(create file)
2.change the allocation mem=Y, mem=Y mem=Y(change to Y)
mem X to Y permanently
3.stop the domain mem=Y, mem=Y mem=Y
4.start the domain <------- <-----------define value
mem=Y, mem=Y --->mem=Y(create file)
5.delete the domain del del delete file
+-------------------------------------------------------------+
Thanks,
Saori Fukuta
17 years, 8 months
[Libvir] Remote & the problem with qemu deadlock
by Richard W.M. Jones
As I wrote here:
https://www.redhat.com/archives/libvir-list/2007-April/msg00114.html
remote access to qemu:/// URLs currently deadlocks. A bit of
explanation follows as to why this happens in the current architecture
of the remote patch.
If you apply the remote patch right now, you'll get a modified
libvirt_qemud server which can handle both qemu and remote requests over
the same socket. (Basically both qemu_internal.c and remote_internal.c
connect to the same Unix domain socket, then depending on the "program
number" encoded within the RPC messages, they get dispatched accordingly
inside libvirt_qemud). The server is written to handle multiple
connections at once using non-blocking poll[1], but once the server has
assembled a whole incoming message, it then blocks while dealing with
that message.
The problem occurs in the qemu case when the remote server issues a call
into qemu_internal (now linked into the server), and qemu_internal then
tries to connect out to the qemu daemon. Unfortunately the qemu daemon
/is/ the remote server, which is blocked handling the current call.
Thus it is unable to accept the new connection (from itself) and
completely deadlocks.
One solution suggested was to have qemu_internal recognise when it is
linked into the server and make local calls back to its counterpart in
the server. However I think this is pretty ugly and unnecessarily
complicates qemu_internal which shouldn't care how it is linked.
My thoughts on the long term solution
-------------------------------------
I'd really like to see the qemu case not require a daemon. At the
moment (AFAICS) the qemu daemon serves two purposes: (a) it keeps track
of the monitor file descriptors of the existing qemu processes, and (b)
it handles the networking stuff, basically starting and stopping
dnsmasq[2]. (a) is easily handled, I think, by having qemu processes
put their monitor sockets into a well-known directory. This has the
other advantage that qemu processes can survive and continue after qemu
programs restart. For the (b) case, I don't think networking which is a
general service should be mixed up with qemu code.
I think (although probably I've missed some things) that this means that
qemu_internal could be implemented entirely as a local service,
requiring no daemon. (In the case where qemu_internal needs to control
a root-owned system-wide set of qemu processes then we'd still have to
have a daemon, but it can be the remote daemon, same way that Xen will
work).
My suggestion for a short term solution
---------------------------------------
Since doing the above is way more than I'm going to do just to get
remote working, my suggestion is that we have two daemons running, qemud
and remote. Both would be built from the exact same codebase: the mode
would be selected by having a 'libvirtd --remote' flag on the command
line (or however, but the important thing is that they'd keep the same
codebase).
This immediately fixes the deadlock problem[3] because qemu_internal
linked to the server is now talking to a different daemon.
Rich.
[1] As an aside, I don't particularly like this architecture. Linus has
handed down to us an efficient operating system which is already capable
of multiplexing different clients using a marvellous system called
"multitasking". Hand-coding polling code inside a single process is
really only necessary in very limited circumstances, such as highly
tuned uniprocessor machines with enormous loads, and we are not likely
to get into such a situation with libvirtd. If we ever did we'd need to
benchmark a range of possible solutions. Processes on the other hand
have real advantages, such as security through isolation and controlled
sharing, and easy scalability onto SMP machines.
[2] Although I don't really understand the networking stuff too well, so
perhaps it does other things.
[3] Except in the "remote-on-remote" case, but we should disallow this
explicitly because it seems like it would be nothing but trouble.
--
Emerging Technologies, Red Hat http://et.redhat.com/~rjones/
64 Baker Street, London, W1U 7DF Mobile: +44 7866 314 421
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. 3798903
Directors: Michael Cunningham (USA), Charlie Peters (USA) and David
Owens (Ireland)
17 years, 8 months
[Libvir] Community IRC chat room for virt management tools/APIs/protocols
by Daniel P. Berrange
At the Xen summit a number of us thought it would be a good idea to have
an IRC chat room for people interested in technical discussions relating to
hypervisor agnostic management tools / APIs / protocols. This includes
libvirt, virt-manager, VNC extensions for virtualization, and more. Thus
we decided to colonise the channel #virt on irc.oftc.net - feel free to come
and join us....
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 -=|
17 years, 8 months
[Libvir] ia64 support
by Aron Griffis
Hi Daniel,
Yesterday in your libvirt presentation at Xen
Summit, you listed sparc and ppc as architectures
with explicit support in libvirt. I looked
through the code to see how to add ia64 to that
list, but I'm not seeing much mention of sparc or
ppc except in the qemud backend. Is there
somewhere else I should be looking?
Thanks,
Aron
17 years, 8 months
[Libvir] Documentation for remote patch (for discussion only)
by Richard W.M. Jones
Attached, a patch which gives almost complete documentation for the
remote patch. Highlights:
* Remote URIs
* Transports
* Limitations
* Implementation
Rich.
--
Emerging Technologies, Red Hat http://et.redhat.com/~rjones/
64 Baker Street, London, W1U 7DF Mobile: +44 7866 314 421
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. 3798903
Directors: Michael Cunningham (USA), Charlie Peters (USA) and David
Owens (Ireland)
17 years, 8 months
[Libvir] [PATCH] Tidy up the error messages produced by test driver
by Richard W.M. Jones
This minor patch:
* Introduces a VIR_FROM_TEST class of errors and makes errors generated
by test come from that class.
* Provides a reasonable error message if the user forgets to supply a
path. Also stops the driver from trying to open ("/"). Example:
$ src/virsh -c test:/// capabilities
libvir: Test error : invalid argument in testOpen: supply a
path or use test:///default
lt-virsh: error: failed to connect to the hypervisor
* Arranges that Xen-unified appears last in the list of drivers, because
qemu and test have well-defined URI syntaxes so can be checked first.
'make check' passes all tests with this patch.
Rich.
--
Emerging Technologies, Red Hat http://et.redhat.com/~rjones/
64 Baker Street, London, W1U 7DF Mobile: +44 7866 314 421
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. 3798903
Directors: Michael Cunningham (USA), Charlie Peters (USA) and David
Owens (Ireland)
17 years, 8 months
[Libvir] Remote patch 2007-04-17 (for discussion only)
by Richard W.M. Jones
Attached is the latest remote patch which should apply against either
CVS or the just-released libvirt-0.2.2. It's only for discussion
because it's not quite complete yet.
This patch includes Dan's QEMUD/XDR patch. And it basically follows the
plan outlined in [1].
Problems:
* QEMUD deadlocks when you try to call qemu over remote (eg. try: virsh
-c qemu+unix:///system?socket=/path/to/libvirt/qemud-sock capabilities).
This is because qemud tries to connect back to itself, but it is in
the middle of handling the request, so it doesn't respond.
* Opening Xen over remote fails, because the Xen unified driver doesn't
understand URLs like xen:///. I'm not sure if it ever did, or if this
is a regresssion, but it certainly _ought_ to support this style of URLs.
* The server will quite happily answer a mixture of remote and qemud
requests even on the same connection (of course, libvirt would never
generate such a mix). I'm not sure if this is a problem.
To do:
* Only supports a small subset of calls (not difficult to do but I'm
trying to get the framework working first).
* Needs GnuTLS support on the server side (copy & paste of the code from
the old remote patch).
* Needs to support TCP sockets on the server side.
Rich.
[1] https://www.redhat.com/archives/libvir-list/2007-March/msg00333.html
--
Emerging Technologies, Red Hat http://et.redhat.com/~rjones/
64 Baker Street, London, W1U 7DF Mobile: +44 7866 314 421
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. 3798903
Directors: Michael Cunningham (USA), Charlie Peters (USA) and David
Owens (Ireland)
17 years, 8 months
[Libvir] Release of libvirt-0.2.2
by Daniel Veillard
Time for the monthly release !
A lot of bug fixes have accumulated, and support for the upcoming Xen-3.0.5
should hopefully be ready:
ftp://libvirt.org/libvirt/
Documentation:
- fix errors due to Amaya (with Simon Hernandez)
- virsh uses kB not bytes (Atsushi SAKAI)
- add command line help to qemud (Richard Jones)
- xenUnifiedRegister docs (Atsushi SAKAI)
- strings typos (Nikolay Sivov)
- ilocalization probalem raised by Thomas Canniot
Bug fixes:
- virsh memory values test (Masayuki Sunou)
- operations without libvirt_qemud (Atsushi SAKAI)
- fix spec file (Florian La Roche
- Jeremy Katz
- Michael Schwendt)
- direct hypervisor call (Atsushi SAKAI)
- buffer overflow on qemu networking command (Daniel Berrange)
- buffer overflow in quemud (Daniel Berrange)
- virsh vcpupin bug (Masayuki Sunou)
- host PAE detections and strcuctures size (Richard Jones)
- Xen PAE flag handling (Daniel Berrange)
- bridged config configuration (Daniel Berrange)
- erroneous XEN_V2_OP_SETMAXMEM value (Masayuki Sunou)
- memory free error (Mark McLoughlin)
- set VIR_CONNECT_RO on read-only connections (S.Sakamoto)
- avoid memory explosion bug (Daniel Berrange)
- integer overflow for qemu CPU time (Daniel Berrange)
- QEMU binary path check (Daniel Berrange)
Cleanups:
- remove some global variables (Jim Meyering)
- printf-style functions checks (Jim Meyering)
- better virsh error messages
- increase compiler checkings and security (Daniel Berrange)
- virBufferGrow usage and docs
- use calloc instead of malloc/memset
- replace all sprintf by snprintf
- avoid configure clobbering user's CTAGS (Jim Meyering)
- signal handler error cleanup (Richard Jones)
- iptables internal code claenup (Mark McLoughlin)
- unified Xen driver (Richard Jones)
- cleanup XPath libxml2 calls
- IPTables rules tightening (Daniel Berrange)
Improvements:
- more regression tests on XML (Daniel Berrange)
- Python bindings now generate exception in error cases (Richard Jones)
- Python bindings for vir*GetAutoStart (Daniel Berrange)
- handling of CD-Rom device without device name (Nobuhiro Itou)
- fix hypervisor call to work with Xen 3.0.5 (Daniel Berrange)
- DomainGetOSType for inactive domains (Daniel Berrange)
- multiple boot devices for HVM (Daniel Berrange)
thanks to everybody who helped, by raising problems or contributing
ideas and 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/
17 years, 8 months
[Libvir] [PATCH] About remote operation restrictions of a general user
by S.Sakamoto
Hi
When I use virt-connect in a general user,
and a general user can perform operation system such as "start".
So, here's the patch adds to can't use operation system in "connect" in a general user.
Signed-off-by: Shigeki Sakamoto <fj0588di(a)aa.jp.fujitsu.com>
Thanks,
Shigeki Sakamoto.
Index: src/virsh.c
===================================================================
RCS file: /data/cvs/libvirt/src/virsh.c,v
retrieving revision 1.71
diff -u -p -r1.71 virsh.c
--- src/virsh.c 2 Apr 2007 11:56:38 -0000 1.71
+++ src/virsh.c 4 Apr 2007 05:51:08 -0000
@@ -360,6 +360,8 @@ static int
cmdConnect(vshControl * ctl, vshCmd * cmd)
{
int ro = vshCommandOptBool(cmd, "readonly");
+ virDomainPtr dom;
+ char *ret;
if (ctl->conn) {
if (virConnectClose(ctl->conn) != 0) {
@@ -374,12 +376,25 @@ cmdConnect(vshControl * ctl, vshCmd * cm
free(ctl->name);
ctl->name = vshStrdup(ctl, vshCommandOptString(cmd, "name", NULL));
+ ctl->conn = virConnectOpenReadOnly(ctl->name);
+ ctl->readonly = 1;
+ if (!ro && ctl->uid != 0){
+ dom = virDomainLookupByID(ctl->conn, 0);
+ if (dom==NULL)
+ return FALSE;
+ ret = virDomainGetXMLDesc(dom, 0);
+ if (NULL != strstr(ret, "domain type='xen'"))
+ ro = 1;
+ free(ret);
+ }
if (!ro) {
+ if (virConnectClose(ctl->conn) != 0) {
+ vshError(ctl, FALSE,
+ _("Failed to disconnect from the hypervisor"));
+ return FALSE;
+ }
ctl->conn = virConnectOpen(ctl->name);
ctl->readonly = 0;
- } else {
- ctl->conn = virConnectOpenReadOnly(ctl->name);
- ctl->readonly = 1;
}
if (!ctl->conn)
@@ -3175,6 +3190,9 @@ _vshStrdup(vshControl * ctl, const char
static int
vshInit(vshControl * ctl)
{
+ virDomainPtr dom;
+ char *ret;
+
if (ctl->conn)
return FALSE;
@@ -3188,8 +3206,26 @@ vshInit(vshControl * ctl)
!strcasecmp(ctl->name, "xen")) && ctl->uid != 0)
ctl->readonly = 1;
- if (!ctl->readonly)
+ if (!ctl->readonly) {
ctl->conn = virConnectOpen(ctl->name);
+
+ if (ctl->uid != 0){
+ dom = virDomainLookupByID(ctl->conn, 0);
+ if (dom==NULL)
+ return FALSE;
+ ret = virDomainGetXMLDesc(dom, 0);
+ if (NULL != strstr(ret, "domain type='xen'")) {
+ if (virConnectClose(ctl->conn) != 0) {
+ vshError(ctl, FALSE,
+ _("Failed to disconnect from the hypervisor"));
+ return FALSE;
+ }
+ ctl->conn = virConnectOpenReadOnly(ctl->name);
+ ctl->readonly = 1;
+ }
+ free(ret);
+ }
+ }
else
ctl->conn = virConnectOpenReadOnly(ctl->name);
17 years, 8 months
