April 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] [RFC]OpenVZ XML def
by Shuveb Hussain 22 May '07

22 May '07

Hi, I am adding OpenVZ support to Libvirt and work is progressing well. I'm able to list VM instances and I'm slowly trying to cover the basic API functions one by one. That brings us to the creation of OpenVZ based VMs. Just wanted to discuss the basic XML definition format so that I can get comments and improve if need be: <domain type='openvz'> <name>openvzdemo</name> <uuid>55a2441d-e012-40fe-a4f7-78e176015d40</uuid> <vpsid>101</vpsid> <template>vps.basic</template> <onboot>true</onboot> <os template='slackware-10.2-i386-minimal'/> <network> <hostname>openvzhost</hostname> <ip address='192.168.1.101' netmask='255.255.255.0' defgw='192.168.1.1' /> <nameserver>192.168.1.1</nameserver> <nameserver>202.56.250.5</nameserver> </network> </domain> Does this look OK? Regards, -- Shuveb Hussain. EasyVZ - OpenVZ management GUI: http://easyvz.sourceforge.net I blog at http://binarykarma.org Spread the Karma.

4 15

[Libvir] [RFC] Life-cycle Management of the domain take2
by Saori Fukuta 22 May '07

22 May '07

Hi, I'm making a patch to provide a changing allocation dynamically and statically without keeping state at the library. And this is still uncompleted works, but I would like to hear your comments. Attached patch shows below: # virsh --help setmem NAME setmem - change memory allocation SYNOPSIS virsh setmem <domain> <kilobytes> [ --static | --dynamic ] DESCRIPTION Change the current memory allocation in the guest domain. OPTIONS <domain> domain name, id or uuid <kilobytes> number of kilobytes of memory --static static change --dynamic dynamic change First, I made upper interface. --- virsh.c ( attached file "add_option2virsh.patch ) - add 2 options as follows: --dynamic, --static - call new APIs: virDomainSetMaxMemory -> virDomainSetMaxMemoryScope virDomainSetMemory -> virDomainSetMemoryScope virDomainSetVcpus -> virDomainSetVcpusScope --- libvirt.c ( attached file "add_option2libvirt.patch ) - add 3 APIs: virDomainSetMaxMemoryScope virDomainSetMemoryScope virDomainSetVcpusScope and I will add lower driver as follows in the case of setmem. --- drivers ( attached file "add_option2driver.patch ) - xen_unified.c : add xenUnifiedDomainSetMemoryScope - xend_internal.c : add xenDaemonDomainSetMemoryScope - other : set NULL to domainSetMemoryScope I plan to achieve allocation dynamically and statically by such a way at xenDaemonDomainSetMemoryScope. 1. get configuration from the Xen Daemon using sexpr_get. 2. change the value when static option is specified, change the node of configuration using new API that I will make. when dynamic option is specified, change the allocation using xend_op 3. set configuration to the Xen Daemon using xend_op Why I did not use virDomainGetXMLDesc and virDomainDefineXML was some elements ware lost in current XML. For example, there is no "vncpasswd", "cpus", "localtime" in XML configuration with virDomainGetXMLDesc. So when I set the "vncpasswd" the "vncpasswd" will disappear after I define the XML configuration. How does this sound ? Thanks, Saori Fukuta.

4 18

[Libvir] [PATCH] Fix the value of XEN_V2_OP_GETDOMAININFOLIST
by Saori Fukuta 08 May '07

08 May '07

