- Devel - libvirt List Archives

[Libvir] [RFC] Linux-VServer support
by Daniel Hokka Zakrisson 06 Nov '07

06 Nov '07

Hi, This is an initial stab at adding Linux-VServer support to libvirt. There are still a couple of things missing, like scheduler support in the XML parsing, and proper network support. I've got a few questions though. virsh's schedinfo hardcodes the available options, should I be adding new ones there? Would better introspection from getSchedulerType make this a non-issue? How do the network domains interact and associate with the regular domains? -- Daniel Hokka Zakrisson

4 24

[Libvir] [PATCH] Fix failure of virsh attach-disk (BZ346281)
by Masayuki Sunou 06 Nov '07

06 Nov '07

Hi Virsh attach-disk fails when the disk is attached to domain. And error message displays that device_configure() failed. # virsh attach-disk PV_RH51RC_12 /dev/hda8 xvdb --driver phy libvir: Xen Daemon error : POST operation failed: (xend.err'device_configure() takes exactly 2 arguments (3 given)') --> BZ346281 : https://bugzilla.redhat.com/show_bug.cgi?id=346281 This problem occurs because search of device ID of disk doesn't operate correctly. This patch fixes it. And this fixes a little comment too. Signed-off-by: Masayuki Sunou <fj1826dm(a)aa.jp.fujitsu.com> Thanks, Masayuki Sunou.

2 1

[Libvir] [PATCH] Fix parameter validation of virsh schedinfo
by Masayuki Sunou 06 Nov '07

06 Nov '07

Hi User cannot judge whether virsh schedinfo successes or fails, because it does not become error when character string is set to an option. -------------------------------------------------- # virsh schedinfo 0 --weight aaa Scheduler : credit weight : 256 cap : 0 -------------------------------------------------- This patch fixes to become error when character string is set. Signed-off-by: Masayuki Sunou <fj1826dm(a)aa.jp.fujitsu.com> Thanks, Masayuki Sunou. -------------------------------------------------------------------------------- Index: src/virsh.c =================================================================== RCS file: /data/cvs/libvirt/src/virsh.c,v retrieving revision 1.104 diff -u -p -r1.104 virsh.c --- src/virsh.c 30 Sep 2007 13:22:16 -0000 1.104 +++ src/virsh.c 5 Nov 2007 06:26:52 -0000 @@ -1149,11 +1149,25 @@ cmdSchedinfo(vshControl * ctl, vshCmd * return FALSE; /* Currently supports Xen Credit only */ - weight = vshCommandOptInt(cmd, "weight", &weightfound); - if (weightfound) nr_inputparams++; - - cap = vshCommandOptInt(cmd, "cap", &capfound); - if (capfound) nr_inputparams++; + if(vshCommandOptBool(cmd, "weight")) { + weight = vshCommandOptInt(cmd, "weight", &weightfound); + if (!weightfound) { + vshError(ctl, FALSE, _("Invalid value of weight")); + goto cleanup; + } else { + nr_inputparams++; + } + } + + if(vshCommandOptBool(cmd, "cap")) { + cap = vshCommandOptInt(cmd, "cap", &capfound); + if (!capfound) { + vshError(ctl, FALSE, _("Invalid value of cap")); + goto cleanup; + } else { + nr_inputparams++; + } + } params = vshMalloc(ctl, sizeof (virSchedParameter) * nr_inputparams); if (params == NULL) { --------------------------------------------------------------------------------

2 1

[Libvir] [Announce] libvirt-cim : An open-source CIM provider for libvirt
by Daniel Veillard 05 Nov '07

05 Nov '07

libvirt-cim : An open-source CIM provider for libvirt This is the announcement of a new open-source project called libvirt-cim based on libvirt and aiming at offering the complete functionality of libvirt via a CIM provider implementing the DMTF SVPC virtualization model and released under an LGPL licence. A CIM [1] provider is an implementation of a set of standardized interfaces (Common Information Model) whose goal are to provide well defined entry points allowing easier and interoperable management tools to be built. In the case of libvirt-cim, the goal is of course to export the SVPC virtualization model, which then can be used to manage storage, hosts and domains remotely. Currently CIM based management targets mostly enterprise deployments but has the potential of solving the more generic problem of remote control interfaces which affects nearly all virtualization use cases and many other aspects of the computing environment. The current state of the project is based on an initial implementation provided by IBM, and released for the libvirt project under an LGPL licence. It currently targets only Xen virtualization but the goal is to expand support to the other mechanisms supported by libvirt, like KVM. It is made of a library libcmpiutil of library functions which are not specific to libvirt and useful for CMPI, the programming interfaces used to develop CIM providers. The main part is in the libvirt-cim module. The CIM provider is currently tested with the Pegasus [2] and SFCB [3] environment and the goal is to ensure compatibility with the various CIM based management systems. The project is hosted on libvirt.org, the source code is managed using Mercurial [4] and Dan Smith [5] is the project maintainer doing the commits. The project home page is available at: http://libvirt.org/CIM/ source code download is available at ftp://libvirt.org/libvirt-cim/ and the Mercurial tree is located at: http://libvirt.org/hg/ A dedicated mailing-list has been set up, libvirt-cim(a)redhat.com with the usual list page and archive mailman pages at: http://www.redhat.com/mailman/listinfo/libvirt-cim Daniel [1] http://en.wikipedia.org/wiki/Common_Information_Model_%28computing%29 [2] http://www.openpegasus.org [3] http://sblim.wiki.sourceforge.net/Sfcb [4] Mercurial: http://www.selenic.com/mercurial/wiki/ [5] Dan Smith <danms(a)us.ibm.com> -- 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/

1 0

[Libvir] collectd libvirtstats plugin (version 1, for discussion only)
by Richard W.M. Jones 05 Nov '07

05 Nov '07

Attached is a plugin allowing collectd to use libvirt to collect CPU, disk and network statistics for domains. There are a few problems with it at the moment, described below. Firstly just to say that this is a patch against the released collectd 4.2.0. I need to pull out the GIT repository and rebase the patch against that. Any other comments, most welcome! Usage ----- With this patch you should be able to collect stats by adding the following to your collectd.conf file: LoadPlugin libvirtstats <Plugin libvirtstats> Connection "xen:///" </Plugin> 'collectd' only needs to be running on the host. It uses libvirt to collect stats for each guest, via mechanisms in the hypervisor or host operating system. Requirements ------------ libvirt >= 0.3.3 and libxml2. The configure file should auto-detect the requirements and configure libvirtstats plugin only if they are available. Problems -------- I can't seem to get the ignorelist to do anything at all. It seems like it includes all the domains and devices, no matter what I specify in the configuration file and what the state of IgnoreSelected is set to. In the types.db, I have set the max for virt_cpu_total to be 256,000,000,000. The max CPU usage for a single CPU is 1 billion nanoseconds per second, but virt_cpu_total is for all CPUs in the system, and there could be (in theory) an unlimited number of CPUs, so an unlimited max. Therefore I have assumed here that max CPUs = 256. I'm using CSV output, which works, but it seems to report the aggregate counter values instead of the differences. Is that to be expected? 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

1 0

[Libvir] [PATCH] finish NUMA code reorg, plug cpuset at creat time support
by Daniel Veillard 05 Nov '07

05 Nov '07

The following patch finishes the cleanup for NUMA parsing code: - the cpuset parsing is moved to xml.c - some comments and cleanups of the include then add the output of a (cpus '...') line based on the /domain/vcpu/@cpuset attributes, this is parsed and reserialized as ranges to avoid any possibility of misinterpretation of say ^ or any special syntax we may want to add in the future. A few things to note: - dependant on the tiny patch I sent earlier today - if we notice that the set covers all CPU maybe we should avoid outputing (cpus '...'), trivial to add - mostly untested yet 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/

3 10

[Libvir] [PATCH] Fix failure of HVM domain definition on Xen 3.0.3 or earlier(BZ328841)
by Masayuki Sunou 01 Nov '07

01 Nov '07

Hi VirDomainDefineXML() fails, when HVM domain using CD-ROM is created on Xen 3.0.3 or earlier. -->BZ328841(https://bugzilla.redhat.com/show_bug.cgi?id=328841) One of attached patches (define.patch) fixes it. But, when domain is started by virsh start using the configuration file created by fixing this, the problem that the CD-ROM device is missed occurs. So, another patch (start.patch) fixes this problem. Signed-off-by: Masayuki Sunou <fj1826dm(a)aa.jp.fujitsu.com> Thanks, Masayuki Sunou.

2 5

[Libvir] PATCH: 0/7 Implementation of storage APIs
by Daniel P. Berrange 31 Oct '07

31 Oct '07

Since the previous discussions didn't really end up anywhere conclusive I decided it would be better to have a crack at getting some working code to illustrate my ideas. Thus, the following series of 7 patches provide an implementation of storage APIs which follow the scheme outlined in the previous mail on storage concepts http://www.redhat.com/archives/libvir-list/2007-October/msg00195.html I have only addressed storage pools & volumes. I am not tackling the host device enumeration APIs at this time, since it is not a blocker for the rest of the work. The mails which follow, in particular the last one, will explain the patches in more details. The focus is primarily on providing the public API, and wiring up the remote driver, daemon and protocol, and the generic storage driver. The generic storage driver then calls out to specific backends for different types of storage. implementation provides a fully functional backend for managing local directories containing raw files (aka equivalent of /var/lib/xen/images). There are empty stubs for LVM, iSCSI, Disks/Partitions, etc to be filled in as we decide... Some open questions - Is it worth bothering with a UUID for individual storage volumes. It is possible to construct a globally unique identifier for most volumes, by combing various bits of metadata we have such as device unique ID, inode, iSCSI target & LUN, etc There isn't really any UUID that fits into the classic libvirt 16 byte UUID. I've implemented (randomly generated) UUIDs for the virStorageVolPtr object, but I'm inclined to remove them, since its not much use if they change each time the libvirtd daemon is restarted. The 'name' field provides a unique identifier scoped to the storage pool. I think we could add a 'char *key' field, as an arbitrary opaque string, forming a globally unique identifier for the volume. This would serve same purpose as UUID, but without the 16 bytes constraint which we can't usefully provide. - For the local directory backend, I've got the ability to choose between file formats on a per-volume basis. eg, /var/lib/xen/images can contain a mix of raw, qcow, vmdk, etc files. This is nice & flexible for the user, but a more complex thing to implement, since it means we have to probe each volume and try & figure out its format each time we list volumes. If we constrained the choice between formats to be at the pool level instead of the volume level we could avoid probing & thus simplify the code. This is what XenAPI does. - If creating non-sparse files, it can take a very long time to do the I/O to fill in the image. In virt-intsall/virt-manager we have nice incremental progress display. The API I've got currently though is blocking. This blocks the calling application. It also blocks the entire libvirtd daemon since we are single process. There are a couple of ways we can address this: - Allow the libvirtd daemon to serve each client connection in a separate thread. We'd need to adding some mutex locking to the QEMU driver and the storage driver to handle this. It would have been nice to avoid threads, but I don't think we can much longer. - For long running operations, spawn off a worker thread (or process) to perform the operation. Don't send a reply to the RPC message, instead just put the client on a 'wait queue', and get on with serving other clients. When the worker thread completes, send the RPC reply to the original client. - Having the virStorageVolCreate() method return immediately, giving back the client app some kind of 'job id'. The client app can poll on another API virStorageVolJob() method to determine how far through the task has got. The implementation in the driver would have to spawn a worker thread to do the actual long operation. Possibly we can allow creation to be async or blocking by making use of the 'flags' field to virStorageVolCreate() method, eg VIR_STORAGE_ASYNC. If we make async behaviour optional, we still need some work in the daemon to avoid blocking all clients. This problem will also impact us when we add cloning of existing volumes. It already sort of hits us when saving & restoring VMs if they have large amounts of memory. So perhaps we need togo for the general solution of making the daemon threaded per client connection. The ASYNC flag may still be useful anyway to get the incremental progress feedback in the UI. 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 -=|

4 26

[Libvir] PATCH: Support NIC model selection for QEMU/KVM
by Jim Paris 31 Oct '07

31 Oct '07

Hi, Sometime between kvm-36 and kvm-46 I ran into problems with the default QEMU network card (ne2k-pci). Switching it fixed the problems, but libvirt doesn't support changing the NIC model. These patches add support for: <interface> <nic model="rtl8139"/> </interface> which becomes qemu -net nic,model=rtl8139,mac=... By default, no model is appended to the qemu command line, as before. Documentation update & some fixes are included too. -jim

3 11

[Libvir] read-only git mirror of libvirt CVS repository
by Jim Meyering 26 Oct '07

26 Oct '07

I've set up an automatically-sync'd git mirror of the libvirt.org's libvirt CVS repository. The mirror is updated approximately every 30 minutes. You can view the change-set summary via this URL: http://git.et.redhat.com/?p=libvirt.git You can get a copy of the repository with the following command: (this uses the efficient "git://" protocol, and is sort of analogous to CVS pserver, in that you get anonymous, read-only access) git clone git://et.redhat.com/libvirt That command creates a libvirt/ directory. It's not big, just 4.2MB for the .git/ repository (containing the entire history) and the usual 10MB of code, docs and .po files. Note, if you're new to "git", you typically run "git clone" only once, initially, and from then on, you "cd" into the directory and download/merge the latest sources via "git pull". But note that if you do development or otherwise modify a version-controlled file, your next "git pull" won't work if the pull would have to merge changes to one of the modified files.

5 8

[Libvir] Build error without Xen
by Jim Paris 26 Oct '07

26 Oct '07

Hi, The recent changes to src/xml.c breaks the build without xen: $ ./autogen.sh \ --prefix=/usr \ --mandir=\${prefix}/share/man \ --infodir=\${prefix}/share/info \ --sysconfdir=/etc \ --localstatedir=/var \ --without-xen $ make ... gcc -g -O2 -o .libs/virsh -Wall -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wextra -Wshadow -Wcast-align -Wwrite-strings -Waggregate-return -Wstrict-prototypes -Winline -Wredundant-decls -Wno-sign-compare -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fasynchronous-unwind-tables virsh-virsh.o virsh-console.o -Wall -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wextra -Wshadow -Wcast-align -Wwrite-strings -Waggregate-return -Wstrict-prototypes -Winline -Wredundant-decls -Wno-sign-compare -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fasynchronous-unwind-tables ./.libs/libvirt.so -lcurses -lreadline ./.libs/libvirt.so: undefined reference to `xenNbCpus' collect2: ld returned 1 exit status make[2]: *** [virsh] Error 1 make[2]: Leaving directory `/usr/local/src/libvirt/libvirt/src' -jim

3 4

[Libvir] problems using libvirt to mange "defined" domains.
by Evan Bigall 26 Oct '07

26 Oct '07

I'm having a problem using libvirt to manage "defined" domains (ie: domains for which it has XML, but are not running.) I have tried several debugging scenarios, but the simplest one is this. In a libvirt C program I define the following XML: char domxml[]="<domain type='xen' id='99'>" "<name>rhel5vm</name>" "<uuid>f948d7f4f36c4bfae8053bca535183b3</uuid>" "<os>" "<type>linux</type>" "<kernel>/var/lib/xen/boot/rhel5vm/vmlinuz-2.6.18-8.el5xen</kernel>" "<initrd>/var/lib/xen/boot/rhel5vm/initrd-2.6.18-8.el5xen.img</initrd>" "<root>/dev/xvda1</root>" "</os>" "<memory>512000</memory>" "<vcpu>1</vcpu>" "<on_poweroff>destroy</on_poweroff>" "<on_reboot>restart</on_reboot>" "<on_crash>restart</on_crash>" "<devices>" "<interface type='bridge'>" "<source bridge='xenbr0'/>" "<mac address='00:16:3e:09:ef:b0'/>" "<script path='vif-bridge'/>" "</interface>" "<disk type='block' device='disk'>" "<driver name='phy'/>" "<source dev='/dev/sda3'/>" "<target dev='xvda'/>" "</disk>" "<console tty='/dev/pts/2'/>" "</devices>" "</domain>"; (I've played with several values for the domain id). What I find is that when I use virDomainDefineXML() to define the domain, for some reason it drops, the "root" element from the "os" specification. Because of this the domain then crashes when I try to start it. I've also tried, using virsh to create the domain from an XML file, capture the XML with virDomainGetXMLDesc(), pause the C program, and then try to redefine the domain with the domain with the exact XML virDomainGetXMLDesc() gave me (after destroying the original of course), and I get the same behavior, it strips the root element from the OS specification. Here is the version information: [root@rhel5-xen tmp]# cat /etc/redhat-release Red Hat Enterprise Linux Server release 5 (Tikanga) [root@rhel5-xen tmp]# uname -a Linux rhel5-xen 2.6.18-8.1.8.el5xen #1 SMP Mon Jun 25 17:19:38 EDT 2007 x86_64 x86_64 x86_64 GNU/Linux [root@rhel5-xen tmp]# virsh version Compiled against library: libvir 0.3.1 Using library: libvir 0.3.1 Using API: Xen 3.0.1 Running hypervisor: Xen 3.0.0 I am using rhel5 "out of the box" with libvirt upgraded to: libvirt-0.3.1-1.x86_64.rpm libvirt-devel-0.3.1-1.x86_64.rpm libvirt-python-0.3.1-1.x86_64.rpm I tried using libvirt-0.3.2-1, but sample code segv'd in virConnectClose(). All I'm really trying to do is build a primitive interface to list domains (both running, and non-running), and start and stop them. I'm open to suggestions as to whether I have this misconfigured or if there would be a better version with which to do this. Thanks, Evan

2 1

Re: [Libvir] Creating a Domain
by Richard W.M. Jones 26 Oct '07

26 Oct '07

chetan saundankar wrote: > "the API should not be targetted to a single virtualization environment > though Xen is the current default...." > Does this mean that other virtualization environments say VMWare ESX > server management can also be done with future releases of Libvirt? If > yes then when do you expect to roll out that feature? That's certainly an aspiration. However there is no firm date for VMWare support at this time. Currently we have support for Xen, QEMU, KVM and OpenVZ. 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

1 0

[Libvir] Creating a Domain
by chetan saundankar 26 Oct '07

26 Oct '07

Hi all, I am new to Libvirt. I have few questions on how to create a guest domain using libvirt, 1. I want to create a guest and say install FC6 in it. Can it be done using "virDomainCreate" or "virDomainCreateLinux" calls? and specifying iso image in Domain description XML e.g. <disk type='file' device='cdrom'> <source file='/root/chelsea/fc6-x86.iso'/> <target dev='hdc'/> <readonly/> </disk> 2. In the Domain Description XML for Fully virtualized guests there is <uuid> tag so if the above mentioned method is used to create guests then is it the callers responsibility to provide a unique uuid? Thanks Chetan <http://libvirt.org/html/libvirt-libvirt.html#virDomainCreate>

2 1

[Libvir] Bash completions for virsh
by David Lutterkort 26 Oct '07

26 Oct '07

