February 2007 - Devel - libvirt List Archives

[Libvir] Storage manager initial requirements and thoughts
by Hugh Brock 15 Jun '07

15 Jun '07

Hi all. At the Red Hat virtualization team meeting last week we spent some time talking about the problem of remote storage management, which is a requirement for at the very least creating remote guests. Remote storage management also delivers a lot of benefits for managing guest storage, provisioning, and a host of other issues. Note that we don't (I think) believe that storage management should be part of libvirt. However we might want to be able to grab storage information with libvirt when creating a guest, for example. Here's the tentative requirements we came up with, along with several questions that came up. We have two important use cases for remote storage management: --Create a new guest against an existing physical device --Create a new guest against a file on an existing physical device (SELinux context must match up on both) Requirements: 2 key requirements: enumerate devices, create files * Enumerate devices (unallocated disks) * storage pool * Unallocated space * Allocated volumes -- free -- in use * Read only / Read-write * Host availability * Volume -- Global unique name -- Local device name -- Usage -- Mounted locally -- Assigned to guest read only shared exclusive -- Inactive guest * Create a backing store for a guest * need to know what storage is available * Can be plain file * Can be a physical partition (local scsi/IDE, SAN) * Can be a logical volume * Can be network - iscsi/nbd Cases: Physical device --> create partitions Volume group --> create logical volumes Directory --> create files Todos: Investigate gparted, one of the partition management tools we already have (apis? remote accessibility?) (I believe Jim Meyering volunteered to take a look at this?) Identify what other scenarios we need to address. Please comment; I'm hoping we can get these into a more definite form sooner rather than later. -- 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

10 43

[Libvir] [PATCH] Add a default network
by Mark McLoughlin 09 Mar '07

09 Mar '07

Hey, So, we want to install a default network which guests can connect to. This can be seen as e.g. a replacement for xenbr0 as the default bridge for xen guests. A few things concern me about the patch, see below for my thinking. However, I'm happy to punt on all of these issues for now and go ahead with the patch. 1) Ordering - we want the default network to have a predictable bridge name, so instead of relying on it being the first network and ending up auto-allocated vnet0, we use virbr0. The alternative is to actually have an ordering scheme, e.g. #define LIBVIRT_AUTOSTART_PRIORITY_DISABLE -1 #define LIBVIRT_AUTOSTART_PRIORITY_FIRST 0 #define LIBVIRT_AUTOSTART_PRIORITY_LAST 99 #define LIBVIRT_AUTOSTART_PRIORITY_DEFAULT 50 int virNetworkSetAutostart(virDomainPtr domain, int priority); autostart/00-default.xml -> ../default.xml autostart/99-MyNetwork.xml -> ../MyNetwork.xml Maybe that's useful, but probably moreso for guests than networks. The "virbr0" solution is fine, IMHO. 2) IP address choice - I've randomly chosen 192.168.122.1/24 as the IP address for the network, and this could happen to clash with an existing network. Since we masquerade outgoing traffic, I think the only problem this would cause in practice would be where the host machine is already on a 192.168.122/24 subnet and it could find itself connecting to a guest rather than another machine on the physical subnet. It's a default configuration choice which admins can change, and I don't see it causing huge problems in practice, so I'm not overly concerned. If it did turn out to be a problem, I'd probably add something like: <ip type="auto" /> But I'm not anxious to go down that route right now. 3) UUID generation - there's no UUID specified, so the default network will have a different UUID across reboots. We could trivially save the UUID at first boot, but we'd really need to put it in /var then. IMHO, it's something we can fix later if it turns out to be important. Cheers, Mark.

3 8

[Libvir] [PATCH] export virConf* symbols (second version)
by Richard W.M. Jones 08 Mar '07

08 Mar '07

Second version of that patch. Rich. -- Emerging Technologies, Red Hat http://et.redhat.com/~rjones/ 64 Baker Street, London, W1U 7DF Mobile: +44 7866 314 421 "[Negative numbers] darken the very whole doctrines of the equations and make dark of the things which are in their nature excessively obvious and simple" (Francis Maseres FRS, mathematician, 1759)

3 3