Hi, The value of "Max memory" shown by using "virsh dominfo" is different from xm command. # virsh dominfo HVM_RH5_sda6 | grep mem Max memory: 300000 kB Used memory: 264064 kB # xm li -l HVM_RH5_sda6 | grep mem (maxmem 450) (memory 292) (shadow_memory 5) So, I changed the definition as follows, (before) #define XEN_V2_OP_GETDOMAININFOLIST 6 (changed) #define XEN_V2_OP_GETDOMAININFOLIST 5 and I could get the value that I want. # ./virsh dominfo HVM_RH5_sda6 | grep mem Max memory: 460800 kB Used memory: 299008 kB # xm li -l HVM_RH5_sda6 | grep mem (maxmem 450) (memory 292) (shadow_memory 5) I think that is not mistake because the XEN_V2_OP_GETDOMAININFOLIST is a system operation, so the definition is not exactly wrong. /usr/include/xen/sysctl.h:#define XEN_SYSCTL_getdomaininfolist 6 Do you know any reason for this? Signed-off-by: Saori Fukuta <fukuta.saori(a)jp.fujitsu.com> Thanks, Saori Fukuta. Index: xen_internal.c =================================================================== RCS file: /data/cvs/libvirt/src/xen_internal.c,v retrieving revision 1.71 diff -u -p -r1.71 xen_internal.c --- xen_internal.c 13 Apr 2007 00:43:57 -0000 1.71 +++ xen_internal.c 26 Apr 2007 11:41:03 -0000 @@ -117,7 +117,7 @@ static regex_t xen_cap_rec; #define XEN_V0_OP_GETDOMAININFOLIST 38 #define XEN_V1_OP_GETDOMAININFOLIST 38 -#define XEN_V2_OP_GETDOMAININFOLIST 6 +#define XEN_V2_OP_GETDOMAININFOLIST 5 struct xen_v0_getdomaininfo { domid_t domain; /* the domain number */

3 7

[Libvir] RFC: Behaviour of virConnectSave, Restore and CoreDump in the remote case
by Richard W.M. Jones 02 May '07

02 May '07

