June 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] Extending libvirt to probe NUMA topology
by Ryan Harper 11 Sep '07

11 Sep '07

Hello all, I wanted to start a discussion on how we might get libvirt to be able to probe the NUMA topology of Xen and Linux (for QEMU/KVM). In Xen, I've recently posted patches for exporting topology into the [1]physinfo hypercall, as well adding a [2]hypercall to probe the Xen heap. I believe the topology and memory info is already available in Linux. With these, we have enough information to be able to write some simple policy above libvirt that can create guests in a NUMA-aware fashion. I'd like to suggest the following for discussion: (1) A function to discover topology (2) A function to check available memory (3) Specifying which cpus to use prior to domain start Thoughts? 1. http://lists.xensource.com/archives/html/xen-devel/2007-06/msg00298.html 2. http://lists.xensource.com/archives/html/xen-devel/2007-06/msg00299.html -- Ryan Harper Software Engineer; Linux Technology Center IBM Corp., Austin, Tx (512) 838-9253 T/L: 678-9253 ryanh(a)us.ibm.com

5 13

[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

[Libvir] [Q]Will virConnectNumOfNetworks and virConnectNumOfDefinedNetworks be supported by Xen ?
by S.Sakamoto 05 Jul '07

05 Jul '07

Hi, When I use virt-manager that is connected by xen, the following error is given at every monitoring. libvir: Error : this function is not supported by the hypervisor: virConnectNumOfNetworks libvir: Error : this function is not supported by the hypervisor: virConnectNumOfDefinedNetworks Therefore I have a question. Will virConnectNumOfNetworks and virConnectNumOfDefinedNetworks be supported by Xen ? When is it if supported ? Thanks, Shigeki Sakamoto.

4 8

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] PATCH: Fix remote driver to handle network API for local non-QEMU
by Daniel P. Berrange 04 Jul '07

04 Jul '07

The remote_internal.c code is basically a no-op in its remoteNetworkOpen method. This means the remote driver will only handle the networking APIs, if it is also handling the main domain APIs. This works fine if connecting to a remote URI, or if using QEMU URIs, but it does not work if using the test or Xen drivers. To make this work the remoteNetworkOpen method needs to open a connection to the remote daemon IIF the remoteOpen method did not already open one. So the attached patch adds the neccessary logic in remoteNetworkOpen. It also adds code to remoteNetworkClose to make it shutdown& free the connection IIF it was opened by the remoteNetworkOpen method. This is what the extra 'networkOnly' field in the 'struct private_data' is used to check. Second, all of the implementations of virNetwork* APIs in the remote_internal.c driver must use the 'struct private_data *' from networkPrivateData field in virConnectPtr, not the 'privateData' field. This is because the 'privateData' field is probably storing data related to the Xen or Test drivers. Third, this also fixes the qemu_driver.c which incorrectly used the privateData field insteadof the networkPrivateData field for 2 of the networking APIs, and finally makes sure the qemu_driver.c also acccepts the use of qemu:///session APIs for root user. 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 -=|

3 5

[Libvir] Cleanup patch
by Daniel Veillard 29 Jun '07

29 Jun '07

Enclosed is a cleanup patch I applied, it corrects the XML api generation, fixes warning in the XSLT stylesheet, add comments to a number of internal functions, makes most function of the QEmu back-end static, fixes a few bugs found in the way. Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/

2 2

[Libvir] re: hvsupport html page
by Philippe Berthault 29 Jun '07

29 Jun '07

A great work ! This new help page will be very useful for all developers :-) Thanks a lot. P.Berthault.

1 0

[Libvir] [PATCH] Do check the UUID in __virGetDomain()
by Masayuki Sunou 29 Jun '07

29 Jun '07

