May 2007 - Devel - libvirt List Archives

[Libvir] RFC: Supporting serial & parallel ports for QEMU (and improving Xen)
by Daniel P. Berrange 26 Feb '08

26 Feb '08

One user's feature request for our QEMU driver is to support serial ports. Easy you might think... you'd be wrong :-) On Xen we have very simple approach. When creating a guest simply add <console/> And it'll cause a serial port to be setup with an autoallocated pty, so you get back <console pty='/dev/pts/5'/> In retrospect calling it 'console' was dumb, but hey we're stuck with that now and its only a tiny naming issue so I don't mind really. We can do the same thing with QEMU quite easily. QEMU, however, supports many many many more ways to hooking up the serial port to Dom0. Indeed so does Xen fullyvirt, but we don't expose this ability. Parallel ports have identical config syntax to serial ports so we might as well deal with both at once. So, here's a stripped down version of the QEMU docs: [quote http://fabrice.bellard.free.fr/qemu/qemu-doc.html#SEC10] `-serial dev' Redirect the virtual serial port to host character device dev. The default device is vc in graphical mode and stdio in non graphical mode. This option can be used several times to simulate up to 4 serials ports. Use -serial none to disable all serial ports. Available character devices are: vc Virtual console pty [Linux only] Pseudo TTY (a new PTY is automatically allocated) none No device is allocated. null void device /dev/XXX [Linux only] Use host tty, e.g. `/dev/ttyS0'. The host serial port parameters are set according to the emulated ones. /dev/parportN [Linux only, parallel port only] Use host parallel port N. Currently only SPP parallel port features can be used. file:filename Write output to filename. No character can be read. stdio [Unix only] standard input/output pipe:filename name pipe filename COMn [Windows only] Use host serial port n udp:[remote_host]:remote_port[@[src_ip]:src_port] This implements UDP Net Console. tcp:[host]:port[,server][,nowait][,nodelay] The TCP Net Console has two modes of operation. telnet:host:port[,server][,nowait][,nodelay] The telnet protocol is used instead of raw tcp sockets. unix:path[,server][,nowait] A unix domain socket is used instead of a tcp socket. [/quote] I don't see any reason to not support all/most of these options. The things I don't like here is that /dev/XXX, vs /dev/parportN, vs COMn differences for connecting guest <-> host passthrough of the devices. I figure it could be simpler if it was just represented as 'n' and we'd translate that to be /dev/ttyS[n] or /dev/parport[n] or COM[n] as needed. The question as ever is how to represent this in XML. For serial ports we'll stick with '<console>', while parallel ports we might as well use a better named '<parallel>'. Next up, I think should use a 'type' attribute on this element to determine the main way ot connecting the device, and then more type specific attributes or sub-elements as needed. If 'type' was not specified then use a default of 'pty', since that gives compatability with existing practice. As an illustrative example /* * Parse the XML definition for a character device * * Top level node will be <console> or <parallel>, but all attributes * and sub-elements are identical. * * type=vc|pty|null|host|file|pipe|udp|tcp|telnet, default is pty * * <console type='vc'/> * * <console type='pty' pty='/dev/pts/3'/> * * <console type='null'/> * * <console type='host' port='3'/> * * <console type='file' path='/some/file'/> * * <console type='pipe' path='/some/file'/> * * <console type='udp'> * <sendto port='12356'/> * </console> * * <console type='udp'> * <sendto addr='127.0.0.1' port='12356'/> * </console> * * <console type='udp'> * <sendto addr='127.0.0.1' port='12356'/> * <bind port='12356'/> * </console> * * <console type='udp'> * <sendto addr='127.0.0.1' port='12356'/> * <bind addr='127.0.0.1' port='12356'/> * </console> * * <console type='tcp'> * <listen port='12356'/> * </console> * * <console type='tcp'> * <listen addr='127.0.0.1' port='12356'> * <nowait/> * <nodelay/> * </listen> * </console> * * <console type='tcp'> * <connect addr='127.0.0.1' port='12356'> * <nodelay/> * </connect> * </console> * * <console type='telnet'> * <listen addr='127.0.0.1' port='12356'/> * </console> * * <console type='telnet'> * <connect addr='127.0.0.1' port='12356'/> * </console> * */ BTW, the udp, tcp, telnet options are only available on QEMU >= 0.9.0. We already have ability to detect / validate that for both Xen & QEMU drivers. NB, whereever there are IP addresses, hostnames can be used too, hence I call the attriute 'addr' instead of 'ip' 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 -=|

5 8

[Libvir] virsh vcpupin does not work with xend
by Saori Fukuta 06 Jul '07

06 Jul '07

Hi, The virsh vcpupin command does not work when it uses Xend(xend_internal.c). HV(xen_internal.c) works fine. I'm testing on Xen3.1.0(hypervisor_version=2, dom_interface_version=5, xendConfigVersion=4), and using current libvirt(ChangeLog revision 1.546). To solve this problem, I got the xend debug information and compared that. * in the case of executing "virsh vcpupin 63 7 1" * [2007-05-29 09:33:20 4258] DEBUG (XendDomain:1297) dom(63) cpu 7 cpumap [1](<type'str'>) * in the case of executing "xm vcpu-pin 63 7 1" * [2007-05-29 09:33:32 4258] DEBUG (XendDomain:1297) dom(63) cpu 7 cpumap [1](<type'list'>) There is one different thing. The type of cpumap is str when executing virsh command, but the type of cpumap is list when executing xm command. Do you have any idea ? Thanks, Saori Fukuta

2 4

Re: [Libvir] [RFC]OpenVZ XML def
by Richard W.M. Jones 05 Jul '07

05 Jul '07

Shuveb Hussain wrote: >> >> Daemon though? Can't the libvirt code just invoke the OpenVZ commands >> directly? > > Yeah, that is very much possible. But if it were a daemon, it could be > a Python daemon, since text processing is much simpler and I don't > have to use the str*( ) funcs in C. What is your comment? I'm a big advocate of using a sane language instead of C, but libvirt is written in C for better or worse. The problem with a separate daemon is management of that daemon. Something needs to start it and stop it, it needs to have sockets with the right permissions and so on. What happens if the process runs and can't find the daemon? What is the path to the socket? etc. etc. At the moment we have two daemons - the qemu daemon (which has two separate functions intertwined), and a remote daemon (necessary, because there's no other way to communicate to a remote machine). One idea would be to have the Python code fork off from the main program and communicate over a pipe. With this, there is no daemon management problem. +----------------+ | Program | | - - - - - - - -| | libvirt | +----------------+ | | fork(2) and pipe(2) | +-------------+ | Python code | +-------------+ But I'm not the person who ultimately decides what would be acceptable in libvirt. You'd need to get general agreement on the best way to do this. 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 7

[Libvir] [RFC] Device attach/detach on virsh
by Masayuki Sunou 19 Jun '07

19 Jun '07

I want to add I/F to do attach/detatch of VIF and VBD to virsh with virDomainAttachDevice()/virDomainDetachDevice(). And, I have two proposals about I/F for virsh to do attach/detach of VIF and VBD. proposal 1: Virsh catches MAC, bridge name, device name (physical,virtual), and another by the command option. ex) ------------------------------------------------------------------ # virsh help attach(detach)-vif(vbd) NAME attach(detach)-vif(vbd) - attach(detach) vif(vbd) SYNOPSIS * VIF attach(detach)-vif <domain> <MAC> <bridge> ... or * VBD attach(detach)-vbd <domain> <virt-dev> ... DESCRIPTION Attach(Detach) vif(vbd) device OPTIONS <domain> domain name, id or uuid * VIF <MAC> MAC address of vif <bridge> bridge name of vif ... * VBD <virt-dev> virtual device name of vbd <phy-dev> physical device name of vbd ... ------------------------------------------------------------------ <advantage> - I/F is easy to use than proposal 1. (Because the user does not have to make XML) <disadvantage> - I/F increases because I/F of VIF and VBD becomes separate. (So, the addition of I/F is necessary at any time for supporting devices other than VIF and VBD. ) - Handling of optional analysis, handling of XML making are necessary in virsh.c, and processing becomes complicated. proposal 2: virsh catches a definition of a device by XML ex) ------------------------------------------------------------------ # virsh help attach(detach)-device NAME attach(detach)-device - attach(detach) device from an XML file SYNOPSIS attach(detach)-device <domain> <file> DESCRIPTION Attach(Detach) device from an XML <file> OPTIONS <domain> domain name, id or uuid <file> XML file of device description ------------------------------------------------------------------ <advantage> - I/F is unified without affecting a device type. (I/F is simple) - Handling of virsh.c is simple. (Optional analysis is not necessary) <disadvantage> - The user has to describe XML.(It is troublesome) I think that specifications that a user is easy to use (proposal 1) are better. Please, give me an opinion which proposal is better. Thanks, Masayuki Sunou

6 28

[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] output virsh log to file
by Nobuhiro Itou 07 Jun '07

07 Jun '07

Hi, I made the patch which output debug messages and error messages of virsh to the log file. I think that it is necessary to leave logs to the file for the investigation at the failure. Debug messages can take appointed optional information, and error messages will make it easy to specify a cause. Moreover, I'm thinking about outputting virterror information to the virsh log file by the next step. It is simple specifications as follows. * Destination -- <USER HOME>/.virsh/virsh.log * Log size -- 1MB(1024*1024) * Number of Rotations -- 5 * There is process exclusion. First, will you take in this patch ? And, I have a plan to enhance logging functionality. (for example, libvirt error logging) Signed-off-by: Nobuhiro Itou <fj0873gn(a)aa.jp.fujitsu.com> Thanks, Nobuhiro Itou.

6 18

[Libvir] [PATCH] Cut out "type=ioemu" on Xen3.1
by Saori Fukuta 07 Jun '07

07 Jun '07

Hi, The definition of (type ioemu) is *not* required by Xen3.1. So I cut out it when xendConfigVersion is 4 or later. Signed-off-by: Saori Fukuta <fukuta.saori(a)jp.fujitsu.com> Thanks, Saori Fukuta. Index: xml.c =================================================================== RCS file: /data/cvs/libvirt/src/xml.c,v retrieving revision 1.73 diff -u -p -r1.73 xml.c --- xml.c 23 Apr 2007 07:41:23 -0000 1.73 +++ xml.c 31 May 2007 07:02:01 -0000 @@ -1047,6 +1047,7 @@ virDomainParseXMLDiskDesc(virConnectPtr * @conn: pointer to the hypervisor connection * @node: node containing the interface description * @buf: a buffer for the result S-Expr + * @xendConfigVersion: xend configuration file format * * Parse the one interface the XML description and add it to the S-Expr in buf * This is a temporary interface as the S-Expr interface @@ -1056,7 +1057,7 @@ virDomainParseXMLDiskDesc(virConnectPtr * Returns 0 in case of success, -1 in case of error. */ static int -virDomainParseXMLIfDesc(virConnectPtr conn ATTRIBUTE_UNUSED, xmlNodePtr node, virBufferPtr buf, int hvm) +virDomainParseXMLIfDesc(virConnectPtr conn ATTRIBUTE_UNUSED, xmlNodePtr node, virBufferPtr buf, int hvm, int xendConfigVersion) { xmlNodePtr cur; xmlChar *type = NULL; @@ -1129,7 +1130,8 @@ virDomainParseXMLIfDesc(virConnectPtr co virBufferVSprintf(buf, "(script '%s')", script); if (ip != NULL) virBufferVSprintf(buf, "(ip '%s')", ip); - if (hvm) + /* HVM type ioemu config for xen < 3.1 */ + if (hvm && xendConfigVersion < 4) virBufferAdd(buf, "(type ioemu)", 12); virBufferAdd(buf, ")", 1); @@ -1335,7 +1337,7 @@ virDomainParseXMLDesc(virConnectPtr conn if (nb_nodes > 0) { for (i = 0; i < nb_nodes; i++) { virBufferAdd(&buf, "(device ", 8); - res = virDomainParseXMLIfDesc(conn, nodes[i], &buf, hvm); + res = virDomainParseXMLIfDesc(conn, nodes[i], &buf, hvm, xendConfigVersion); if (res != 0) { free(nodes); goto error; @@ -1494,7 +1496,7 @@ virParseXMLDevice(virConnectPtr conn, ch goto error; } else if (xmlStrEqual(node->name, BAD_CAST "interface")) { - if (virDomainParseXMLIfDesc(conn, node, &buf, hvm) != 0) + if (virDomainParseXMLIfDesc(conn, node, &buf, hvm, xendConfigVersion) != 0) goto error; } cleanup:

3 6

Re: [Libvir] [PATCH] add scheduler API(take 3?)
by Richard W.M. Jones 04 Jun '07

04 Jun '07

+char * +virDomainGetSchedulerType(virDomainPtr domain, int *nparams) +{ + virConnectPtr conn; + char *schedtype; + + if (domain == NULL) { + TODO + return NULL; + } Is this case an error, or were you thinking of adding more semantics later on here? (and the same comment for virDomainGet/SetSchedulerParameters) +static int +cmdSchedinfo(vshControl * ctl, vshCmd * cmd) +{ [...] + char *str_weight = strdup("weight"); + char *str_cap = strdup("cap"); + + nparams = malloc(sizeof(int)); + *nparams = 0; + + if (!vshConnectionUsability(ctl, ctl->conn, TRUE)) + return FALSE; There's still a problem memory leak here. + /* Currently supports Xen Credit only */ + weight = vshCommandOptInt(cmd, "weight", &weightfound); + if(weightfound){ inputparam++; } + + cap = vshCommandOptInt(cmd, "cap", &capfound); + if(capfound){ inputparam++; } and can this be made so it isn't Xen-specific? + if ((domain == NULL) || (domain->conn == NULL)) + return -1; + + priv = (xenUnifiedPrivatePtr) domain->conn->privateData; + if (priv->handle < 0 || domain->id < 0) + return -1; At the lowest level, these functions should return error messages back to the upper layers. Otherwise users have nothing to diagnose errors with. + /* + * Support only dom_interface_version >=5 + * (Xen3.1.0 or later) + */ + if (dom_interface_version < 5) + return -1; Is this because earlier hypervisors didn't support this, or is it just not implemented? Rich.

3 7

[Libvir] [PATCH] Fix strange error message in virsh attach-device
by Masayuki Sunou 04 Jun '07

04 Jun '07

Hi Now, virsh attach-device displays the following messages when "device" attribute of "disk" element is "floppy" in XML. # virsh attach-device HVM_RH4_file floppy.xml libvir: Xen Daemon error : POST operation failed: (xend.err 'Invalid Configuration: XendConfig: @\x14\xce not a valid device type') error: Failed to attach device from floppy.xml This patch fixes this strange error message displaying "@\x14\xce". Description of this patch VirDomainParseXMLDiskDesc() returns 0 without putting data in virBuffer, when "floppy" is set. Therefore, virParseXMLDevice() returns no initialized data, and xenDaemonAttachDevice() passes Xen this data. Because virDomainParseXMLDesc() works wrong when this patch changes return value of VirDomainParseXMLDiskDesc(),this patch fixes virParseXMLDevice() as follows. - Initialize data - Return error if data does not change. As a result, xenDaemonAttachDevice() doesn't pass strange data to Xen, and Xen doesn't return strange error message. Signed-off-by: Masayuki Sunou <fj1826dm(a)aa.jp.fujitsu.com> Thanks, Masayuki Sunou. ---------------------------------------------------------------------- Index: src/xml.c =================================================================== RCS file: /data/cvs/libvirt/src/xml.c,v retrieving revision 1.73 diff -u -p -r1.73 xml.c --- src/xml.c 23 Apr 2007 07:41:23 -0000 1.73 +++ src/xml.c 25 May 2007 09:46:56 -0000 @@ -1481,6 +1481,7 @@ virParseXMLDevice(virConnectPtr conn, ch return (NULL); buf.size = 1000; buf.use = 0; + memset(buf.content, 0, (size_t)buf.size); xml = xmlReadDoc((const xmlChar *) xmldesc, "domain.xml", NULL, XML_PARSE_NOENT | XML_PARSE_NONET | XML_PARSE_NOERROR | XML_PARSE_NOWARNING); @@ -1492,6 +1493,9 @@ virParseXMLDevice(virConnectPtr conn, ch if (xmlStrEqual(node->name, BAD_CAST "disk")) { if (virDomainParseXMLDiskDesc(conn, node, &buf, hvm, xendConfigVersion) != 0) goto error; + /* SXP is not created when device is "floppy". */ + else if (!strlen(buf.content)) + goto error; } else if (xmlStrEqual(node->name, BAD_CAST "interface")) { if (virDomainParseXMLIfDesc(conn, node, &buf, hvm) != 0) ----------------------------------------------------------------------

2 5

[Libvir] cannot use vncviewer and VMM graphics console to access HVM guest on RHES 5
by Glen Deem 01 Jun '07

01 Jun '07

Hi all, I've created an HVM guest under RHES 5 (Xen 3.0.3) using "xm create" but I cannot access it with vncviewer. The Virtual Machine Manager also informs about graphics console unavailability. What am I doing wrong, please? I do > vncviewer 123.456.789.123:4, where 4 is the guest id. This is the xm config file is: name = "hvmGuest" builder = "hvm" memory = "500" disk = [ 'file:/var/lib/red-hat.img,hda,w', ] vif = [ 'type=ioemu, mac=00:16:3e:34:3b:ba, bridge=xenbr0', ] device_model = "/usr/lib/xen/bin/qemu-dm" kernel = "/usr/lib/xen/boot/hvmloader" vnc=1 vncunused=1 apic=1 acpi=1 pae=1 vcpus=1 serial = "pty" on_reboot = 'restart' on_crash = 'restart' Thanks a lot in advance. Glen from Ottawa, Canada

3 2