virDomainSave (for example) is currently defined like this: /** * virDomainSave: * @domain: a domain object * @to: path for the output file * * This method will suspend a domain and save its memory contents to * a file on disk. After the call, if successful, the domain is not * listed as running anymore (this may be a problem). * Use virDomainRestore() to restore a domain after saving. * * Returns 0 in case of success and -1 in case of failure. */ In the remote case there are, I think, three possible things that this call could do: (A) Copy the image over the network connection to save it locally This is possibly the most "authentic" option. Callers using remote can specify a local path and the image file will appear at that path, locally, making the remote case reasonably transparent. However image files are usually pretty large, and copying them over a network connection could be slow. In particular the network connection may be over loopback -- eg. in the case where we are allowing ordinary users to connect to a locally running libvirtd with elevated priviledges. (It's quite hard in general to determine if remote is really connected to a different machine, eg. think about the case where we are using ssh tunnels). In some ways this is the most secure option. The image or core dump is written by the user process, so there is no way to get a daemon with elevated privs to write over a file in /etc for example. (B) Save it remotely Remote isn't transparent. We save it remotely. We could consider adding a virDomainSaveLocal API call for the case when we really want to save it locally. (C) Do nothing / present an error Recognise that remote cannot deal with this at the moment, and don't implement this call. Perhaps come back to it later in the context of remote storage management. Opinions? 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)

2 2

[Libvir] [PATCH] increase storage domains of a definition file
by S.Sakamoto 02 May '07

02 May '07

Hi, When I install by virt-intall with long command (e.g."# /usr/sbin/virt-install --name testvm --ram 350 --vcpus 2 --file /root/test.img --file-size 1 --file /root/tmp02.img -- file-size 1 --file /root/tmp03.img --file-size 1 --file /root/tmp04.img --file-size 1 --file /root/tmp05.img --file-size 1 --file /root/tmp06.img --file-size 1 --file /root/tmp07.img --file-size 1 --file /root/tmp08.img --file-size 1 --file /root/tmp09.img --file-size 1 --file /root/tmp10.img --file-size 1 --file /root/tmp11.img --file-size 1 --file /root/tmp12.img --file-size 1 --file /root/tmp13.img --file-size 1 --file /root/tmp14.img --file-size 1 --file /root/tmp15.img --file-size 1 --file /root/tmp16.img --file-size 1 --vnc --paravirt --location ftp://xx.xx.xx.xx/rhel5ga_x86 --noautoconsole -- debug"), put out "abort". Because a definition file is long, it overflows from buffer. So, this patch increase buffer size. Signed-off-by: Shigeki Sakamoto <fj0588di(a)aa.jp.fujitsu.com> Thanks, Shigeki Sakamoto. Index: src/internal.h =================================================================== RCS file: /data/cvs/libvirt/src/internal.h,v retrieving revision 1.37 diff -u -p -r1.37 internal.h --- src/internal.h 4 Apr 2007 14:19:49 -0000 1.37 +++ src/internal.h 19 Apr 2007 11:01:12 -0000 @@ -106,6 +106,11 @@ extern "C" { #define VIR_CONNECT_RO 1 /** + * buffer size for definition file + */ +#define VIR_XML_STRING_BUFLEN (1024 + PATH_MAX * 16 + FILENAME_MAX * 16) + +/** * _virConnect: * * Internal structure associated to a connection Index: src/xend_internal.c =================================================================== RCS file: /data/cvs/libvirt/src/xend_internal.c,v retrieving revision 1.109 diff -u -p -r1.109 xend_internal.c --- src/xend_internal.c 13 Apr 2007 14:08:38 -0000 1.109 +++ src/xend_internal.c 19 Apr 2007 11:01:16 -0000 @@ -587,7 +587,7 @@ static int xend_op_ext2(virConnectPtr xend, const char *path, char *error, size_t n_error, const char *key, va_list ap) { - char ops[1024]; + char ops[VIR_XML_STRING_BUFLEN]; const char *k = key, *v; int offset = 0; Index: src/xml.c =================================================================== RCS file: /data/cvs/libvirt/src/xml.c,v retrieving revision 1.72 diff -u -p -r1.72 xml.c --- src/xml.c 13 Apr 2007 00:43:57 -0000 1.72 +++ src/xml.c 19 Apr 2007 11:01:20 -0000 @@ -1165,7 +1165,7 @@ virDomainParseXMLDesc(virConnectPtr conn { xmlDocPtr xml = NULL; xmlNodePtr node; - char *ret = NULL, *nam = NULL; + char *nam = NULL; virBuffer buf; xmlChar *prop; xmlParserCtxtPtr pctxt; @@ -1182,10 +1182,9 @@ virDomainParseXMLDesc(virConnectPtr conn if (name != NULL) *name = NULL; - ret = malloc(1000); - if (ret == NULL) + buf.content = malloc(1000); + if (buf.content == NULL) return (NULL); - buf.content = ret; buf.size = 1000; buf.use = 0; @@ -1376,7 +1375,7 @@ virDomainParseXMLDesc(virConnectPtr conn else free(nam); - return (ret); + return (buf.content); error: if (nam != NULL) @@ -1389,8 +1388,8 @@ virDomainParseXMLDesc(virConnectPtr conn xmlFreeDoc(xml); if (pctxt != NULL) xmlFreeParserCtxt(pctxt); - if (ret != NULL) - free(ret); + if (buf.content != NULL) + free(buf.content); return (NULL); }

5 9

[Libvir] Proposed remote protocol (XDR source file qemud/remote_protocol.x)
by Richard W.M. Jones 01 May '07

01 May '07

Attached are the args (*_args) and return structures (*_ret) for all the calls covered by the remote protocol, that is to say everything except Save, Restore and CoreDump (see previous email). The only problem area are the upper limits imposed on the lengths of various strings and arrays. The upper limits seem to be required for safely decoding messages from untrusted sources. Some of them however would impose limits on such things as the number of CPUs supported, and perhaps those limits are too low (or too high)? I don't really have any experience of the sort of huge machines that people might be running libvirt on. 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) /* -*- c -*- * remote_protocol.x: private protocol for communicating between * remote_internal driver and libvirtd. This protocol is * internal and may change at any time. * * Copyright (C) 2006-2007 Red Hat, Inc. * * This library is free software; you can redistribute it and/or * modify it under the terms of the GNU Lesser General Public * License as published by the Free Software Foundation; either * version 2.1 of the License, or (at your option) any later version. * * This library is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU * Lesser General Public License for more details. * * You should have received a copy of the GNU Lesser General Public * License along with this library; if not, write to the Free Software * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA * * Author: Richard Jones <rjones(a)redhat.com> */ /* Notes: * * (1) The protocol is internal and may change at any time, without * notice. Do not use it. Instead link to libvirt and use the remote * driver. * * (2) See bottom of this file for a description of the home-brew RPC. * * (3) Authentication/encryption is done outside this protocol. * * (4) For namespace reasons, all exported names begin 'remote_' or * 'REMOTE_'. This makes names quite long. */ %#include "libvirt/libvirt.h" /*----- Data types. -----*/ /* Maximum total message size (serialised). */ const REMOTE_MESSAGE_MAX = 262144; /* Length of long, but not unbounded, strings. * This is an arbitrary limit designed to stop the decoder from trying * to allocate unbounded amounts of memory when fed with a bad message. */ const REMOTE_STRING_MAX = 65536; /* A long string, which may NOT be NULL. */ typedef string remote_nonnull_string<REMOTE_STRING_MAX>; /* A long string, which may be NULL. */ typedef remote_nonnull_string *remote_string; /* This just places an upper limit on the length of lists of * domain IDs which may be sent via the protocol. */ const REMOTE_DOMAIN_ID_LIST_MAX = 4096; /* Upper limit on lists of domain names. */ const REMOTE_DOMAIN_NAME_LIST_MAX = 256; /* Upper limit on cpumap (bytes) passed to virDomainPinVcpu. */ const REMOTE_CPUMAP_MAX = 256; /* Upper limit on number of info fields returned by virDomainGetVcpus. */ const REMOTE_VCPUINFO_MAX = 2048; /* Upper limit on cpumaps (bytes) passed to virDomainGetVcpus. */ const REMOTE_CPUMAPS_MAX = 16384; /* Upper limit on lists of network names. */ const REMOTE_NETWORK_NAME_LIST_MAX = 256; /* Domains and networks are represented on the wire by (name, UUID). */ typedef opaque remote_uuid[VIR_UUID_BUFLEN]; struct remote_name { remote_nonnull_string name; remote_uuid uuid; }; /* A domain or network which may not be NULL. */ typedef struct remote_name remote_nonnull_domain; typedef struct remote_name remote_nonnull_network; /* A domain or network which may be NULL. */ typedef remote_nonnull_domain *remote_domain; typedef remote_nonnull_network *remote_network; /* Error message. See <virterror.h> for explanation of fields. */ /* NB. Fields "code", "domain" and "level" are really enums. The * numeric value should remain compatible between libvirt and * libvirtd. This means, no changing or reordering the enums as * defined in <virterror.h> (but we don't do that anyway, for separate * ABI reasons). */ struct remote_error { int code; int domain; remote_string message; int level; remote_domain dom; remote_string str1; remote_string str2; remote_string str3; int int1; int int2; remote_network net; }; /* Wire encoding of virVcpuInfo. */ struct remote_vcpu_info { unsigned int number; int state; unsigned hyper cpu_time; int cpu; }; /*----- Calls. -----*/ /* For each call we may have a 'remote_CALL_args' and 'remote_CALL_ret' * type. These are omitted when they are NULL. The virConnectPtr * is not passed at all (it is inferred on the remote server from the * connection). Errors are returned implicitly in the RPC protocol. */ struct remote_open_args { /* NB. "name" might be NULL although in practice you can't * yet do that using the remote_internal driver. */ remote_string name; int flags; }; struct remote_get_type_ret { remote_nonnull_string type; }; struct remote_get_version_ret { hyper hv_ver; }; struct remote_get_max_vcpus_args { /* The only backend which supports this call is Xen HV, and * there the type is ignored so it could be NULL. */ remote_string type; }; struct remote_get_max_vcpus_ret { int max_vcpus; }; struct remote_node_get_info_ret { string model<32>; hyper memory; int cpus; int mhz; int nodes; int sockets; int cores; int threads; }; struct remote_get_capabilities_ret { remote_nonnull_string capabilities; }; struct remote_list_domains_args { int maxids; }; struct remote_list_domains_ret { int ids<REMOTE_DOMAIN_ID_LIST_MAX>; }; struct remote_num_of_domains_ret { int num; }; struct remote_domain_create_linux_args { remote_nonnull_string xml_desc; int flags; }; struct remote_domain_create_linux_ret { remote_nonnull_domain dom; }; struct remote_domain_lookup_by_id_args { int id; }; struct remote_domain_lookup_by_id_ret { /* XXX "Not found" semantic is ill-defined. */ remote_nonnull_domain dom; }; struct remote_domain_lookup_by_uuid_args { remote_uuid uuid; }; struct remote_domain_lookup_by_uuid_ret { /* XXX "Not found" semantic is ill-defined. */ remote_nonnull_domain dom; }; struct remote_domain_lookup_by_name_args { remote_nonnull_string name; }; struct remote_domain_lookup_by_name_ret { /* XXX "Not found" semantic is ill-defined. */ remote_nonnull_domain dom; }; struct remote_domain_suspend_args { remote_nonnull_domain dom; }; struct remote_domain_resume_args { remote_nonnull_domain dom; }; struct remote_domain_shutdown_args { remote_nonnull_domain dom; }; struct remote_domain_reboot_args { remote_nonnull_domain dom; int flags; }; struct remote_domain_destroy_args { remote_nonnull_domain dom; }; struct remote_domain_get_os_type_args { remote_nonnull_domain dom; }; struct remote_domain_get_os_type_ret { remote_nonnull_string type; }; struct remote_domain_get_max_memory_args { remote_nonnull_domain dom; }; struct remote_domain_get_max_memory_ret { unsigned hyper memory; }; struct remote_domain_set_max_memory_args { remote_nonnull_domain dom; unsigned hyper memory; }; struct remote_domain_set_memory_args { remote_nonnull_domain dom; unsigned hyper memory; }; struct remote_domain_get_info_args { remote_nonnull_domain dom; }; struct remote_domain_get_info_ret { unsigned char state; unsigned hyper max_mem; unsigned hyper memory; unsigned short nr_virt_cpu; /* XXX cpu_time is declared as unsigned long long */ unsigned hyper cpu_time; }; /* XXX Save, Restore, CoreDump not yet implemented because we * don't know where we will write the images. */ struct remote_domain_dump_xml_args { remote_nonnull_domain dom; int flags; }; struct remote_domain_dump_xml_ret { remote_nonnull_string xml; }; struct remote_domain_list_defined_domains_args { int maxnames; }; struct remote_domain_list_defined_domains_ret { remote_nonnull_string names<REMOTE_DOMAIN_NAME_LIST_MAX>; }; struct remote_domain_num_of_defined_domains_ret { int num; }; struct remote_domain_create_args { remote_nonnull_domain dom; }; struct remote_domain_define_xml_args { remote_nonnull_string xml; }; struct remote_domain_define_xml_ret { remote_nonnull_domain dom; }; struct remote_domain_undefine_args { remote_nonnull_domain dom; }; struct remote_domain_set_vcpus_args { int nvcpus; }; struct remote_domain_pin_vcpu_args { int vcpu; opaque cpumap<REMOTE_CPUMAP_MAX>; }; struct remote_domain_get_vcpus_args { remote_nonnull_domain dom; int maxinfo; int maplen; }; struct remote_domain_get_vcpus_ret { remote_vcpu_info info<REMOTE_VCPUINFO_MAX>; opaque cpumaps<REMOTE_CPUMAPS_MAX>; }; struct remote_domain_get_max_vcpus_args { remote_nonnull_domain dom; }; struct remote_domain_get_max_vcpus_ret { int num; }; struct remote_domain_attach_device_args { remote_nonnull_domain dom; remote_nonnull_string xml; }; struct remote_domain_detach_device_args { remote_nonnull_domain dom; remote_nonnull_string xml; }; struct remote_domain_get_autostart_args { remote_nonnull_domain dom; }; struct remote_domain_get_autostart_ret { int autostart; }; struct remote_domain_set_autostart_args { remote_nonnull_domain dom; int autostart; }; /* Network calls: */ struct remote_num_of_networks_ret { int num; }; struct remote_list_networks_args { int maxnames; }; struct remote_list_networks_ret { remote_nonnull_string names<REMOTE_NETWORK_NAME_LIST_MAX>; }; struct remote_num_of_defined_networks_ret { int num; }; struct remote_list_defined_networks_args { int maxnames; }; struct remote_list_defined_networks_ret { remote_nonnull_string names<REMOTE_NETWORK_NAME_LIST_MAX>; }; struct remote_network_lookup_by_uuid_args { remote_uuid uuid; }; struct remote_network_lookup_by_uuid_ret { /* XXX "Not found" semantic is ill-defined. */ remote_nonnull_network net; }; struct remote_network_lookup_by_name_args { remote_nonnull_string name; }; struct remote_network_lookup_by_name_ret { /* XXX "Not found" semantic is ill-defined. */ remote_nonnull_network net; }; struct remote_network_create_xml_args { remote_nonnull_string xml; }; struct remote_network_create_xml_ret { remote_nonnull_network net; }; struct remote_network_define_xml_args { remote_nonnull_string xml; }; struct remote_network_define_xml_ret { remote_nonnull_network net; }; struct remote_network_undefine_args { remote_nonnull_network net; }; struct remote_network_create_args { remote_nonnull_network net; }; struct remote_network_destroy_args { remote_nonnull_network net; }; struct remote_network_dump_xml_args { remote_nonnull_network net; int flags; }; struct remote_network_dump_xml_ret { remote_nonnull_string xml; }; struct remote_network_get_bridge_name_args { remote_nonnull_network net; }; struct remote_network_get_bridge_name_ret { remote_nonnull_string name; }; struct remote_network_get_autostart_args { remote_nonnull_network net; }; struct remote_network_get_autostart_ret { int autostart; }; struct remote_network_set_autostart_args { remote_nonnull_network net; int autostart; }; /*----- Protocol. -----*/ /* Define the program number, protocol version and procedure numbers here. */ const REMOTE_PROGRAM = 0x20008086; const REMOTE_PROTOCOL_VERSION = 1; enum remote_procedure { REMOTE_PROC_OPEN = 1, REMOTE_PROC_CLOSE = 2, REMOTE_PROC_GET_CAPABILITIES = 3 }; /* Custom RPC structure. */ /* Each message consists of: * int length Number of bytes in message _including_ length. * remote_message_header Header. * then either: args Arguments (for REMOTE_CALL). * or: ret Return (for REMOTE_REPLY, status = REMOTE_OK) * or: remote_error Error (for REMOTE_REPLY, status = REMOTE_ERROR) * * The first two words (length, program number) are meant to be compatible * with the qemud protocol (qemud/protocol.x), although the rest of the * messages are completely different. */ enum remote_message_direction { REMOTE_CALL = 0, /* client -> server */ REMOTE_REPLY = 1, /* server -> client */ REMOTE_MESSAGE = 2 /* server -> client, asynchronous [NYI] */ }; enum remote_message_status { /* Status is always REMOTE_OK for calls. * For replies, indicates no error. */ REMOTE_OK = 0, /* For replies, indicates that an error happened, and a struct * remote_error follows. */ REMOTE_ERROR = 1 }; struct remote_message_header { unsigned prog; /* REMOTE_PROGRAM */ unsigned vers; /* REMOTE_PROTOCOL_VERSION */ remote_procedure proc; /* REMOTE_PROC_x */ remote_message_direction direction; unsigned serial; /* Serial number of message. */ remote_message_status status; }; /* * vim: set tabstop=4: * vim: set shiftwidth=4: * vim: set expandtab: */ /* * Local variables: * indent-tabs-mode: nil * c-indent-level: 4 * c-basic-offset: 4 * tab-width: 4 * End: */

2 4

[Libvir] [PATCH] Remove VIR_DRV_OPEN_QUIET
by Richard W.M. Jones 01 May '07

01 May '07

VIR_DRV_OPEN_QUIET causes important diagnostic error messages to be thrown away. This patch removes this. 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)