Hi This patch adds checking the UUID in __virGetDomain(). Now, the UUID of domain is wrong in the following operations. 1. Start virsh in interactive mode. 2. Execute domuuid to the domain 3. Execute undefine to the domain which executed domuuid in 2. 4. Create the domain whose name is same as the domain that executed undefine. 5. Execute domuuid for the new domain This patch can fix it. Signed-off-by: Masayuki Sunou <fj1826dm(a)aa.jp.fujitsu.com> Thanks, Masayuki Sunou. -------------------------------------------------------------------------------- Index: src/hash.c =================================================================== RCS file: /data/cvs/libvirt/src/hash.c,v retrieving revision 1.22 diff -u -p -r1.22 hash.c --- src/hash.c 8 May 2007 10:53:27 -0000 1.22 +++ src/hash.c 7 Jun 2007 02:08:41 -0000 @@ -758,8 +758,14 @@ __virGetDomain(virConnectPtr conn, const ret = (virDomainPtr) virHashLookup(conn->domains, name); if (ret != NULL) { - /* TODO check the UUID */ - goto done; + if (memcmp(ret->uuid, uuid, 16)) { + if (virFreeDomain(conn, ret, 0) < 0) { + xmlMutexUnlock(conn->hashes_mux); + return(NULL); + } + } else { + goto done; + } } /* @@ -813,7 +819,7 @@ error: * Returns the reference count or -1 in case of failure. */ int -virFreeDomain(virConnectPtr conn, virDomainPtr domain) { +virFreeDomain(virConnectPtr conn, virDomainPtr domain, int lock) { int ret = 0; if ((!VIR_IS_CONNECT(conn)) || (!VIR_IS_CONNECTED_DOMAIN(domain)) || @@ -821,7 +827,8 @@ virFreeDomain(virConnectPtr conn, virDom virHashError(conn, VIR_ERR_INVALID_ARG, __FUNCTION__); return(-1); } - xmlMutexLock(conn->hashes_mux); + if (lock) + xmlMutexLock(conn->hashes_mux); /* * decrement the count for the domain @@ -853,13 +860,14 @@ virFreeDomain(virConnectPtr conn, virDom if (conn->domains != NULL) virHashFree(conn->domains, (virHashDeallocator) virDomainFreeName); - if (conn->hashes_mux != NULL) + if (conn->hashes_mux != NULL && lock) xmlFreeMutex(conn->hashes_mux); free(conn); return(0); done: - xmlMutexUnlock(conn->hashes_mux); + if (lock) + xmlMutexUnlock(conn->hashes_mux); return(ret); } Index: src/internal.h =================================================================== RCS file: /data/cvs/libvirt/src/internal.h,v retrieving revision 1.41 diff -u -p -r1.41 internal.h --- src/internal.h 8 May 2007 10:53:27 -0000 1.41 +++ src/internal.h 7 Jun 2007 02:08:41 -0000 @@ -202,7 +202,7 @@ virDomainPtr __virGetDomain (virConnectP const char *name, const unsigned char *uuid); int virFreeDomain (virConnectPtr conn, - virDomainPtr domain); + virDomainPtr domain, int lock); virDomainPtr virGetDomainByID(virConnectPtr conn, int id); virNetworkPtr __virGetNetwork (virConnectPtr conn, Index: src/libvirt.c =================================================================== RCS file: /data/cvs/libvirt/src/libvirt.c,v retrieving revision 1.73 diff -u -p -r1.73 libvirt.c --- src/libvirt.c 5 Jun 2007 12:06:08 -0000 1.73 +++ src/libvirt.c 7 Jun 2007 02:08:41 -0000 @@ -730,7 +730,7 @@ virDomainFree(virDomainPtr domain) virLibDomainError(domain, VIR_ERR_INVALID_DOMAIN, __FUNCTION__); return (-1); } - if (virFreeDomain(domain->conn, domain) < 0) + if (virFreeDomain(domain->conn, domain, 1) < 0) return (-1); return(0); } Index: src/qemu_internal.c =================================================================== RCS file: /data/cvs/libvirt/src/qemu_internal.c,v retrieving revision 1.25 diff -u -p -r1.25 qemu_internal.c --- src/qemu_internal.c 5 Jun 2007 12:06:08 -0000 1.25 +++ src/qemu_internal.c 7 Jun 2007 02:08:42 -0000 @@ -906,7 +906,7 @@ static int qemuUndefine(virDomainPtr dom } cleanup: - if (virFreeDomain(dom->conn, dom) < 0) + if (virFreeDomain(dom->conn, dom, 1) < 0) ret = -1; return ret; Index: src/xend_internal.c =================================================================== RCS file: /data/cvs/libvirt/src/xend_internal.c,v retrieving revision 1.116 diff -u -p -r1.116 xend_internal.c --- src/xend_internal.c 5 Jun 2007 12:06:09 -0000 1.116 +++ src/xend_internal.c 7 Jun 2007 02:08:42 -0000 @@ -1900,7 +1900,7 @@ error: virXendError(conn, VIR_ERR_INTERNAL_ERROR, _("failed to parse Xend domain information")); if (ret != NULL) - virFreeDomain(conn, ret); + virFreeDomain(conn, ret, 1); return(NULL); } #endif /* !PROXY */ @@ -3055,7 +3055,7 @@ xenDaemonCreateLinux(virConnectPtr conn, /* Make sure we don't leave a still-born domain around */ if (dom != NULL) { xenDaemonDomainDestroy(dom); - virFreeDomain(dom->conn, dom); + virFreeDomain(dom->conn, dom, 1); } if (name != NULL) free(name);

4 8

[Libvir] request for libvirt documentation improvement
by Philippe Berthault 29 Jun '07

29 Jun '07

The documentation of libvirt doesn't indicate which functions are for Xen or QEMU or both. The only way to know that, is by searching in libvirt sources. It would be interesting for libvirt users to add in the documentation, for each function, a mention such as "QEMU only", "Xen(TM) only", "QEMU and Xen(TM)", etc.. Regards. Libvirt 0.2.3 functions dedicated to QEMU only: virConnectListDefinedNetworks virConnectListNetworks virConnectNumOfDefinedNetworks virConnectNumOfNetworks virDomainGetAutostart virDomainSetAutostart virNetworkCreate virNetworkCreateXML virNetworkDefineXML virNetworkDestroy virNetworkFree virNetworkGetAutostart virNetworkGetBridgeName virNetworkGetName virNetworkGetUUID virNetworkGetUUIDString virNetworkGetXMLDesc virNetworkLookupByName virNetworkLookupByUUID virNetworkLookupByUUIDString virNetworkSetAutostart virNetworkUndefine Libvirt 0.2.3 functions dedicated to Xen(TM) only: virConnectGetMaxVcpus virConnectGetType virDomainAttachDevice virDomainCoreDump virDomainDetachDevice virDomainGetMaxMemory virDomainGetSchedulerParameters virDomainGetSchedulerType virDomainPinVcpu virDomainReboot virDomainSetMaxMemory virDomainSetMemory virDomainSetSchedulerParameters virDomainSetVcpus

6 10