[Libvir] Remote patch, 2007-02-28
by Richard W.M. Jones 08 Mar '07

08 Mar '07

http://www.annexia.org/tmp/libvirt-tls-20070228.patch Not an enormous amount of difference between this and the patch from two days ago. This patch correctly logs/audits new connections and fixes a whole collection of different bugs which used to happen when the server rejected a client connection. Rich. -- Emerging Technologies, Red Hat http://et.redhat.com/~rjones/ 64 Baker Street, London, W1U 7DF Mobile: +44 7866 314 421 "[Negative numbers] darken the very whole doctrines of the equations and make dark of the things which are in their nature excessively obvious and simple" (Francis Maseres FRS, mathematician, 1759)

6 22

[Libvir] Patch: Fix documentation and code of virGetDomain function
by Richard W.M. Jones 07 Mar '07

07 Mar '07

It turns out that you _can't_ pass name=NULL to virGetDomain, despite what the docs say. Rich. -- Emerging Technologies, Red Hat http://et.redhat.com/~rjones/ 64 Baker Street, London, W1U 7DF Mobile: +44 7866 314 421 "[Negative numbers] darken the very whole doctrines of the equations and make dark of the things which are in their nature excessively obvious and simple" (Francis Maseres FRS, mathematician, 1759)

5 6

[Libvir] [PATCH] patch for virsh domname <uuid> command error
by Tatsuro Enokura 02 Mar '07

02 Mar '07

Hi, Virsh domname <uuid> command for shut-off domain fails on xen-3.0.4. I think that xm_internal.c shoud be modified. But, it seems that xm_internal's structure isn't for xen-3.0.4, and shut-off domain's information is got from xend. I make a patch for xend_internal.c The attached patch resolve this issue in the following way: 1) If the domain's name can't be pulled out from the running domains list by uuid, request xend by "/xend/domains/<uuid>". 2) If the domain's data can be teken from xend, pull out the domain's name. Signed-off-by: Tatsuro Enokura <fj7716hz(a)aa.jp.fujitsu.com> Thanks, Tatsuro Enokura. Index: src/xend_internal.c (libvirt-0.2.0) =================================================================== --- xend_internal.c 2007-02-15 01:16:16.000000000 +0900 +++ xend_internal.c.new 2007-02-23 21:13:22.000000000 +0900 @@ -2759,6 +2759,8 @@ xenDaemonLookupByUUID(virConnectPtr conn char **tmp; unsigned char ident[VIR_UUID_BUFLEN]; int id = -1; + struct sexpr *root = NULL; + char *domname = NULL; names = xenDaemonListDomainsOld(conn); tmp = names; @@ -2779,6 +2781,26 @@ xenDaemonLookupByUUID(virConnectPtr conn } free(names); + if (name == NULL) { + char uuidstr[VIR_UUID_STRING_BUFLEN]; + memset(uuidstr, '\0', VIR_UUID_STRING_BUFLEN); + + snprintf(uuidstr, VIR_UUID_STRING_BUFLEN, + "%02x%02x%02x%02x-%02x%02x-%02x%02x-%02x%02x-%02x%02x%02x%02x%02x%02x", + uuid[0], uuid[1], uuid[2], uuid[3], + uuid[4], uuid[5], uuid[6], uuid[7], + uuid[8], uuid[9], uuid[10], uuid[11], + uuid[12], uuid[13], uuid[14], uuid[15]); + root = sexpr_get(conn, "/xend/domain/%s?detail=1", uuidstr); + if (root == NULL) + goto error; + domname = (char*)sexpr_node(root, "domain/name"); + if (domname == NULL) + goto error; + name = strdup(domname); + id = -1; + } + if (name == NULL) goto error; @@ -2793,6 +2815,8 @@ xenDaemonLookupByUUID(virConnectPtr conn return (ret); error: + if (root != NULL) + sexpr_free(root); if (name != NULL) free(name); return (NULL); ===================================================================

2 4

[Libvir] [PATCH]Report the error from xend for Domain-0
by Kazuki　Mizushima 02 Mar '07

02 Mar '07