2 2

[Libvir] [PATCH] Xen proxy - adds getCapabilities call
by Richard W.M. Jones 01 May '07

01 May '07

Seems to me that it should be safe to allow non-root callers to use the getCapabilities call over the Xen proxy. This patch adds that feature. 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)

2 2

[Libvir] [PATCH] Fix xen-unified to work in non-root case
by Richard W.M. Jones 01 May '07

01 May '07

Xen-unified introduced a stupid bug, down to me, when running in the non-root case. It didn't keep track of which drivers successfully opened, so will try and perform operations on drivers which didn't open. I suggest that if people approve of the attached patch, then it is applied with some urgency. 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)

2 2

[Libvir] Difference between API functions virConnectNumOfDefinedDomains and virConnectNumOfDomains
by Jan Michael 01 May '07

01 May '07

Hello libvirt fellows, I have some problems to distinguish between those function calls in libvirt API: > virConnectNumOfDefinedDomains > virConnectNumOfDomains The API description states on both function that they will return me the number of active domain. Am I right if I assume that the first function virConnectNumOfDefinedDomains returns me all defined, but necessarily not running domains, and the second one only running and therefore active domains? Can you please help me and clarify this? Didn't had the chance to test this so far. But I will do so asap. Maybe the API documentation has to be updated in this point. Cheers, Jan

