- Devel - libvirt List Archives

[Libvir] [PATCH] Cleanup - remove virDomainKernel structure
by Richard W.M. Jones 25 Jun '07

25 Jun '07

... unless anyone can remember what it was for. It still builds fine without it. 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] OCaml bindings for libvirt
by Richard W.M. Jones 25 Jun '07

25 Jun '07

Weekend project: http://et.redhat.com/~rjones/ocaml-libvirt/ 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 2

[Libvir] Useful additional functions for libvirt
by Richard W.M. Jones 25 Jun '07

25 Jun '07

[I haven't implemented any of these yet, but if people think they're a good idea, or at least not an actively bad idea, then I'll post a patch.] virDomainGetConnection virNetworkGetConnection Purpose: Given a virDomainPtr or virNetworkPtr, obtain the virConnectPtr. Reason: All the language bindings to libvirt need to keep the virConnectPtr separately alongside the virDomain/NetworkPtr, in the main so that they can query if an error has happened from inside some deep call. This is wasteful since the connection pointer is already included in the virDomain or virNetwork structure, so we should just provide a call to get it. virConnectGetHostname virConnectGetTransport virConnectGetURI Purpose: Get the remote hostname, remote transport (tls, ssh, etc.), and URI. Reason: In virt-manager it would be nice to display the remote hostname. However doing this at the moment requires parsing the connection URI, which is duplicated code and also significantly complicated. Instead, allow the remote driver to just give us this information, and in non-remote cases default to something sensible. The case for the other two calls is weaker, but it might still be useful to know something about the security of the actual transport selected, and also to not have to keep the URI around with the connection (we might also canonicalise the transport for the user). virConnectPing Purpose: "Ping" the hypervisor to see if its up. Reason: Since we now support remote connections, there is a much more signficant chance that we will lose contact with the hypervisor, for example if the host goes down. This will do some very minimal operation to cheaply test whether the hypervisor can be contacted. Of course we could do something like 'virConnectNumOfDomains', but it's not clear to me that this operation would always be cheap (eg. if we had to implement it through xend). 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 2

[Libvir] [PATCH] Allow maxnames to be 0 in List{, Defined}{Domains, Networks}
by Richard W.M. Jones 25 Jun '07

25 Jun '07

It seems a bit pathological to check if maxNames <= 0 and throw an error if it is 0. In particular if you don't have any defined domains or networks (both fairly common scenarios) then this causes an error when you just pass the result of NumOfNetworks straight into ListNetworks. Backend drivers & QEMU seem to have no problem with maxNames being zero, so let's allow it. 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] Fix virDomainGetMaxVcpus in remote case
by Richard W.M. Jones 25 Jun '07

25 Jun '07

There's a typo in the remote_internal.c driver which causes it to call the wrong back-end function for virDomainGetMaxVcpus. The simple fix is 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] Fix virDomainGetVcpus in the remote case
by Richard W.M. Jones 25 Jun '07

25 Jun '07

I wasn't copying enough data in the cpumaps parameter. This fixes that bug ... 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] can not use the monitor of Qemu-dm
by Saori Fukuta 25 Jun '07

25 Jun '07

Hi, I opened the new bugzilla: Summary: can not use the monitor of Qemu-dm URL: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=245284 And I attached the patch to fix this problem. Thanks, Saori Fukuta

4 5

[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