Hi, When I test virsh subcommands, dump save, for Domain-0, It says following normal messages, but the processing is not done. #virsh dump 0 a Domain 0 dumpd to a #echo $? 0 #virsh save 0 a Domain 0 saved to a #echo $? 0 I made a patch which reports the error from xend like this. #virsh dump 0 a libvir: Xen Daemon error : POST operation failed: (xend.err 'Cannot save privileged domain 0') libvir: error : library call virDomainSave failed, possibly not supported error: Failed to save domain 0 to a # echo $? 1 #virsh dump 0 a libvir: Xen Daemon error : POST operation failed: (xend.err 'Cannot dump core for privileged domain 0') libvir: error : library call virDomainCoreDump failed, possibly not supported error: Failed to core dump domain 0 to a # echo $? 1 Signed-off-by: Kazuki Mizushima <mizushima.kazuk(a)jp.fujitsu.com> Thanks, Kazuki Mizushima Index: xend_internal.c (libvirt-0.2.0) ---------------------------------------------------------------------- --- ../../libvirt-0.2.0/src/xend_internal.c 2007-02-15 01:16:16.000000000 +0900 +++ xend_internal.c 2007-02-27 22:45:05.000000000 +0900 @@ -507,7 +507,10 @@ xend_post(virConnectPtr xend, const char if ((ret < 0) || (ret >= 300)) { virXendError(xend, VIR_ERR_POST_FAILED, content); - } else if ((ret = 202) && (strstr(content, "failed") != NULL)) { + } else if ((ret == 202) && (strstr(content, "failed") != NULL)) { + virXendError(xend, VIR_ERR_POST_FAILED, content); + ret = -1; + } else if ((ret == 202) && (strcasestr(content, "cannot") != NULL)) { virXendError(xend, VIR_ERR_POST_FAILED, content); ret = -1; } ----------------------------------------------------------------------

4 5

[Libvir] Patch: driver->open functions return declined or error status
by Richard W.M. Jones 01 Mar '07

01 Mar '07

I want to change the driver->open function so that as well as declining a name (returning -1 as now), it may also indicate that it accepts the name, but there is an error opening the name (-2). virConnectOpen fails in this second case, rather than going on and trying the next driver in sequence. Rich. -- Emerging Technologies, Red Hat http://et.redhat.com/~rjones/ 64 Baker Street, London, W1U 7DF Mobile: +44 7866 314 421 "[Negative numbers] darken the very whole doctrines of the equations and make dark of the things which are in their nature excessively obvious and simple" (Francis Maseres FRS, mathematician, 1759)

3 3

[Libvir] ABI compatibility question: static strings returned from some functions
by Richard W.M. Jones 01 Mar '07

01 Mar '07

We have some functions such as virConnectGetType which are defined to return statically allocated strings: /** * virConnectGetType: * @conn: pointer to the hypervisor connection * * Get the name of the Hypervisor software used. * * Returns NULL in case of error, a static zero terminated string otherwise. */ const char * virConnectGetType(virConnectPtr conn) [...] This is all well and good in the typical local case, but when working over a remote connection the string we return is allocated and requires freeing at some point. Unfortunately I don't see a good thing to do in this case except to change the semantics of virConnectGetType, which arguably breaks ABI compatibility. Suggestions from anyone? Rich. garbage.collection++ -- Emerging Technologies, Red Hat http://et.redhat.com/~rjones/ 64 Baker Street, London, W1U 7DF Mobile: +44 7866 314 421 "[Negative numbers] darken the very whole doctrines of the equations and make dark of the things which are in their nature excessively obvious and simple" (Francis Maseres FRS, mathematician, 1759)

3 3

[Libvir] Patch: Driver private data
by Richard W.M. Jones 01 Mar '07

01 Mar '07

This patch is more aspirational than currently useful. Only the remote patch would use driver->private, but I think others should be changed to do so too. Rich. -- Emerging Technologies, Red Hat http://et.redhat.com/~rjones/ 64 Baker Street, London, W1U 7DF Mobile: +44 7866 314 421 "[Negative numbers] darken the very whole doctrines of the equations and make dark of the things which are in their nature excessively obvious and simple" (Francis Maseres FRS, mathematician, 1759)

3 2