The attached file provides tab completion for virsh. To use them, just source the file in bash; after that, typing 'virsh <TAB>' should do something sensible (if you are on KVM, you also need to have VIRSH_DEFAULT_CONNECT_URI set, otherwise virsh will complain when trying to gather various info during completion. Could this be added to the libvirt CVS in some appropriate place ? The RPM should probably install it in /etc/bash_completion.d/ David

2 1

[Libvir] detect overflow in string-to-int conversion
by Jim Meyering 24 Oct '07

24 Oct '07

Hi, Not a big deal, but it's better not to accept a bogus "4294967297" and silently map it to "1". Don't accept an arbitrarily-long string of digits. * src/xml.c (parseNumber): Detect overflow. diff --git a/src/xml.c b/src/xml.c index 3e92040..5011dc2 100644 --- a/src/xml.c +++ b/src/xml.c @@ -1,7 +1,7 @@ /* * xml.c: XML based interfaces for the libvir library * - * Copyright (C) 2005 Red Hat, Inc. + * Copyright (C) 2005, 2007 Red Hat, Inc. * * See COPYING.LIB for the License of this software * @@ -77,7 +77,7 @@ skipSpaces(const char **str) { * * Parse a number * - * Returns the CPU number or -1 in case of error. @str will be + * Returns the unsigned number or -1 in case of error. @str will be * updated to skip the number. */ static int @@ -89,8 +89,11 @@ parseNumber(const char **str) { return(-1); while ((*cur >= '0') && (*cur <= '9')) { - ret = ret * 10 + (*cur - '0'); - cur++; + unsigned int c = *cur - '0'; + if (ret > INT_MAX / 10 || (ret == INT_MAX / 10 && c > INT_MAX % 10)) + return(-1); + ret = ret * 10 + c; + cur++; } *str = cur; return(ret);

2 1

[Libvir] virt-install : *** glibc detected *** /usr/bin/python: free(): invalid pointer *** ***
by suyash jape 24 Oct '07

24 Oct '07

Hi all I am getting the following output when i try to use virt-install [root@localhost]# virt-install *** glibc detected *** /usr/bin/python: free(): invalid pointer: 0x08bea0a0 *** ======= Backtrace: ========= /lib/i686/nosegneg/libc.so.6[0x2f89b1] /lib/i686/nosegneg/libc.so.6(cfree+0x90)[0x2fc060] /usr/lib/libvirt.so.0[0xb2885e] /usr/lib/libvirt.so.0[0xb2a07b] /usr/lib/libvirt.so.0[0xb019d3] /usr/lib/python2.5/site-packages/libvirtmod.so(libvirt_virConnectOpen+0x66)[0xf09ce6] . . . . b7d25000-b7f25000 r--p 00000000 fd:00 312403 /usr/lib/locale/locale-archive b7f25000-b7fa9000 rw-p b7f25000 00:00 0 b7fb4000-b7fb5000 rw-p b7fb4000 00:00 0 bff2a000-bff4a000 rw-p bff2a000 00:00 0 [stack] Aborted My package versions : [root@localhost ~]# rpm -qa|grep libvirt libvirt-0.3.3-1.fc7 libvirt-python-0.3.3-1.fc7 [root@localhost ~]# uname -a Linux localhost.localdomain 2.6.20-2936.fc7xen #1 SMP Fri Sep 21 12:07:35 EDT 2007 i686 i686 i386 GNU/Linux [root@localhost ~]# rpm -qa|grep xen xen-libs-3.1.0-6.fc7 xen-devel-3.1.0-6.fc7 xen-3.1.0-6.fc7 kernel-xen-2.6.20-2936.fc7 kernel-xen-devel-2.6.20-2936.fc7 I have attached the full back trace if anyone is interested Any suggestions ? Thanks Suyash

2 1

[Libvir] virt-install virt-install virt-install : *** glibc detected *** /usr/bin/python: free(): invalid pointer *** *** glibc detected *** /usr/bin/python: free(): invalid pointer: ******
by suyash jape 24 Oct '07

24 Oct '07

Hi I am getting the following output when i try to use virt-install [root@localhost]# virt-install *** glibc detected *** /usr/bin/python: free(): invalid pointer: 0x08bea0a0 *** ======= Backtrace: ========= /lib/i686/nosegneg/libc.so.6[0x2f89b1] /lib/i686/nosegneg/libc.so.6(cfree+0x90)[0x2fc060] /usr/lib/libvirt.so.0[0xb2885e] /usr/lib/libvirt.so.0[0xb2a07b] /usr/lib/libvirt.so.0[0xb019d3] /usr/lib/python2.5/site-packages/libvirtmod.so(libvirt_virConnectOpen+0x66)[0xf09ce6] . . . . b7d25000-b7f25000 r--p 00000000 fd:00 312403 /usr/lib/locale/locale-archive b7f25000-b7fa9000 rw-p b7f25000 00:00 0 b7fb4000-b7fb5000 rw-p b7fb4000 00:00 0 bff2a000-bff4a000 rw-p bff2a000 00:00 0 [stack] Aborted My package versions : [root@localhost ~]# rpm -qa|grep libvirt libvirt-0.3.3-1.fc7 libvirt-python-0.3.3-1.fc7 [root@localhost ~]# uname -a Linux localhost.localdomain 2.6.20-2936.fc7xen #1 SMP Fri Sep 21 12:07:35 EDT 2007 i686 i686 i386 GNU/Linux [root@localhost ~]# rpm -qa|grep xen xen-libs-3.1.0-6.fc7 xen-devel-3.1.0-6.fc7 xen-3.1.0-6.fc7 kernel-xen-2.6.20-2936.fc7 kernel-xen-devel-2.6.20-2936.fc7 I have attached the full back trace if anyone is interested Any suggestions ? Thanks Suyash

1 0

[Libvir] Re: Should we settle on one SSL implementation?
by Richard W.M. Jones 23 Oct '07

23 Oct '07

Bernardo Innocenti wrote: > I remember this topic being discussed some time ago, > but software is fluid and maybe it's time to respin > the topic. > > It would seem a worthwhile goal to unify SSL/TLS > implementations like we did for spell checkers. > Or, if it turns out to be too hard, at least it would > be nice to their pki files. I've asked whether we have a standard layout for /etc/pki before, but no one seems to know. > We're now shipping no less than 4 different implementations > of SSL: > > - openssl (OpenBSD's implementation) > - nss (Netscape's implementation) > - gnutls (LGPL implementation) > - puretls (Java implementation) Make that at least five - ocaml-ocamlnet has a pure-OCaml SSL impl. I'm sure Perl & Python probably have their own too. > But which one should replace the others? When we implemented encryption in libvirt, we chose gnutls because it has excellent examples which allow you to actually write code to use it in a short period of time. The others have (or we perceived them to have) hideous, confusing or undocumented APIs. For a short while I documented the certificate management code in terms of the OpenSSL command line tools. But after I found out about 'certtool' (part of GnuTLS), I was able to rewrite that documentation and make it considerably simpler[1]. 'certtool' is a lot more sane than the OpenSSL stuff. Nevertheless, I don't think you're going to get rid of the competing SSL libraries. Rewriting code to use a different API is a lot of make-work that no one wants to do, and doesn't contribute much benefit to anyone. Rich. [1] http://libvirt.org/remote.html#Remote_certificates -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903

3 2

[Libvir] Small cleanup patch for Xen NUMA
by Daniel Veillard 22 Oct '07

22 Oct '07

xenHypervisorNodeGetCellsFreeMemory was calling xend to find the number of cells on a node and keeping the information thereafter in a static variable. This patch just move the lookup code in the xen_unified driver, using the unified call (and hence the hypervisor instead of xend rpc). Provides the same for CPUs. Also helps centralizing those lookup in case Xen supports dynamic CPUs or cells in the future. 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/

1 0

[Libvir] PATCH: 0/4 Implement CDROM media change for QEMU/KVM driver
by Daniel P. Berrange 22 Oct '07

22 Oct '07

This series of patches provides CDROM media change for QEMU/KVM driver. It builds on the previous patch, incorporating the feedback everyone gave. I split the refactoring out from the main new feature patch hence the series of 4... 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 -=|

2 5

[Libvir] save and restore guest
by Farkas Levente 22 Oct '07

22 Oct '07

hi, if i use xen with xendomain it's possible to save and restore guest state. if i use libvirt it's not working (at least by default with kvm). i mean if i stop or restart libvirtd all guests a stopped and even if i restart libvirtd i've to start all guests manually. imho this's a very essential feature. what is the reason this not working with libvirtd?: - this feature is missing from libvirtd? or - this feature is not turned on by default? or - this feature is missing from kvm/qemu? or something else? thanks in advance. -- Levente "Si vis pacem para bellum!"

3 10

[Libvir] Proposal for the storage API (for discussion only)
by Richard W.M. Jones 22 Oct '07

22 Oct '07

This is an outline for the storage API, for discussion only. It is mostly unimplemented, but presented as a kind of "literate patch", so you can read the API calls and how they could be implemented. I've tried to follow as far as possible operations which are needed in order to make virt-install / virt-manager work in the remote case, and also to support discovery and creation of partitions / LVs / iSCSI LUNs. The new API calls are: virStorageFileLocations - returns a list of locations which can be used for creating file-backed guests virStorageFileStat virStorageFileStatVFS virStorageCreateFile - for creating file-backed guest storage virStorageListGroups virStorageCreateVolume - for discovering and creating partitions, LVs, LUNs, &c. 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

6 17

[Libvir] Concepts in storage management
by Daniel P. Berrange 22 Oct '07

22 Oct '07

So we've had many email threads on the subject of storage, but none have resulted in a satisfactory way forward to implementing any storage mgmt apis. Part of the problem I think is that we've not tried to understand all the various concepts / technologies which are available & how they relate to each other. This mail attempts to outline all the different technologies. There's a short list of API operations, but I don't want to particularly get into API details until we have a good undersatnding of the concepts. First and foremost I don't believe it is acceptable to say we're only going to allow one kind of storage. Storage is the key piece of infrastructure for any serious network, and we have to be able to adapt to deployment scenarios that present themselves. Second, there is clearly a huge number of storage technologies here and there's no way we'll implement support for all of them in one go. So we need to prioritize getting the conceptual model correct, to allow us to incrementally support new types of storage backend. Taxonomy of storage types ========================= | +- Block | | | +- Disk | | | | | +- Direct attached | | | | | | | +- IDE/ATA disk | | | +- SCSI disk | | | +- FibreChannel disk | | | +- USB disk/flash | | | +- FireWire disk/flash | | | | | +- Remote attached | | | | | +- iSCSI disk | | +- GNBD disk | | | +- Partition | | | +- Virtual | | | +- Direct attached | | | | | +- LVM | | +- ZFS | | | +- Remote attached | | | +- Cluster LVM | +- FileSystem | | | +- Directed attached | | | | | +- ext2/3/4 | | +- xfs | | +- ZFS | | | +- Remote attached | | | +- NFS | +- GFS | +- OCFS2 | +- Directory | +- File | +- Raw allocated +- Raw sparse +- QCow2 +- VMDK Storage attributes ================== - Local vs network (ext3 vs NFS, SCSI vs iSCSI) - Private vs shared (IDE vs FibreChannel) - Pool vs volume (LVM VG vs LV, Directory vs File, Disk vs Partition) - Container vs guest (OpenVZ vs Xen) - Attributes - Compressed - Encrypted - Auto-extend - Snapshots - RO - RW - Partition table - MBR - GPT - UUID - 16 hex digits - Unique string - SCSI WWID (world wide ID) - Local Path(s) (/dev/sda, /var/lib/xen/images/foo.img) - Server Hostname - Server Identifier (export path/target) - MAC security label (SELinux) - Redundancy - Mirrored - Striped - Multipath - Pool operation - RO - RW Nesting hierarchy ================= Many possibilities... - 1 x Host -> N x iSCSI target -> N x LUN -> N x Partition - N x Disk/Partition -> 1 x LVM VG -> B x LVM LV - 1 x Filesystem -> N x directory -> N x file - 1 x File -> 1 x Block (loopback) Application users ================= - virt-manager / virt-install - Enumerate available pools - Allocate volume from pool - Create guest with volume - virt-clone - Copy disks - Snapshot disks - virt-df - Filesystem usage - pygrub - Extract kernel/initrd from filesystem - virt-factory - Manage storage pools - Pre-migration sanity checks - virt-backup - Snapshot disks - virt-p2v - Snapshot disks Storage representation ====================== Two core concepts - Volume - a chunk of storage - assignable to a guest - assignable to a pool - optionally part of a pool - Pool - a chunk of storage - contains free space - allocate to provide volumes - compromised of volumes Recursive! n x Volume -> Pool -> n x Volume Nesting to many levels... Do we need an explicit Filesystem concept ? Operations ========== Limited set of operations to perform - List host volumes (physical attached devices) - List pools (logical volume groups, partitioned devs, filesystems) - List pool volumes (dev partitions, LVM logical volumes, files) - Define pool (eg create directory, or define iSCSI target) - Undefine pool (delete directory, undefine iSCSI config - Activate pool (mount NFS volume, login to iSCSI target) - Deactivate pool (unmount volume, logout of iSCSI) - Dump pool XML (get all the metadata) - Lookup by path - Lookup by UUID - Lookup by name - Create volume (create a file, allocate a LVM LV, etc) - Destroy volume (delete a file, deallocate a LVM LV) - Resize volume (grow or shrink volume) - Copy volume (copy data between volumes) - Snapshot volume (snapshot a volume) - Dump volume XML (get all the metadata) - Lookup by path - Lookup by UUID - Lookup by name http://www.redhat.com/archives/libvir-list/2007-February/msg00010.html http://www.redhat.com/archives/libvir-list/2007-September/msg00119.html Do we also need some explicit Filesystem APIs ? XML description =============== The horrible recursiveness & specific attributes are all in the XML description for different storage pool / volume types. This is where we define things like what physical volume are in a volume group, iSCSI server / target names, login details, etc, etc XXX fill in the hard stuff for metadata description here Implementation backends ======================= - FileSystem/Directory/File - POSIX APIs - LVM - LVM tools, or libLVM - Disk/partitions - sysfs / parted - iSCSI - sysfs / iscsi utils - ZFS - ZFS tools Implementation strategy ======================= Should prioritize implementation according to immediate application needs Initial goal to support remote guest creation on par with current capabilities: - Directory + allocateing raw sparse files - Enumerate existing disks, partitions & LVM volumes Further work: - Allocating LVM volumes - Defining LVM volume groups - Partitioning disks - Mounting networked filesystems - Accessing iSCSI volumes - Copying existing volumes - Snapshotting volumes - Cluster aware filesystems (GFS) - Various file formats (QCow, VMDK, etc) 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 -=|

4 13

Re: [Libvir] Problem to compile virt-manager in debian etch
by Richard W.M. Jones 19 Oct '07

19 Oct '07

Marco Sinhoreli wrote: > The configure script was found, but the Makefile hasn't been created. Need to see the full messages. 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

4 8

[Libvir] [PATCH] fix negative value handling of virConfParseLong()
by Tatsuro Enokura 19 Oct '07

19 Oct '07

Hi, I found a bug about negative value at virConfParseLong() in conf.c. This patch fixes it. Signed-off-by: Tatsuro Enokura <fj7716hz(a)aa.jp.fujitsu.com> Thanks, Tatsuro Enokura. -------------------------------------------------------------------------- Index: libvirt/src/conf.c =================================================================== RCS file: /data/cvs/libvirt/src/conf.c,v retrieving revision 1.11 diff -u -p -r1.11 conf.c --- libvirt/src/conf.c 4 Jul 2007 09:16:23 -0000 1.11 +++ libvirt/src/conf.c 19 Oct 2007 08:37:36 -0000 @@ -345,6 +345,8 @@ virConfParseLong(virConfParserCtxtPtr ct l = l * 10 + (CUR - '0'); NEXT; } + if (neg) + l *= -1; *val = l; return(0); } --------------------------------------------------------------------------

3 2

[Libvir] Opening KVM guest in xterm rather than vnc
by David Mueller 19 Oct '07

19 Oct '07

I'm trying to setup my virtual machines to display in an xterm window rather than a VNC window. The guests and host are Fedora 7; the guest only needs to run in a console mode (no X11). I see a bit on http://libvirt.org/format.html about using a console tag instead of graphics in my XML, but I can't figure out how to connect to that. With our older Xen on Fedora Core 5 setup, we used the following command to create a guest and it worked great; I'm trying to approximate something similar with libvirt/KVM on Fedora 7: xterm -e "/usr/sbin/xm create -c guest.xen" A notable advantage of using an xterm over VNC is that we can resize the window; with VNC as far as I've been able to see, we've been stuck with the default 80x24 window. We also can't copy and paste text from the VNC window to other applications. Any suggestions would be appreciated. I am currently using libvirt-0.3.2-1.fc7; if this is something that we'll have to wait for a newer version that will be in Fedora 8, that's okay. - David

3 2

[Libvir] memory error in another test
by Jim Meyering 19 Oct '07

19 Oct '07

Running tests under valgrind exposed this: (line numbers are slightly off, due to local changes) ==27876== ERROR SUMMARY: 32 errors from 2 contexts (suppressed: 5 from 2) ==27876== ==27876== 16 errors in context 1 of 2: ==27876== Conditional jump or move depends on uninitialised value(s) ==27876== at 0x41BA18: qemudBuildCommandLine (qemu_conf.c:1871) ==27876== by 0x406764: testCompareXMLToArgvFiles (qemuxml2argvtest.c:46) ==27876== by 0x4069DA: testCompareXMLToArgvHelper (qemuxml2argvtest.c:97) ==27876== by 0x406D60: virtTestRun (testutils.c:69) ==27876== by 0x406A46: main (qemuxml2argvtest.c:114) ==27876== ==27876== 16 errors in context 2 of 2: ==27876== Conditional jump or move depends on uninitialised value(s) ==27876== at 0x41AA45: qemudBuildCommandLine (qemu_conf.c:1606) ==27876== by 0x406764: testCompareXMLToArgvFiles (qemuxml2argvtest.c:46) ==27876== by 0x4069DA: testCompareXMLToArgvHelper (qemuxml2argvtest.c:97) ==27876== by 0x406D60: virtTestRun (testutils.c:69) ==27876== by 0x406A46: main (qemuxml2argvtest.c:114) Both of those are due to uses of uninitialized vm->migrateFrom[0]. Here's the fix: Avoid memory error in a test program. * tests/qemuxml2argvtest.c (testCompareXMLToArgvFiles): Initialize vm.migrateFrom[0], to avoid "read-uninitialized" error from within qemudBuildCommandLine. Index: tests/qemuxml2argvtest.c =================================================================== RCS file: /data/cvs/libvirt/tests/qemuxml2argvtest.c,v retrieving revision 1.5 diff -u -p -r1.5 qemuxml2argvtest.c --- tests/qemuxml2argvtest.c 21 Sep 2007 21:20:32 -0000 1.5 +++ tests/qemuxml2argvtest.c 17 Oct 2007 13:42:15 -0000 @@ -40,6 +40,7 @@ static int testCompareXMLToArgvFiles(con vm.qemuVersion = 0 * 1000 * 100 + (8 * 1000) + 1; vm.qemuCmdFlags = QEMUD_CMD_FLAG_VNC_COLON | QEMUD_CMD_FLAG_NO_REBOOT; + vm.migrateFrom[0] = '\0'; vmdef->vncActivePort = vmdef->vncPort;

2 2

[Libvir] avoid reading uninitialized memory in test program
by Jim Meyering 19 Oct '07

19 Oct '07

valgrind complained about the printf in conftest.c. Here's the fix: * src/conf.c (__virConfWriteMem): Fix typos in comment. * tests/conftest.c (main): Use fwrite, not printf, since the result buffer is not NUL-terminated. =================================================================== RCS file: /data/cvs/libvirt/src/conf.c,v retrieving revision 1.11 diff -u -p -r1.11 conf.c --- src/conf.c 4 Jul 2007 09:16:23 -0000 1.11 +++ src/conf.c 17 Oct 2007 11:31:54 -0000 @@ -1,7 +1,7 @@ /** * conf.c: parser for a subset of the Python encoded Xen configuration files * - * Copyright (C) 2006 Red Hat, Inc. + * Copyright (C) 2006, 2007 Red Hat, Inc. * * See COPYING.LIB for the License of this software * @@ -916,7 +916,7 @@ error: /** * __virConfWriteMem: * @memory: pointer to the memory to store the config file - * @len: pointer to the lenght in byte of the store, on output the size + * @len: pointer to the length in bytes of the store, on output the size * @conf: the conf * * Writes a configuration file back to a memory area. @len is an IN/OUT =================================================================== RCS file: /data/cvs/libvirt/tests/conftest.c,v retrieving revision 1.1 diff -u -p -r1.1 conftest.c --- tests/conftest.c 29 Aug 2006 22:27:07 -0000 1.1 +++ tests/conftest.c 17 Oct 2007 11:31:54 -0000 @@ -24,7 +24,10 @@ int main(int argc, char **argv) { fprintf(stderr, "Failed to serialize %s back\n", argv[1]); exit(3); } - printf("%s", buffer); virConfFree(conf); + if (fwrite(buffer, len, 1, stdout) != len) { + fprintf(stderr, "Write failed\n"); + exit(1); + } exit(0); }

2 2

[Libvir] PATCH: RFC supporting SASL authentication
by Daniel P. Berrange 18 Oct '07

18 Oct '07

History: we currently provide two TCP sockets, one clear text, no auth, the other TLS with x509 client certificate verification for auth. We also provide a UNIX domain socket relying on file perms to restrict access. I have previously provided a policykit patch for the latter allowing admin defined auth policy for UNIX socket access. The PolicyKit patch was flawed in that it did not provide a way for a client app to determine whether the UNIX socket needed PolicyKit auth ahead of time or not. This required apps to make assumptions prior to connecting which is not really viable. This mail is working towards a more flexible authentication solution, and goes straight for the big picture by integrating SASL authentication. This gives us integration with Kerberos (GSSAPI) and PAM and whatever the hell else SAS supports[1]. The critical decision in all this is the wire protocol & how to adapt it to slot in authentication in a way that is compatible with existing clients. As it stands the decision to use clear data vs TLS on the wire is based on the socket the client connects to - we do a TLS handshake at the very start. We need to be able to support SASL on all sockets, TCP, TLS & UNIX since they can all benefit from stuff like Kerberos. So I decided we need to integrate at the RPC layer for this to work. The general protocol picture ---------------------------- It helps to look at qemud/remote_protocol.x when reading this next ... Every API basically has an RPC call & reply pair. The reply messages have a status field, either 'REMOTE_OK' or 'REMOTE_ERROR'. In the former case the normal API return values follow on the wire. In the latter case a virErrroPtr object is serialized on the wire. For this patch I decided to add a 3rd code, REMOTE_AUTH. If an application tries to make an RPC call on a socket requiring authentication, and has not yet authenticated the server will return REMOTE_AUTH code. It then also returns an int (remote_auth_type) specifying the authentication method to use. I have defined two: enum remote_auth_type { REMOTE_AUTH_NONE = 0, REMOTE_AUTH_SASL = 1 }; With plans to add REMOTE_AUTH_POLKIT in a future patch. A legacy client getting back REMOTE_AUTH code will just quit the connection attempt since they don't support authentication. If the admin so desires they can still provide the TLS socket in a non-authenticated mode and only turn on SASL for the TCP socket. So the decision about whether to enable legacy clients is admin controlled. This is the best we can do. A new client getting back REMOTE_AUTH code will then read the remote_auth_type off the wire. If the requested type is one that the client supports then it can begin the authentication process, otherwise we virRaiseError and stop connecting. The SASL specific picture ------------------------- For the SASL auth the process involves a multi-phase handshake looking something like: client server 1. -> ask for mechanism list -> new ctx 2. new ctx <- list of mechanisms <- 3. start auth -> initial auth data -> start auth 4. step auth <- reply auth data <- 5. -> step auth data -> step auth goto 4. <- reply auth data <- Authentication can complete at step 4 in this process, or steps 4 & 5 can repeat an arbitrary number of times. So, to implement this if it neccessary to define 3 new RPC calls internal to the remote driver/daemon (aka not exposed to public API like the rest of the RPC calls). These are: REMOTE_PROC_AUTH_SASL_INIT = 66, REMOTE_PROC_AUTH_SASL_START = 67, REMOTE_PROC_AUTH_SASL_STEP = 68 These are basically just punting back & forth the data going in & out of the appropriate SASL apis. sasl_{server,client}_{new,start,step} See the man pages for more info. So on the server end, if a socket is configured to require SASL auth, the server will reject all RPC calls *except* for those three above with the REMOTE_AUTH code. Once SASL auth has completed, it will allow all the normal RPC calls. The effect is basically that the client is not able to call virConnectOpen & friends until auth has completed. On the client end, the fun is in the 'call' method of remote_internal.c. This has been split in two. The original method is now 'onecall', and there is a thin wrapper named 'call'. 'call' simply invokves onecall, and if it gets back a REMOTE_AUTH code, will do the SASL handshake & then re-run the original call. So again the effect is basically that the first virConnectOpen will cause the auth handshake to be performed. The SASL implementation details ------------------------------- This is the bare minimum SASL integration. I have not attempted to hook up any callbacks for gathering credentials. This basically means that the only SASL mechanism which works is Kerberos GSSAPI - its credentials are fetched out-of-band & so don't require callbacks. We do need to consider callbacks later so we can do username/password auth, and all the various other methods SASL has. As well as authentication, some SASL mechanisms provide a way to negotiate a data encryption layer for the subsequent session. GSSAPI is the only commonly used mechanism which supports this. I have not implemented this yet though. What we would do though is to enable this capability on the the plain TCP socket only. This would make the TCP socket truely secure, and avoid any extra overhead on the TLS socket or UNIX domain socket. I have set the wire packet size for the SASL negotiation to 8192 bytes at a time. This has been sufficient so far, but I need to validate this before we commit, because this will be wire ABI sensitive. Or I could change the XDR spec to be variable length. Anyway needs re-visiting This only deals with authentication. I have not attempted any authoriztion controls. So anyone who has a valid kerberos principle can connect to the server. We clearly need a local group list as we do for the x509 client certificates. Ultimately we could try LDAP lookups & other intersting suggestions. The SASL stuff is detected in configure & enabled/disabled as appropriate. I need to add extra config file params though to let the sysadmin control what socket uses what auth mechanism. The setup / usage details ------------------------- As I said, I only used GSSAPI so far. To use this all your clients need to be able to kinit & get a ticket. For testing I have setup my own personal Kerberos server using Fedora 7 & FreeIPA (http://freeipa.org/) Each libvirt server needs to be issued with a Kerberos service principle. I am using the word 'libvirt' as the service name. The service principle must match the FQDN of the server host. So on your Kerberos server you can issue a service principle with kadmin.local > addprinc libvirt/cherry.virt.boston.redhat.com(a)VIRT.BOSTON.REDHAT.COM > ktadd -k /tmp/cherry-libvirt.tab libvirt/cherry.virt.boston.redhat.com(a)VIRT.BOSTON.REDHAT.COM > quit Then copy the /tmp/cherry-libvirt.tab file to /etc/libvirt/krb5.tab on the server in question. (Change the hostnames & REALM as needed of course). If you want to change the GSSAPI mechanism, the settings are in the file /etc/sasl2/libvirt.conf. Though again only GSSAPI works so far. If you edit the /etc/libvirt/libvirtd.conf file you can enable listen_tcp=1 and run run libvirtd --listen. >From the client machine it should now be possible to do $ kinit berrange(a)VIRT.BOSTON.REDHAT.COM $ virsh --connect xen+tcp://cherry.virt.boston.redhat.com/ You probably screwed something up though along the way because Kerberos is nasty like that. If you use --verbose with libvirtd it'll show details of any errors during authentication. On the client end you can add in a param on the connect URI of ?debug=stderr and it'll print some info about the auth process to stderr. Check that it shows 'GSSAPI' as a valid mechanism. If it doesn't, then your server is not configured as it should be - check keytab file - check you have cyrus-sasl-gssapi RPM. If that's ok, then check 'klist' on the client - if the first phase of chatter between the client & the KDC worked you should see the principle of the server cached on the client. If you don't, then check the KDC logs in /var/log/krb5kdc.log Kerberos/GSSAPI error reporting sucks really bad. That said, I'm sure I'm missing something, because the errors I get out of SASL are even worse than normal. BTW, you can see various 'XXX' in my patch. Basically all of them need to be addressed before I'd consider this patch suitable to merge. configure.in | 39 +++ include/libvirt/virterror.h | 1 libvirt.spec.in | 3 qemud/Makefile.am | 21 +- qemud/internal.h | 8 qemud/libvirtd.init.in | 3 qemud/libvirtd.sysconf | 3 qemud/qemud.c | 29 ++ qemud/remote.c | 370 ++++++++++++++++++++++++++++++++++-- qemud/remote_dispatch_localvars.h | 5 qemud/remote_dispatch_proc_switch.h | 24 ++ qemud/remote_dispatch_prototypes.h | 3 qemud/remote_protocol.c | 164 +++++++++++++++ qemud/remote_protocol.h | 59 +++++ qemud/remote_protocol.x | 53 ++++- src/Makefile.am | 3 src/remote_internal.c | 307 +++++++++++++++++++++++++++++ src/virsh.c | 4 src/virterror.c | 6 tests/Makefile.am | 2 20 files changed, 1073 insertions(+), 34 deletions(-) Regards, Dan. [1] Not entirely true. Some auth methods require credentials to be fetched from the user, so we can only support methods for which we have callbacks. This patch ignores the callback question, so only support GSSAPI where the credentials are fetched out-of-band. This can be addressed later. -- |=- 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 -=|

2 3

Re: [Libvir] Problem to compile virt-manager in debian etch
by Richard W.M. Jones 18 Oct '07

18 Oct '07

Marco Sinhoreli wrote: > The autogen.sh output: > > ./autogen.sh > libtoolize: `config.guess' exists: use `--force' to overwrite > libtoolize: `config.sub' exists: use `--force' to overwrite > libtoolize: `ltmain.sh' exists: use `--force' to overwrite > hecking for a BSD-compatible install... /usr/bin/install -c > checking whether build environment is sane... yes > checking for a thread-safe mkdir -p... /bin/mkdir -p > checking for gawk... no > checking for mawk... mawk > [...] > > The remaining seems okay. So looks like it's working then? Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903

2 1

[Libvir] storage API and ZFS
by John Levon 18 Oct '07

18 Oct '07

Accidentally deleted your reply Richard, sorry. ZFS 'pools' are aggregates composed of some number of real devices. LVM confuses me so I don't know what they map on to, but the basic idea is that you can carve filesystems out of such pools at will. You can also carve out 'volumes' - these appear as a disk device in /dev/zvol/dsk/poolname/volumename It's the latter that you use in Xen to hold domU root filesystems (or you can use a normal file on whatever file system, or a real device, as desired). What might be tricky is anything that claims to return "space left", depending exactly on what you want it to mean. But (I think) certain LVM setups have similar issues. regards john

2 1

[Libvir] Is it possible to add an interface to intercept the migration process?
by Meng Ran 18 Oct '07

18 Oct '07

Hi All, I'm thinking about if it possible to add an interface to let user specified action to happen on destination during the migration, this should be useful for migrating things that have different paths on source and destination. Allowing specified action(callback) to happen at a time point, e.g., after the config file is transfered and before starting the vm, can bring in a lot of flexibilities considering the migration of devices which are shared but have different paths/views. Giving the dest a chance to recognize these devices and update the config, and then start the vm probably is helpful there. Comment? Thanks, Jack

5 6

[Libvir] CPU pinning of domains at creation time
by Daniel Veillard 18 Oct '07

18 Oct '07

There are a few things I gathered on this issue. This affects NUMA setups, where basically if a domain must be placed on a given cell it is not good to let the hypervisor place it first with its own heuristics and then later migrate it to a different set of CPU, but better to instruct the hypervisor to start said domain on the given set. - For Xen it is possible to instruct the hypervisor by passing (cpus '2,3') in the SExpr where the argument is a list of the physical processors allowed - For KVM I think the standard way would be to select the cpuset using sched_setaffinity() between the fork of the current process and the exec of the qemu process - there is no need (from a NUMA perspective) to do fine grained allocation at that point, as long as the domain can be restricted to a given cell at startup, then if needed virDomainPinVcpu() can be used later to do more precise pinning in order to try to optimize placement - to be able to instruct the hypervisor at creation time adding the information in the domain XML description looks the more natural way (another option would be to force to use virDomainDefineXML, add a call using the resulting virDomainPtr to define the set, and then virDomainCreate would be used to do the actual start) + the good point of having this embedded in the XML is that we still have all informations about the domain settings in the XML, if we want to restart it later + the bad point is that we need to fetch and carry this extra information when doing XML dumps to not loose it for example when manipulating the domain to add or remove devices - extracting a cpuset can still be an heavy operation, for example if using xend on need one RPC per vcpu in the domain, the cpuset being constructed by OR'ing logically all cpumaps used by the vcpus of the domain (though in most case this will be the full map after the first CPU and can be stopped immediately) - for the mapping at the XML level I suggest to use a simple extension to the <vcpu>n</vcpu> and extend it to <vcpu cpuset='2,3'>n</vcpu> with a limited syntax which is just the comma separated list of allowed CPU numbers (if the code actually detects such a cpuset is in effect i.e. in general this won't be added). Internally implementing this should not be too hard, I would probably refactor some of the existing parsing code, provide functions to get the cpuset and the number of physical processors. Does this sounds okay ? 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/

6 13

[Libvir] Problem to compile virt-manager in debian etch
by Marco Sinhoreli 18 Oct '07

18 Oct '07

Hello all, I have a problem to compile the virt-manager in a Debian etch (64 bit version). I got the virt-manager source from mercurial repository. Bellow the output autogen.sh command: ./autogen.sh libtoolize: `config.guess' exists: use `--force' to overwrite libtoolize: `config.sub' exists: use `--force' to overwrite libtoolize: `ltmain.sh' exists: use `--force' to overwrite configure.ac:7: required file `./config.rpath' not found man/Makefile.am:6: `%'-style pattern rules are a GNU make extension pixmaps/Makefile.am:3: wildcard $(srcdir: non-POSIX variable name pixmaps/Makefile.am:3: (probably a GNU make extension) src/Makefile.am:15: wildcard $(srcdir: non-POSIX variable name src/Makefile.am:15: (probably a GNU make extension) src/Makefile.am:35: `%'-style pattern rules are a GNU make extension src/Makefile.am:38: `%'-style pattern rules are a GNU make extension src/Makefile.am:41: `%'-style pattern rules are a GNU make extension src/Makefile.am:44: `%'-style pattern rules are a GNU make extension src/Makefile.am:26: variable `schema_SOURCES' is defined but no program or src/Makefile.am:26: library has `schema' as canonic name (possible typo) src/Makefile.am:11: variable `libexec_SOURCES' is defined but no program or src/Makefile.am:11: library has `libexec' as canonic name (possible typo) src/Makefile.am:4: variable `bin_SOURCES' is defined but no program or src/Makefile.am:4: library has `bin' as canonic name (possible typo) src/Makefile.am:18: variable `desktop_SOURCES' is defined but no program or src/Makefile.am:18: library has `desktop' as canonic name (possible typo) src/Makefile.am:8: variable `python_SOURCES' is defined but no program or src/Makefile.am:8: library has `python' as canonic name (possible typo) src/Makefile.am:22: variable `dbus_SOURCES' is defined but no program or src/Makefile.am:22: library has `dbus' as canonic name (possible typo) src/graphWidgets/Makefile.am:5: `:='-style assignments are not portable src/graphWidgets/Makefile.am:5: shell pkg-config --variable=codegendir pygtk-2.0: non-POSIX variable name src/graphWidgets/Makefile.am:5: (probably a GNU make extension) src/graphWidgets/Makefile.am:6: `:='-style assignments are not portable src/graphWidgets/Makefile.am:6: shell pkg-config --variable=defsdir pygtk-2.0: non-POSIX variable name src/graphWidgets/Makefile.am:6: (probably a GNU make extension) src/virtManager/Makefile.am:3: wildcard $(srcdir: non-POSIX variable name src/virtManager/Makefile.am:3: (probably a GNU make extension) src/virtManager/Makefile.am:7: python_DATA:$(srcdir: non-POSIX variable name src/virtManager/Makefile.am:15: `%'-style pattern rules are a GNU make extension Any idea? regards. -- Marco Sinhoreli

2 4

[Libvir] PATCH: Remote protocol receive+dispatch cleanup
by Daniel P. Berrange 18 Oct '07

18 Oct '07

Dating the from time when we had both the QEMU & generic remote protocol there are tiny qemud/protocol.{x,c,h} files basically just containing one struct for the packet header. This is more or less duplicated in the remote protocol & with a few small tweaks can simplify this code. So the attached patch removes the protocol.{x,c,h} files. The qemud.c file in the 'receive header' branch now merely reads a single 4 byte unsigned int to discover the packet length. The rest of the packet is dealt with in the 'receive payload' branch. It immediately dispatches to the remote program. There is no wire format change here - shouuld just be code cleanup a/qemud/protocol.c | 17 -------------- a/qemud/protocol.h | 39 -------------------------------- a/qemud/protocol.x | 40 --------------------------------- qemud/Makefile.am | 5 ---- qemud/internal.h | 1 qemud/qemud.c | 57 +++++++++++++++--------------------------------- qemud/remote.c | 2 - qemud/remote_protocol.h | 1 qemud/remote_protocol.x | 3 ++ src/Makefile.am | 1 10 files changed, 24 insertions(+), 142 deletions(-) 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 -=|

2 1

[Libvir] BuildRequires check
by Jim Meyering 17 Oct '07

17 Oct '07

Hi, I tried to configure libvirt from cvs on a just-built rawhide system and it failed like this, since I hadn't installed the "check" package, which defines PKG_CHECK_EXISTS: checking for init script flavor... redhat checking for iptables... /sbin/iptables ./configure: line 12187: syntax error near unexpected token `libxml-2.0,LIBXML_FOUND=yes' ./configure: line 12187: ` PKG_CHECK_EXISTS(libxml-2.0,LIBXML_FOUND=yes)' Here's a fix: 2007-10-17 Jim Meyering <meyering(a)redhat.com> * libvirt.spec.in (BuildRequires): Add "check". Index: libvirt.spec.in =================================================================== RCS file: /data/cvs/libvirt/libvirt.spec.in,v retrieving revision 1.65 diff -u -p -r1.65 libvirt.spec.in --- libvirt.spec.in 12 Oct 2007 19:54:15 -0000 1.65 +++ libvirt.spec.in 17 Oct 2007 10:03:22 -0000 @@ -16,6 +16,7 @@ Requires: ncurses Requires: dnsmasq Requires: bridge-utils Requires: iptables +BuildRequires: check BuildRequires: xen-devel BuildRequires: libxml2-devel BuildRequires: readline-devel

2 2

[Libvir] "make check" requires qemu
by Jim Meyering 17 Oct '07

17 Oct '07

So perhaps libvirt should BuildRequire qemu, too? When I ran "make check" on a system without qemu, I got lots of failures: ... QEMU XML-2-ARGV Misc ACPI ... FAILED libvir: QEMU error : Cannot find QEMU binary /usr/bin/qemu: No such file or directory QEMU XML-2-ARGV Misc No Reboot ... FAILED libvir: QEMU error : Cannot find QEMU binary /usr/bin/qemu: No such file or directory QEMU XML-2-ARGV Net User ... FAILED FAIL: qemuxml2argvtest Here's a patch: 2007-10-17 Jim Meyering <meyering(a)redhat.com> * libvirt.spec.in (BuildRequires): Add "qemu". Index: libvirt.spec.in =================================================================== RCS file: /data/cvs/libvirt/libvirt.spec.in,v retrieving revision 1.65 diff -u -p -r1.65 libvirt.spec.in --- libvirt.spec.in 12 Oct 2007 19:54:15 -0000 1.65 +++ libvirt.spec.in 17 Oct 2007 10:11:33 -0000 @@ -25,6 +25,7 @@ BuildRequires: gnutls-devel BuildRequires: avahi-devel BuildRequires: dnsmasq BuildRequires: bridge-utils +BuildRequires: qemu Obsoletes: libvir ExclusiveArch: i386 x86_64 ia64

2 1

[Libvir] sexpr_get: add __printf__ attribute
by Jim Meyering 17 Oct '07

17 Oct '07

I noticed sexpr_get takes a printf-style format, yet it is declared with no printf attribute. Here's the fix: 2007-10-17 Jim Meyering <meyering(a)redhat.com> * src/xend_internal.c (sexpr_get): Declare with gcc's printf attribute. Index: src/xend_internal.c =================================================================== RCS file: /data/cvs/libvirt/src/xend_internal.c,v retrieving revision 1.148 diff -u -p -r1.148 xend_internal.c --- src/xend_internal.c 15 Oct 2007 21:38:56 -0000 1.148 +++ src/xend_internal.c 17 Oct 2007 08:29:26 -0000 @@ -692,6 +692,10 @@ xend_op(virConnectPtr xend, const char * */ static struct sexpr * sexpr_get(virConnectPtr xend, const char *fmt, ...) + __attribute__ ((__format__ (__printf__, 2, 3))); + +static struct sexpr * +sexpr_get(virConnectPtr xend, const char *fmt, ...) { char buffer[4096]; char path[1024];

2 2

[Libvir] FYI: bug in remote code
by Mark Johnson 16 Oct '07

16 Oct '07

I ran into a bug in the remote code... I was doing # virsh -c xen_tcp://<ip_addr>/ It you don't have qemu compiled in, you will hang in in libvirtd in do_open() res = virNetworkDriverTab[i]->open (ret, name, flags); when trying to open the remote network driver. Usually qemu returns success and you fall out of the loop before you call this (which is why you won't see it with qemu support built in). You hang in libvirtd trying to read from the libvirtd PF_UNIX socket. You read from the socket because you hit this code path in doRemoteOpen() if (!uri->server && !transport_str) { if (flags & VIR_DRV_OPEN_REMOTE_UNIX) { transport = trans_unix; No idea what it should be doing? :-) I reproduced it on todays CVS bits on FC7 by commenting out qemu's network register.. int qemudRegister(void) { virRegisterDriver(&qemuDriver); /* virRegisterNetworkDriver(&qemuNetworkDriver); */ virRegisterStateDriver(&qemuStateDriver); return 0; } MRJ

2 4

[Libvir] [for discussion only] virDomainBlockPeek preliminary implementation
by Richard W.M. Jones 16 Oct '07

16 Oct '07

The attached patch (for discussion only) adds a virDomainBlockPeek call, allowing callers to peek into the block devices of domains. +/** + * virDomainBlockPeek: + * @dom: pointer to the domain object + * @path: path to the block device + * @offset: offset within block device + * @size: size to read + * @buffer: return buffer (must be at least size bytes) + * + * This function allows you to read the contents of a domain's + * disk device. + * + * Typical uses for this are to determine if the domain has + * written a Master Boot Record (indicating that the domain + * has completed installation), or to try to work out the state + * of the domain's filesystems. + * + * (Note that in the local case you might try to open the + * block device or file directly, but that won't work in the + * remote case, nor if you don't have sufficient permission. + * Hence the need for this call). + * + * 'path' must be a device or file corresponding to the domain. + * In other words it must be the precise string returned in + * a <disk><source dev='...'/></disk> from + * virDomainGetXMLDesc. + * + * 'offset' and 'size' represent an area which must lie entirely + * within the device or file. 'size' may be 0 to test if the + * call would succeed. + * + * 'buffer' is the return buffer and must be at least 'size' bytes. + * + * Returns: 0 in case of success or -1 in case of failure. + */ +int +virDomainBlockPeek (virDomainPtr dom, + const char *path, + long long offset /* really 64 bits */, + size_t size, + void *buffer) The patch doesn't include: - remote - qemu - Xen < 3.0.3 inactive domains I will add these if I get favourable feedback. Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903

2 3

[Libvir] PATCH: Implement CDROM media change for QEMU/KVM driver
by Daniel P. Berrange 16 Oct '07

16 Oct '07

Hugh recently added support for CDROM media change to the Xen driver, so I thought it was time I did the same for the QEMU/KVM driver. The attached patch implements the virDomainAttachDevice API to support changing the media of the CDROM device. To re-use the existing QEMU code for parsing I had to re-factor a couple of the internal QEMU device parsing apis so that they get supplied with a pre-allocated struct for the device info, rather than allocating it themselves. Although this isn't strictly needed for CDROM media change, I have prepared the virDomainAttachDevice method so that I can easily add USB device hotplut in the near future. It will also be useful when KVM gets paravirt driver support sooon... The actual implementation just runs the 'change cdrom path' command over the QEMU monitor console. diffstat libvirt-qemu-cdrom-change.patch qemu_conf.c | 135 +++++++++++++++++++++++++++++++++++++++------------------- qemu_conf.h | 21 +++++++++ qemu_driver.c | 132 ++++++++++++++++++++++++++++++++++++++++++++++++++------ 3 files changed, 230 insertions(+), 58 deletions(-) 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 7

[Libvir] Thoughts on remote storage support
by Tóth István 16 Oct '07

16 Oct '07

Hello! I had a hobby project where I needed to manipulate xen disk images on remote systems, that used a model similar to libirt's remote support. Based on what I learnt from it, I came up with a possible model for libvirt's remote storage support. I present it here for discussion. We typically store the images in volumes on LVM, or in dedicated file system folders. The folders and volume groups usable by libvirt can be limited in a config file. It is probably not neccessary to differentiate between defined and created files, as you can not stop and start a file like a domain, you either have it on disk, or not. Libvirt should not store information on these files, everything should be checked/listed on the fly, so that if you just copy an image to a directory, libvirt can deduct all information (well, all it can) on it, and handle it just as if the file was created by it. The handle for the file is its path, plus its virConnect object (i.e. the host it is on). For consistency, it may be possible to create an object for it, but as disk images have no persistent properties apart from what is on the disk, and it can always be checked from there, it provides no extra functionality. I think there is no need to support remote files explicitly, as the domains mount local files/volumes. The file/volume may actually be mounted from a NAS or SAN, of course, but it does not matter because we use the local path names, and AFAIK all virtualization tools use local files or local devices as blockdevs. I have added compression to the mix because it is immensely useful. I have used lzop in my project, and a full backup and restore was much faster when using a compressed backup file, than with and uncrompessed one. It conserves disk space, as well as cpu/bus capacity. Zeroing out newly allocated files, helps with compressed backups, as well as security. It also means that no holey files can be used. The objects we are dealing with are disk images. They have the following properties: -Path: The unix path of the file ( /mnt/images/fc7.img or /dev/VG/fc7) -Compression: Mountable/compressed -Type: Plain file/LVM volume/ What else? -Size -Filesystem: swap/ext3/xfs/.... -Is it mounted? We can do the following operations on the images: Create -connection -filepath -size Allocates a new image of the given type, size, and name. Libvirt should parse the filepath, and determine the base path, check if it's a directory or a VG, check if libvirt is allowed to operate on the path/VG, then create the file/volume. For security reasons zeroing out the allocated space should be a non-optional step of the allocation. DirectoryList -connection -directorypath Plain ls functionality, that returns the list of files, and any subdirectories. If called on a VG, it returns the volumes in it. Info -connection -filepath Returns information on the given file/volume, including size, type, filesystem (if available), whether it is a snapshot (if a volume), and whether it is mounted or not. size can be determined by ls or lvinfo, filesystem by 'file' command. Delete -connection -filepath Delete the file/volume. Find out if it's a file or volume, and rm or lvremove it. Grow -connection -path -filename -newsize Grows the specified image to the given size. The newly added space is zeroed out. Shrink? -connection -path -filename -newsize Shrinks the specified image the the given size. It's very tricky, because to avoid data loss, we need to analyze the file system size. Of course, we can just say that it's the reponsibility of the user, after all, we allow him to outright delete the file as well. We may combine it with Grow, and call it Resize. Growfs -connection -path -filename -newsize? Grows the filesystem on the image to fill the size of the image, or the given newsize. Can only be used on umounted images. It is neccesary because some filesystems may not be grown while mounted, so the guest can not do it on its own. Shrinkfs -connection -path -filname -newsize Shrinks the filesystem to the given size. Same coniderations apply as with growfs, may be combined to Resizefs? Snapshot -connection -filepath -filesize Creates a snapshot of the given image. It is only possible with images on LVM. Should return the snapshot image name. The snapshot can later be deleted with Delete. CopyTo -connection -source filepath -target connection -target filepath -snapshot flag -archive flag -overwrite flag Copy the source image to the target image. If connection is on another machine, then it's a network copy. If the snapshot flag is true, then first create a snapshot of the source image, copy that, then delete the snapshot. If the archive flag is active, then the target file will be archive file (compressed). If the overwite flag is active, then the target file is overwitten, if it exists. Otherwise existing files are not changed. Even if the source file is compressed, the target file is uncompressed, unless the archive flag is set. CopyContents -connection -source filepath -target connection -target filepath -snapshot flag Copies the contents of the source file to the target file. The target file must already exist, and be no smaller than the source file. The contents of the target file are overwitten, and any extra space is zeroed out. Archive -connection -filepath compresses the given file. Makes sense only on files, not volumes. Unarchive -connection -filepath uncompresses the given file. Makes sense only on archved(compressed) files. StorageInfo - connection Returns information on the node's storage configuration. What kind of filesystems it can handle, What are the accessible file / VG paths, what's the free space on them, etc. A typical usage scenario could be something like this: Aconn=getVirconn("ssh:Ahost"); //Open the connection to host A Bconn=getVirconn("ssh:Bhost"); //Host B will hold our backup image Ainfo=StorageInfo(Aconn); //Get Ainfo AVGPath = <get the first usable VG path from VG info> Newimage = Create(Aconn, concat("AVGPath", "newimage", 100000); //A 100Mb volume is created and zeroed out. CopyContents(Aconn, NewImage, Aconn, "/images/ghost/FC7default.img", no); //Copy our pre-created FC7 image to the new image Growfs(Aconn, NewImage, 0); //Grow the copied filesystem to fill the whole volume. <Here we define a new domain, and use NewImage as the name of the backing image for the guest's block device> <Start the new domain> Copy(Aconn, NewImage, Bconn, "/mnt/backups/backup23image", snapshot=yes, archive=yes, overwrite=no); //Make an LVM snapshot of NewImage, and copy it to Host B on the given filename, compressing it on the fly, then remove the snapshot <Stop the domain> CopyContents(Bconn, "/mnt/backups/backup23image", Aconn, NewImage, snapshot=no); //Restore the backed-up image to NewImage, decompress it on the fly. <Start the domain> <Stop the domain> Grow(Aconn, NewImage, 200000); //Grow the volume to 200MBs Growfs(Aconn, NewImage); //Grow the fs on the volume to fill the volume <Start the domain> ..... Best regards István

3 4

[Libvir] [PATCH] Refactor xend_internal.c block device detection
by Richard W.M. Jones 16 Oct '07

16 Oct '07

This patch is a little bit esoteric, but I need it for something I'm working on at the moment. At the moment the code in xend_internal.c: xend_parse_sexp_desc parses the domain sexpr directly into XML. This makes it rather hard to just get a list of block devices without repeating the same code. So here I've factored out the common code for parsing block devices into a separate function and callback. There are a couple of small changes that you should be aware of: (1) The <devices> list may be returned in a different order (specifically, block devices are always returned first). (2) We iterate over the root nodes of the sexpr twice (once for block devices, once for vifs and vfbs). But the sexpr is small and in-memory so this shouldn't be a problem compared to having to do the HTTP request to xend to get it in the first place. 'make check' passes. 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 4

[Libvir] remote access ?
by Mark Johnson 16 Oct '07

16 Oct '07

I was looking through some of the remote code.. I was wondering if a 32-bit virsh client is supposed to be able to connect to a 64-bit libvirtd? The reason I ask is because I saw some references to longs.. For example, in xdr_remote_node_get_info_ret() ... objp->cpus = IXDR_GET_LONG(buf); objp->mhz = IXDR_GET_LONG(buf); objp->nodes = IXDR_GET_LONG(buf); objp->sockets = IXDR_GET_LONG(buf); objp->cores = IXDR_GET_LONG(buf); objp->threads = IXDR_GET_LONG(buf); Thanks, MRJ

4 17

[Libvir] [PATCH] [REPOST] Remove virDomainRestart typedef from the public API
by Richard W.M. Jones 15 Oct '07

15 Oct '07

... however it is still used internally by the test driver, so the typedef is moved into src/test.c. Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903

3 2

[Libvir] [PATCH] Topology fix for "no cpus"
by beth kon 15 Oct '07

15 Oct '07

I was able to test on a 128-way NUMA box and found a bug. My code did not handle the case of no cpus being associated with a node. I decided to represent (pretty straightforward decision :-) no cpus as follows in the xml... <cell id='2'> <cpus num='0'> </cpus> </cell> Here is the patch... Signed-off-by: Beth Kon <eak(a)us.ibm.com> -- Elizabeth Kon (Beth) IBM Linux Technology Center Open Hypervisor Team email: eak(a)us.ibm.com

3 3

[Libvir] PATCH: Fix const-ness for attach/detach device APIs
by Daniel P. Berrange 15 Oct '07

15 Oct '07

virDomainAttachDevice and virDomainDetachDevice both take a char * for the XML description, but this is mistakenly not declared to be const. This patch fixes the public header files & all the internal drivers. NB, yes this is in the public API, no it won't break any apps since these are input params only. 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 -=|

3 2

[Libvir] Core dump while executing virsh in RHEL5 .
by Veerendra 15 Oct '07

15 Oct '07

Hi all, I have installed <mailto:libvir-list@redhat.com>libvirt-0.3.3-1, on my RHEL 5 64 bit machine(KerVer 2.6.18-8.el5xen). But I am getting core-dump , while executing virsh command. Could anyone please help me to solve this? #gdb /usr/bin/virsh core Core was generated by `virsh'. Program terminated with signal 11, Segmentation fault. #0 0x000000393686ca27 in malloc_consolidate () from /lib64/libc.so.6 (gdb) where #0 0x000000393686ca27 in malloc_consolidate () from /lib64/libc.so.6 #1 0x000000393686eea2 in _int_malloc () from /lib64/libc.so.6 #2 0x00000039368706dd in malloc () from /lib64/libc.so.6 #3 0x000000393685eb4a in __fopen_internal () from /lib64/libc.so.6 #4 0x000000393682cb5f in read_alias_file () from /lib64/libc.so.6 #5 0x000000393682d09e in _nl_expand_alias () from /lib64/libc.so.6 #6 0x000000393682b93e in _nl_find_domain () from /lib64/libc.so.6 #7 0x000000393682b2ff in __dcigettext () from /lib64/libc.so.6 #8 0x000000393687530c in strerror_r () from /lib64/libc.so.6 #9 0x000000393687514e in strerror () from /lib64/libc.so.6 #10 0x00002aaaaab018f2 in __virConfReadFile () from /usr/lib64/libvirt.so.0 #11 0x00002aaaaab021ec in __virConfReadFile () from /usr/lib64/libvirt.so.0 #12 0x00002aaaaaadd44b in virInitialize () from /usr/lib64/libvirt.so.0 #13 0x000000000040a65e in ?? () #14 0x000000393681d8a4 in __libc_start_main () from /lib64/libc.so.6 #15 0x00000000004033b9 in ?? () #16 0x00007fffd2df95c8 in ?? () #17 0x0000000000000000 in ?? () I have installed the following rpms from libvirt.org/libvirt # rpm -qa | grep virt libvirt-devel-0.3.3-1 libvirt-0.3.3-1 libvirt-debuginfo-0.3.3-1// * With Regards Veerendra C*

4 9

[Libvir] PATCH: Allow libvirtd configuration for QEMU VNC server
by Daniel P. Berrange 13 Oct '07

13 Oct '07

The QEMU VNC server spawned by the QEMU driver in libvirt is hardcoded to start off on 127.0.0.1, unless the person creating a guest overides this in the XML passed to libvirt. If wanting to setup off-host VNC access, it is much much more convenient to be able to set the system wide default to be 0.0.0.0 than to specify 0.0.0.0 for each VM created. In addition, it is desirable to be able to configure use of TLS and x509 certificates for the VNC servers system wide. In Xen world this is already possible through the /etc/xen/xend-config.sxp configuration file. In QEMU world, libvirtd takes the place of XenD. The /etc/libvirt/libvirtd.conf file though is for the daemon as a whole. There is no config file for the QEMU driver in libvirt itself. So this patch extends the QEMU driver to be able to load /etc/libvirt/qemu.conf and configure a handful of options. - vnc_listen = "0.0.0.0" - the address for VNC to listen on. Defaults to 127.0.0.1 for security sake - vnc_tls = 1 - turn on use of TLS extension - vnc_tls_x509_verify - request client certificates for auth - vnc_tls_cert_dir - the location of the VNC server certs. Defaults to /etc/pki/libvirt-vnc The code for building command line args for the -vnc flag to QEMU takes care to look at these options & add approprivate syntax. 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 -=|

2 2

[Libvir] how to setup usb/serial ports with libvirt & kvm (Fedora 7)
by John Davey 11 Oct '07

11 Oct '07

I am experimenting with the following Redhat 9 kvm on Fedora 7. How do I add a USB device with Libvirt? Specifically I'd like to add a usb-serial converter for logging data. "Man qemu-kvm" shows -usbdevice devname to add a USB device but I cannot find out how to do this with libvirt. Regards John <domain type='kvm'> <name>Rho</name> <memory>458752</memory> <currentMemory>458752</currentMemory> <vcpu>1</vcpu> <os> <type>hvm</type> <boot dev='hd'/> </os> <features> <acpi/> </features> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> <on_reboot>restart</on_reboot> <on_crash>restart</on_crash> <devices> <emulator>/usr/bin/qemu-kvm</emulator> <disk type='file' device='disk'> <source file='/var/lib/xen/images/rho.img'/> <target dev='hda'/> </disk> <interface type='bridge'> <mac address='06:00:CF:DE:01:A2'/> <source bridge='eth0'/> <target dev='rho0'/> </interface> <input type='mouse' bus='ps2'/> <graphics type='vnc' port='-1' listen='127.0.0.1'/> </devices> </domain>

2 2

[Libvir] [PATCH] qemu: reset migration source if restore fails
by Jim Paris 10 Oct '07

10 Oct '07

With the latest KVM I'm having some issues with save/restore, but I think it's a kvm issue and not libvirt. The problems did expose a libvirt bug, though; patch below. -jim --- A failed restore of a configured VM would leave the migration source set incorrectly, preventing the VM from being started normally. Always clear migration source, then deal with failures. src/qemu_driver.c | 12 ++++++------ 1 files changed, 6 insertions(+), 6 deletions(-) diff --git a/src/qemu_driver.c b/src/qemu_driver.c index 87b66ad..bff17b0 100644 --- a/src/qemu_driver.c +++ b/src/qemu_driver.c @@ -2083,6 +2083,7 @@ static int qemudDomainRestore(virConnectPtr conn, struct qemud_vm_def *def; struct qemud_vm *vm; int fd; + int ret; char *xml; struct qemud_save_header header; @@ -2161,18 +2162,17 @@ static int qemudDomainRestore(virConnectPtr conn, /* Set the migration source and start it up. */ snprintf(vm->migrateFrom, sizeof(vm->migrateFrom), "stdio"); vm->stdin = fd; - - if (qemudStartVMDaemon(conn, driver, vm) < 0) { + ret = qemudStartVMDaemon(conn, driver, vm); + close(fd); + vm->migrateFrom[0] = '\0'; + vm->stdin = -1; + if (ret < 0) { qemudReportError(conn, NULL, NULL, VIR_ERR_OPERATION_FAILED, "failed to start VM"); if (!vm->configFile[0]) qemudRemoveInactiveVM(driver, vm); - close(fd); return -1; } - close(fd); - vm->migrateFrom[0] = '\0'; - vm->stdin = -1; /* If it was running before, resume it now. */ if (header.was_running) { -- 1.5.3.rc4

3 2

[Libvir] Win Pro 64 dies in second half of windows guest installation
by Lawrence Nitz 10 Oct '07

10 Oct '07

When I set up a guest VM using virtp-install on a Fedor a 7 system, the process gets as far as reading the raw device (/dev/scd0) for the install disk, writes the basic windows data onto the disk, and then reboots to complete the Windows installation. At this point the installation hangs, with a diagnostic that says the file cannot be found. The same error occurs whether the install is from the hard disk image or from the cd-rom. The install gets half done, and has nothing to read when the install program restarts itself. In the Virt manager the edit command allows me to edit the machine, but not to add back the cd drive, only add network cards and hard disk partitions. Any help by a more experienced virt-install user would be much appreciated. Larry Nitz.

1 0

[Libvir] Problems with defineXML in python..
by Mark Dehus 10 Oct '07

10 Oct '07

I am having some problems getting libvirt under python to work properly. I can setup new domains by using the createLinux() function, but when I attempt to use defineXML() it fails with no reason given other then "virDomainDefineXML() failed". I am using the same XML file for both functions. This is on a Ubuntu 7.04 server running python 2.5 & libvirt 0.1.8 (from the ubuntu universe repo). Here is my test code: import libvirt import sys import xml import random try: conn = libvirt.open(None) except Exception, e: print e if conn == None: print 'Failed to open connection to the hypervisor' sys.exit(1) create = True if create: xmlfile = open('webserv.xml') xmldesc = xmlfile.read() xmlfile.close() try: # webserv = conn.createLinux(xmldesc, 0) webserv = conn.defineXML(xmldesc) except Exception, e: print 'Failed to create webserv: %s' % e sys.exit(1) if webserv is None: print 'whoops this shouldnt happen!' conn.create(webserv) try: print "Domain 0: id %d running %s" % (webserv.ID(), webserv.OSType()) print webserv.info() print webserv.XMLDesc(0) except Exception, e: print e #webserv.shutdown() And the XML file: <domain type='xen' > <name>webserv</name> <os> <type>linux</type> <kernel>/boot/vmlinuz-2.6.19-4-generic-amd64</kernel> <initrd>/boot/initrd.img-2.6.19-4-generic-amd64</initrd> <root>/dev/hda1</root> </os> <memory>1024</memory> <vcpu>1</vcpu> <on_poweroff>destroy</on_poweroff> <on_reboot>restart</on_reboot> <on_crash>restart</on_crash> <devices> <interface type='bridge'> <source bridge='xenbr0'/> <mac address='00:16:3e:24:27:a5'/> <script path='vif-bridge'/> </interface> <graphics type='vnc' port='5902'/> <disk type='file' device='disk'> <driver name='tap' type='aio'/> <source file='/virtual/images/webserv/webserv.img'/> <target dev='hda1'/> </disk> <console tty='/dev/pts/4'/> </devices> </domain> Am I missing something simple, or is there a bug? Thanks!

2 1

[Libvir] [PATCH] Topology fix for "no cpus"
by beth kon 08 Oct '07

08 Oct '07

Here is a resubmission of this patch, corrected. -- Elizabeth Kon (Beth) IBM Linux Technology Center Open Hypervisor Team email: eak(a)us.ibm.com

2 1

[Libvir] [PATCH] Found minor bug in topology code
by beth kon 05 Oct '07

05 Oct '07

I found a problem with an error path... I was cutting off incrementing of a value in the loop then checking if it was too big after the loop, so the way it was structured, it could never happen. Here is the fix. -- Elizabeth Kon (Beth) IBM Linux Technology Center Open Hypervisor Team email: eak(a)us.ibm.com

2 1

[Libvir] PATCH: Updated patches for PolicyKit support
by Daniel P. Berrange 03 Oct '07

03 Oct '07

A few weeks back I posted some prototype patches for PolicyKit support to allow the main libvirt daemon socket to be made world-accessible. PolicyKit then can do ACLs on incoming connections, allowing definition of rules which could for example, allow only the user who owns the active X login sesion http://www.redhat.com/archives/libvir-list/2007-August/msg00027.html This is an updated patch which takes account of a change in the PolicyKit XML file syntax between 0.4 and 0.5 releases. The configure.in scripts has been tweaked to automatically disable PolicyKit if pkg-config is not available instead of aborting. The code for getting UNIX socket credentials has been factored out into its own method. There is still only a Linux implementation. I was going to take the code for other OS from DBus, but DBus is currently under a GPL/Academic license options, which is not compatible with LGPL. Fortunately DBus is in middle of re-licensing to X11 style which is LGPL compatible, so in a week or so's time we'll be able to safely take their OS portability code for socket credentials. I short-circuit the logic to always allow root. This allows existing people running libvirt tools as root to continue use without any regressions. There is one small issue still that the default policy I provide only allows the use of read-only connections if the user is logged into to the desktop. This is a partial regression - the admin can edit /etc/PolicyKit/PolicyKit.conf and add a site-local rule allowing all users access, regardless of whether they're in a session. I've spoken with David Zeuthan and he's going to add ability to specify rules for non-session clients in the default policy config files, which will fix this minor regression. Once this is done the libvirt default policy will be identical to current file permission based policy (root == full access, non-root == read only). As I mentioned previously, with this change it is now possible to open a full read-write connection from virt-manager running as non-root. Depending on site policy it will optionally prompt for root password (su style equiv) or the user's password (sudo style equiv) without needing virt-manager itself to gain any elevated privileges. When compiling with PolicyKit support, the default file permissions for both the main & readonly UNIX sockets in the daemon switch to 0777, instead of the previous 0700 & 0777. It is possible to turn off PolicyKit auth in the daemon config file, even if it is compiled in - in which case the default permissions get set back to 0700 & 0777. Although in previous feedback Daniel suggested I leave the LIBVIRTD_AUTH_POLKIT constant compiled in all the time, I feel it is better to remove it when the policykit support is disabled in configure. This removes the need to have extra switch/case statements to explicitly reject LIBVIRTD_AUTH_POLKIT auth, since it will be handle by the 'default:' statement which already has code to reject connections. I've done more extensive testing with virt-manager since my previous patch, and its working very nicely with the new UI which allows multiple hypervisor connections. Instead of asking for the root password up-front at app start time, we now only need ask for it if the user connects to a local HV. If they only ever manage remote connections we don't need to do anything with the local root password. 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 4

[Libvir] Release of libvirt-0.3.3
by Daniel Veillard 30 Sep '07

30 Sep '07

More than a month without a release ... it was clearly time to push the bits out. Available as usual from ftp://libvirt.org/libvirt/ A lot of new things in the last month: * New features: - Avahi mDNS daemon export (Daniel Berrange) - NUMA support (Beth Kan) * Documentation: - cleanups (Toth Istvan) - typos (Eduardo Pereira) * Bug fixes: - memory corruption on large dumps (Masayuki Sunou) - fix virsh vncdisplay command exit (Masayuki Sunou) - Fix network stats TX/RX result (Richard Jones) - warning on Xen 3.0.3 (Richard Jones) - missing buffer check in virDomainXMLDevID (Hugh Brock) - avoid zombies when using remote (Daniel Berrange) - xend connection error message (Richard Jones) - avoid ssh tty prompt (Daniel Berrange) - username handling for remote URIs (Fabian Deutsch) - fix potential crash on multiple input XML tags (Daniel Berrange) - Solaris Xen hypercalls fixup (Mark Johnson) * Improvements: - OpenVZ support (Shuveb Hussain and Anoop Cyriac) - CD-Rom reload on XEn (Hugh Brock) - PXE boot got QEmu/KVM (Daniel Berrange) - QEmu socket permissions customization (Daniel Berrange) - more QEmu support (Richard Jones) - better path detection for qemu and dnsmasq (Richard Jones) - QEmu flags are per-Domain (Daniel Berrange) - virsh freecell command - Solaris portability fixes (Mark Johnson) - default bootloader support (Daniel Berrange) - new virNodeGetFreeMemory API - vncpasswd extraction in configuration files if secure (Mark Johnson and Daniel Berrange) - Python bindings for block and interface statistics * Code cleanups: - virDrvOpenRemoteFlags definition (Richard Jones) - configure tests and output (Daniel Berrange) Thanks to everybody who helped with sugegstion, bug reports patches and more ! 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/

1 0

[Libvir] PATCH: vncpasswd
by Mark Johnson 30 Sep '07

30 Sep '07

This adds support for handling vncpasswd.. MRJ vncpasswd support diff --git a/src/xend_internal.c b/src/xend_internal.c --- a/src/xend_internal.c +++ b/src/xend_internal.c @@ -1657,11 +1657,14 @@ xend_parse_sexp_desc(virConnectPtr conn, } else if (tmp && !strcmp(tmp, "vnc")) { int port = xenStoreDomainGetVNCPort(conn, domid); const char *listenAddr = sexpr_node(node, "device/vfb/vnclisten"); + const char *vncPasswd = sexpr_node(node, "device/vfb/vncpasswd"); const char *keymap = sexpr_node(node, "device/vfb/keymap"); virBufferVSprintf(&buf, " <input type='mouse' bus='%s'/>\n", hvm ? "ps2": "xen"); virBufferVSprintf(&buf, " <graphics type='vnc' port='%d'", port); if (listenAddr) virBufferVSprintf(&buf, " listen='%s'", listenAddr); + if (vncPasswd) + virBufferVSprintf(&buf, " passwd='%s'", vncPasswd); if (keymap) virBufferVSprintf(&buf, " keymap='%s'", keymap); virBufferAdd(&buf, "/>\n", 3); @@ -1723,6 +1726,7 @@ xend_parse_sexp_desc(virConnectPtr conn, if (tmp[0] == '1') { int port = xenStoreDomainGetVNCPort(conn, domid); const char *listenAddr = sexpr_fmt_node(root, "domain/image/%s/vnclisten", hvm ? "hvm" : "linux"); + const char *vncPasswd = sexpr_fmt_node(root, "domain/image/%s/vncpasswd", hvm ? "hvm" : "linux"); const char *keymap = sexpr_fmt_node(root, "domain/image/%s/keymap", hvm ? "hvm" : "linux"); /* For Xen >= 3.0.3, don't generate a fixed port mapping * because it will almost certainly be wrong ! Just leave @@ -1736,6 +1740,8 @@ xend_parse_sexp_desc(virConnectPtr conn, virBufferVSprintf(&buf, " <graphics type='vnc' port='%d'", port); if (listenAddr) virBufferVSprintf(&buf, " listen='%s'", listenAddr); + if (vncPasswd) + virBufferVSprintf(&buf, " passwd='%s'", vncPasswd); if (keymap) virBufferVSprintf(&buf, " keymap='%s'", keymap); virBufferAdd(&buf, "/>\n", 3);

2 2

[Libvir] PATCH: Allow emptry bootloader
by Daniel P. Berrange 30 Sep '07

30 Sep '07

Latest XenD allows for default bootloader to be used if one is not defined for a paravirt OS. libvirt doesn't currently cope with this (see Solaris thread), since it requires either a bootloader or kernel to always be present. The attached patch allows for an emptry bootloader element to indicate that the domain should use the default. <domain type='xen' id='-1'> <name>rhel5pv</name> <uuid>614d7eb0-c6b1-5235-ac39-361b20f6cd49</uuid> <bootloader/> <os> <type>linux</type> </os> ...snip... </domain> The current API for looking up nodes in the SEXPR did not allow for the scenario where you might want to lookup a node with no content, eg (bootloader ) This distinction is needed here, so I added an sexpr_has() method to check for this. Second, it fixes a long standing bug where we'd record an error about the missing kernel or bootloader, but then continue generating (malformed) XML anyway. With this patch, it will correctly fail if the empty bootloader field is missing from the SEXPR. 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 -=|

2 4

[Libvir] [RFC][PATCH 0/2] Tested NUMA patches for available memory and topology
by beth kon 30 Sep '07

30 Sep '07

I have tested the patches on a NUMA and a non-NUMA configuration, and they fundamentally appear to work. The first patch is for accessing available memory on a per-node basis. The second patch is for accessing NUMA node topology. I've gotten some helpful suggestions about my string parsing code, introducing me to sscanf :-). I've become convinced that there are more elegant ways to do this which would have about the same level of error checking. However, I am out of time if Daniel wants to check this in this week. So I offer what I do have, which functions, but is not elegant. I have been playing with other ways to do this and am not far from finished. So, Daniel, you need to tell me if you want to take this code, and possibly upgrade to something more compact later, or if you'd like to wait for the next revision. One point to comment on for posterity is that the string returned from xend is not what might be expected. An example: printf("string is %s\n", tempstr); would return string is node0:0\n node1:1 So, this means that the '\n' sent by the xend python code is somehow translated to "\n". And the trailing '\n' that should be there isn't. Instead there is a '\0'. Looking at the xend code, it would appear this string should look like: "node0:0\n node1:1\n" where these are '\n'. -- Elizabeth Kon (Beth) IBM Linux Technology Center Open Hypervisor Team email: eak(a)us.ibm.com

4 11

[Libvir] Updated Solaris dom0 patch (part 1)
by Mark Johnson 29 Sep '07

29 Sep '07

I've broken this patch up into a few pieces to make it more reviewable and tried to address the comments from the previous patch (Jun 15th'ish if your looking). Here is first part... tested on today's CVS bits on a FC7 dom0 (LD_PRELOAD=src/.libs/libvirt.so src/.libs/virsh) One note, it looks like you still need a xend change on FC7 before the no kernel/bootloader option works. It looks like it's close though.. works fine with them of course. More details... [root@fedora solaris]# cat guest.py name = "solaris" vcpus = 1 memory = "512" #bootloader = "/usr/bin/pygrub" #kernel = "/platform/i86xpv/kernel/unix" #ramdisk = "/platform/i86pc/boot_archive" extra = "-k" root = "/dev/dsk/c0d0s0" disk = ['file:/export/guests/solaris/disk.img,0,w'] vif = ['bridge=xenbr0'] on_shutdown = "destroy" on_reboot = "restart" on_crash = "destroy" [root@fedora solaris]# xm list -l solaris (domain (on_crash destroy) (uuid 72f9b45e-4be9-bf1f-a500-3707b9c3922c) (bootloader_args ) (vcpus 1) (name solaris) (on_poweroff destroy) (on_reboot restart) (bootloader ) (maxmem 512) (memory 512) (shadow_memory 0) (cpu_weight 256) (cpu_cap 0) (features ) (on_xend_start ignore) (on_xend_stop ignore) (image (linux (kernel ) (args 'root=/dev/dsk/c0d0s0 -k'))) (status 0) (device (vif (bridge xenbr0) (uuid 9a8d5a2f-0a70-3a1f-fed0-fd2459e63733))) (device (vbd (uuid a6ba2241-1019-151e-6dd7-28638d3e17b7) (bootable 1) (driver paravirtualised) (dev 0) (uname file:/export/guests/solaris/disk.img) (mode w) ) ) ) [root@fedora solaris]# virsh # start solaris Domain solaris started virsh # dominfo solaris Id: 5 Name: solaris UUID: 72f9b45e-4be9-bf1f-a500-3707b9c3922c OS Type: linux State: no state CPU(s): 1 CPU time: 2.1s Max memory: 524288 kB Used memory: 524288 kB virsh # console solaris libvir: Xen Daemon error : internal error domain information incomplete, missing kernel & bootloader domain.xml:25: parser error : Opening and ending tag mismatch: os line 4 and domain </domain> ^ domain.xml:26: parser error : Premature end of data in tag domain line 1 ^ virsh # quit [root@fedora solaris]# xm console solaris Loading kmdb... SunOS Release 5.11 Version matrix-devel-build 32-bit Copyright 1983-2007 Sun Microsystems, Inc. All rights reserved. Use is subject to license terms. WARNING: Found xen v3.1.0-rc7-2934.fc7 but need xen v3.0.4-1-xvm WARNING: The kernel may not function correctly Hostname: unknown Reading ZFS config: done. Sep 28 18:48:53 unknown ntpdate[419]: no server suitable for synchronization found unknown console login: root Password: Last login: Fri Sep 28 18:45:46 on console Sep 28 18:50:30 unknown login: ROOT LOGIN /dev/console Sun Microsystems Inc. SunOS 5.11 matrix-devel-build October 2007 bfu'ed from /net/girltalk/export/xvm/matrix-devel/archives/i386/nightly-nd on 2007-09-28 Sun Microsystems Inc. SunOS 5.11 xen-nv66-2007-06-24 October 2007 # poweroff Sep 28 18:50:33 unknown poweroff: initiated by root on /dev/console [root@fedora solaris]# Thanks, MRJ --- Solaris dom0 support diff --git a/src/xen_internal.c b/src/xen_internal.c --- a/src/xen_internal.c +++ b/src/xen_internal.c @@ -56,9 +56,10 @@ typedef struct v0_hypercall_struct { unsigned long op; unsigned long arg[5]; } v0_hypercall_t; + +#ifdef __linux__ #define XEN_V0_IOCTL_HYPERCALL_CMD \ _IOC(_IOC_NONE, 'P', 0, sizeof(v0_hypercall_t)) - /* the new one */ typedef struct v1_hypercall_struct { @@ -67,8 +68,12 @@ typedef struct v1_hypercall_struct } v1_hypercall_t; #define XEN_V1_IOCTL_HYPERCALL_CMD \ _IOC(_IOC_NONE, 'P', 0, sizeof(v1_hypercall_t)) - typedef v1_hypercall_t hypercall_t; +#elif define(__sun__) +typedef privcmd_hypercall_t hypercall_t; +#else +#error "unsupported platform" +#endif #ifndef __HYPERVISOR_sysctl #define __HYPERVISOR_sysctl 35 @@ -314,6 +319,26 @@ typedef union xen_getschedulerid xen_get dominfo.v2.handle : \ dominfo.v2d5.handle)) + +static int +lock_pages(void *addr, size_t len) +{ +#ifdef __linux__ + return (mlock(addr, len)); +#elif define(__sun) + return (0); +#endif +} + +static int +unlock_pages(void *addr, size_t len) +{ +#ifdef __linux__ + return (munlock(addr, len)); +#elif define(__sun) + return (0); +#endif +} struct xen_v0_getdomaininfolistop { @@ -616,7 +641,17 @@ typedef struct xen_op_v2_dom xen_op_v2_d #include "xen_unified.h" #include "xen_internal.h" -#define XEN_HYPERVISOR_SOCKET "/proc/xen/privcmd" +#ifdef __linux__ +#define XEN_HYPERVISOR_SOCKET "/proc/xen/privcmd" +#define HYPERVISOR_CAPABILITIES "/sys/hypervisor/properties/capabilities" +#define CPUINFO "/proc/cpuinfo" +#elif define(__sun__) +#define XEN_HYPERVISOR_SOCKET "/dev/xen/privcmd" +#define HYPERVISOR_CAPABILITIES "" +#define CPUINFO "/dev/cpu/self/cpuid" +#else +#error "unsupported platform" +#endif #ifndef PROXY static const char * xenHypervisorGetType(virConnectPtr conn); @@ -773,7 +808,7 @@ xenHypervisorDoV0Op(int handle, xen_op_v hc.op = __HYPERVISOR_dom0_op; hc.arg[0] = (unsigned long) op; - if (mlock(op, sizeof(dom0_op_t)) < 0) { + if (lock_pages(op, sizeof(dom0_op_t)) < 0) { virXenError(VIR_ERR_XEN_CALL, " locking", sizeof(*op)); return (-1); } @@ -783,7 +818,7 @@ xenHypervisorDoV0Op(int handle, xen_op_v virXenError(VIR_ERR_XEN_CALL, " ioctl ", xen_ioctl_hypercall_cmd); } - if (munlock(op, sizeof(dom0_op_t)) < 0) { + if (unlock_pages(op, sizeof(dom0_op_t)) < 0) { virXenError(VIR_ERR_XEN_CALL, " releasing", sizeof(*op)); ret = -1; } @@ -814,7 +849,7 @@ xenHypervisorDoV1Op(int handle, xen_op_v hc.op = __HYPERVISOR_dom0_op; hc.arg[0] = (unsigned long) op; - if (mlock(op, sizeof(dom0_op_t)) < 0) { + if (lock_pages(op, sizeof(dom0_op_t)) < 0) { virXenError(VIR_ERR_XEN_CALL, " locking", sizeof(*op)); return (-1); } @@ -824,7 +859,7 @@ xenHypervisorDoV1Op(int handle, xen_op_v virXenError(VIR_ERR_XEN_CALL, " ioctl ", xen_ioctl_hypercall_cmd); } - if (munlock(op, sizeof(dom0_op_t)) < 0) { + if (unlock_pages(op, sizeof(dom0_op_t)) < 0) { virXenError(VIR_ERR_XEN_CALL, " releasing", sizeof(*op)); ret = -1; } @@ -856,7 +891,7 @@ xenHypervisorDoV2Sys(int handle, xen_op_ hc.op = __HYPERVISOR_sysctl; hc.arg[0] = (unsigned long) op; - if (mlock(op, sizeof(dom0_op_t)) < 0) { + if (lock_pages(op, sizeof(dom0_op_t)) < 0) { virXenError(VIR_ERR_XEN_CALL, " locking", sizeof(*op)); return (-1); } @@ -866,7 +901,7 @@ xenHypervisorDoV2Sys(int handle, xen_op_ virXenError(VIR_ERR_XEN_CALL, " sys ioctl ", xen_ioctl_hypercall_cmd); } - if (munlock(op, sizeof(dom0_op_t)) < 0) { + if (unlock_pages(op, sizeof(dom0_op_t)) < 0) { virXenError(VIR_ERR_XEN_CALL, " releasing", sizeof(*op)); ret = -1; } @@ -898,7 +933,7 @@ xenHypervisorDoV2Dom(int handle, xen_op_ hc.op = __HYPERVISOR_domctl; hc.arg[0] = (unsigned long) op; - if (mlock(op, sizeof(dom0_op_t)) < 0) { + if (lock_pages(op, sizeof(dom0_op_t)) < 0) { virXenError(VIR_ERR_XEN_CALL, " locking", sizeof(*op)); return (-1); } @@ -908,7 +943,7 @@ xenHypervisorDoV2Dom(int handle, xen_op_ virXenError(VIR_ERR_XEN_CALL, " ioctl ", xen_ioctl_hypercall_cmd); } - if (munlock(op, sizeof(dom0_op_t)) < 0) { + if (unlock_pages(op, sizeof(dom0_op_t)) < 0) { virXenError(VIR_ERR_XEN_CALL, " releasing", sizeof(*op)); ret = -1; } @@ -936,7 +971,7 @@ virXen_getdomaininfolist(int handle, int { int ret = -1; - if (mlock(XEN_GETDOMAININFOLIST_DATA(dominfos), + if (lock_pages(XEN_GETDOMAININFOLIST_DATA(dominfos), XEN_GETDOMAININFO_SIZE * maxids) < 0) { virXenError(VIR_ERR_XEN_CALL, " locking", XEN_GETDOMAININFO_SIZE * maxids); @@ -992,7 +1027,7 @@ virXen_getdomaininfolist(int handle, int if (ret == 0) ret = op.u.getdomaininfolist.num_domains; } - if (munlock(XEN_GETDOMAININFOLIST_DATA(dominfos), + if (unlock_pages(XEN_GETDOMAININFOLIST_DATA(dominfos), XEN_GETDOMAININFO_SIZE * maxids) < 0) { virXenError(VIR_ERR_XEN_CALL, " release", XEN_GETDOMAININFO_SIZE * maxids); @@ -1679,7 +1714,7 @@ virXen_setvcpumap(int handle, int id, un if (hypervisor_version > 1) { xen_op_v2_dom op; - if (mlock(cpumap, maplen) < 0) { + if (lock_pages(cpumap, maplen) < 0) { virXenError(VIR_ERR_XEN_CALL, " locking", maplen); return (-1); } @@ -1697,7 +1732,7 @@ virXen_setvcpumap(int handle, int id, un } ret = xenHypervisorDoV2Dom(handle, &op); - if (munlock(cpumap, maplen) < 0) { + if (unlock_pages(cpumap, maplen) < 0) { virXenError(VIR_ERR_XEN_CALL, " release", maplen); ret = -1; } @@ -1794,7 +1829,7 @@ virXen_getvcpusinfo(int handle, int id, ipt->cpu = op.u.getvcpuinfod5.online ? (int)op.u.getvcpuinfod5.cpu : -1; } if ((cpumap != NULL) && (maplen > 0)) { - if (mlock(cpumap, maplen) < 0) { + if (lock_pages(cpumap, maplen) < 0) { virXenError(VIR_ERR_XEN_CALL, " locking", maplen); return (-1); } @@ -1812,7 +1847,7 @@ virXen_getvcpusinfo(int handle, int id, op.u.getvcpumapd5.cpumap.nr_cpus = maplen * 8; } ret = xenHypervisorDoV2Dom(handle, &op); - if (munlock(cpumap, maplen) < 0) { + if (unlock_pages(cpumap, maplen) < 0) { virXenError(VIR_ERR_XEN_CALL, " release", maplen); ret = -1; } @@ -1963,6 +1998,7 @@ xenHypervisorInit(void) goto detect_v2; } +#ifndef __sun__ /* * check if the old hypercall are actually working */ @@ -1980,6 +2016,7 @@ xenHypervisorInit(void) hypervisor_version = 0; goto done; } +#endif /* * we faild to make any hypercall diff --git a/src/xend_internal.c b/src/xend_internal.c --- a/src/xend_internal.c +++ b/src/xend_internal.c @@ -1280,9 +1280,7 @@ xend_parse_sexp_desc_os(virConnectPtr xe virBufferVSprintf(buf, " <type>hvm</type>\n"); tmp = sexpr_node(node, "domain/image/hvm/kernel"); if (tmp == NULL && !bootloader) { - virXendError(xend, VIR_ERR_INTERNAL_ERROR, - _("domain information incomplete, missing kernel & bootloader")); - return(-1); + virBufferVSprintf(buf, " \n"); } if (tmp) virBufferVSprintf(buf, " <loader>%s</loader>\n", tmp); @@ -1311,9 +1309,7 @@ xend_parse_sexp_desc_os(virConnectPtr xe virBufferVSprintf(buf, " <type>linux</type>\n"); tmp = sexpr_node(node, "domain/image/linux/kernel"); if (tmp == NULL && !bootloader) { - virXendError(xend, VIR_ERR_INTERNAL_ERROR, - _("domain information incomplete, missing kernel & bootloader")); - return(-1); + virBufferVSprintf(buf, " \n"); } if (tmp) virBufferVSprintf(buf, " <kernel>%s</kernel>\n", tmp); diff --git a/src/xml.c b/src/xml.c --- a/src/xml.c +++ b/src/xml.c @@ -703,10 +703,7 @@ virDomainParseXMLOSDescPV(virConnectPtr return (-1); } virBufferAdd(buf, "(image (linux ", 14); - if (kernel == NULL) { - virXMLError(conn, VIR_ERR_NO_KERNEL, NULL, 0); - return (-1); - } else { + if (kernel != NULL) { virBufferVSprintf(buf, "(kernel '%s')", (const char *) kernel); } if (initrd != NULL) diff --git a/src/xs_internal.c b/src/xs_internal.c --- a/src/xs_internal.c +++ b/src/xs_internal.c @@ -31,7 +31,13 @@ #include "xs_internal.h" #include "xen_internal.h" /* for xenHypervisorCheckID */ +#ifdef __linux__ #define XEN_HYPERVISOR_SOCKET "/proc/xen/privcmd" +#elif define(__sun__) +#define XEN_HYPERVISOR_SOCKET "/dev/xen/privcmd" +#else +#error "unsupported platform" +#endif #ifndef PROXY static char *xenStoreDomainGetOSType(virDomainPtr domain);

2 2

[Libvir] updated: Support Sun's Compiler
by Mark Johnson 29 Sep '07

29 Sep '07

I've cleaned up the patch from the previous comments... Sorry I'm off the original thread, switched over to mutt and am waiting for fetchmail to catch up with gmail.. tested on today's CVS bits on a FC7 dom0 (LD_PRELOAD=src/.libs/libvirt.so src/.libs/virsh) Thanks, MRJ --- fixes to compile with Sun's CC diff --git a/src/internal.h b/src/internal.h --- a/src/internal.h +++ b/src/internal.h @@ -25,11 +25,6 @@ extern "C" { #define _(str) dgettext(GETTEXT_PACKAGE, (str)) #define N_(str) dgettext(GETTEXT_PACKAGE, (str)) #define gettext_noop(str) (str) - -#ifdef __GNUC__ -#ifdef HAVE_ANSIDECL_H -#include <ansidecl.h> -#endif /* String equality tests, suggested by Jim Meyering. */ #define STREQ(a,b) (strcmp((a),(b)) == 0) @@ -39,6 +34,15 @@ extern "C" { #define STREQLEN(a,b,n) (strncmp((a),(b),(n)) == 0) #define STRNEQLEN(a,b,n) (strncmp((a),(b),(n)) != 0) +#ifndef __GNUC__ +#define __FUNCTION__ __func__ +#endif + +#ifdef __GNUC__ +#ifdef HAVE_ANSIDECL_H +#include <ansidecl.h> +#endif + /** * ATTRIBUTE_UNUSED: * @@ -61,7 +65,7 @@ extern "C" { #else #define ATTRIBUTE_UNUSED #define ATTRIBUTE_FORMAT(...) -#endif +#endif /* __GNUC__ */ /** * TODO: diff --git a/src/sexpr.c b/src/sexpr.c --- a/src/sexpr.c +++ b/src/sexpr.c @@ -80,11 +80,11 @@ sexpr_free(struct sexpr *sexpr) switch (sexpr->kind) { case SEXPR_CONS: - sexpr_free(sexpr->car); - sexpr_free(sexpr->cdr); + sexpr_free(sexpr->u.s.car); + sexpr_free(sexpr->u.s.cdr); break; case SEXPR_VALUE: - free(sexpr->value); + free(sexpr->u.value); break; case SEXPR_NIL: break; @@ -127,12 +127,12 @@ sexpr_string(const char *str, ssize_t le return ret; ret->kind = SEXPR_VALUE; if (len > 0) { - ret->value = strndup(str, len); + ret->u.value = strndup(str, len); } else { - ret->value = strdup(str); - } - - if (ret->value == NULL) { + ret->u.value = strdup(str); + } + + if (ret->u.value == NULL) { return NULL; } @@ -157,8 +157,8 @@ sexpr_cons(struct sexpr *car, struct sex if (ret == NULL) return ret; ret->kind = SEXPR_CONS; - ret->car = car; - ret->cdr = cdr; + ret->u.s.car = car; + ret->u.s.cdr = cdr; return ret; } @@ -174,12 +174,12 @@ append(struct sexpr *lst, struct sexpr * append(struct sexpr *lst, struct sexpr *value) { while (lst->kind != SEXPR_NIL) { - lst = lst->cdr; + lst = lst->u.s.cdr; } lst->kind = SEXPR_CONS; - lst->car = value; - lst->cdr = sexpr_nil(); + lst->u.s.car = value; + lst->u.s.cdr = sexpr_nil(); } /** @@ -228,18 +228,18 @@ sexpr2string(struct sexpr * sexpr, char if (tmp == 0) goto error; ret += tmp; - tmp = sexpr2string(sexpr->car, buffer + ret, n_buffer - ret); + tmp = sexpr2string(sexpr->u.s.car, buffer + ret, n_buffer - ret); if (tmp == 0) goto error; ret += tmp; - while (sexpr->cdr->kind != SEXPR_NIL) { - sexpr = sexpr->cdr; + while (sexpr->u.s.cdr->kind != SEXPR_NIL) { + sexpr = sexpr->u.s.cdr; tmp = snprintf(buffer + ret, n_buffer - ret, " "); if (tmp == 0) goto error; ret += tmp; tmp = - sexpr2string(sexpr->car, buffer + ret, n_buffer - ret); + sexpr2string(sexpr->u.s.car, buffer + ret, n_buffer - ret); if (tmp == 0) goto error; ret += tmp; @@ -250,12 +250,12 @@ sexpr2string(struct sexpr * sexpr, char ret += tmp; break; case SEXPR_VALUE: - if (strchr(sexpr->value, ' ')) + if (strchr(sexpr->u.value, ' ')) tmp = snprintf(buffer + ret, n_buffer - ret, "'%s'", - sexpr->value); + sexpr->u.value); else tmp = snprintf(buffer + ret, n_buffer - ret, "%s", - sexpr->value); + sexpr->u.value); if (tmp == 0) goto error; ret += tmp; @@ -346,8 +346,8 @@ _string2sexpr(const char *buffer, size_t ptr++; } - ret->value = strndup(start, ptr - start); - if (ret->value == NULL) { + ret->u.value = strndup(start, ptr - start); + if (ret->u.value == NULL) { virSexprError(VIR_ERR_NO_MEMORY, _("failed to copy a string")); } @@ -361,15 +361,15 @@ _string2sexpr(const char *buffer, size_t ptr++; } - ret->value = strndup(start, ptr - start); - if (ret->value == NULL) { + ret->u.value = strndup(start, ptr - start); + if (ret->u.value == NULL) { virSexprError(VIR_ERR_NO_MEMORY, _("failed to copy a string")); } } ret->kind = SEXPR_VALUE; - if (ret->value == NULL) + if (ret->u.value == NULL) goto error; } @@ -426,11 +426,11 @@ sexpr_lookup(struct sexpr *sexpr, const ptr = buffer; token = strsep(&ptr, "/"); - if (sexpr->kind != SEXPR_CONS || sexpr->car->kind != SEXPR_VALUE) { - return NULL; - } - - if (strcmp(sexpr->car->value, token) != 0) { + if (sexpr->kind != SEXPR_CONS || sexpr->u.s.car->kind != SEXPR_VALUE) { + return NULL; + } + + if (strcmp(sexpr->u.s.car->u.value, token) != 0) { return NULL; } @@ -440,16 +440,16 @@ sexpr_lookup(struct sexpr *sexpr, const if (token == NULL) continue; - sexpr = sexpr->cdr; - for (i = sexpr; i->kind != SEXPR_NIL; i = i->cdr) { + sexpr = sexpr->u.s.cdr; + for (i = sexpr; i->kind != SEXPR_NIL; i = i->u.s.cdr) { if (i->kind != SEXPR_CONS || - i->car->kind != SEXPR_CONS || - i->car->car->kind != SEXPR_VALUE) { + i->u.s.car->kind != SEXPR_CONS || + i->u.s.car->u.s.car->kind != SEXPR_VALUE) { continue; } - if (strcmp(i->car->car->value, token) == 0) { - sexpr = i->car; + if (strcmp(i->u.s.car->u.s.car->u.value, token) == 0) { + sexpr = i->u.s.car; break; } } @@ -463,10 +463,10 @@ sexpr_lookup(struct sexpr *sexpr, const return NULL; } - if (sexpr->kind != SEXPR_CONS || sexpr->cdr->kind != SEXPR_CONS) - return NULL; - - return sexpr->cdr; + if (sexpr->kind != SEXPR_CONS || sexpr->u.s.cdr->kind != SEXPR_CONS) + return NULL; + + return sexpr->u.s.cdr; } /** @@ -484,7 +484,7 @@ sexpr_node(struct sexpr *sexpr, const ch { struct sexpr *n = sexpr_lookup(sexpr, node); - return (n && n->car->kind == SEXPR_VALUE) ? n->car->value : NULL; + return (n && n->u.s.car->kind == SEXPR_VALUE) ? n->u.s.car->u.value : NULL; } /** diff --git a/src/sexpr.h b/src/sexpr.h --- a/src/sexpr.h +++ b/src/sexpr.h @@ -29,9 +29,9 @@ struct sexpr { struct { struct sexpr *car; struct sexpr *cdr; - }; + } s; char *value; - }; + } u; }; /* conversion to/from strings */ diff --git a/src/virsh.c b/src/virsh.c --- a/src/virsh.c +++ b/src/virsh.c @@ -4295,9 +4295,9 @@ vshDomainStateToString(int state) case VIR_DOMAIN_CRASHED: return gettext_noop("crashed"); default: - return gettext_noop("no state"); /* = dom0 state */ - } - return NULL; + ;/*FALLTHROUGH*/ + } + return gettext_noop("no state"); /* = dom0 state */ } static const char * @@ -4311,9 +4311,9 @@ vshDomainVcpuStateToString(int state) case VIR_VCPU_RUNNING: return gettext_noop("running"); default: - return gettext_noop("no state"); - } - return NULL; + ;/*FALLTHROUGH*/ + } + return gettext_noop("no state"); } static int @@ -4825,7 +4825,7 @@ vshParseArgv(vshControl * ctl, int argc, } last = argv[i]; } - end = end ? : argc; + end = end ? end : argc; /* standard (non-command) options */ while ((arg = getopt_long(end, argv, "d:hqtc:vrl:", opt, &idx)) != -1) { diff --git a/src/xend_internal.c b/src/xend_internal.c --- a/src/xend_internal.c +++ b/src/xend_internal.c @@ -189,9 +189,9 @@ virXendErrorInt(virConnectPtr conn, virE #define foreach(iterator, start) \ - for (_for_i = (start), *iterator = (start)->car; \ + for (_for_i = (start), *iterator = (start)->u.s.car; \ _for_i->kind == SEXPR_CONS; \ - _for_i = _for_i->cdr, iterator = _for_i->car) + _for_i = _for_i->u.s.cdr, iterator = _for_i->u.s.car) #define foreach_node(iterator, start, path) \ foreach(iterator, start) \ @@ -661,23 +661,22 @@ xend_node_op(virConnectPtr xend, const c * Returns 0 in case of success, -1 in case of failure. */ static int -xend_op_ext(virConnectPtr xend, const char *name, char *error, - size_t n_error, const char *key, ...) +xend_op(virConnectPtr xend, const char *name, const char *key, ...) { char buffer[1024]; + char error[1024]; va_list ap; int ret; snprintf(buffer, sizeof(buffer), "/xend/domain/%s", name); va_start(ap, key); - ret = xend_op_ext2(xend, buffer, error, n_error, key, ap); + ret = xend_op_ext2(xend, buffer, error, sizeof(error), key, ap); va_end(ap); return ret; } -#define xend_op(xend, name, key, ...) ({char error[1024]; xend_op_ext(xend, name, error, sizeof(error), key, __VA_ARGS__);}) #endif /* ! PROXY */ /** @@ -960,11 +959,11 @@ xenDaemonListDomainsOld(virConnectPtr xe if (root == NULL) goto error; - for (_for_i = root, node = root->car; _for_i->kind == SEXPR_CONS; - _for_i = _for_i->cdr, node = _for_i->car) { + for (_for_i = root, node = root->u.s.car; _for_i->kind == SEXPR_CONS; + _for_i = _for_i->u.s.cdr, node = _for_i->u.s.car) { if (node->kind != SEXPR_VALUE) continue; - extra += strlen(node->value) + 1; + extra += strlen(node->u.value) + 1; count++; } @@ -976,13 +975,13 @@ xenDaemonListDomainsOld(virConnectPtr xe ptr += sizeof(char *) * (count + 1); i = 0; - for (_for_i = root, node = root->car; _for_i->kind == SEXPR_CONS; - _for_i = _for_i->cdr, node = _for_i->car) { + for (_for_i = root, node = root->u.s.car; _for_i->kind == SEXPR_CONS; + _for_i = _for_i->u.s.cdr, node = _for_i->u.s.car) { if (node->kind != SEXPR_VALUE) continue; ret[i] = ptr; - strcpy(ptr, node->value); - ptr += strlen(node->value) + 1; + strcpy(ptr, node->u.value); + ptr += strlen(node->u.value) + 1; i++; } @@ -1461,8 +1460,8 @@ xend_parse_sexp_desc(virConnectPtr conn, if ((tmp != NULL) && (tmp[0] != 0)) virBufferVSprintf(&buf, " <emulator>%s</emulator>\n", tmp); - for (cur = root; cur->kind == SEXPR_CONS; cur = cur->cdr) { - node = cur->car; + for (cur = root; cur->kind == SEXPR_CONS; cur = cur->u.s.cdr) { + node = cur->u.s.car; /* Normally disks are in a (device (vbd ...)) block but blktap disks ended up in a differently named (device (tap ....)) block.... */ @@ -1701,8 +1700,8 @@ xend_parse_sexp_desc(virConnectPtr conn, /* in case of HVM we have devices emulation */ if (hvm) { - for (cur = sexpr_lookup(root, "domain/image/hvm"); cur && cur->kind == SEXPR_CONS; cur = cur->cdr) { - node = cur->car; + for (cur = sexpr_lookup(root, "domain/image/hvm"); cur && cur->kind == SEXPR_CONS; cur = cur->u.s.cdr) { + node = cur->u.s.car; if (sexpr_lookup(node, "usbdevice")) { tmp = sexpr_node(node, "usbdevice"); if (tmp && *tmp) { @@ -2677,11 +2676,11 @@ xenDaemonListDomains(virConnectPtr conn, ret = 0; - for (_for_i = root, node = root->car; _for_i->kind == SEXPR_CONS; - _for_i = _for_i->cdr, node = _for_i->car) { + for (_for_i = root, node = root->u.s.car; _for_i->kind == SEXPR_CONS; + _for_i = _for_i->u.s.cdr, node = _for_i->u.s.car) { if (node->kind != SEXPR_VALUE) continue; - id = xenDaemonDomainLookupByName_ids(conn, node->value, NULL); + id = xenDaemonDomainLookupByName_ids(conn, node->u.value, NULL); if (id >= 0) ids[ret++] = (int) id; if (ret >= maxids) @@ -2715,8 +2714,8 @@ xenDaemonNumOfDomains(virConnectPtr conn ret = 0; - for (_for_i = root, node = root->car; _for_i->kind == SEXPR_CONS; - _for_i = _for_i->cdr, node = _for_i->car) { + for (_for_i = root, node = root->u.s.car; _for_i->kind == SEXPR_CONS; + _for_i = _for_i->u.s.cdr, node = _for_i->u.s.car) { if (node->kind != SEXPR_VALUE) continue; ret++; @@ -2884,11 +2883,11 @@ xenDaemonDomainGetVcpus(virDomainPtr dom memset(cpumaps, 0, maxinfo * maplen); /* scan the sexprs from "(vcpu (number x)...)" and get parameter values */ - for (s = root; s->kind == SEXPR_CONS; s = s->cdr) { - if ((s->car->kind == SEXPR_CONS) && - (s->car->car->kind == SEXPR_VALUE) && - !strcmp(s->car->car->value, "vcpu")) { - t = s->car; + for (s = root; s->kind == SEXPR_CONS; s = s->u.s.cdr) { + if ((s->u.s.car->kind == SEXPR_CONS) && + (s->u.s.car->u.s.car->kind == SEXPR_VALUE) && + !strcmp(s->u.s.car->u.s.car->u.value, "vcpu")) { + t = s->u.s.car; vcpu = ipt->number = sexpr_int(t, "vcpu/number"); if ((oln = sexpr_int(t, "vcpu/online")) != 0) { if (sexpr_int(t, "vcpu/running")) ipt->state = VIR_VCPU_RUNNING; @@ -2905,14 +2904,14 @@ xenDaemonDomainGetVcpus(virDomainPtr dom * get sexpr from "(cpumap (x y z...))" and convert values * to bitmap */ - for (t = t->cdr; t->kind == SEXPR_CONS; t = t->cdr) - if ((t->car->kind == SEXPR_CONS) && - (t->car->car->kind == SEXPR_VALUE) && - !strcmp(t->car->car->value, "cpumap") && - (t->car->cdr->kind == SEXPR_CONS)) { - for (t = t->car->cdr->car; t->kind == SEXPR_CONS; t = t->cdr) - if (t->car->kind == SEXPR_VALUE) { - cpu = strtol(t->car->value, NULL, 0); + for (t = t->u.s.cdr; t->kind == SEXPR_CONS; t = t->u.s.cdr) + if ((t->u.s.car->kind == SEXPR_CONS) && + (t->u.s.car->u.s.car->kind == SEXPR_VALUE) && + !strcmp(t->u.s.car->u.s.car->u.value, "cpumap") && + (t->u.s.car->u.s.cdr->kind == SEXPR_CONS)) { + for (t = t->u.s.car->u.s.cdr->u.s.car; t->kind == SEXPR_CONS; t = t->u.s.cdr) + if (t->u.s.car->kind == SEXPR_VALUE) { + cpu = strtol(t->u.s.car->u.value, NULL, 0); if (cpu >= 0 && (VIR_CPU_MAPLEN(cpu+1) <= maplen)) { VIR_USE_CPU(cpumap, cpu); } @@ -3434,8 +3433,8 @@ xenDaemonNumOfDefinedDomains(virConnectP ret = 0; - for (_for_i = root, node = root->car; _for_i->kind == SEXPR_CONS; - _for_i = _for_i->cdr, node = _for_i->car) { + for (_for_i = root, node = root->u.s.car; _for_i->kind == SEXPR_CONS; + _for_i = _for_i->u.s.cdr, node = _for_i->u.s.car) { if (node->kind != SEXPR_VALUE) continue; ret++; @@ -3464,12 +3463,12 @@ int xenDaemonListDefinedDomains(virConne ret = 0; - for (_for_i = root, node = root->car; _for_i->kind == SEXPR_CONS; - _for_i = _for_i->cdr, node = _for_i->car) { + for (_for_i = root, node = root->u.s.car; _for_i->kind == SEXPR_CONS; + _for_i = _for_i->u.s.cdr, node = _for_i->u.s.car) { if (node->kind != SEXPR_VALUE) continue; - names[ret++] = strdup(node->value); + names[ret++] = strdup(node->u.value); if (ret >= maxnames) break; }

2 2

Fwd: [Libvir] Updated Solaris dom0 patch (part 1)
by Mark Johnson 28 Sep '07

28 Sep '07

sorry, missed the cc..... ---------- Forwarded message ---------- From: Mark Johnson <johnson.nh(a)gmail.com> Date: Sep 28, 2007 4:09 PM Subject: Re: [Libvir] Updated Solaris dom0 patch (part 1) To: "Daniel P. Berrange" <berrange(a)redhat.com> On 9/28/07, Daniel P. Berrange <berrange(a)redhat.com> wrote: > On Fri, Sep 28, 2007 at 03:03:15PM -0400, Mark Johnson wrote: > > > > I've broken this patch up into a few pieces to make > > it more reviewable and tried to address the comments > > from the previous patch (Jun 15th'ish if your looking). > > > > Here is first part... > > > > tested on today's CVS bits on a FC7 dom0 > > (LD_PRELOAD=src/.libs/libvirt.so src/.libs/virsh) > > > > One note, it looks like you still need a xend change on > > FC7 before the no kernel/bootloader option works. It > > looks like it's close though.. works fine with them > > of course. > > > > > > More details... > > > > > > [root@fedora solaris]# cat guest.py > > name = "solaris" > > vcpus = 1 > > memory = "512" > > > > #bootloader = "/usr/bin/pygrub" > > #kernel = "/platform/i86xpv/kernel/unix" > > #ramdisk = "/platform/i86pc/boot_archive" > > extra = "-k" > > > > root = "/dev/dsk/c0d0s0" > > disk = ['file:/export/guests/solaris/disk.img,0,w'] > > Oooh, that's interesting. Can you explain a little about Solaris paravirt > disk naming, since it doesn't use xvdN/hdN/sdN style config ? No, it uses a disk #... 0, 1, 2, 3, 4.. We also have a PV :cdrom e.g. for an install... disk = ['file:/tank/guests/install/solaris/66-0624-nd.iso,6:cdrom,r', 'file:/tank/guests/install/solaris/disk.img,0,w'] > Does the > HVM disk naming still use the named devs ? Yes. That is the same. > Also one other question. There is a config option > > builder='linux' > > Which is never used on Linux since 'linux' is the default. Do you change > the default on Solaris, or dooes the existing 'linux' builder work just > fine with Solaris DomU images ? I guess the latter, since the SEXPR > you have below is using 'linux'. Yep, we use the linux domain builder... > > [root@fedora solaris]# xm list -l solaris > > (domain > > (on_crash destroy) > > (uuid 72f9b45e-4be9-bf1f-a500-3707b9c3922c) > > (bootloader_args ) > > (vcpus 1) > > (name solaris) > > (on_poweroff destroy) > > (on_reboot restart) > > (bootloader ) > > Since I notice it has the bootloader bit in the SEXPR, I'm thinking I'll > tweak our XML generation so it at least includes an empty <bootloade/> > since there may be tools using libvirt which expect at least one of <os> > or <bootloader> and using an empty tag may keep them happier. > > eg, it'd probably avoid this problem... OK. MRJ > > virsh # console solaris > > libvir: Xen Daemon error : internal error domain information incomplete, missing kernel & bootloader > > domain.xml:25: parser error : Opening and ending tag mismatch: os line 4 and domain > > </domain> > > ^ > > domain.xml:26: parser error : Premature end of data in tag domain line 1 > > > Though obviously your patch fixes that too. > > 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] [RFC][PATCH 1/2] Tested NUMA patches for available memory and topology
by beth kon 28 Sep '07

28 Sep '07

Patch for accessing available memory. -- Elizabeth Kon (Beth) IBM Linux Technology Center Open Hypervisor Team email: eak(a)us.ibm.com

5 12

[Libvir] PATCH: Fix crash parsing input devices for QEMU
by Daniel P. Berrange 28 Sep '07

28 Sep '07

There is an edge case in parsing of input devices where if you have a PS2 mouse defined, before a USB tablet, it could generate a null pointer deference & thus crash. Normally you'd only have one pointer defined, but one might add a USB tablet for getting a improved mouse experience. 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 -=|

2 1

[Libvir] [RFC][PATCH 2/2] Tested NUMA patches for available memory and topology
by beth kon 28 Sep '07

28 Sep '07

Patch for accessing topology information. -- Elizabeth Kon (Beth) IBM Linux Technology Center Open Hypervisor Team email: eak(a)us.ibm.com

1 0

[Libvir] PATCH: Allow remote driver to handle any connection URI
by Daniel P. Berrange 28 Sep '07

28 Sep '07

We currently have logic in the remote driver so that it handles the local QEMU driver URIs, so they get re-directed to the daemon. It also handles networking APIs for Xen driver. For normal APIs, Xen has the auto-spawned setuid proxy daemon. This was very useful at the time we wrote it, but it only supports a handful of operations, and only in read-only mode. One other factor is that SUSE, for example, do not ship it because it is setuid. I don't know whether this is just a general policy, or just because they've not had time to audit it, but that's not very good for their users. With the development of the remote driver & the flexible UNIX socket perms & group ownership, or with policykit support it is possible to replace the proxy with calls straight to the remote daemon. So this patch is the first step by allowing the remote driver to handle any hypervisor connection URI. If it doesn't have a hostname or transport specified, then it automatically tries to connect to the local libvirt daemon over UNIX sockets. 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 -=|

4 7

[Libvir] virt-df (a 'df' tool for virtual domains)
by Richard W.M. Jones 27 Sep '07

27 Sep '07

Brave (or foolhardy?) souls may want to try out the almost-working version of 'virt-df' that I wrote: hg clone http://hg.et.redhat.com/virt/applications/virt-top--devel Usage is similar to ordinary 'df'. It understands the -h (human-readable) and -i (show inodes) options. You need to run it on the dom0, it won't work remotely. # virt-df.opt -c qemu:///system debian32kvm /dev/hda (3.9 GiB) /var/lib/xen/images/debian32kvm.img hda1 3662792 990276 2672516 Linux ext2/3 hda5 232908 Linux swap [The numbers are 1K blocks total, used, available] # virt-df.opt -c qemu:///system -h debian32kvm /dev/hda (3.9 GiB) /var/lib/xen/images/debian32kvm.img hda1 3.5 GiB 967.1 MiB 2.5 GiB Linux ext2/3 hda5 227.4 MiB Linux swap From the README file: virt-df is a 'df' tool for printing out the used and available disk space in all active and inactive domains. Without this tool you would need to log in to each domain individually or set up monitoring. It is only a proof-of-concept. Please bare in mind the following limitations when using this tool: (1) It does not work over remote connections. Part of the reason why I wrote virt-df was to get an idea of how the remote storage API for libvirt might look. (2) It only understands a limited set of partition types. Assuming that the files and partitions that we get back from libvirt / Xen correspond to block devices in the guests, we can go some way towards manually parsing those partitions to find out what they contain. We can read the MBR, EBR, superblocks and so on. However that's a lot of parsing work, and currently there is no library which understands a wide range of partition schemes and filesystem types (not even libparted which doesn't support LVM yet). The Linux kernel does support that, but there's not really any good way to access that work. The current implementation uses a hand-coded parser which understands some simple formats (MBR, EBR, ext2/3, not LVM yet but coming soon). In future we should use something like libparted. (3) The statistics you get are delayed. The real state of, for example, an ext2 filesystem is only stored in the memory of the guest's kernel. The ext2 superblock contains some meta-information about blocks used and free, but this superblock is not up to date. In fact the guest kernel may not update it even on a 'sync', not until the filesystem is unmounted. Some operations do appear to write the superblock, for example fsync(2) [that is my reading of the ext2/3 source code at least]. $ wc -l virt-df/*.ml 84 virt-df/virt_df_ext2.ml 24 virt-df/virt_df_linux_swap.ml 22 virt-df/virt_df_lvm2.ml 5 virt-df/virt_df_main.ml 460 virt-df/virt_df.ml 595 total 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 4

[Libvir] topology test program
by beth kon 27 Sep '07

27 Sep '07

Daniel, As we discussed, here is the program I was using for testing different topology strings. -- Elizabeth Kon (Beth) IBM Linux Technology Center Open Hypervisor Team email: eak(a)us.ibm.com

1 0

[Libvir] /etc/sysconfig/keyboard syntax subtilities
by Guillaume Rousse 27 Sep '07

27 Sep '07

virtmanager split content of /etc/sysconfig/keyboard on '"' for determining keyboard. On mandriva system, there isn't any quote in this file: see http://qa.mandriva.com/show_bug.cgi?id=34190 Here is a patch making parsing of this file a bit more robust. -- Guillaume Rousse Moyens Informatiques - INRIA Futurs Tel: 01 69 35 69 62

2 1

[Libvir] trouble using ssh tunnel for remote hypervisor
by Guillaume Rousse 27 Sep '07

27 Sep '07

Hello. I'm trying to use ssh tunnel for remote hypervisor access. However, I'm can't make it working... [guillaume@oberkampf ~]$ LC_ALL=C virsh --connect xen+ssh://root@acacia.futurs.inria.fr list --all libvir: error : could not connect to xen:// error: failed to connect to the hypervisor error: no valid connection On the remote host: [root@acacia ~]# libvirtd --verbose libvir: error : could not connect to xen:// It seems the error lies between libvirtd and the local hypervisor. And indeed, local usage of virsh with xen:// URLs fail: [root@acacia ~]# LC_ALL=C virsh -c xen:// list libvir: error : could not connect to xen:// error: failed to connect to the hypervisor error: no valid connection Using xen:///, instead of xen://, as explained at http://libvirt.org/uri.html, is OK, despite a few error messages: [root@acacia ~]# LC_ALL=C virsh -c xen:/// list libvir: Remote error : No such file or directory libvir: warning : Failed to find the network: Is the daemon running ? Id Name State ---------------------------------- 0 Domain-0 running 1 barman blocked 2 cocktail blocked 3 mojito blocked >From the documentation, it seems xen:// transport implies TLS, and requires an host name, so it is quite normal it fails here (I didn't generated any certificate). But how can I force libvirtd to use xen:/// transport then ? I don't see anything related in libvirt configuration documentation at http://libvirt.org/remote.html ? Neither about how to configure it for listening on unix transport, as explained in svn+ssh transport requirements on the same page (but I presume it is the default) ? Also, from where does those error and warning come ? [root@acacia ~]# LC_ALL=C virsh -c xen:/// list libvir: Remote error : No such file or directory libvir: warning : Failed to find the network: Is the daemon running ? [..] I'm using libvirt 0.3.2 on mandriva 2007.1, with xen 3.1.0. -- Guillaume Rousse Moyens Informatiques - INRIA Futurs Tel: 01 69 35 69 62

4 4

[Libvir] python libvirt methods to virDomainBlockStats and virDomainInterfaceStats
by Marco Sinhoreli 27 Sep '07

27 Sep '07

Hello all, I'm using libvirt from cvs, and in libvirt.h there are virDomainBlockStats, and virDomainInterfaceStats calls. I think it is compiled into libvirtmod, then I'm trying to write two methods, blockStats, and interfacesStats in the class virDomain at the libvirt.py library file. I'm not a specialist in python programming and it's not working. Bellow folow the code I have been wrote: def blockStats(self): """Block device stats for virDomainBlockStats """ ret = libvirtmod.virDomainBlockStats(self._o) if ret is None: raise libvirtError ('virDomainBlockStats() failed', dom=self) return ret def interfaceStats(self): """Network interface stats for virDomainInterfaceStats.""" ret = libvirtmod.virDomainInterfaceStats(self._o) if ret is None: raise libvirtError ('virDomainInterfaceStats() failed', dom=self) return ret Any help will be welcome. Best regards -- Marco Sinhoreli

2 3

[Libvir] [RFC][PATCH 1/2] NUMA memory and topology patches
by beth kon 26 Sep '07

26 Sep '07

[PATCH 1/2] - add capability to access free memory information on each NUMA cell. Signed-off-by: Beth Kon (eak(a)us.ibm.com) -- Elizabeth Kon (Beth) IBM Linux Technology Center Open Hypervisor Team email: eak(a)us.ibm.com

4 9

[Libvir] [PATCH] virsh NUMA command freecell
by Daniel Veillard 26 Sep '07

26 Sep '07

Useful for testing the virNodeGetCellsFreeMemory() call, it requires the 3 precedent NUMA patches. The patch lack the documentation update. The function takes an optional argument which is the cell number. If no cell is provided it will print the total free memory available on the Node. A more useful function would be to find the cell with the most available memory, but that one should still be useful and not just for testing. 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/

1 0

[Libvir] [RFC][PATCH 2/2] NUMA memory and topology patches
by beth kon 25 Sep '07

25 Sep '07

[PATCH 2/2] - add capability to access topology information (cell to cpu mapping) for each numa cell. Signed-off-by: Beth Kon (eak(a)us.ibm.com) -- Elizabeth Kon (Beth) IBM Linux Technology Center Open Hypervisor Team email: eak(a)us.ibm.com

2 1

[Libvir] [RFC][PATCH 0/2] NUMA memory and topology patches
by beth kon 25 Sep '07

25 Sep '07

I am reposting an updated patch for accessing NUMA cell available memory, and posting the initial patch for accessing NUMA topology information. Again, this code is primarily untested. I am looking for comments in parallel with the testing I will begin tomorrow. These patches prereq Daniel Veillard's initial framework patch: https://www.redhat.com/archives/libvir-list/2007-September/msg00069.html [PATCH 1/2] - add capability to access free memory information on each NUMA cell. [PATCH 2/2] - add capability to access topology information (cell to cpu mapping) for each numa cell. I have not yet added the full node available memory API call that was discussed on the list. As I understand the NUMA code is more urgent. If you would like to get this code in too, I can create another patch for that. My focus for the moment is testing. Signed-off-by: Beth Kon (eak(a)us.ibm.com) -- Elizabeth Kon (Beth) IBM Linux Technology Center Open Hypervisor Team email: eak(a)us.ibm.com

1 0

[Libvir] RFC PATCH - Initial NodeGetCellsFreeMemory patch
by beth kon 24 Sep '07

24 Sep '07

Here is my first pass at a patch for accessing the available memory associated with each NUMA cell through libvirt. The initial framework patch provided by Daniel Veillard is a prereq of this patch: https://www.redhat.com/archives/libvir-list/2007-September/msg00069.html I have not yet tested this. I'm just distributing for comments. A few comments/questions: 1) I think I got the versioning stuff right but that deserves a close look. 2) In Daniel's patch, libvirt.h and libvirt.h.in were identical. I assumed the patch would be before running autogen.sh, and only contain changes in libvirt.h.in, so that's how I did mine. Let me know if I misunderstand something here. 3) I had to put #ifdef PROXY around calls to virXenErrorFunc in xenHypervisorNodeGetCellsFreeMemory to get this to build. I haven't figured out how the proxy code works so am not sure if this is the right approach. -- Elizabeth Kon (Beth) IBM Linux Technology Center Open Hypervisor Team email: eak(a)us.ibm.com

3 6

[Libvir] Remotely starting a fully-virtualized guest
by Meng Kuan 24 Sep '07

24 Sep '07

Hi, I am trying to start a fully virtualized guest called "full1" remotely. The connection URI I am using is "xen+ssh://root@dell1/". (Note that I am able to start/stop/resume/shutdown para-virtualized guests without any problems with this connection URI.) The XML definition for the fully virtualized guest is this: <domain type='xen'> <name>full1</name> <os> <type>hvm</type> <loader>/usr/lib/xen/boot/hvmloader</loader> <boot dev='hd'/> </os> <memory>1048576</memory> <vcpu>2</vcpu> <on_poweroff>destroy</on_poweroff> <on_reboot>restart</on_reboot> <on_crash>restart</on_crash> <features> <acpi/> <apic/> <pae/> </features> <clock offset='utc'/> <devices> <emulator>/usr/lib64/xen/bin/qemu-dm</emulator> <interface type='bridge'> <source bridge='xenbr0'/> <script path='vif-bridge'/> </interface> <disk type='file' device='disk'> <driver name='file'/> <source file='/xen/full1.img'/> <target dev='hda'/> </disk> <graphics type='vnc' port='5904'/> </devices> </domain> The guest failed to start up and this is what I found in the xend.log file: [2007-09-24 18:55:46 xend.XendDomainInfo 4176] DEBUG (XendDomainInfo: 190) XendDomainInfo.create(['vm', ['name', 'full1'] , ['memory', '1024'], ['maxmem', '1024'], ['vcpus', '2'], ['on_poweroff', 'destroy'], ['on_reboot', 'restart'], ['on_crash ', 'restart'], ['image', ['hvm', ['kernel', '/usr/lib/xen/boot/ hvmloader'], ['device_model', '/usr/lib64/xen/bin/qemu-dm '], ['vcpus', '2'], ['boot', 'c'], ['acpi', '1'], ['apic', '1'], ['pae', '1'], ['usb', '1'], ['vnc', '1'], ['vncdisplay' , '4']]], ['device', ['vbd', ['dev', 'hda:disk'], ['uname', 'file:/ xen/full1.img'], ['mode', 'w']]], ['device', ['vif', ['bridge', 'xenbr0'], ['script', 'vif-bridge'], ['type', 'ioemu']]]]) [2007-09-24 18:55:46 xend.XendDomainInfo 4176] DEBUG (XendDomainInfo: 296) parseConfig: config is ['vm', ['name', 'full1' ], ['memory', '1024'], ['maxmem', '1024'], ['vcpus', '2'], ['on_poweroff', 'destroy'], ['on_reboot', 'restart'], ['on_cras h', 'restart'], ['image', ['hvm', ['kernel', '/usr/lib/xen/boot/ hvmloader'], ['device_model', '/usr/lib64/xen/bin/qemu-d m'], ['vcpus', '2'], ['boot', 'c'], ['acpi', '1'], ['apic', '1'], ['pae', '1'], ['usb', '1'], ['vnc', '1'], ['vncdisplay ', '4']]], ['device', ['vbd', ['dev', 'hda:disk'], ['uname', 'file:/ xen/full1.img'], ['mode', 'w']]], ['device', ['vif', ['bridge', 'xenbr0'], ['script', 'vif-bridge'], ['type', 'ioemu']]]] [2007-09-24 18:55:46 xend.XendDomainInfo 4176] DEBUG (XendDomainInfo: 397) parseConfig: result is {'shadow_memory': None, 'start_time': None, 'uuid': None, 'on_crash': 'restart', 'on_reboot': 'restart', 'localtime': None, 'image': ['hvm', [' kernel', '/usr/lib/xen/boot/hvmloader'], ['device_model', '/usr/lib64/ xen/bin/qemu-dm'], ['vcpus', '2'], ['boot', 'c'], ['acpi', '1'], ['apic', '1'], ['pae', '1'], ['usb', '1'], ['vnc', '1'], ['vncdisplay', '4']], 'on_poweroff': 'destroy', 'bootloader_args': None, 'cpus': None, 'name': 'full1', 'backend': [], 'vcpus': 2, 'cpu_weight': None, 'features': None, 'vcpu_avail': None, 'memory': 768, 'device': [('vbd', ['vbd', ['dev', 'hda:disk'], ['uname', 'file:/xen/full1.img'], [' mode', 'w']]), ('vif', ['vif', ['bridge', 'xenbr0'], ['script', 'vif- bridge'], ['type', 'ioemu']])], 'bootloader': None, 'cpu': None, 'maxmem': 768} [2007-09-24 18:55:46 xend.XendDomainInfo 4176] DEBUG (XendDomainInfo: 1264) XendDomainInfo.construct: None [2007-09-24 18:55:46 xend.XendDomainInfo 4176] DEBUG (XendDomainInfo: 1296) XendDomainInfo.initDomain: 91 1.0 [2007-09-24 18:55:46 xend 4176] DEBUG (image:329) args: boot, val: c [2007-09-24 18:55:46 xend 4176] DEBUG (image:329) args: fda, val: None [2007-09-24 18:55:46 xend 4176] DEBUG (image:329) args: fdb, val: None [2007-09-24 18:55:46 xend 4176] DEBUG (image:329) args: soundhw, val: None [2007-09-24 18:55:46 xend 4176] DEBUG (image:329) args: localtime, val: None [2007-09-24 18:55:46 xend 4176] DEBUG (image:329) args: serial, val: None [2007-09-24 18:55:46 xend 4176] DEBUG (image:329) args: std-vga, val: None [2007-09-24 18:55:46 xend 4176] DEBUG (image:329) args: isa, val: None [2007-09-24 18:55:46 xend 4176] DEBUG (image:329) args: vcpus, val: 2 [2007-09-24 18:55:46 xend 4176] DEBUG (image:329) args: acpi, val: 1 [2007-09-24 18:55:46 xend 4176] DEBUG (image:329) args: usb, val: 1 [2007-09-24 18:55:46 xend 4176] DEBUG (image:329) args: usbdevice, val: None [2007-09-24 18:55:46 xend 4176] DEBUG (image:329) args: k, val: None [2007-09-24 18:55:46 xend.XendDomainInfo 4176] ERROR (XendDomainInfo: 202) Domain construction failed Traceback (most recent call last): File "/usr/lib64/python2.4/site-packages/xen/xend/ XendDomainInfo.py", line 195, in create vm.initDomain() File "/usr/lib64/python2.4/site-packages/xen/xend/ XendDomainInfo.py", line 1309, in initDomain self.info['device']) File "/usr/lib64/python2.4/site-packages/xen/xend/image.py", line 45, in create return findImageHandlerClass(imageConfig)(vm, imageConfig, deviceConfig) File "/usr/lib64/python2.4/site-packages/xen/xend/image.py", line 75, in __init__ self.configure(imageConfig, deviceConfig) File "/usr/lib64/python2.4/site-packages/xen/xend/image.py", line 272, in configure self.dmargs += self.configVNC(imageConfig) File "/usr/lib64/python2.4/site-packages/xen/xend/image.py", line 383, in configVNC ret += ['-vnc', '%d' % vncdisplay] TypeError: int argument required [2007-09-24 18:55:46 xend.XendDomainInfo 4176] DEBUG (XendDomainInfo: 1463) XendDomainInfo.destroy: domid=91 [2007-09-24 18:55:46 xend.XendDomainInfo 4176] DEBUG (XendDomainInfo: 1471) XendDomainInfo.destroyDomain(91) [2007-09-24 18:55:46 xend 4176] ERROR (SrvBase:88) Request create failed. Traceback (most recent call last): File "/usr/lib64/python2.4/site-packages/xen/web/SrvBase.py", line 85, in perform return op_method(op, req) File "/usr/lib64/python2.4/site-packages/xen/xend/server/ SrvDomainDir.py", line 82, in op_create raise XendError("Error creating domain: " + str(ex)) XendError: Error creating domain: int argument required It seems that xend got a string instead of an integer for the vnc port. I modified the file "image.py" at line 383 from this ret += ['-vnc', '%d' % vncdisplay] to this: ret += ['-vnc', '%s' % vncdisplay] Restarted xend for the change to take effect and then try starting the guest again. This time the guest gets created but its state does not change to "running". # xm list Name ID Mem(MiB) VCPUs State Time(s) Domain-0 0 451 2 r----- 356.7 full1 88 773 1 ------ 0.0 I removed the following vnc line from the xml definition and try again: <graphics type='vnc' port='5904'/> The guest gets created but again its state is not "running". According to xml format documentation the <graphics> tag is required. At this point I am stumped. Any ideas what else I can try? cheers, mengkuan

2 2

[Libvir] PATCH 0/5: Rework the configure script
by Daniel P. Berrange 24 Sep '07

24 Sep '07

The following series of patches re-work the configure to solve a number of issues. I'll describe each one alongside its respective patch... 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 -=|

6 28

Re: [Libvir] RFC PATCH - Initial NodeGetCellsFreeMemory patch
by beth kon 21 Sep '07

21 Sep '07

oops... meant to post to list as well beth kon wrote: > Daniel Veillard wrote: > >> On Thu, Sep 20, 2007 at 05:10:49PM -0400, beth kon wrote: >> >> >>> Here is my first pass at a patch for accessing the available memory >>> associated with each NUMA cell through libvirt. >>> >> >> Thanks ! >> >> > Thanks for the quick comments! > >>> +struct xen_v2s4_availheap { >>> + uint32_t min_bitwidth; /* Smallest address width (zero if don't >>> care). */ >>> + uint32_t max_bitwidth; /* Largest address width (zero if don't >>> care). */ >>> >> >> I'm a bit puzzled by those 2 fields I still wonder what it is about :-) >> >> >> > I was puzzled too! These fields are related to the case when 32 bit > guests need to reserve certain ranges of memory for DMA, for example. > I checked with Ryan and he assured me we don't need to worry about > those fields for these purposes. > >>> + int32_t node; /* NUMA node (-1 for sum across all nodes). */ >>> + uint64_t avail_bytes; /* Bytes available in the specified region. */ >>> +}; >>> + >>> +typedef struct xen_v2s4_availheap xen_v2s4_availheap; >>> + >>> >> [...] >> >> > What does [...] mean? :-) > >> >> >>> +xenHypervisorNodeGetCellsFreeMemory(virConnectPtr conn, long long >>> *freeMems, >>> + int startCell, int maxCells) >>> { >>> - if ((conn == NULL) || (freeMems == NULL) || (nbCells < 0)) >>> - return -1; >>> + xen_op_v2_sys op_sys; >>> + int i, ret, nbCells; >>> + virNodeInfo nodeInfo; >>> + virNodeInfoPtr nodeInfoPtr = &nodeInfo; >>> + xenUnifiedPrivatePtr priv; >>> + >>> + if ((conn == NULL) || (freeMems == NULL) || (maxCells < 0)) >>> + return -1; >>> >> >> Hum, actually, that would catch the (maxCells == -1) so that won't work >> and won't catch maxCells == 0 which could lead to a segfault. Maybe >> (maxCells == 0) || (maxCells < -1) should be used instead. >> >> >> > Yes, you're right. I added maxcells = -1 and startCell as an > afterthought, and it shows! > >>> + /* get actual number of cells */ >>> + if (xenDaemonNodeGetInfo(conn, nodeInfoPtr)) { >>> >> >> Hum, since the number of cells is static, maybe this should be stored >> permanently in a variable on init. The xenDaemon RPC will be orders >> of magnitude >> more expensive than the direct hypercall below. >> >> >> >>> + virXenError(VIR_ERR_XEN_CALL, " cannot determine actual number of >>> cells", 0); >>> + return -1; >>> + } >>> + nbCells = nodeInfoPtr->nodes; >>> + >>> + if (maxCells > nbCells) >>> + maxCells = nbCells; >>> >> >> >> > I wondered about that. Would you like me to make that change as part > of this patch? > >> Hum ... maxCells is the number of entries in the array, I'm afraid >> you will >> need 2 counters or I misunderstood the way the API works (possible :-), >> I would fill in freeMems[] starting at index 0 for startCell, and >> going up. >> That feels more coherent than leaving uninitialized values at the >> start of >> the array: >> >> for (i = startCell, j = 0;(i < nbCells) && (j < maxCells);i++,j++) { >> op_sys.u.availheap.node = i; >> ret = xenHypervisorDoV2Sys(priv->handle, &op_sys); >> if (ret < 0) >> return(-1); >> freeMems[j] = op_sys.u.availheap.avail_bytes; >> } >> return (j); >> >> >> > Yes, right again! > > Thanks so much for the great feedback! > -- Elizabeth Kon (Beth) IBM Linux Technology Center Open Hypervisor Team email: eak(a)us.ibm.com

2 1

[Libvir] How to deploy Virtual Machine via libvirt
by Omer Khalid 21 Sep '07

21 Sep '07

Hi, I have been using libvirt in my python software for a while just to get deployed domain information. Usually I create a xen configuration file with all the parameters and trigger a "xm create -f file" command to deploy the VM. The problem I have noticed since some time is that as this command is forwarded from Python to Xen, and no error code is returned; I loose track if the domain deployment request fails which is rare but happens. So I thought to use libvirt for virtual machine deployment, and wondered if there are python bindings which I could use. I also try to look up for some kind of small example code to deploy a VM via libvirt on the libvirt site but didn't succeed to find. Can any body help me out with their experience? Thanks, Omer -- ---------------------------------------------------------- CERN – European Organization for Nuclear Research, IT Department, CH-1211 Geneva 23, Switzerland Phone: +41 (0) 22 767 2224 Fax: +41 (0) 22 766 8683 E-mail : Omer.Khalid(a)cern.ch Homepage: http://cern.ch/Omer.Khalid

2 3

[Libvir] Java bindings
by Tóth István 21 Sep '07

21 Sep '07

Hello! A development version of the java bindings I've been working on are available at : http://tiger.3ginformatika.hu/java-libvirt.tgz I'd appreciate your feedback on it. Building: Have java/gcc set up correctly through alternatives ( I use jpackage sun java 1.5.0 on Fedora 7 x86_64) Fix the include path in jni/Makefile run build.sh You should have the .so and .jar files built, and see the output from the basic test program. Using: See the test in build.sh Note: It's meant to be a thin translation layer on top of libvirt. The object model is similar to the python one. All error handling is done exclusively through exceptions. No documentation yet, but It's pretty self-explanatory. The build system is very primitive, I just hacked together something to build it outside my eclipse devel environment. The bindings are pretty complete, but minimally tested. License is LGPL. Best regards István

3 6

[Libvir] [PATCH] add no_tty flag for ssh
by Richard W.M. Jones 21 Sep '07

21 Sep '07

This patch adds an extra no_tty=1 flag to the connection URI. This stops ssh from asking for a password if it can't log in automatically. Typical use-case for this is in graphical programs where if ssh asks for a password it would cause the GUI program to hang. Example: $ virsh -c xen+ssh://xxx/ list rjones@xxx's password: Permission denied, please try again. rjones@xxx's password: Permission denied, please try again. rjones@xxx's password: Permission denied (publickey,gssapi-with-mic,password). libvir: Remote error : Connection reset by peer error: failed to connect to the hypervisor error: no valid connection $ virsh -c xen+ssh://xxx/?no_tty=1 list Permission denied (publickey,gssapi-with-mic,password). libvir: Remote error : Connection reset by peer error: failed to connect to the hypervisor error: no valid connection 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 8

[Libvir] PATCH: Do proper URI parsing for QEMU driver
by Daniel P. Berrange 21 Sep '07

21 Sep '07

The QEMU driver doesn't cope with URI parameters appended to the end of a path since it is just doing strcmp on the URI. This patch makes it use libxml's URI parsing code 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 -=|

2 2

[Libvir] [PATCH] detect path of dnsmasq, brctl
by Richard W.M. Jones 20 Sep '07

20 Sep '07

I have found 3 bugs in libvirtd in the way that it runs the external programs dnsmasq and brctl. Bug (1) is that it searches the $PATH to find dnsmasq. This is normally OK when libvirtd is launched from start-up scripts, but it's not very helpful if you run libvirtd by hand because likely-as-not your path won't contain /usr/sbin (the normal location of dnsmasq). Bug (2) is that if libvirtd can't execvp dnsmasq, then it doesn't fail in any obvious way. Bug (3) is that the path to brctl is hard-coded. This patch fixes bugs (1) & (3), but does not fix bug (2). Firstly configure has been changed so that it searches for dnsmasq and brctl programs in the usual places. If it find them then it generates a config.h file which looks like this: -------------------- /* Location or name of the brctl program (see bridge-utils) */ #define BRCTL "/usr/sbin/brctl" /* Location or name of the dnsmasq program */ #define DNSMASQ "/usr/sbin/dnsmasq" -------------------- If it doesn't find them then it just includes the program names, not full paths: -------------------- /* Location or name of the brctl program (see bridge-utils) */ #define BRCTL "brctl" /* Location or name of the dnsmasq program */ #define DNSMASQ "dnsmasq" -------------------- The code continues to use execvp to actually run the programs, so if the program names contain '/' then the absolute paths are used directly, otherwise execvp will do a shell-like search for the program along $PATH. Please nota bene the change to the spec file. Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903

2 2

Re: [Libvir] PATCH: Explicit detection of KVM version
by Daniel P. Berrange 20 Sep '07

20 Sep '07

On Thu, Sep 20, 2007 at 10:45:03AM +0200, Gerd Hoffmann wrote: > Daniel P. Berrange wrote: > > Before starting any guest, the QEMU driver needs to figure out what version > > of QEMU is in use & thus determine whether it supports particular command > > line flags. We currently do that just by calling /usr/bin/qemu, since all > > the various qemu-system-XXX binaries share the same syntax. The only problem > > is that qemu-kvm does not neccessarily match the version of qemu installed. > > So we detect QEMU version 0.8.2, but KVM is 0.9.0 based. The result is that > > we pass the wrong style VNC argument to KVM & it fails to start. The second > > problem is that even if you only ever want to run KVM guests, you still have > > to have KVM itself installed. > > We have the same problem if the domain.xml has > "<emulator>/path/to/qemu-foo</emulator>" specified, which I think isn't > addressed by this patch ... Nope it is not addressed. I think maybe instead of detecting once for QEMU and KVM for the QEMU driver as whole, I'll move the flags into the per-VM data structure. This will have extra overhead, since for each distinct VM we'll have todo a test launch of QEMU, but VM creation is not a performance bottleneck so I don't think its an issue. 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 1

[Libvir] PATCH: Remove Xen Proxy driver
by Daniel P. Berrange 20 Sep '07

20 Sep '07

Since the previous patch allows the remote daemon to serve all the functions of the current Xen Proxy driver, this patch simply removes the Xen proxy and its driver. $ diffstat .hg/patches/remote-proxy Makefile.am | 2 a/proxy/.cvsignore | 5 a/proxy/Makefile.am | 19 a/proxy/libvirt_proxy.c | 852 ------------------------------------ a/src/proxy_internal.c | 1124 ------------------------------------------------ a/src/proxy_internal.h | 116 ---- src/Makefile.am | 1 src/xen_unified.c | 51 -- src/xen_unified.h | 9 9 files changed, 15 insertions(+), 2164 deletions(-) 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] [PATCH] Add support for virConnectGetHostname and virConnectGetURI for qemu
by Richard W.M. Jones 20 Sep '07

20 Sep '07

Specifically this just adds support for virConnectGetHostname on qemu:/// URIs. Because of the way that the qemu driver now works, calls to virConnectGetURI are answered by the remote driver before the qemu driver ever sees them, so they have worked all along. 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 3

[Libvir] PATCH: Explicit detection of KVM version
by Daniel P. Berrange 20 Sep '07

20 Sep '07

Before starting any guest, the QEMU driver needs to figure out what version of QEMU is in use & thus determine whether it supports particular command line flags. We currently do that just by calling /usr/bin/qemu, since all the various qemu-system-XXX binaries share the same syntax. The only problem is that qemu-kvm does not neccessarily match the version of qemu installed. So we detect QEMU version 0.8.2, but KVM is 0.9.0 based. The result is that we pass the wrong style VNC argument to KVM & it fails to start. The second problem is that even if you only ever want to run KVM guests, you still have to have KVM itself installed. This patch tweaks the feature/version detection so we do separate detection just for KVM. With this applied I can successfully start KVM guests if the QEMU version is different, or even if QEMU is not installed. 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 2

[Libvir] [PATCH] virConnectNumOfDefinedDomains should set virterror if cannot connect to xend
by Richard W.M. Jones 19 Sep '07

19 Sep '07

As well as $SUBJECT this also adds a comment so that the apparent lack of error in another part of the code is clear. Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903

3 2

[Libvir] PATCH: Cleanup conditionals from proxy driver in Xen code
by Daniel P. Berrange 19 Sep '07

19 Sep '07

The various xen drivers have alot of their code conditionally compiled using #ifdef PROXY to avoid functions when built into the proxy. Without the proxy this is no longer needed. There are a couple of functions that were only used by the proxy & so can go completely. $ diffstat .hg/patches/proxy-cpp-cleanup xen_internal.c | 24 +------------------ xend_internal.c | 70 +++----------------------------------------------------- xml.c | 2 - xs_internal.c | 59 +---------------------------------------------- 4 files changed, 8 insertions(+), 147 deletions(-) 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 -=|

2 1

[Libvir] PATCH: Allow control over UNIX socket perms & group in libvirtd
by Daniel P. Berrange 19 Sep '07

19 Sep '07

When I submitted the patches for PolicyKit[1] support a few weeks back Rich suggested that we should have the ability to set UNIX socket permissions and group ownership regardless. So this patch adds that ability. The default setting is still, group=root, and mode=0700 for R/W socket and mode=0777 for the R/O socket. It is possible to override this via the config file eg, Don't allow R/O monitoring unix_sock_ro_perms="0700" eg, Allow any user in 'admin' group to manage VMs unix_sock_group="admin" unix_sock_rw_perms="0770" eg, Allow anyone todo anything unix_sock_rw_perms="0777" NB, the fchgrp, and fchown syscalls don't have any effect on sockets, so to set the group ownership & desired mode, I have to play games with the setgid() and umask() calls prior to bind(), and then restore them to their original values. NB, the virConf apis don't seem to recognise Octal numbers when parsing the config file, so I've used strings for the permissions. Not a big deal really unless someone desperately wants to fix the config file parser... Dan. [1] A new set of patches will be forthcoming soon... -- |=- 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 -=|

2 3

[Libvir] PATCH: Avahi advertisement for libvirtd
by Daniel P. Berrange 19 Sep '07

19 Sep '07

This is a serious patch at supporting Avahi advertisement of the libvirtd service. - configure by default will probe to see if avahi is available and if found will enable appropriate code. --with-avahi will force error if not found --without-avahi will disable it with no checking - HAVE_AVAHI is defined in config.h if avahi is found & used to conditionally enable some code in qemud/qemud.c - HAVE_AVAHI is also a Makefile conditional to enable compilation of the mdns.c and mdns.h files. A little makefile rearrangement was needed to make sure variables like EXTRA_DIST were defined before we appended to them with += - The code in mdns.c contains all the support for dealing with the Avahi APIs. - The primary Avahi API is horribily complicated for day-to-day use in application code, exposing far too much of the event loop and state machine. So we expose a simplified API to libvirt in mdns.h - We fully support the Avahi state machine, so you can start libvirt even if Avahi is not running on the machine. If you later start Avahi, then libvirt will automatically detect & register with it. Likewise if you stop Avahi we handle that gracefully by shutting down our internal mdns support & waiting for avahi to restart. NB this does require that the DBus system bus daemon is running. This is a limitation of the current Avahi client library & not our use of it. It is expected this will be fixed in future avahi releases. - The Avahi client library is basically a shim which talks to the Avahi daemon using DBus system daemon. The DBus stuff doesn't leak out of the Avahi APIs - it is loosely couple - all we need do is provide Avahi with an event loop implementation which was surprisingly easy. The libvirtd daemon does now indirectly link with DBus, but I don't see any problem with this. Don't want it - then use --without-avahi - We advertise a service name of _libvirt._tcp The IETF draft recommends use of the name from /etc/services associated with your app. There is a way to register official Avahi services names. We don't have an /etc/service name registered either though. - If TLS is *not* enabled, we advertise _libvirt._tcp with a port number of 0. The use of a port number 0 is explicitly allowed by the IETF draft docs - see [1] "8. Flagship Naming". If seeing the _libvirt._tcp service with a port of 0, then clients should figure out some way to to tunnel to the UNXI domain socket on the advertised machine. The tunnel mechanism is undefined, though SSH is the obvious choice. If TLS is enabled, then we use getsockname() to fetch the actual port number we're listening on for the TLS enabled socket. This plays nice with admins ability to override the port number. Clients can still of course choose to tunnel instead of use TLS. NB. we explicitly refuse to advertise the non-TLS port. - The default service name we advertise is 'Virtualization Host %h' where '%h' is the short hostname (ie without domain name). This has to be less than 63 characters & stripping domain name is usual practice, since this is implicit from the mdns domain you are browsing. This can be overridden with mdns_name="Blah" in the libvirtd.conf configuration file. Service names *must* be unique in the LAN. If a name clashes, then avahi appends junk like #1, #2, #3... until it is unique. - Even when compiled in, use of Avahi mdns can be disabled by setting the mdns_adv=0 config file parameter in /etc/libvirt/libvirtd.conf - This patch does not advertise any per-VM VNC server instances, but I have prepared the APIs in mdns.h to be ready to support that with minimal effort. A pre-requisite for this is an extension to the driver API to get async signals when VMs start & stop, since making the daemon poll hypervisors will suck big time. When implemented each VM will be its own mdns 'group' and the VNC server associated with it will be the 'service' advertised in that group. Having applied this patch & started the daemon, if /etc/init.d/avahi-daemon is running, you should see the service advertised on the LAN. As mentioned earlier if you start Avahi daemon after libvirt it should detect this too. You can verify by running the following on another box on the same local LAN segment. $ avahi-browse --resolve _libvirt._tcp When you start libvirtd on the other box the avahi-browse should print out a record. It should look like this: + eth0 IPv4 Virtualization Host avocado _libvirt._tcp local = eth0 IPv4 Virtualization Host avocado _libvirt._tcp local hostname = [avocado.local] address = [10.13.7.48] port = [16514] txt = ["org.freedesktop.Avahi.cookie=3025088350"] If you've not configured TLS, then port will be '0' instead of 16514. So that brings me nicely onto the main outstanding issue. Notice the hostname is 'avocado.local' - this is the standard mdns practice for zero-conf DNS hostnames. If you're /etc/nsswitch.conf is setup correctly the name avocado.local will actually resolve to the IP address you see there of '10.13.7.48' (well s/avocado/your hostname/ of course). Well, x509 certificates include a FQDN in them & the client is expected to validate the certificate hostname against the hostname it connected to. Now my FQDN is avocado.virt.boston.redhat.com which is obviously going to not validate against avocado.local. There're a couple of ways around this issue I can come up with so far - Recommend that the client try to reverse-DNS the 'address' field from the mdns advertisement. If reverse-DNS is working, 10.13.7.48 will be transformed into 'avocado.virt.boston.redhat.com' which the client can then connect to. - Add TXT record containing the hostname associated with the certificate. If the client were to use this record, then obviously any validation of it against the resulting certificate is sort-of pointless, since both came from the server. The first approach rather had this drawback too. - Advertise the records in the real domain 'virt.boston.redhat.com' instead of '.local'. Not been able to make this work. - Simply don't bother validating the remote hostname against the server certificate cname. ie, take the position that if using zero-conf then you already have some implicit level of trust in your LAN and validating the cert against the CA cert is sufficient & hostname matching can be ignored. These are all mildy abusing mdns / zeroconf, but then x509 certificates don't really fit into the model of 'zero conf' in the first place. If people want true zero-conf then the (SSH) tunnel is better (and always available), but if they've setup certificates they should still be allowed to use zero-conf to at least locate hosts. So mildly abusing the rules is reasonable IMHO. Personally I'm tending towards the latter approach. Regards, Dan. [1] http://files.dns-sd.org/draft-cheshire-dnsext-dns-sd.txt -- |=- 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] PATCH: Allow updating of timer & file handle event watches
by Daniel P. Berrange 19 Sep '07

19 Sep '07

The forthcoming patch to add Avahi support requires a couple of enhancements to our event loop to support integration with Avahi's event callback needs - Ability to update the event mask for a pre-existing file handle watch - Ability to change the frequency of a timer watch - Ability to have a timer which fires immediately - Ability to disable events on a timer watch The first point was trivial - just change the 'events' flag we have recorded in the virEventHandle struct. The second point was also trivial - just change the period of the timer as recorded in virEventTimer struct. The last two points were more tricky, but doable. To fire a timer immediately I tweaked the logic so that it allows a frequency of '0'. Obviously to avoid spinning 100%, the app should unregister the timer once it has fired the desired number of times (usually 1). To disable a timer temporarily I allow the use of '-1' in the frequency. THe code had a bad mix of terminology using a 'timer' and 'timeout' field in the virEventTimer struct which confused me no end. So I renamed the 'timeout' field to 'frequency' which reflects its actual purpose. Finally, when building with debugging, the event loop can generate alot of data, so I added a EVENT_DEBUG macro to the file which prefixes EVENT: on all debug output so allow easy filtering. 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 -=|

2 3

[Libvir] PATCH: Disable automake portability warnings
by Daniel P. Berrange 19 Sep '07

19 Sep '07

The latest automake has a nasty habit of complaining about use of GNU Make features such as wildcards. We use these extensively in the tests/ directory since there are so many test datafiles, listing them explicitly is a waste of time. The attached patch passes the -Wno-portability flag to automake to make it keep quiet. NB, to do this required a bit of a re-working of the automake/autoconf initialization stuff. Our current configure script uses AC_INIT and AM_INIT_AUTOMAKE in the so called 'legacy style'. To quote the automake manual [quote] If your `configure.ac' has: AC_INIT([src/foo.c]) AM_INIT_AUTOMAKE([mumble], [1.5]) you can modernize it as follows: AC_INIT([mumble], [1.5]) AC_CONFIG_SRCDIR([src/foo.c]) AM_INIT_AUTOMAKE [/quote] This re-arrangement is valid on any non-jurassic era automake & only impacts developers running autogen.sh - not end users running the configure script itself. The one complication is that the version given to AC_INIT must be a literal, but we currently used an environment variable. So m4 black-magic gets around this problem. I also killed LIBVIRT_VERSION_EXTRA since it is not referenced anywhere in the source tree. 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 -=|

2 2

[Libvir] Network blocking issue
by Shuveb Hussain 17 Sep '07

17 Sep '07

Hi, I observed this while using the python bindings and accessing a remote host with libvirt: >>> import libvirt >>> c = libvirt.open('xen://veetee/') >>> c.getInfo() ['i686', 2021, 2, 1864, 1, 1, 2, 1] >>> c.getInfo() ['i686', 2021, 2, 1864, 1, 1, 2, 1] # remove network cable from remote machine now >>> c.getInfo() # blocks forever.... What is the problem here and is there a solution to this? I am running FC7 and here is the version info from virsh: virsh # version Compiled against library: libvir 0.3.2 Using library: libvir 0.3.2 Using API: Xen 3.0.1 Running hypervisor: Xen 3.1.0 I observed this for more than 10 mins, it was still hung. Thanks in advance! -- Shuveb Hussain. Money has nothing to do with Happiness, But, Poverty has a lot to do with Sorrow. Company: www.binarykarma.com Blog: www.binarykarma.org

4 9

[Libvir] NUMA topology calls
by beth kon 17 Sep '07

17 Sep '07

Daniel, We agreed that xenHypervisorGetCapabilities will call a xend_internal.c function to get the topology through xend. Was your intent to extend xenDaemonNodeGetInfo or have a new function, such as xenDaemonNodeGetTopology? I assumed a new function would be cleaner, but you didn't include such a function in your patch so I'm not sure if you had some other idea. -- Elizabeth Kon (Beth) IBM Linux Technology Center Open Hypervisor Team email: eak(a)us.ibm.com

2 1

[Libvir] PATCH: Prevent zombie ssh tunnels
by Daniel P. Berrange 17 Sep '07

17 Sep '07

I noticed that when using the SSH tunnel for the remote driver I ended up with alot of zombie SSH processes. We simply forgot to waitpid() on the child when a connection attempt failed, or when shutting down an open remote connection. Attached is a possible patch 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 -=|

4 10

[Libvir] RFC: Broadcast our presence with avahi
by Daniel P. Berrange 14 Sep '07

14 Sep '07

All the really trendy network services these days broadcast their presence on the LAN using mDNS. In Linux world this means becoming an Avahi client and registering our services. virt-manager is also able to become an Avahi client and browser for services. So you'll be able to let the user just pick a host straight off a list instead of typing in hostname. The attached patch does two things: - Extends our event loop implementation so it can modify the event mask associated with an FD, and the timeout associated with a timer. While you could simulate this with an add & remove, this has the possibility of failure (from malloc). Merely updating an existing event can be done without failure. Avahi needs this ability for its event loop integration - Added qemu/mdns.c file to actually provide the service information. This has two parts. The first section of code is taken straight from one of the Avahi example programs. The second section is a implementaiton of the Avahi event loop contract in terms of our event API - it works very nicely which says good things about design of our event loop Some things... - I arbitrarily picked a service type of '_libvirtd._tcp'. The docs on picking service types seem non-existant on Avahi website, but it seems to be common to use service name from /etc/services and protocol both prefixed with _. - I advertise two subtypes, of '_xen.libvirtd._tcp' and '_qemu.libvirtd._tcp' What I actually want todo is to be able to probe the libvirt local drivers to auto-discover what virtualization platforms are available. A sort of lightweight virConnectOpen which merely returns TRUE/FALSE and doesn't actually allocate a virConnectPtr object. Need to extend the internal driver API for this. - I want to advertise whether the server is configured with TLS certs or not, so remote clients can automatically choose to use SSH urls with the remote driver if neccessary. - Let the admin turn advertisement on/off in the config file because some people may not like it on their LAN. If you fancy trying it, avahi-browse --all from another host on the LAN should show the service being advertised. The advertisements do not cross LAN routers by default. 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 -=|

4 8