3 3

[Libvir] [PATCH] If xenHypervisorInit fails, produce an error message
by Richard W.M. Jones 28 Apr '07

28 Apr '07

.. and if opening the Xen HV file under /proc fails, show us the errno. 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)

1 0

[Libvir] Remote patch, 2007-04-27
by Richard W.M. Jones 28 Apr '07

28 Apr '07

This (re-)adds support for TLS and TCP sockets, the configuration file, certificate checking, clients IP address whitelists. 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)

1 0

[Libvir] Relax NG for network XML
by David Lutterkort 28 Apr '07

28 Apr '07

Hi, I wrote up a basic Relax NG schema for the network XML. It would be nice if those who know these things could look over/expand on the comments on what the various elements do. David

1 0

[Libvir] plans to support vde_switch ?
by adrian.lambeck＠basicsedv.de 27 Apr '07

27 Apr '07

Hello everybody, I am working on a project where I found vde_switch (http://vde.sourceforge.net/) very useful. It is based on uml_switch from the UML project. Are there any plans to support it in libvirt? Thanks. Adrian

3 2

[Libvir] about domctl
by Atsushi SAKAI 27 Apr '07

27 Apr '07

Hi, Dan I have a question about domctl(Xen hypervisor call). It seems not working on Fedora7(i386). But sysctl works fine. for example "virsh setmem" does not set memory. "virsh vcpuinfo " shows following message on dom0 (strange) VCPU: 0 CPU: 0 State: blocked CPU time: 0.0s CPU Affinity: - Would you investigate this issue? I look around the code but it should be works. Thanks Atsushi SAKAI

2 3

[Libvir] [FYI] Holidays of Japan
by Atsushi SAKAI 26 Apr '07

26 Apr '07

Next week Japan has many national holidays.(Apr 29, May 3, 4, 5) http://en.wikipedia.org/wiki/Holidays_of_Japan Someone appeared on May 1 and 2 Thanks Atsushi SAKAI

2 1

[Libvir] Remote patch, 2007-04-26
by Richard W.M. Jones 26 Apr '07

26 Apr '07

Been on holiday last week, and then got massively sidetracked with query strings in libxml2, so there's not been much progress. Nevertheless, here is the current remote patch. It still needs GnuTLS support to be copied over from the old version, so currently it only listens on Unix sockets. 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)

1 0

[Libvir] [PATCH][RFC] Adding Cloning Feature
by Kazuki Mizushima 25 Apr '07

25 Apr '07

Hi all, I've been planing to adding cloning feature. Then, I tried to make the patch in the following way. 1)Get the XML used virDomainGetXMLDesc 2)Delete <uuid>, <mac> node element This intened to automatically generated. 3)Changing <name>, <source dev> string node element 4)Fork "dd" process 5)Define XML used virDomainDefineXML This feature is just a first revision, because I make this patch within current libvirt API limitation. Also Remote Cloining is Limited. But if we can libvirtd for feature, it will be enhance remote cloning based on this pach (as http://libvirt.org/remote.html#Remote_libvirtd_configuration) Finally, to have to communicate with the demon remotely as libvirt library, actually I want to put down to new libvirt API (e.g. virDomainClone). Could you hear your comments about this ? Attached patch shows below. --------------------------------------------- # ./virsh --help clone NAME clone - clone a domain SYNOPSIS virsh clone <domain> <devices,...> DESCRIPTION Clone a domain. OPTIONS <domain> shut off state domain name <devices> destination devices (comma separated) # ./virsh clone PV_RH5 /dev/sdb2 Cloning from /dev/sda5 to /dev/sdb2 ..... # ./virsh list --all Id Name State ---------------------------------- 0 Domain-0 running - PV_RH5 shut off - PV_RH5_CLONE shut off #./virsh start PV_RH5_CLONE Domain PV_RH5_CLONE started --------------------------------------------- Thanks, Kazuki Mizushima

4 9

Re: [Libvir] [PATCH][RFC] Adding Cloning Feature
by Kazuki Mizushima 25 Apr '07

25 Apr '07

Hi Rich, > I think cloning is a great feature. From when I used to sysadmin a Xen > server, I used cloning as the main technique to create new servers - ie. > take an existing machine which is similar to the new one which I want, > and just clone it. Thank you for your comments and agreement. > There is no problem with interaction with the remote patch. Nor do you > have to worry about the remote stuff when implementing this (the "dd" > will fork on the remote libvirtd automagically). O.K. I understood it. I warry about remote support for libvirt architecture always. > So the idea is that you can only clone an inactive domain? This first revision, only inactive domain. But next step, I think snapshot command will be able to used instead of "dd". Thanks, Kazuki Mizushima

2 1

[Libvir] Capabilities XML format
by Mark McLoughlin 23 Apr '07

23 Apr '07

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.

2 2

[Libvir] [RFC] Life-cycle Management of the domain
by Saori Fukuta 23 Apr '07

23 Apr '07

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

3 8

[Libvir] Remote & the problem with qemu deadlock
by Richard W.M. Jones 19 Apr '07

19 Apr '07

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)

2 4

[Libvir] Community IRC chat room for virt management tools/APIs/protocols
by Daniel P. Berrange 19 Apr '07

19 Apr '07

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 -=|

1 0

[Libvir] ia64 support
by Aron Griffis 19 Apr '07

19 Apr '07

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

2 3