- Devel - libvirt List Archives

[Libvir] [PATCH] Xen driver doesn't support autostart, so remove it from xen_unified
by Richard W.M. Jones 22 Jun '07

22 Jun '07

Our implementation of the Xen driver doesn't support autostart[*]. However xen_unified.c has a loop for get/setAutostart which causes it to return an error without setting virterror first. This patch removes that loop. Rich. [*] Although Xen supports it, by putting files in /etc/xen/autostart/ (at least that was the "old Xen" way before the current insanity of getting rid of config files was invented). -- 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

3 2

[Libvir] Avoid leak upon failed realloc
by Jim Meyering 22 Jun '07

22 Jun '07

This matters only if/when this realloc call fails. And then, only in the small way that with this patch, there's a slightly better chance of recovering from the low-memory condition. 2007-06-22 Jim Meyering <jim(a)meyering.net> * qemud/driver.c (qemudMonitorCommand): Avoid leak upon failed realloc. Index: qemud/driver.c =================================================================== RCS file: /data/cvs/libvirt/qemud/driver.c,v retrieving revision 1.21 diff -u -p -r1.21 driver.c --- qemud/driver.c 15 Jun 2007 13:44:19 -0000 1.21 +++ qemud/driver.c 22 Jun 2007 09:43:59 -0000 @@ -75,6 +75,7 @@ int qemudMonitorCommand(struct qemud_ser for (;;) { char data[1024]; int got = read(vm->monitor, data, sizeof(data)); + char *b; if (got == 0) { if (buf) @@ -91,8 +92,11 @@ int qemudMonitorCommand(struct qemud_ser free(buf); return -1; } - if (!(buf = realloc(buf, size+got+1))) + if (!(b = realloc(buf, size+got+1))) { + free(buf); return -1; + } + buf = b; memmove(buf+size, data, got); buf[size+got] = '\0'; size += got;

3 3

[Libvir] [PATCH] Add support for scheduler functions in remote
by Richard W.M. Jones 22 Jun '07

22 Jun '07

This is a rather tedious patch, but I've tested it against the Xen driver and it works for getting and setting the various parameters and scheduler type. 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

2 3

[Libvir] [PATCH] Fix string handling in virDomain{Get, Set}SchedulerParameters
by Richard W.M. Jones 22 Jun '07

22 Jun '07

This small patch fixes some bugs in the handling of the field string in virDomainGetSchedulerParameters and makes a similar pre-emptive fix to virDomainSetSchedulerParameters. Also, please don't use !strcmp(a,b), because it confuses me. Better is to write strcmp(a,b) == 0 to mean "strings match" and strcmp(a,b) != 0 to mean "strings don't match". 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

4 10

[Libvir] [PATCH] Fix remote virDomainGetXMLDesc
by Richard W.M. Jones 21 Jun '07

21 Jun '07

I was wondering why dumpxml didn't work on remote connections. Turned out to be the same bug that Dan found last week: https://www.redhat.com/archives/libvir-list/2007-June/msg00186.html The attached patch includes that fix, plus it adds proper error handling into xend_internal.c:xenDaemonDomainDumpXML and related functions. 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

2 2

[Libvir] [PATCH] Fix remote virConnectGetMaxVcpus
by Richard W.M. Jones 21 Jun '07

21 Jun '07

I've been going over the interface to libvirt, trying out every call locally and remotely with all possible combinations of parameters that I can think of. Not surprisingly one or two problems have cropped up. So here's a short series of patches to fix the problems I've found. virConnectGetMaxVcpus has a second "type" parameter. In practice this isn't used and can be passed as NULL. However that fails in the remote case. The fix is simple enough -- attached. 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

2 1

[Libvir] [PATCH] Correct documentation for virConnectOpen*
by Richard W.M. Jones 20 Jun '07

20 Jun '07

Simple patch to fix the currently incorrect documentation for these two functions. 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

2 1

[Libvir] RFC: replace "no support for hypervisor" error
by Richard W.M. Jones 20 Jun '07

20 Jun '07

The "no support for hypervisor" error is both very common and pretty annoying because it gives you nowhere to go to find out what you did wrong. $ virsh -c xen://localhost/ libvir: Xen Daemon error : no support for hypervisor virsh: error: failed to connect to the hypervisor (The actual problem is that my URI is wrong, which is a separate bug in the Xen driver. But the error message gives me no particular indication of what is wrong or how to correct the situation). I think there are several possible solutions to this - discuss, or suggest your own. (1) Document the URI formats fully. -- This is a feature which has been requested a few times and I will do it anyway if Daniel Veillard will do the magic to set up a "http://libvirt.org/uri.html" page. (2) Add a method to query available drivers and URI syntax. -- Something along the lines of char *virQueryDrivers (void); Note that it doesn't need an open connection. -- The remote case would have to be handled specially because you want to find out what's available locally and what's available remotely, and in the remote case you do need some sort of a connection. (3) Split VIR_ERR_NO_SUPPORT into two categories. Currently this category mixes up cases where we fail to open a connection, and cases where there is no driver support for a particular operation (even with an open connection). In the first case, go through all the places which return this error and add proper diagnostic information to the error messages. -- Again, I am prepared to do this if people think it's a good idea. (4) Add diagnostics to higher layers such as virsh and virt-manager. -- I would be less happy with this because it ends up repeating code, and the diagnostics could get out of date w.r.t. what libvirt can do. 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

3 11

[Libvir] Re: URI documentation and xen:/// patch
by Richard W.M. Jones 19 Jun '07

19 Jun '07

Daniel Veillard wrote: > On Tue, Jun 19, 2007 at 05:15:40PM +0100, Richard W.M. Jones wrote: >> Daniel Veillard wrote: >> $ virsh -c ///var/lib/xend/xend-socket list >> libvir: error : no support for hypervisor >> virsh: error: failed to connect to the hypervisor > > Hum, I not sure I ever tried to get that working. Maybe > file:///var/lib/xend/xend-socket > would work better, though libxml2 URI parsing should be able to > parse ///var/lib/xend/xend-socket and make it more or less equivalent > to the file:/// one. I would strace both to check. Yeah, I tried all the obvious ones like that. I'll run it under gdb later & find out what's really going on. I was just pointing out that it didn't seem to work right now ... Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903

1 0

[Libvir] [PATCH] hypervisor version
by Mark Johnson 19 Jun '07

19 Jun '07

This is another patch which may not be popular? Xen's extra version does not fit in libvirt's release field (since it's part of an int). Instead of printing out the wrong value, just display major.minor in virsh. Mark

4 12