- Devel - libvirt List Archives

[libvirt] [PATCH] qemu -drive takes format= not fmt=
by Mark McLoughlin 16 Apr '09

16 Apr '09

Hey, Looks like a simple typo. Original addition of the flag to qemu was here: http://git.kernel.org/?p=virt/qemu/qemu.git;a=commitdiff;h=1e72d3b7 and support added to libvirt by this: http://git.et.redhat.com/?p=libvirt.git;a=commitdiff;h=74ce659266 Cheers, Mark. From: Mark McLoughlin <markmc(a)redhat.com> Subject: [PATCH] qemu -drive takes format= not fmt= Seems like a simple typo - it has been "format=" since the flag was introduced, but we added it as "fmt=". Signed-off-by: Mark McLoughlin <markmc(a)redhat.com> --- src/qemu_conf.c | 2 +- .../qemuxml2argv-disk-drive-cache-v1-none.args | 2 +- .../qemuxml2argv-disk-drive-cache-v1-wb.args | 2 +- .../qemuxml2argv-disk-drive-cache-v1-wt.args | 2 +- .../qemuxml2argv-disk-drive-cache-v2-none.args | 2 +- .../qemuxml2argv-disk-drive-cache-v2-wb.args | 2 +- .../qemuxml2argv-disk-drive-cache-v2-wt.args | 2 +- .../qemuxml2argv-disk-drive-fmt-qcow.args | 2 +- .../qemuxml2argv-disk-drive-shared.args | 2 +- 9 files changed, 9 insertions(+), 9 deletions(-) diff --git a/src/qemu_conf.c b/src/qemu_conf.c index f36c927..6f9e610 100644 --- a/src/qemu_conf.c +++ b/src/qemu_conf.c @@ -1135,7 +1135,7 @@ int qemudBuildCommandLine(virConnectPtr conn, disk->device == VIR_DOMAIN_DISK_DEVICE_DISK) virBufferAddLit(&opt, ",boot=on"); if (disk->driverType) - virBufferVSprintf(&opt, ",fmt=%s", disk->driverType); + virBufferVSprintf(&opt, ",format=%s", disk->driverType); if (disk->cachemode) { const char *mode = diff --git a/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-cache-v1-none.args b/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-cache-v1-none.args index 67c8e0d..13b5dd5 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-cache-v1-none.args +++ b/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-cache-v1-none.args @@ -1 +1 @@ -LC_ALL=C PATH=/bin HOME=/home/test USER=test LOGNAME=test /usr/bin/qemu -S -M pc -m 214 -smp 1 -nographic -monitor pty -pidfile /nowhere/QEMUGuest1.pid -no-acpi -boot c -drive file=/dev/HostVG/QEMUGuest1,if=ide,index=0,fmt=qcow2,cache=off -drive file=/dev/HostVG/QEMUGuest2,if=ide,media=cdrom,index=2,fmt=raw -net none -serial none -parallel none -usb +LC_ALL=C PATH=/bin HOME=/home/test USER=test LOGNAME=test /usr/bin/qemu -S -M pc -m 214 -smp 1 -nographic -monitor pty -pidfile /nowhere/QEMUGuest1.pid -no-acpi -boot c -drive file=/dev/HostVG/QEMUGuest1,if=ide,index=0,format=qcow2,cache=off -drive file=/dev/HostVG/QEMUGuest2,if=ide,media=cdrom,index=2,format=raw -net none -serial none -parallel none -usb diff --git a/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-cache-v1-wb.args b/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-cache-v1-wb.args index 2b4fd34..2197cd0 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-cache-v1-wb.args +++ b/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-cache-v1-wb.args @@ -1 +1 @@ -LC_ALL=C PATH=/bin HOME=/home/test USER=test LOGNAME=test /usr/bin/qemu -S -M pc -m 214 -smp 1 -nographic -monitor pty -pidfile /nowhere/QEMUGuest1.pid -no-acpi -boot c -drive file=/dev/HostVG/QEMUGuest1,if=ide,index=0,fmt=qcow2,cache=on -drive file=/dev/HostVG/QEMUGuest2,if=ide,media=cdrom,index=2,fmt=raw -net none -serial none -parallel none -usb +LC_ALL=C PATH=/bin HOME=/home/test USER=test LOGNAME=test /usr/bin/qemu -S -M pc -m 214 -smp 1 -nographic -monitor pty -pidfile /nowhere/QEMUGuest1.pid -no-acpi -boot c -drive file=/dev/HostVG/QEMUGuest1,if=ide,index=0,format=qcow2,cache=on -drive file=/dev/HostVG/QEMUGuest2,if=ide,media=cdrom,index=2,format=raw -net none -serial none -parallel none -usb diff --git a/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-cache-v1-wt.args b/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-cache-v1-wt.args index 67c8e0d..13b5dd5 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-cache-v1-wt.args +++ b/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-cache-v1-wt.args @@ -1 +1 @@ -LC_ALL=C PATH=/bin HOME=/home/test USER=test LOGNAME=test /usr/bin/qemu -S -M pc -m 214 -smp 1 -nographic -monitor pty -pidfile /nowhere/QEMUGuest1.pid -no-acpi -boot c -drive file=/dev/HostVG/QEMUGuest1,if=ide,index=0,fmt=qcow2,cache=off -drive file=/dev/HostVG/QEMUGuest2,if=ide,media=cdrom,index=2,fmt=raw -net none -serial none -parallel none -usb +LC_ALL=C PATH=/bin HOME=/home/test USER=test LOGNAME=test /usr/bin/qemu -S -M pc -m 214 -smp 1 -nographic -monitor pty -pidfile /nowhere/QEMUGuest1.pid -no-acpi -boot c -drive file=/dev/HostVG/QEMUGuest1,if=ide,index=0,format=qcow2,cache=off -drive file=/dev/HostVG/QEMUGuest2,if=ide,media=cdrom,index=2,format=raw -net none -serial none -parallel none -usb diff --git a/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-cache-v2-none.args b/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-cache-v2-none.args index 7e6bea7..f4e5c1a 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-cache-v2-none.args +++ b/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-cache-v2-none.args @@ -1 +1 @@ -LC_ALL=C PATH=/bin HOME=/home/test USER=test LOGNAME=test /usr/bin/qemu -S -M pc -m 214 -smp 1 -nographic -monitor pty -pidfile /nowhere/QEMUGuest1.pid -no-acpi -boot c -drive file=/dev/HostVG/QEMUGuest1,if=ide,index=0,fmt=qcow2,cache=none -drive file=/dev/HostVG/QEMUGuest2,if=ide,media=cdrom,index=2,fmt=raw -net none -serial none -parallel none -usb +LC_ALL=C PATH=/bin HOME=/home/test USER=test LOGNAME=test /usr/bin/qemu -S -M pc -m 214 -smp 1 -nographic -monitor pty -pidfile /nowhere/QEMUGuest1.pid -no-acpi -boot c -drive file=/dev/HostVG/QEMUGuest1,if=ide,index=0,format=qcow2,cache=none -drive file=/dev/HostVG/QEMUGuest2,if=ide,media=cdrom,index=2,format=raw -net none -serial none -parallel none -usb diff --git a/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-cache-v2-wb.args b/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-cache-v2-wb.args index 2fd6b9f..273f68b 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-cache-v2-wb.args +++ b/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-cache-v2-wb.args @@ -1 +1 @@ -LC_ALL=C PATH=/bin HOME=/home/test USER=test LOGNAME=test /usr/bin/qemu -S -M pc -m 214 -smp 1 -nographic -monitor pty -pidfile /nowhere/QEMUGuest1.pid -no-acpi -boot c -drive file=/dev/HostVG/QEMUGuest1,if=ide,index=0,fmt=qcow2,cache=writeback -drive file=/dev/HostVG/QEMUGuest2,if=ide,media=cdrom,index=2,fmt=raw -net none -serial none -parallel none -usb +LC_ALL=C PATH=/bin HOME=/home/test USER=test LOGNAME=test /usr/bin/qemu -S -M pc -m 214 -smp 1 -nographic -monitor pty -pidfile /nowhere/QEMUGuest1.pid -no-acpi -boot c -drive file=/dev/HostVG/QEMUGuest1,if=ide,index=0,format=qcow2,cache=writeback -drive file=/dev/HostVG/QEMUGuest2,if=ide,media=cdrom,index=2,format=raw -net none -serial none -parallel none -usb diff --git a/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-cache-v2-wt.args b/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-cache-v2-wt.args index 07fe4f7..d5791f0 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-cache-v2-wt.args +++ b/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-cache-v2-wt.args @@ -1 +1 @@ -LC_ALL=C PATH=/bin HOME=/home/test USER=test LOGNAME=test /usr/bin/qemu -S -M pc -m 214 -smp 1 -nographic -monitor pty -pidfile /nowhere/QEMUGuest1.pid -no-acpi -boot c -drive file=/dev/HostVG/QEMUGuest1,if=ide,index=0,fmt=qcow2,cache=writethrough -drive file=/dev/HostVG/QEMUGuest2,if=ide,media=cdrom,index=2,fmt=raw -net none -serial none -parallel none -usb +LC_ALL=C PATH=/bin HOME=/home/test USER=test LOGNAME=test /usr/bin/qemu -S -M pc -m 214 -smp 1 -nographic -monitor pty -pidfile /nowhere/QEMUGuest1.pid -no-acpi -boot c -drive file=/dev/HostVG/QEMUGuest1,if=ide,index=0,format=qcow2,cache=writethrough -drive file=/dev/HostVG/QEMUGuest2,if=ide,media=cdrom,index=2,format=raw -net none -serial none -parallel none -usb diff --git a/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-fmt-qcow.args b/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-fmt-qcow.args index cc76fa4..577d353 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-fmt-qcow.args +++ b/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-fmt-qcow.args @@ -1 +1 @@ -LC_ALL=C PATH=/bin HOME=/home/test USER=test LOGNAME=test /usr/bin/qemu -S -M pc -m 214 -smp 1 -nographic -monitor pty -pidfile /nowhere/QEMUGuest1.pid -no-acpi -boot c -drive file=/dev/HostVG/QEMUGuest1,if=ide,index=0,boot=on,fmt=qcow2 -drive file=/dev/HostVG/QEMUGuest2,if=ide,media=cdrom,index=2,fmt=raw -net none -serial none -parallel none -usb +LC_ALL=C PATH=/bin HOME=/home/test USER=test LOGNAME=test /usr/bin/qemu -S -M pc -m 214 -smp 1 -nographic -monitor pty -pidfile /nowhere/QEMUGuest1.pid -no-acpi -boot c -drive file=/dev/HostVG/QEMUGuest1,if=ide,index=0,boot=on,format=qcow2 -drive file=/dev/HostVG/QEMUGuest2,if=ide,media=cdrom,index=2,format=raw -net none -serial none -parallel none -usb diff --git a/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-shared.args b/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-shared.args index 67c8e0d..13b5dd5 100644 --- a/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-shared.args +++ b/tests/qemuxml2argvdata/qemuxml2argv-disk-drive-shared.args @@ -1 +1 @@ -LC_ALL=C PATH=/bin HOME=/home/test USER=test LOGNAME=test /usr/bin/qemu -S -M pc -m 214 -smp 1 -nographic -monitor pty -pidfile /nowhere/QEMUGuest1.pid -no-acpi -boot c -drive file=/dev/HostVG/QEMUGuest1,if=ide,index=0,fmt=qcow2,cache=off -drive file=/dev/HostVG/QEMUGuest2,if=ide,media=cdrom,index=2,fmt=raw -net none -serial none -parallel none -usb +LC_ALL=C PATH=/bin HOME=/home/test USER=test LOGNAME=test /usr/bin/qemu -S -M pc -m 214 -smp 1 -nographic -monitor pty -pidfile /nowhere/QEMUGuest1.pid -no-acpi -boot c -drive file=/dev/HostVG/QEMUGuest1,if=ide,index=0,format=qcow2,cache=off -drive file=/dev/HostVG/QEMUGuest2,if=ide,media=cdrom,index=2,format=raw -net none -serial none -parallel none -usb -- 1.6.0.6

3 2

[libvirt] [PATCH] Make SELinuxSecurityDriverProbe() fail on Fedora 10
by Mark McLoughlin 16 Apr '09

16 Apr '09

Running "make check" on F10, I get: libvir: Security Labeling error : SELinuxInitialize: cannot open SELinux virtual domain context file /etc/selinux/targeted/contexts/virtual_domain_context: No such file or directory Failed to start security driverFAIL: seclabeltest Seems virtual_domain_context isn't available on F10. Haven't investigated further, just want to have "make check" pass. Signed-off-by: Mark McLoughlin <markmc(a)redhat.com> --- src/security_selinux.c | 8 +++++++- 1 files changed, 7 insertions(+), 1 deletions(-) diff --git a/src/security_selinux.c b/src/security_selinux.c index ac317d7..c0b4a67 100644 --- a/src/security_selinux.c +++ b/src/security_selinux.c @@ -218,7 +218,13 @@ done: static int SELinuxSecurityDriverProbe(void) { - return is_selinux_enabled() ? SECURITY_DRIVER_ENABLE : SECURITY_DRIVER_DISABLE; + if (!is_selinux_enabled()) + return SECURITY_DRIVER_DISABLE; + + if (!virFileExists(selinux_virtual_domain_context_path())) + return SECURITY_DRIVER_DISABLE; + + return SECURITY_DRIVER_ENABLE; } static int -- 1.6.0.6

3 2

[libvirt] [PATCH 1/1] changes in src/lxc_container.c so that it passes make syntax-check
by Pritesh Kothari 16 Apr '09

16 Apr '09

Hi All, This patch just clean up src/lxc_container.c so that the make syntax-check passes. Regards, Pritesh

2 1

[libvirt] [PATCH] Fix lxc syntax-check failure
by Mark McLoughlin 16 Apr '09

16 Apr '09

>From 7ebf401c747b61b44bdba0aebc85fbead7ec1d12 Mon Sep 17 00:00:00 2001 From: Mark McLoughlin <markmc(a)redhat.com> Date: Thu, 16 Apr 2009 11:36:41 +0100 Subject: Fixes: CHECK: avoid_if_before_free src/lxc_container.c: if (oldroot) VIR_FREE(oldroot) src/lxc_container.c: if (newroot) VIR_FREE(newroot) Makefile.maint: found useless "if" before "free" above and: src/lxc_container.c:317: Makefile.maint: found trailing blank(s) Signed-off-by: Mark McLoughlin <markmc(a)redhat.com> --- src/lxc_container.c | 16 ++++++++-------- 1 files changed, 8 insertions(+), 8 deletions(-) diff --git a/src/lxc_container.c b/src/lxc_container.c index ff115d1..67c66bd 100644 --- a/src/lxc_container.c +++ b/src/lxc_container.c @@ -282,9 +282,11 @@ static int lxcContainerChildMountSort(const void *a, const void *b) static int lxcContainerPivotRoot(virDomainFSDefPtr root) { - int rc; + int rc, ret; char *oldroot = NULL, *newroot = NULL; + ret = -1; + /* root->parent must be private, so make / private. */ if (mount("", "/", NULL, MS_PRIVATE|MS_REC, NULL) < 0) { virReportSystemError(NULL, errno, "%s", @@ -312,7 +314,7 @@ static int lxcContainerPivotRoot(virDomainFSDefPtr root) oldroot); goto err; } - + /* Create a directory called 'new' in tmpfs */ if (virAsprintf(&newroot, "%s/new", oldroot) < 0) { virReportOOMError(NULL); @@ -366,15 +368,13 @@ static int lxcContainerPivotRoot(virDomainFSDefPtr root) goto err; } + ret = 0; + +err: VIR_FREE(oldroot); VIR_FREE(newroot); - return 0; - -err: - if (oldroot) VIR_FREE(oldroot); - if (newroot) VIR_FREE(newroot); - return -1; + return ret; } static int lxcContainerPopulateDevices(void) -- 1.6.0.6

2 1

[libvirt] problem to connect to libvirtd as ordinary user
by Sebastian Reitenbach 16 Apr '09

16 Apr '09

Hi, I'm trying to setup an eucalyptus cloud managing my virtual xen nodes. I'm on SLES11, x86_64. I compiled libvirt-0.6.2 with the following configure parameters: ./configure --prefix=/usr --without-storage-iscsi --without-remote --without-sasl --without-openvz --without-storage-disk below the parameters I've set in the /etc/libvirt/libvirt.conf file: listen_tls = 0 listen_tcp = 1 unix_sock_group = "libvirt" unix_sock_ro_perms = "0777" unix_sock_rw_perms = "0777" unix_sock_dir = "/var/run/libvirt" auth_unix_ro = "none" auth_unix_rw = "none" auth_tcp = "none" auth_tls = "none" log_level = 1 log_outputs="0:stderr" as root, I can run "virsh list" or "virsh -c xen+unix:/// list" and it just works, however, I cannot do this as user eucalyptus. The user eucalyptus is a member of the libvirt group. # id eucalyptus uid=1000(eucalyptus) gid=1000(eucalyptus) groups=1000(eucalyptus),0(root),16 (dialout),17(audio),33(video),100(users),1001(libvirt) I ran virsh through strace, to see what happens: strace virsh.bin -c xen+unix:/// list ... open("/proc/xen/privcmd", O_RDWR) = -1 EACCES (Permission denied) ... Shouldn't the permissions of /proc/xen/privcmd be OK due to the libvirt.conf file? However, I changed them, and now the strace output looks like this: chmod 777 /proc/xen/privcmd strace virsh.bin -c xen+unix:/// list ... open("/proc/xen/privcmd", O_RDWR) = 3 ioctl(3, SNDCTL_DSP_RESET, 0x7fff4721a0f0) = 196611 mlock(0x7fff4721a070, 72) = 0 mlock(0x7fff47219f00, 136) = 0 ioctl(3, SNDCTL_DSP_RESET, 0x7fff47219d80) = -1 EACCES (Permission denied) munlock(0x7fff47219f00, 136) = 0 munlock(0x7fff4721a070, 72) = 0 mlock(0x7fff4721a070, 72) = 0 mlock(0x7fff47219f00, 136) = 0 ioctl(3, SNDCTL_DSP_RESET, 0x7fff47219d80) = -1 EACCES (Permission denied) munlock(0x7fff47219f00, 136) = 0 munlock(0x7fff4721a070, 72) = 0 mlock(0x7fff4721a070, 72) = 0 mlock(0x7fff47219f00, 136) = 0 ioctl(3, SNDCTL_DSP_RESET, 0x7fff47219d80) = -1 EACCES (Permission denied) munlock(0x7fff47219f00, 136) = 0 munlock(0x7fff4721a070, 72) = 0 mlock(0x7fff4721a070, 72) = 0 mlock(0x7fff47219f00, 136) = 0 ioctl(3, SNDCTL_DSP_RESET, 0x7fff47219d80) = 0 munlock(0x7fff47219f00, 136) = 0 munlock(0x7fff4721a070, 72) = 0 mlock(0x7fff47219e00, 136) = 0 ioctl(3, SNDCTL_DSP_RESET, 0x7fff47219d80) = 0 munlock(0x7fff47219e00, 136) = 0 close(3) = 0 ... actually, there is no sound card at all, I wonder what the SNDCTL_DSP_RESET is doing there. After the close(3), the virsh is only looking for language to generate the error message: error: failed to connect to the hypervisor Those xen versions are installed: xen-doc-pdf-3.3.1_18546_12-3.1 xen-doc-html-3.3.1_18546_12-3.1 xen-3.3.1_18546_12-3.1 xen-libs-3.3.1_18546_12-3.1 xen-tools-3.3.1_18546_12-3.1 xen-kmp-default-3.3.1_18546_12_2.6.27.19_5-3.1 kernel-xen-base-2.6.27.19-5.1 kernel-xen-2.6.27.19-5.1 xen-devel-3.3.1_18546_12-3.1 any idea what is wrong here? kind regards sebastian

2 2

[libvirt] [Docs] More work on the API and architecture
by Daniel Veillard 15 Apr '09

15 Apr '09

Another patch, incomplete adding a new page api.html[.in] with the goals of describing the main API concepts, architectures, naming conventions, etc ... It includes Dan's graphics and a change of how the stylesheet process the .html.in content allowing to turn <code class='docref'>foo</code> into a link to reference for foo in the API page. Ultimately I should be able to load the API description from the stylesheet and do that link generation automagically without any markup (like all the links in the API reference). Still need to write the drivers and remote sections, and augment some of the APIs entry points, but it's a first step and better in than out. Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel(a)veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/

2 2

[libvirt] XML network model type stripped on define.
by Adrian Garay 15 Apr '09

15 Apr '09

Greetings! I am currently testing Centos5.3, KVM-84, libvirt from the Centos default packages and a Vista 32 guest. I am unfortunately experiencing difficulties with the default realtek8139 network driver, the solution for which I've read would be to change the emulated network device type to e1000. When editing the xml file for my guest, I change: <interface type='bridge'> <mac address='00:16:3e:38:a8:ad'/> <source bridge='br0'/> </interface> to: <interface type='bridge'> <mac address='00:16:3e:38:a8:ad'/> <source bridge='br0'/> <model type='e1000'/> </interface> and then doing a: virsh --connect qemu:///system define /etc/libvirt/qemu/vista32.xml The correct guest is updated, but the model type information I've just added is stripped from my XML and I'm once again left with an 8139 emulated nic. According to the command: qemu-kvm -net nic,model=? /dev/null I should be able to use the e1000 driver. My sincerest apologies if this is already known, or I'm missing something terribly obvious. I am new to mailing lists (this would be my first!) Thanks in advance.

3 5

[libvirt] libvirt 0.3.3 and unix_sock_group
by Daniel Labrosse 15 Apr '09

15 Apr '09

Hi All, I've been using libvirt 0..4.4 for a few weeks now. I have unix_sock_group = "mygroup" set so that i can perform non-root management capabilities on the host. I have recently installed a new host running Scientific Linux 5.3 and libvirt 0.3.3 comes as default. First off, there is no libvirtd.conf file included with 0.3.3, so I copied the file from libvirt 0.4.4 (which is running on my Fedora 8 box). I am still unable to get non-root management capabilities (i.e virsh create etc) after a restart of libvirtd. Is this feature supported in libvirt 0.3.3? Perhaps the file format is different between versions and hence unix_sock_group isnt being read correctly? hope you can help. thanks Daniel

2 2

[libvirt] [PATCH] trivial fix for virsh return value bug
by Daniel Veillard 15 Apr '09

15 Apr '09

https://bugzilla.redhat.com/show_bug.cgi?id=495954 virsh ttyconsole [node] always sets a return code of 1 we initialize ret to FALSE, but don't set it to TRUE when the operation succeeds Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel(a)veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/

1 1

[libvirt] [PATCH] add some text to http://libvirt.org/drvlxc.html
by Serge E. Hallyn 15 Apr '09

15 Apr '09

--- drvlxc-orig.html 2009-04-15 09:36:48.000000000 -0500 +++ drvlxc.html 2009-04-15 09:44:27.000000000 -0500 @@ -140,7 +140,89 @@ </div> <div id="content"> - <h1>LXC container driver</h1> +<h1>LXC container driver</h1> +<p> +The libvirt LXC driver manages "Linux Containers". Containers are sets of processes +with private namespaces which can (but don't always) look like separate machines, but +do not have their own OS. Here are two example configurations. The first is a very +light-weight "application container" which does not have it's own root image. You would +start it using +</p> + +<h3>Example config version 1</h3> +<p> +<pre> +<domain type='lxc'> + <name>vm1</name> + <memory>500000</memory> + <os> + <type>exe</type> + <init>/bin/sh</init> + </os> + <vcpu>1</vcpu> + <clock offset='utc'/> + <on_poweroff>destroy</on_poweroff> + <on_reboot>restart</on_reboot> + <on_crash>destroy</on_crash> + <devices> + <emulator>/usr/libexec/libvirt_lxc</emulator> + <interface type='network'> + <source network='default'/> + </interface> + <console type='pty' /> + </devices> +</domain> +</pre> +</p> + +<p> +The next example assumes there is a private root filesystem +(perhaps hand-crafted using busybox, or installed from media, +debootstrap, whatever) under /opt/vm-1-root: +</p> +<p> +<pre> +<domain type='lxc'> + <name>vm1</name> + <memory>32768</memory> + <os> + <type>exe</type> + <init>/init</init> + </os> + <vcpu>1</vcpu> + <clock offset='utc'/> + <on_poweroff>destroy</on_poweroff> + <on_reboot>restart</on_reboot> + <on_crash>destroy</on_crash> + <devices> + <emulator>/usr/libexec/libvirt_lxc</emulator> + <filesystem type='mount'> + <source dir='/opt/vm-1-root'/> + <target dir='/'/> + </filesystem> + <interface type='network'> + <source network='default'/> + </interface> + <console type='pty' /> + </devices> +</domain> + +</pre> +</p> + +<p> +In both cases, you can define and start a container using: +<pre> +lxc --connect lxc:/// define v1.xml +lxc --connect lxc:/// start v1.xml +</pre> +and then get a console using: +<pre> +lxc --connect lxc:/// console v1 +</pre> +Now doing 'ps -ef' will only show processes in the container, for +instance. +</p> </div> </div> <div id="footer">

2 1

[libvirt] virsh ttyconsole [node] has rc of 1?
by Darryl L. Pierce 15 Apr '09

15 Apr '09

I have a script that's breaking when trying to get the ttyconsole for a node. The script gets the console by invoking: virsh ttyconsole [nodename] The script also has trap on error enabled, and the above command has a return code of 1. This is causing the script to exit at that point. Is this a bug? Or is there a reason that return code is 1 and not 0? -- Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc. Virtual Machine Management - http://www.ovirt.org/ Is fearr Gaeilge bhriste ná Béarla cliste.

2 1

[libvirt] How to prevent libvirt from adding iptables rules?
by Mariano Absatz 15 Apr '09

15 Apr '09

Hi, I'm new to libvirt but not a complete neophite. I'm using libvirt and kvm in ubuntu with "vmbuilder". I'm creating a couple of VMs inside a host that is directly connected to internet with a public routeable address. Since I only have one public address, I won't use bridging. I'm using shorewall (www.shorewall.net) to configure my iptables rules. I intend to use DNAT to route specific ports in the host to one or other VM. With standard masquerading, I give the VMs access to the outside world. At first I used the 'default' network (with a different rfc1918 network)... everything was kinda working until I rebooted the host... at that point I lost connectivity between the outside world and the VMs. From inside the host I had no trouble connecting to the VMs. If I restarted shorewall (which actually cleans all iptables rules and regenerate them according to its configuration) everything works fine. After sending a report and some debugging in the shorewall mailing list, it was clear that libvirt was adding rules to iptables. After reading a bit (http://libvirt.org/formatnetwork.html#examplesPrivate) I created a new network called "isolated". I stopped default (and disabled its autostart), and defined and started isolated. This is the content of isolated.xml: <network> <name>isolated</name> <uuid>51cffbcc-88f5-4edc-a81c-1765c1045691</uuid> <bridge name='virbr%d' stp='on' forwardDelay='0' /> <ip address='10.3.14.1' netmask='255.255.255.0'> <dhcp> <range start='10.3.14.128' end='10.3.14.254' /> </dhcp> </ip> </network> I modified my VMs to use isolated rather than default, but rules keep being added to iptables when libvirt-bin is started. Is there a way to convince libvirt not to add these rules? Feel free to ask for any data that I didn't send here. TIA. -- Mariano Absatz - "El Baby" el.baby(a)gmail.com www.clueless.com.ar -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- An expert is a person who has made all the mistakes that can be made in a very narrow field. Niels Bohr Danish physicist (1885 - 1962) -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- * TagZilla 0.066 * http://tagzilla.mozdev.org

5 11

[libvirt] Libvirt PHP binding
by Radek Hladik 15 Apr '09

15 Apr '09

Hi, I am trying to develop PHP binding for Libvirt API. As discussed previously on the list the best way is to create a ZEND extension. There is a great tutorial on the net ( http://devzone.zend.com/tag/Extension ) and PHP provides a lot of macros and functions to make extension writing easier. I've implemented functions for connecting, listing domains, getting info about domains and node, dumping domain XML, some basic domain life-cycle actions and very basic error reporting. Before moving to other functions I need to solve a few issues :-) The biggest issue is that PHP used from webserver can (and usually does) run multithread. One thread can process more than one request and the threads can run in parallel. PHP/ZEND provides "tools" to solve this. It provides "request-global" variables, resources (containers for objects like file handles or connection pointers) and much more. In single threaded environment (like calling from command line) all these fallback to usual behavior. In addition ZEND has its own memory manager to be able to better manage the memory on per request basis (functions are called emalloc(), efree(),...). One can still use malloc() and free() but this is bypassing the ZEND memory manager. Free()ing emalloced memory or vice versa leads to crash. So one thing is that every memory allocated by libvirt (using malloc()) I need to copy to memory allocated using emalloc(). Also every memory, that would be free()ed by libvirt I need to malloc() and copy from emmaloc()ed memory. The first one is done by simple macro: #define RECREATE_STRING_WITH_E(str_out, str_in) \ str_out = estrndup(str_in, strlen(str_in)); \ free(str_in); The second case I encountered only on authentication callback and I use simple strndup() to copy it for libvirt. When running from command line everything seems to work fine. This is of course singlethreaded and potential resource leaks need not to cause a problem. However when running from webserver, the result is much more interesting. When connecting to qemu:///system (via local socket) using <? libvirt_connect($uri,true); ?> I can crash the libvirt daemon after cca 10 page reloads - sometimes with message Apr 13 15:32:44 kvmtest kernel: libvirtd[8263]: segfault at 4 ip 00000039d7223fc0 sp 00007fa6fbc29a88 error 6 in libdbus-1.so.3.4.0[39d7200000+3c000] in system log, sometimes without any message. (When running the same script from command line it worked for 1000 executions without noticing a problem). When connecting to qemu+tcp:///system using credentials (explained later): <? libvirt_connect($uri,true,Array(VIR_CRED_AUTHNAME=>"fred",VIR_CRED_PASSPHRASE=>"fred")); ?> It works but httpd processes open a lot pipes and after a few hours with page refreshing every 10 sec I even ran into error: [Mon Apr 13 02:40:26 2009] [error] [client 10.38.25.152] PHP Warning: libvirt_connect() unable to make pipe: Too many open files Next issue I am not sure about is callbacks. I need them mainly for authentication. As PHP is intended to run the whole script non-interactively at most times, I've created this solution. When calling the libvirt_connect() PHP function you can provide list of credentials in form of an array Array(VIR_CRED_AUTHNAME=>"fred",VIR_CRED_PASSPHRASE=>"fred"). This PHP array is parsed to C array and this prepopulated array is passed to my authentication callback function. That function receives the requested credential, looks it up in the provided array and returns it. I think this suits more the PHP nature but in future I may provide real callback solution. Little trouble is that libvirt free()s the values returned by callback so I need to copy them to malloc()ed memory. I am not sure about multithread safety of callback functions but I think that if the function only obtains the parameters via cbdata and operates only with them then it should be safe. However sometimes I get error: [Mon Apr 13 14:19:48 2009] [error] [client 10.38.25.152] PHP Warning: libvirt_connect(): Failed to collect auth credentials and I need to restart http daemon for a few times to make it work again. The last trouble is with error callback, where I am not sure whether it is thread safe. I need to call PHP function for reporting error, storing the error in "global" variable for next use and the PHP may even terminate the whole processing of the request... And if you are still reading then I can point you to http://phplibvirt.cybersales.cz/ where you can download the source code and browse the documentation - you can find there list of implemented functions and brief instructions how to install the extension. But be warned it really can crash your libvirt and maybe apache! For completeness: I use Fedora 10 with some rawhide updates: httpd-2.2.11-6.x86_64 php-5.2.9-1.fc11.x86_64 php-devel-5.2.9-1.fc11.x86_64 libvirt-0.6.0-2.fc11.x86_64 qemu-0.9.1-12.fc11.x86_64 libvirt-devel-0.6.0-2.fc11.x86_64 php-cli-5.2.9-1.fc11.x86_64 kvm-83-5.fc10.x86_64 php-common-5.2.9-1.fc11.x86_64 Radek

3 8

[libvirt] [Patch] Fix vcpupin to inactive domains on Xend3.0.3.
by Takahashi Tomohiro 15 Apr '09

15 Apr '09

Hi, I made the patch that corrected the following problem. It is that when I execute the "virsh vcpupin" command to inactive domains on Xend3.0.3, Libvirt outputs the following Segmentation fault. # virsh vcpupin guest_dom 0 0,1,2 Segmentation fault Signed-off-by: Tomohiro Takahashi <takatom(a)jp.fujitsu.com> Thanks, Tomohiro Takahashi --- xm_internal.c.org 2009-04-07 21:50:17.000000000 +0900 +++ xm_internal.c 2009-04-13 20:53:22.000000000 +0900 @@ -1700,7 +1700,8 @@ int xenXMDomainPinVcpu(virDomainPtr doma ret = 0; cleanup: - VIR_FREE(mapstr); + if( *mapstr != '\0' ) + VIR_FREE(mapstr); VIR_FREE(cpuset); xenUnifiedUnlock(priv); return (ret);

2 3

[libvirt] [PATCH] lxc: Add lxcGetHostname()
by Dan Smith 15 Apr '09

15 Apr '09

This patch adds the getHostname method to the lxc driver structure (using the qemu driver's generic code). Apparently virsh started using that method during console attachment recently. Without this implementation, the virsh refused to attach to lxc consoles. Signed-off-by: Dan Smith <danms(a)us.ibm.com> -- Dan Smith IBM Linux Technology Center email: danms(a)us.ibm.com Index: src/lxc_driver.c =================================================================== RCS file: /data/cvs/libvirt/src/lxc_driver.c,v retrieving revision 1.65 diff -u -r1.65 lxc_driver.c --- src/lxc_driver.c 31 Mar 2009 15:47:17 -0000 1.65 +++ src/lxc_driver.c 14 Apr 2009 18:22:45 -0000 @@ -1404,6 +1404,20 @@ return ret; } +static char *lxcGetHostname (virConnectPtr conn) +{ + char *result; + + result = virGetHostname(); + if (result == NULL) { + virReportSystemError (conn, errno, + "%s", _("failed to determine host name")); + return NULL; + } + /* Caller frees this string. */ + return result; +} + /* Function Tables */ static virDriver lxcDriver = { VIR_DRV_LXC, /* the number virDrvNo */ @@ -1413,7 +1427,7 @@ NULL, /* supports_feature */ NULL, /* type */ lxcVersion, /* version */ - NULL, /* getHostname */ + lxcGetHostname, /* getHostname */ NULL, /* getMaxVcpus */ NULL, /* nodeGetInfo */ NULL, /* getCapabilities */

3 2

[libvirt] vcpuinfo returns wrong CPU value for kvm
by Gerrit Slomma 15 Apr '09

15 Apr '09

vcpuinfo returns a wrong value for kvm with libvirt 0.6.2: virsh # nodeinfo CPU-Modell: x86_64 CPU(s): 2 CPU-Frequenz: 2333 MHz CPU-Socket(s): 1 Kern(e) pro Socket: 2 Thread(s) pro Kern: 1 NUMA-Zelle(n): 1 Speichergrösse: 3062956 kB virsh # dominfo rr019v3 Id: 2 Name: rr019v3 UUID: ff1ba599-5801-fca9-ab33-8962c2dfa46c OS Typ: hvm Status: laufend CPU(s): 2 CPU-Zeit: 46,5s Max Speicher: 1572864 kB Verwendeter Speicher: 1572864 kB Automatischer Start: deaktiviert As default a kvm-vm has a affinity on all cpus provided by the node virsh # vcpuinfo rr019v3 VCPU: 0 CPU: 0 Status: laufend CPU-Affinität: yy VCPU: 1 CPU: 0 Status: laufend CPU-Affinität: yy When i set the affinity of the vCPUs to dedicated CPUs of the node vcpuinfo returns CPU 0 as the assigned CPU. virsh # vcpupin rr019v3 0 0 virsh # vcpupin rr019v3 1 1 virsh # vcpuinfo rr019v3 VCPU: 0 CPU: 0 Status: laufend CPU-Affinität: y- VCPU: 1 CPU: 0 Status: laufend CPU-Affinität: -y Furthermore even when pinning all - in my case both - vCPUs of the domain to the second CPU of the node virsh reports the first cpu as the assigned cpu. virsh # vcpupin rr019v3 0 1 virsh # vcpuinfo rr019v3 VCPU: 0 CPU: 0 Status: laufend CPU-Affinität: -y VCPU: 1 CPU: 0 Status: laufend CPU-Affinität: -y Watching at the code in virsh.c i am a little bit on my wits end where virVcpuInfoPtr is defined as i am no c-programmer - only some java on my side. On my xen-machine with libvirt 0.3.3 the CPU is shown correctly though: virsh vcpuinfo rr010v2 VCPU: 0 CPU: 0 Status: blockiert CPU-Zeit: 550,4s CPU-Affinität: y--- VCPU: 1 CPU: 1 Status: blockiert CPU-Zeit: 27,9s CPU-Affinität: -y-- VCPU: 2 CPU: 2 Status: blockiert CPU-Zeit: 31,2s CPU-Affinität: --y- VCPU: 3 CPU: 3 Status: blockiert CPU-Zeit: 49,1s CPU-Affinität: ---y Is this only working with the xen-driver?

2 1

[libvirt] [PATCH] lxc: stop rootless containers from messing with system mounts
by Serge E. Hallyn 15 Apr '09

15 Apr '09

If a container has no root, liblxc remounts /proc. If the system had marked / as MS_SHARED, then even though the container is in a new mounts namespace, the mount event is propagated back to the host mounts namespace, overwriting /proc. After that, for instance, ps will no longer show system processes. A Fedora 11 default install has / MS_SHARED. Make sure that root is not MS_SHARED before remounting /proc. I'm making it MS_SLAVE so that the container will receive mount events from the host, but not vice versa. Signed-off-by: Serge Hallyn <serue(a)us.ibm.com> --- src/lxc_container.c | 11 ++++++++++- 1 files changed, 10 insertions(+), 1 deletions(-) diff --git a/src/lxc_container.c b/src/lxc_container.c index d3959f6..8addd23 100644 --- a/src/lxc_container.c +++ b/src/lxc_container.c @@ -273,7 +273,11 @@ static int lxcContainerChildMountSort(const void *a, const void *b) #endif #ifndef MS_PRIVATE -#define MS_PRIVATE 1<<18 +#define MS_PRIVATE (1<<18) +#endif + +#ifndef MS_SLAVE +#define MS_SLAVE (1<<19) #endif static int lxcContainerPivotRoot(virDomainFSDefPtr root) @@ -558,6 +562,11 @@ static int lxcContainerSetupExtraMounts(virDomainDefPtr vmDef) { int i; + if (mount("", "/", NULL, MS_SLAVE|MS_REC, NULL) < 0) { + virReportSystemError(NULL, errno, "%s", + _("failed to make / slave")); + return -1; + } for (i = 0 ; i < vmDef->nfss ; i++) { // XXX fix to support other mount types if (vmDef->fss[i]->type != VIR_DOMAIN_FS_TYPE_MOUNT) -- 1.6.2

2 2

[libvirt] libvirt arch detection on x86_64 host
by Gerry Reno 15 Apr '09

15 Apr '09

I have a 64-bit host that is running a 32-bit OS (Fedora 10). # cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 16 model : 2 model name : AMD Phenom(tm) 9850 Quad-Core Processor stepping : 3 cpu MHz : 2511.416 cache size : 512 KB physical id : 0 siblings : 4 core id : 0 cpu cores : 4 apicid : 0 initial apicid : 0 fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 5 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs bogomips : 5022.83 clflush size : 64 power management: ts ttp tm stc 100mhzsteps hwpstate processor : 1 vendor_id : AuthenticAMD cpu family : 16 model : 2 model name : AMD Phenom(tm) 9850 Quad-Core Processor stepping : 3 cpu MHz : 2511.416 cache size : 512 KB physical id : 0 siblings : 4 core id : 1 cpu cores : 4 apicid : 1 initial apicid : 1 fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 5 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs bogomips : 5023.06 clflush size : 64 power management: ts ttp tm stc 100mhzsteps hwpstate processor : 2 vendor_id : AuthenticAMD cpu family : 16 model : 2 model name : AMD Phenom(tm) 9850 Quad-Core Processor stepping : 3 cpu MHz : 2511.416 cache size : 512 KB physical id : 0 siblings : 4 core id : 3 cpu cores : 4 apicid : 3 initial apicid : 3 fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 5 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs bogomips : 5023.06 clflush size : 64 power management: ts ttp tm stc 100mhzsteps hwpstate processor : 3 vendor_id : AuthenticAMD cpu family : 16 model : 2 model name : AMD Phenom(tm) 9850 Quad-Core Processor stepping : 3 cpu MHz : 2511.416 cache size : 512 KB physical id : 0 siblings : 4 core id : 2 cpu cores : 4 apicid : 2 initial apicid : 2 fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 5 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs bogomips : 5023.06 clflush size : 64 power management: ts ttp tm stc 100mhzsteps hwpstate # virsh nodeinfo CPU model: i686 CPU(s): 4 CPU frequency: 2511 MHz CPU socket(s): 1 Core(s) per socket: 4 Thread(s) per core: 1 NUMA cell(s): 1 Memory size: 4147340 kB # virsh capabilities <capabilities> <host> <cpu> <arch>i686</arch> </cpu> </host> <guest> <os_type>hvm</os_type> <arch name='i686'> <wordsize>32</wordsize> <emulator>/usr/bin/qemu</emulator> <machine>pc</machine> <machine>isapc</machine> <domain type='qemu'> </domain> <domain type='kvm'> <emulator>/usr/bin/qemu-kvm</emulator> </domain> </arch> <features> <pae/> <nonpae/> <acpi default='on' toggle='yes'/> <apic default='on' toggle='no'/> </features> </guest> <guest> <os_type>hvm</os_type> <arch name='x86_64'> <wordsize>64</wordsize> <emulator>/usr/bin/qemu-system-x86_64</emulator> <machine>pc</machine> <machine>isapc</machine> <domain type='qemu'> </domain> </arch> <features> <acpi default='on' toggle='yes'/> <apic default='on' toggle='no'/> </features> </guest> <guest> <os_type>hvm</os_type> <arch name='mips'> <wordsize>32</wordsize> <emulator>/usr/bin/qemu-system-mips</emulator> <machine>mips</machine> <domain type='qemu'> </domain> </arch> </guest> <guest> <os_type>hvm</os_type> <arch name='mipsel'> <wordsize>32</wordsize> <emulator>/usr/bin/qemu-system-mipsel</emulator> <machine>mips</machine> <domain type='qemu'> </domain> </arch> </guest> <guest> <os_type>hvm</os_type> <arch name='sparc'> <wordsize>32</wordsize> <emulator>/usr/bin/qemu-system-sparc</emulator> <machine>sun4m</machine> <domain type='qemu'> </domain> </arch> </guest> <guest> <os_type>hvm</os_type> <arch name='ppc'> <wordsize>32</wordsize> <emulator>/usr/bin/qemu-system-ppc</emulator> <machine>g3bw</machine> <machine>mac99</machine> <machine>prep</machine> <domain type='qemu'> </domain> </arch> </guest> </capabilities> Shouldn't the host arch have been detected and identified as x86_64? Regards, Gerry

3 3

[libvirt] test driver for interface config
by Laine Stump 15 Apr '09

15 Apr '09

I'm now trying to write the test driver for the interface config driver that I'm putting into libvirt. For comparison I'm using the network driver. My understanding so far is that it calls the functions in the real driver to construct network objects and manipulate them, then just doesn't call the code that makes the changes to the system config. My driver is a bit different, in that I don't need any object management - I just pass everything through to the netcf library, and return the results to the caller; libvirt is just being used as an RPC conduit with some minimal wrapping. What I'm wondering now is exactly what the test driver should be testing - should the test driver also call netcf and return the results, or should it be a minimal interface driver in its own right that, for example, comes up with no interfaces, and allows adding only one? The former (call netcf) is problematic in that many netcf functions make changes to the real live network config (which I don't think is a very nice thing to have in test code, but maybe I'm being over-cautious) and netcf doesn't have provisions for a test mode where changes made to the config aren't committed. In the latter case it seems that not a lot will be tested (just the client side API, and libvirt's RPC - all parameter checking and XML parsing will be done by netcf), although maybe that's all anyone is looking for. I would hesitate to make the driver any more complicated than just allowing a single interface, or do any parameter validation that's normally done by netcf, since then much of the testing would be of code that was only used in the test itself - not very productive. Any advice?

5 19

[libvirt] [PATCH 2/2] VirtualBox support
by Pritesh Kothari 14 Apr '09

14 Apr '09

Hi All, I have attached a patch which when applied on the HEAD as of today would allow virtualbox support in libvirt. It takes cares of all the stuff mentioned on the list earlier. Still if I have missed anything, please do tell me. The patch works very well with the VirtualBox OSE version and the 2.2 release. [PATCH 1/2] contains diff of files already in libvirt. [PATCH 2/2] contains new files needed for VirtualBox support. Regards, Pritesh

3 5

[libvirt] RFC: Import / export of Domain XML from/to native "formats"
by Daniel P. Berrange 14 Apr '09

14 Apr '09

Some of the frequently asked questions I see floating around various user forums / mailing lists wrt libvirt XML, relate the import or export of existing configurations from/to libvirt. eg - What is the libvirt XML matching the QEMU args 'qemu -foo -bar -wiz' - What are the QEMU arguments used by libvirt for XML config XYZ - What is the libvirt XML matching the Xen file XYZ in /etc/xen - What is the Xen config file corresponding to the libvirt XML XYZ When those questions arise, the best we do is point the user at wiki page or XML format docs, sometimes give them some examples, etc It occurred to me that we could do much better than this. We already have code in libvirt that knows how todo - libvirt XML -> QEMU args - libvirt XML -> Xen config file - Xen config file -> libvirt XML - Xen SEXPR -> libvirt XML - libvirt XML -> Xen SEXPR it is not possible to access this functionality directly though - it is used internally via things like the DumpXML / DefineXML commands. It would be helpful to be able to use these conversion functions directly in many cases, to be able to do conversions, without having to actually define a new VM. I did a proof of concept creating some tools - virt-xml-from-qemu-args - virt-xml-to-qemu-args - virt-xml-from-xen-config - virt-xml-to-xen-config - virt-xml-from-xen-sxpr - virt-xml-to-xen-sxpr that just linked directly to the internal conversion APIs. This is a bit of a hack though, and I think it might be preferable to have a formal public API for invoking the conversions, instead of restricting them to a set of command line tools. What I think we could do is: - char *virConnectDomainXMLExport(const char *nativeFormat, const char *xml) Export 'xml' doc from libvirt XML to a config in 'nativeFormat', returning the native config data - char *virConnectDomainXMLImport(const char *nativeFormat, const char *config) Import 'config' data in 'nativeFormat', to libvirt XML, returning the libvirt XML doc The 'nativeFormat' would be a hypervisor specific format. The QEMU driver would initially provide a format called 'qemu-argv'. The Xen driver would provide 2 formats 'xen-xm' and 'xen-sxpr'. Later the QEMU driver might also provide 'qemu-conf' as & when QEMU gets native config file format. Most of the hard code for these functions already exists. The only one missing is the QEMU ARGV -> libvirt XML conversion, but its not too hard to get a basic impl up & running. In virsh, we might expose virsh domxml-export [XMLFILE [CONFIGFILE]] virsh domxml-import [CONFIGFILE [XMLFILE]] Both these would read/write from/to STDIN/STDOUT, if their optional filename args were ommitted. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

2 1

[libvirt] [PATCH] fix build on RHEL and Centos
by Daniel Veillard 14 Apr '09

14 Apr '09

I applied the minimal fix below preventing "make rpm" on those two platforms, except it applies ot libvirt.spec.in, fixes #495610 Daniel --- libvirt.spec.orig 2009-04-13 20:49:11.000000000 -0400 +++ libvirt.spec 2009-04-13 20:49:59.000000000 -0400 @@ -46,6 +46,7 @@ %define with_rhel5 0 %else %define with_rhel5 1 +%define with_polkit 0 %endif -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel(a)veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/

1 0

[libvirt] Intro to libvirt-TCK (Technology Compatibility Kit)
by Daniel P. Berrange 14 Apr '09

14 Apr '09

This mail provides a braindump introduction to a testing system I've been working on for libvirt drivers. Also following that is a short guide on how to actually write test cases to give a better flavour of what its all about. Be warned, this is a very long email :-) libvirt TCK : Technology Compatibility Kit =========================================== The libvirt TCK provides a framework for performing testing of the integration between libvirt drivers, the underlying virt hypervisor technology, related operating system services and system configuration. The idea (and name) is motivated by the Java TCK In particular the libvirt TCK is intended to address the following scenarios - Validate that a new libvirt driver is in compliance with the (possibly undocumented!) driver API semantics - Validate that an update to an existing driver does not change the API semantics in a non-compliant manner - Validate that a new hypervisor release is still providing compatability with the corresponding libvirt driver usage - Validate that an OS distro deployment consisting of a hypervisor and libvirt release is configured correctly Thus the libvirt TCK will allow developers, administrators and users to determine the level of compatability of their platform, and evaluate whether it will meet their needs, and get awareness of any regressions that may have occurred since a previous test run In relation to other libvirt testing, the split of responsibiity will be libvirt testsuite (aka $CHECKOUT/tests) - unit testing of specific internal APIs - functional testing of the libvirtd using the 'test'+'remote' drivers - functional testing of the virsh command using the 'test' driver libvirt TCK - functional/integration testing of the 'live' drivers Framework requirements ====================== The libvirt TCK is built using Perl in order to take advantage of the advanced, but yet very simple, testing frameworks available with Perl. Thus the libvirt interactions will all be done via the libvirt Perl bindings, Sys::Virt (or perl-Sys-Virt RPMs) The framework is thus built on the following Perl modules - Test::More - simple framework for writing individual tests - TAP::Harness - simple framework for running sets of tests - Sys::Virt - binding for libvirt API - XML::Writer - module for generating XML documents - XML::Twig - module for parsing XML documents & XPath - Config::Record - module for parsing simple configuration files There are a handful of other modules these depend on, but these are the most important 'top level' modules in use. These is all currently available within Fedora 10, with exception of perl-accessors, perl-TAP-Formatter-HTML. A similar situation existss for RHEL-5 considering modules from EPEL-5 These modules are all well tested, actively maintained parts of Perl / CPAN, so easily available for every other operating system in existance. As a convenience I have published repositories for Fedora 10 and RHEL-5 on x86_64 including these modules. Use the following YUM configs For Fedora 10: [libvirt-tck] name=libvirt TCK baseurl=http://berrange.fedorapeople.org/libvirt-tck/yum-f10/x86_64/ gpgcheck=0 enabled=1 For RHEL-5: [libvirt-tck] name=libvirt TCK baseurl=http://berrange.fedorapeople.org/libvirt-tck/yum-rhel5/x86_64/ gpgcheck=0 enabled=1 NB: These repos assume you have already updated to the latest 0.6.2 libvirt RPM available for the distro in question. Overview of framework structure =============================== For following discussions, it may be convenient to refer to the source code of the framework. This is available from hg clone http://libvirt.org/hg/libvirt-tck First there are a couple of Perl modules to provide assistance when dealing with libvirt / writing tests - Sys::Virt::TCK in lib/Sys/Virt/TCK.pm The core module for connecting to libvirt, creating a clean environment (ie blowing away all existing domains), and generating simple XML configs for guests - Sys::Virt::TCK::DomainBuilder in lib/Sys/Virt/TCK/DomainBuilder.pm A helper for constructing XML configs for guest domains - Sys::Virt::TCK::Capabilities in lib/Sys/Virt/TCK/Capabilities.pm A helper for parsing the libvirt capabilities XML - Sys::Virt::TCK::TAP::XMLFormatter in lib/Sys//Virt/TCK/TAP/XMLFormatter.pm A plugin for TAP::Harness that is able to record all test results in a structured XML document. As mentioned before, the framework is built about Test:More and the TAP::Harness modules from Perl. This already comes with a simple command called 'prove' for running tests & reporting on results. It has a rather baffling array of options, so to make it simpler to run the libvirt TCK, there is a small program - bin/libvirt-tck (installed to /usr/bin/libvirt-tck) Given no arguments, this will connect using the default hypervisor URI and a previously obtained kernel+initrd and run all the tests currently available for the libvirt TCK, and report on failures. It comes witha number of options to alter the output format or choose different configurations. 'man 1 libvirt-tck' will produce details The actual tests themselves are simply short Perl scripts using the Test::More, Sys::Virt and Sys::Virt::TCK modules. Each test decides on what aspect it wants to test, and then implements that logic and tests results. As a demonstration, there are 4 initial scripts - scripts/domain/050-transient-lifecycle.t Creates a guest from XML, destroys it, and then verifies that it has actually gone away. - scripts/domain/060-persistent-lifecycle.t Defines a guest config XML, starts it, destroys it, verifies that the config still exists, and then undefines the config and verifies that it has actually gone. - scripts/domain/070-transient-to-persistent.t Creates a guest from XML, then defines a persistent config for it, destroys the running guest, and then verifies the config is still present. - scripts/domain/080-unique-identifiers.t Defines a guest, and then tries to define / create more guests with clashing name or UUID, and verifies that suitable errors are raised by libvirt. Even these 4 simple proof of concept scripts have highlighted some horrible problems - The QEMU driver 'define domain' method doesn't check for name or UUID uniqueness correctly (well, at all) - After starting an inactive domain, the remote driver does not update the 'ID' field in the virDomainPtr - After destroying a active domain, the remote driver does not update the 'ID' field in the virDomainPtr - When defining a persistent config for an already running domain the Xen XM driver blows away the current 'ID' field for the running domain, replacing it with -1. - QEMU refuses to boot kernel+initrd unless at least one disk image is provided In looking at some other things to test I specifically noticed that there terrible inconsistency in the virErrorPtr error codes used for reporting problems. For each API there needs to be a formal core set of error codes that will always be used for a certain set of conditions. eg, when looking up a domain by name, if no such domain exists the driver *must* always return VIR_ERR_NO_DOMAIN Output information ================== The libvirt-tck tool outputs results in a number of formats. The default format is a simple plain test summary listing each test case, and the pass/fail state, and details of each check failure A more verbose text format otputs the full Perl TAP (Test Anything Protocol) format results as described in 'man 3 TAP' or 'man 3 Test::Harness::TAP'. For producing pretty web pages, it is possible to request an HTML output format. Ultimately though it will be desirable to do automated analysis, and comparison of results across releases, OS, drivers, etc. To assist in creating tools todo this, an XML format is also provided There are some examples of these formats, when run against RHEL-5 Xen, Fedora 10 QEMU (libvirt 0.6.2), and Fedora 10 QEMU (libvirt 0.6.2 plus a bunch of code fixes to make it pass) In pretty HTML format: http://berrange.fedorapeople.org/libvirt-tck/results/libvirt-tck-rhel-5.html http://berrange.fedorapeople.org/libvirt-tck/results/libvirt-tck-f10-broken… http://berrange.fedorapeople.org/libvirt-tck/results/libvirt-tck-f10-fixed.… In full plain text format: http://berrange.fedorapeople.org/libvirt-tck/results/libvirt-tck-rhel-5.txt http://berrange.fedorapeople.org/libvirt-tck/results/libvirt-tck-f10-broken… http://berrange.fedorapeople.org/libvirt-tck/results/libvirt-tck-f10-fixed.… In formal XML format http://berrange.fedorapeople.org/libvirt-tck/results/libvirt-tck-rhel-5.xml http://berrange.fedorapeople.org/libvirt-tck/results/libvirt-tck-f10-broken… http://berrange.fedorapeople.org/libvirt-tck/results/libvirt-tck-f10-fixed.… Running the test suite ====================== For those feeling brave it is possible to try out the current test suite. The best bet is to install the perl-Sys-Virt-TCK RPM from the YUM repos listed above. Then create a config file # cat > /home/fred/qemu.cfg <<EOF uri = "qemu:///session" kernel=/home/fred/vmlinuz initrd=/home/fred/initrd.img disk=/home/fred/empty.img EOF For current tests, it is sufficient to have a kernel + initrd that is able to boot and just sit there being bored. The Fedora 10 PXEboot install kernels suit this job perfectly # wget http://download.fedora.redhat.com/pub/fedora/linux/releases/10/Fedora/x86_6… # wget http://download.fedora.redhat.com/pub/fedora/linux/releases/10/Fedora/x86_6… A empty disk image is need to keep QEMU happy - it won't boot a kernel/initrd without a disk image, so just create a 10 MB image # dd if=/dev/zero of=empty.img bs=1M count=10 Next, start an unprivileged instance of libvirtd, eg as your normal user account # /usr/sbin/libvirtd Now it should be possible to run # libvirt-tck -c /home/fred/qemu.cfg It will no doubt show many failures. To get more information add the -v flag # libvirt-tck -c /home/fred/qemu.cfg -v Or to get XML format # libvirt-tck -c /home/fred/qemu.cfg --format xml What's still todo ================= The code as it stands is the bare minimum to get a proof of concept working for testing of domain APIs for Xen and QEMU drivers. The test suite though is intended to be independant of any driver, and also allow for coverage of all the libvirt APIs. Of the top of my head, some important things that need doing - libvirt-tck-prepare For now it was sufficient to just grab the kernel+initrd from Fedora 10 pxeboot location, but not every kind of virtualization can boot off a kernel + initrd. Older Xen HVM cannot do this. VMWare cannot do this. OpenVZ / LXC have no concept of separate kernels, etc. The libvirt-tck-prepare command would automate the process of setting up some pre-requisite pieces. Specifically it would - Download kernel+initrd.img from a suitable location - Build an bootable ISO image using the kernel+initrd - Create a virtual root filesystem, populated with busybox commands (for LXC/OpenVZ) - Create an empty disk image - Be more intelligent about building domain XML configs. In particular look at the capabilities XML to decide whether to create a config that boots off kernel+initrd vs ISO vs a virtual root filesystem for containers - Add helpers for building network, storage and inteface XML configs - Expand on configuration to allow admin to indicate some resources that can be safely used during tests - A friendly NFS server & some of its exports - A spare disk (eg /dev/sdb) that can be played with and trashed - A spare network interface (or two) that can be played with - A spare PCI device that can be detached from host - A spare USB device that can be detached from host - A path with X GB of free space to play with for storage pool usage - A friendly iSCSI server & some of its targets If any of those resources were not available, the test cases needing them would simply be skipped. This is very easy to cope with in the Test::More framework plan skip_all "no iscsi server available" unless $tck->has_config("iscsi-server"); - Fix up all the horribly broken areas of libvirt that this uncovers. This will entail deciding that the semantics for various edge cases are with each API. Deciding what errors codes need to be formally defined for each API. Figuring out how to implement/fix the neccessary semantics in the drivers. - A way to record specific test failures as 'known broken' for a particular driver / platform combination. - A tool to take an XML report from the TCK, mask out all tests that are 'known broken', and then report on the remaining problems which need fixing. - A tool to compare two XML reports and show interesting differences in functionality, and / or bugs How this might be used ====================== The original motivating goal for this is obviously to improve the overall quality control of libvirt and things it interacts with. There are a number of scenarios in which I see this being used: - Fedora rawhide updates to a release of QEMU => Run the TCK to make sure it didn't break anything (new) in libvirt - Declaring feature freeze for a libvirt release => Run the TCK to determine what state of each driver is. Decide what problems should be release blockers. It is expected that some drivers may have long term failures, due to features that will not be implemented - Released new libvirt => Provide online 'reference' reports for the new libvirt release against various platforms. Allows OS distributors to determine whether their changes cause regressions, or if it is a known-broken item. - App developer looking to understand feature support => Look at the TCK reports for the driver and decide if it implements enough of the functionality to be worth supporting. The key factor I think is that it is unreasonable to expect that the TCK will complete without failures for every libvirt driver, let alone every OS. Some features will simply be impossible to implement for certain platforms. Thus the key is in tracking what areas are known to be broken, to make it possible to identify regressions in areas that are expected to work. The known broken areas may also provide motivation for new feature development in associated tools. libvirt TCK: An introduction to writing tests ============================================= The libvirt TCK provides a framework for testing the correct operation of libvirt drivers and their integration with the host operating system virtualization services. Since the focus is on functional integration testing, the tests and driven from the public libvirt API, closely replicating the kind of usage expected from applications using libvirt. The tests are written in Perl, primarily using the libvirt Perl language bindings (Sys::Virt / perl-Sys-Virt), and the common Test::More framework. The libvirt TCK also provides a number of helper modules to simplify the process of creating interesting tests Output format for a test case ============================= To enable automated reporting and analysis of test results, there is a well defined output format that tests must follow. A single test case consists of a sequence of checks each with a pass/fail status, the aggregate status giving the pass/fail state of the test as a whole. This information is presented in a simple, line oriented text format The general format can be summarized as 1..N ok 1 Description # Directive # Diagnostic not ok 2 Description .... ok N Description The first line here defines the plan, giving the expected number of checks that will be run in the test case. This enables the test harness to determine if a test case crashed / exited earlier than expected without running all checks. Each line starts with a word 'ok' or 'not ok' to indicate state of the check, followed by the check number (assigned incremnetally), and a description of the check performed. Diagnostic comments can be output using a leading '#' to assist in debugging / interpreting the results. A more real example would be 1..4 ok 1 - Input file opened not ok 2 - First line of the input valid ok 3 - Read the rest of the file not ok 4 - Summarized correctly # TODO Not written yet This is more or less all that it is neccessary to know about the output format, though far far more details can be found by reading the Perl documentation for 'TAP' (aka Test Anything Protocol) available either in 'man 3 TAP' or 'man 3 Test::Harness::TAP' depending on the Perl version. Writing tests with a compliant output format ============================================ As if that output format were not simple enough to understand and generate, there are helper modules to make this even easier to deal with. The Perl Test::More module provides a set of useful functions can be invoked to perform checks. The first step is to declare how many checks are intended to be run. This is typically done at time Test::More is imported into the script use Test::More tests => 15; The rest of the test case should be a Perl script that implements the logic you wish to test. At key points throughout the script, checks can be inserted to validate the state. Depending on the type of check desired, there are a number of helper functions available For a simple boolean condition, the 'ok' function can be used ok($boolean, $description); eg my $id = $dom->get_id; ok($id >= 0, "virtual domain ID is greater than or equal to 0"); To compare two pieces of data for equality (or inequality), the 'is'/'isnt' functions are preferred: is($expect, $actual, $description); isnt($expect, $actual, $description); eg my $name = $dom->get_name; is($name, "apache", "virtual domain has name 'apache'"); To compare a list or hash table, then a deep comparison is required. NB, if comparing lists, it will also often be desirable to sort their elements my @domains = sort { $a cmp $b } $conn->list_domains; is_deeply(\@domains, ['apache', 'dns'], $description); Finally to output a diagnostic message, the 'diag' command is suitable diag("Checking that the running guest has an ID > -1"); There are quite a few other variations on these functions, and extensive documentation can be found in the 'Test::More' manual page. Helpers for writing libvirt TCK test checks =========================================== While the above functions are useful for testing simple properties and conditions, they can be a little tedious to use when having to deal with exceptions and objects. The libvirt TCK thus provides a couple of helper functions. The first thing when writing a test is to get a connection to libvirt and make sure the test environment is clean. ie there are no existing guests lieing around. If anything goes wrong here, we need to bail out and not bother with rest of the test. We also want to ensure cleanup when the test case finishes. For this there is a simple boilerplate piece of code that can be included use Sys::Virt::TCK; my $tck = Sys::Virt::TCK->new(); my $conn = eval { $tck->setup(); }; BAIL_OUT "failed to setup test harness: $@" if $@; END { $tck->cleanup if $tck; } Going line by line, this first imports the 'Sys::Virt::TCK' package and its functions. Then it creates an instance of the 'Sys::Virt::TCK' object. Then it runs the 'setup' method to obtain a libvirt connection, catching any error that may be thrown. The fourth line willl abort the entire test if an error occurred during setup. The final line registers a 'END' block which will perform cleanup when Perl exits. When testing APIs, it will often be neccessary to create / define real guest domains with a config. Much of the time the test won't care about the exact config, just wanting a minimal generic domain config that is highly likely to work without error. For such cases, a nice simple API is provided: my $xml = $tck->generic_domain("test")->as_xml; This creates an XML document for a guest that is of the correct OS and domain type to be able to run on the current hypervisor, with a name of 'test', and a single disk. It is possible to set further parameters if required. For example, to set an explicit UUID, give 3 virtual CPUs and turn on ACPI: my $xml = $tck->generic_domain("test")->vcpus(3) ->uuid("11111111-1111-2222-3333-444444444444") ->with_acpi()->as_xml() Notice how it allows for chaining the method calls together to build the domain config, turning it into XML at the last step If testing a method that is expected to return a virtual domain object (ie an instance of Sys::Virt::Domain), the 'ok_domain' helper should be used. This takes 2 or 3 parameters. The first is the code block to be checks, the second is a description and the optional third parameter is the expected name of the guest domain. eg to test domain creation from an XML doc my $dom; ok_domain { $dom = $conn->create_domain($xml) } \ "created a running domain", "test"; This creates a new running guest from '$xml', and checks that it succeeeded and returns a domain object with an expected name of 'test'. If an exception was thrown during guest creation this will be reported as an error. If the guest has the incorrect name, that will also be reported as an error. If testing a method that is expected to thrown an exception and thus not return a value, the 'ok_error' helper should be used. This takes 2 or 3 parameters. The first is the code block to be checked, the second is a description and the optional third parameter is the expected error code. eg to ensure that the guest named 'test' does not exists, and that an error is raised when attempting to do a lookup for it. ok_error { $conn->lookup_domain_by_name("test") } \ "no such domain error raised", \ Sys::Virt::Error:ERR_NO_DOMAIN; This code block attempts to lookup a domain based on its name. For success, it requires that the domain does not exist and that libvirt throws an exception with a code VIR_ERR_NO_DOMAIN. If that does not happen, then a failure will be reported. A real test case example walkthrough ==================================== This example will illustrate how to test operation of persistent virtual domains. Our plan for the test is to run the following sequence of operations - Define a new inactive guest from XML - Start the guest config - Stop the running guest - Undefine the now inactive guest config There will be certain sanity checks at various stages. For example, after starting the guest, it will check that the guest ID is greater than zero. After stopping the guest, it will check the ID is -1. After undefining the guest, it will check that another lookup fails, to validate that it really went away. The first step is to write the core algorithm in Perl code using the Sys::Virt APIs. Very simplified it looks like this my $conn = ...get a libvirt connection... my $xml = "....the xml config..."; my $dom; $dom = $conn->define_domain($xml); $dom->create; $dom->destroy; $dom->undefine; Now it is time to start putting in sanity checks. When defining the domain, it is neccessary to check that returned a real domain object, and that no exception is thrown. The 'ok_domain' method can be used for that. It is also wise to print a diagnostic method before doing anything interesting So the define_domain line turns into diag "Defining inactive domain config again"; ok_domain { $dom = $conn->define_domain($xml) } "defined persistent domain config"; After then starting the domain, the test will check that it has a proper unique ID number. So the 'create' line turns into diag "Starting inactive domain config"; $dom->create; ok($dom->get_id() > 0, "running domain has an ID > 0"); Since this is testing persistent domains, after stopping the running guest, it should still be possible to look it up. Thus the line that stops the guest, gains a check for its ID number, followed by another check that the guest is still present diag "Destroying the running domain"; $dom->destroy(); is($dom->get_id(), -1 , "inactive domain has an ID == -1"); diag "Checking there is still an inactive domain config"; ok_domain { $dom1 = $conn->get_domain_by_name("test") } "the inactive domain object"; Finally, after undefining the guest it is neccessary to validate that it really has gone away, by trying to look it up based on name, and checking that an error is raised diag "Undefining the inactive domain config"; $dom->undefine; ok_error { $conn->get_domain_by_name("test") } \ "NO_DOMAIN error raised from missing domain", \ Sys::Virt::Error::ERR_NO_DOMAIN; The completed example test script ================================= It is good practice to include a short documentation comment in test scripts to outline what the script intends to validate. The Perl POD format is useful for this (see 'man perlpod') for more info. Taking this into account, the complete example script looks like # -*- perl -*- # # Copyright (C) 2009 A N Other =pod =head1 NAME example-persistent-domain.t - Persistent domain lifecycle =head1 DESCRIPTION The test case validates the core lifecycle operations on persistent domains. A persistent domain is one with a configuration enabling it to be tracked when inactive. =cut use strict; use warnings; use Test::More tests => 5; use Sys::Virt::TCK; my $tck = Sys::Virt::TCK->new(); my $conn = eval { $tck->setup(); }; BAIL_OUT "failed to setup test harness: $@" if $@; END { $tck->cleanup if $tck; } my $xml = $tck->generic_domain("test")->as_xml; my $dom; diag "Defining inactive domain config again"; ok_domain { $dom = $conn->define_domain($xml) } "defined persistent domain config"; diag "Starting inactive domain config"; $dom->create; ok($dom->get_id() > 0, "running domain has an ID > 0"); diag "Destroying the running domain"; $dom->destroy(); is($dom->get_id(), -1 , "inactive domain has an ID == -1"); diag "Checking there is still an inactive domain config"; my $dom1; ok_domain { $dom1 = $conn->get_domain_by_name("test") } "the inactive domain object"; diag "Undefining the inactive domain config"; $dom->undefine; ok_error { $conn->get_domain_by_name("test") } \ "NO_DOMAIN error raised from missing domain", \ Sys::Virt::Error::ERR_NO_DOMAIN; Running the test script ======================= Having created the test script it can be run directly using Perl, simply by setting an environment variable pointing to the config file # export LIBVIRT_TCK_CONFIG=/etc/libvirt-tck/xen.cfg # perl example-persistent-domain.t If the libvirt driver being tested were bug-free it would result in the following output 1..5 # Defining inactive domain config again ok 1 - defined persistent domain config # Starting inactive domain config ok 2 - running domain has an ID > 0 # Destroying the running domain ok 3 - inactive domain has an ID == -1 # Checking there is still an inactive domain config ok 4 - the inactive domain object # Undefining the inactive domain config ok 5 - NO_DOMAIN error raised from missing domain If something went wrong, it might look like 1..5 # Defining inactive domain config again ok 1 - defined persistent domain config # Starting inactive domain config not ok 2 - running domain has an ID > 0 # Failed test 'running domain has an ID > 0' # at /home/berrange/ex line 39. # Destroying the running domain libvirt error code: 7, message: invalid domain pointer in no domain with matching id -1 # Looks like you planned 5 tests but only ran 2. # Looks like you failed 1 test of 2 run. # Looks like your test died just after 2. Notice that since the tst script declared upfront that it intended to run 5 checks, Perl was able to detect that it aborted earlier than expected. -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

2 2

[libvirt] "state" drivers?
by Laine Stump 14 Apr '09

14 Apr '09

I'm looking through the network driver, and see the "state" driver registered. Several other drivers also register a state driver. What is this used for? It looks like it's handling a startup/shutdown at a more basic level than then open/close in the network (storage/qemu/etc) driver itself. Is it the case that things that should happen only once as libvirtd is loaded/unloaded should be put in the state driver's Startup/shutdown? It seems possible that these callouts may be unnecessary in my case, since I'll be modifying the OS's own interface config, so the interfaces will already be up and running by the time libvirtd starts, and should remaining running after libvirtd is unloaded. (as for initializing/shutting down netcf, this may be useful for shutting it down before exit, but its init should probably only be called on demand if someone actually calls a virInterface* function -otherwise we're using up resources for nothing. Any other guildelines/advice?

2 1

[libvirt] [PATCH 0/1] NPIV support
by David Allan 13 Apr '09

13 Apr '09

This patch implements NPIV support. I don't have easy access to an NPIV capable switch at the moment, so this is all untested code at least from the perspective of whether it actually creates and deletes virtual adapters, but I thought I should get it out to the list for comment sooner rather than later. I'll have a switch shortly. If anybody has an NPIV capable test SAN and wants to test it as well, I'd much appreciate the feedback. Note that libvirt doesn't do any sanity checking of the WWPN/WWNN. It expects the kernel to verify that the names are valid and the calling application to verify that the names are appropriate for the fabric. The XML to create a pool and create the virtual adapter when the pool is started is: <pool type="scsi"> <name>npiv</name> <source> <adapter name="host6" wwpn="0000111122223333" wwnn="4444555566667777"/> </source> <target> <path>/dev/disk/by-id</path> </target> </pool> Stopping the pool deletes the vport. Dave

3 8

[libvirt] [PATCH 1/3] Allow multiple monitor devices
by Anthony Liguori 09 Apr '09

09 Apr '09

Right now only one monitor device can be enabled at a time. In order to support asynchronous notification of events, I would like to introduce a 'wait' command that waits for an event to occur. This implies that we need an additional monitor session to allow commands to still be executed while waiting for an asynchronous notification. Signed-off-by: Anthony Liguori <aliguori(a)us.ibm.com> diff --git a/vl.c b/vl.c index 4bd173f..f78cabb 100644 --- a/vl.c +++ b/vl.c @@ -184,6 +184,9 @@ int main(int argc, char **argv) /* Max number of bluetooth switches on the commandline. */ #define MAX_BT_CMDLINE 10 +/* Maximum number of monitor devices */ +#define MAX_MONITOR_DEVICES 10 + /* XXX: use a two level table to limit memory usage */ #define MAX_IOPORTS 65536 @@ -4252,8 +4255,9 @@ int main(int argc, char **argv, char **envp) int hda_index; int optind; const char *r, *optarg; - CharDriverState *monitor_hd = NULL; - const char *monitor_device; + CharDriverState *monitor_hds[MAX_MONITOR_DEVICES]; + const char *monitor_devices[MAX_MONITOR_DEVICES]; + int monitor_device_index; const char *serial_devices[MAX_SERIAL_PORTS]; int serial_device_index; const char *parallel_devices[MAX_PARALLEL_PORTS]; @@ -4324,7 +4328,6 @@ int main(int argc, char **argv, char **envp) kernel_cmdline = ""; cyls = heads = secs = 0; translation = BIOS_ATA_TRANSLATION_AUTO; - monitor_device = "vc:80Cx24C"; serial_devices[0] = "vc:80Cx24C"; for(i = 1; i < MAX_SERIAL_PORTS; i++) @@ -4340,6 +4343,11 @@ int main(int argc, char **argv, char **envp) virtio_consoles[i] = NULL; virtio_console_index = 0; + monitor_devices[0] = "vc:80Cx24C"; + for (i = 1; i < MAX_MONITOR_DEVICES; i++) + monitor_devices[i] = NULL; + monitor_device_index = 0; + usb_devices_index = 0; nb_net_clients = 0; @@ -4723,7 +4731,12 @@ int main(int argc, char **argv, char **envp) break; } case QEMU_OPTION_monitor: - monitor_device = optarg; + if (monitor_device_index >= MAX_MONITOR_DEVICES) { + fprintf(stderr, "qemu: too many monitor devices\n"); + exit(1); + } + monitor_devices[monitor_device_index] = optarg; + monitor_device_index++; break; case QEMU_OPTION_serial: if (serial_device_index >= MAX_SERIAL_PORTS) { @@ -4974,8 +4987,8 @@ int main(int argc, char **argv, char **envp) serial_devices[0] = "stdio"; if (parallel_device_index == 0) parallel_devices[0] = "null"; - if (strncmp(monitor_device, "vc", 2) == 0) - monitor_device = "stdio"; + if (strncmp(monitor_devices[0], "vc", 2) == 0) + monitor_devices[0] = "stdio"; } #ifndef _WIN32 @@ -5184,14 +5197,14 @@ int main(int argc, char **argv, char **envp) #endif /* Maintain compatibility with multiple stdio monitors */ - if (!strcmp(monitor_device,"stdio")) { + if (!strcmp(monitor_devices[0],"stdio")) { for (i = 0; i < MAX_SERIAL_PORTS; i++) { const char *devname = serial_devices[i]; if (devname && !strcmp(devname,"mon:stdio")) { - monitor_device = NULL; + monitor_devices[0] = NULL; break; } else if (devname && !strcmp(devname,"stdio")) { - monitor_device = NULL; + monitor_devices[0] = NULL; serial_devices[i] = "mon:stdio"; break; } @@ -5208,11 +5221,20 @@ int main(int argc, char **argv, char **envp) } } - if (monitor_device) { - monitor_hd = qemu_chr_open("monitor", monitor_device, NULL); - if (!monitor_hd) { - fprintf(stderr, "qemu: could not open monitor device '%s'\n", monitor_device); - exit(1); + for (i = 0; i < MAX_MONITOR_DEVICES; i++) { + const char *devname = monitor_devices[i]; + if (devname && strcmp(devname, "none")) { + char label[32]; + if (i == 0) + snprintf(label, sizeof(label), "monitor"); + else + snprintf(label, sizeof(label), "monitor%d", i); + monitor_hds[i] = qemu_chr_open(label, devname, NULL); + if (!monitor_hds[i]) { + fprintf(stderr, "qemu: could not open monitor device '%s'\n", + devname); + exit(1); + } } } @@ -5335,8 +5357,13 @@ int main(int argc, char **argv, char **envp) text_consoles_set_display(display_state); qemu_chr_initial_reset(); - if (monitor_device && monitor_hd) - monitor_init(monitor_hd, MONITOR_USE_READLINE | MONITOR_IS_DEFAULT); + for (i = 0; i < MAX_MONITOR_DEVICES; i++) { + if (monitor_devices[i] && monitor_hds[i]) { + monitor_init(monitor_hds[i], + MONITOR_USE_READLINE | + ((i == 0) ? MONITOR_IS_DEFAULT : 0)); + } + } for(i = 0; i < MAX_SERIAL_PORTS; i++) { const char *devname = serial_devices[i];

8 19

Re: [Qemu-devel] Re: [libvirt] Re: [PATCH 2/3] Introduce monitor 'wait' command
by Anthony Liguori 09 Apr '09

09 Apr '09

Paul Brook wrote: >> It has to be some finite amount. You're right, it's arbitrary, but so >> is every other memory limitation we have in QEMU. You could make it >> user configurable but that's just punting the problem. >> >> You have to do some level of buffering. It's unavoidable. If you >> aren't buffering at the event level, you buffer at the socket level, etc. >> > > No you don't. If you use event flags rather than discrete events then you > don't need to buffer at all. You just need to be able to store the state of > each type of event you're going to raise, which should be a bounded set. > > This has its own set of issues - typically race conditions or "lost" events if > the client (libvirt) code isn't written carefully, and means you can't attach > information with an event, only indicate that something happened. > However if the correct model is used (event driven polling rather than purely > event driven) this shouldn't be problem. > It's just deferring the problem. Consider the case of VNC user authentication. You want to have events associated with whenever a user connects and disconnects so you can keep track of who's been on a virtual machine for security purposes. In my model, you record the last 10 minutes worth of events. If a user aggressively connects/reconnects, you could consume a huge amount of memory. You could further limit it by recording only a finite number of events to combat that problem. In your model, the VNC server triggers a user-connected event and a user-disconnected event. This bits are constantly reset which is fine. When libvirt gets around to seeing the events, it know wants to know who's been connecting/disconnecting. Either you show only the current user, which is not terribly useful, or you have the VNC server queue a list of the most recent user connects/disconnects. The problem with this model is that by pushing the queuing to the event generators, you end open up the possibility that someone is going to get something wrong. It's just more places to do it poorly. Regards, Anthony Liguori > Paul >

2 1

Re: [Qemu-devel] Re: [libvirt] Re: [PATCH 2/3] Introduce monitor 'wait' command
by Avi Kivity 09 Apr '09

09 Apr '09

Paul Brook wrote: > No you don't. If you use event flags rather than discrete events then you > don't need to buffer at all. You just need to be able to store the state of > each type of event you're going to raise, which should be a bounded set. > > This has its own set of issues - typically race conditions or "lost" events if > the client (libvirt) code isn't written carefully, and means you can't attach > information with an event, only indicate that something happened. > However if the correct model is used (event driven polling rather than purely > event driven) this shouldn't be problem. > I agree. Every event notification should be readable with an info command. The best way to enforce it is to have the event just say 'something changed' and force the management app to issue an info command to find out what exactly. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.

1 0

[libvirt] Problems using unix_sock_group
by Niraj Tolia 09 Apr '09

09 Apr '09

Hi, I am sure I am missing something simple but I can't seem to figure it out. I am trying to allow a non-root user rw access to libvirt 0.6.2. The user is a member of the libvirtd group, unix_sock_group="libvirtd", and unix_sock_rw_perms=0770. However, 'virsh list' doesn't seem to work. The permissions seem correct srwxrwx--- 1 root libvirtd 0 2009-04-08 17:32 libvirt-sock srwxrwxrwx 1 root libvirtd 0 2009-04-08 17:32 libvirt-sock-ro When I strace 'virsh list', it doesn't attempt to connect to /usr/local/var/run/libvirt/libvirt-sock but when I strace 'virsh --readonly list', it successfully connects to the "-ro" socket. configure reported that polkit wasn't configured. This is on a system with Xen. Any ideas on what I might be doing wrong? Thanks, Niraj

1 0

[libvirt] 0.6.2: git mirror tagged, too
by Jim Meyering 08 Apr '09

08 Apr '09

Mark McLoughlin mentioned that the LIBVIRT_0_6_2 tag was not automatically mirrored into the git tree, so I've added it. I also added a signed tag on the same change set. Among other things, that makes it so that "git describe" now generates sensible output for recent changes. But adding all the rest would be nice, too, so I did it with this for tag in $(git tag -l 'LIBVIRT_0_[0-5]*'); do v=$(echo $tag|sed 's/LIBVIRT_/v/;s/_/./g') git tag -s -m $v $v $tag done and pushed those tags.

1 0

[libvirt] migration by libvirt
by Zvi Dubitzky 08 Apr '09

08 Apr '09

Using libvirt virDomainMigrate () do I have to set the target VM with same XML config as the source VM machine before the migrate starts or the source machine Host libvirt takes care of this preparation before it starts the live migration. I am talking about the equivalent of a tcp migration as defined per the qemu/kvm migrate command done via the qemu monitor thanks Zvi Dubitzky Virtualization and System Architecture Email:dubi@il.ibm.com IBM Haifa Research Laboratory Phone: +972-4-8296182 Haifa, 31905, ISRAEL

2 1

[libvirt] Re: [PATCH] Hardware watchdog patch, version 6 (was: Re: [Qemu-devel] [PATCH] Hardware watchdog patch, version 5)
by Hollis Blanchard 08 Apr '09

08 Apr '09

Hi Rich, your watchdog qemu patch is working fine for me (i6300esb, default reset behavior), but I was wondering... how should libvirt find out about the watchdog firing? At that point, I think the next step from libvirt is to send a VIR_DOMAIN_EVENT_STOPPED_CRASHED domain event, correct? -- Hollis Blanchard IBM Linux Technology Center

4 4

[libvirt] Changing the QEMU svn VERSION string
by Anthony Liguori 08 Apr '09

08 Apr '09

Hi, I'd like to update the VERSION string in QEMU's svn tree. Right now, it's 0.10.0 and since we have a 0.10.2 release, that's somewhat confusing. I don't want to make it 0.11.0 either because that's not going to be reliable from a feature detection perspective. What I would like is to make it 0.11.0-devel or something similar to that. Being the nice guy I am, I thought I would check that this didn't make libvirt go bonkers :-) This is the relevant detection code in libvirt: if (sscanf(help, "QEMU PC emulator version %u.%u.%u (kvm-%u)", &major, &minor, &micro, &kvm_version) != 4) kvm_version = 0; if (!kvm_version && sscanf(help, "QEMU PC emulator version u.%u.%u", &major, &minor, &micro) != 3) goto cleanup2; If I change SVN to 0.11.0-devel, that's going to break the KVM string although the QEMU string will continue to work. Avi could potentially carry a patch to keep it 0.10.x and since kvm-%u will be used to identify features, that should keep things working. Anyone have any objections/suggestions? Regards, Anthony Liguori

7 10

[libvirt] Thoughts on svirt configuration files.
by Daniel J Walsh 08 Apr '09

08 Apr '09

Currently we do not want to hard code virtual image names into libvirt, so libvirt and virtual-manager can use libselinux to get the default image label and process label. svirt_t and svirt_image_t. The idea was one policy writer might want his virtual images labeled differently than another. One problem with this is I added to interfaces one for the domain, and one for the image label. Now we realize we have other images. We have process Label - svirt_t:MCS Exclusive RW Image - svirt_image_t:MCS Shared RW Image - svirt_image_t:s0 Read Only Image - virt_content_t:s0 So I am suggesting that we remove the virtual_image_context file and allowing policy writers to define context in the virtual_domain_context files but have multiple records and multiple fields. Something like a space separated list where each field corresponds to above. system_u:system_r:svirt_t:s0 system_u:object_r:svirt_image_t:s0 system_u:object_r:svirt_image_t:s0 system_u:object_r:virt_content_t:s0 Then you could add optional types with similar fields system_u:system_r:svirt_nonet_t:s0 system_u:object_r:svirt_image_t:s0 system_u:object_r:svirt_image_t:s0 system_u:object_r:virt_content_t:s0 Since SELinux just returns a path, the virt team could choose the format of the file if a space separated list is not addequate. (xml?) Name Value Pairs? Policy writers would have to enter the format that is chosen. Thoughts? I am thinking we might eventually want to allow an admin to select dynamic labels but specify alternative types. So svirt_t would be default but if someone wanted svirt_nonet_t, they could choose that also and get separation with a different type.

2 2

[libvirt] [PATCH 1/2] VirtualBox support
by Pritesh Kothari 08 Apr '09

08 Apr '09

Hi All, I have attached a patch which when applied on the HEAD as of today would allow virtualbox support in libvirt. It takes cares of all the stuff mentioned on the list earlier. Still if I have missed anything, please do tell me. The patch works very well with the VirtualBox OSE version and the 2.2 release. [PATCH 1/2] contains diff of files already in libvirt. [PATCH 2/2] contains new files needed for VirtualBox support. Regards, Pritesh

1 0

[libvirt] [PATCH] lxc: fix veth off by 1 error
by Serge E. Hallyn 08 Apr '09

08 Apr '09

When not specifying a target for veth device, veth.c:getFreeVethName() is supposed to scan for unused veth devices in /sys/class/net. However, when it finds one, it bumps the index by one before returning it. So, if you have one container running, veth0 is passed into the container, veth1 is taken and still sitting in /sys/class/net. When you now start a second container, getFreeVethName() finds veth0 is unused, but returns 1. Now container creation dies becuase /sys/class/net/veth1 exists. Signed-off-by: Serge Hallyn <serue(a)us.ibm.com> --- src/veth.c | 5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/src/veth.c b/src/veth.c index 93173e4..90c1dcb 100644 --- a/src/veth.c +++ b/src/veth.c @@ -35,12 +35,12 @@ static int getFreeVethName(char *veth, int maxLen, int startDev) { int rc = -1; - int devNum = startDev; + int devNum = startDev-1; char path[PATH_MAX]; do { - snprintf(path, PATH_MAX, "/sys/class/net/veth%d/", devNum); ++devNum; + snprintf(path, PATH_MAX, "/sys/class/net/veth%d/", devNum); } while (virFileExists(path)); snprintf(veth, maxLen, "veth%d", devNum); @@ -97,6 +97,7 @@ int vethCreate(char* veth1, int veth1MaxLen, while ((1 > strlen(veth2)) || STREQ(veth1, veth2)) { vethDev = getFreeVethName(veth2, veth2MaxLen, vethDev); + ++vethDev; DEBUG("assigned veth2: %s", veth2); } -- 1.6.2

2 1

[libvirt] [PATCH 0/1] Trigger SCSI scans on pool refresh
by David Allan 07 Apr '09

07 Apr '09

This patch is a small piece of code that causes the SCSI midlayer to rescan all targets for new LUs by echoing "- - -" into /sys/class/scsi_host/hostN/scan It does not attempt to cause a LIP to be issued. Dave

4 6

[libvirt] [PATCH] lxc: make the pivot_root more robust.
by Serge E. Hallyn 07 Apr '09

07 Apr '09

libvirt/lxc is broken on F11. The pivot_root() call returns -EINVAL. The below is one way we can fix it. I'm also sending another patch which takes the simpler approach of using chroot. However, chroot is trivially escapable (see for instance http://www.linuxsecurity.com/content/view/117632/49/) I don't know whether the typical libvirt user would care. If so, then the below patch is probably the way to go. >From 26cac415771a2d9712af0e1ce60a0bcb41b44665 Mon Sep 17 00:00:00 2001 From: root <root(a)localhost.localdomain> Date: Sat, 4 Apr 2009 22:49:20 -0400 Subject: [PATCH 1/1] lxc: make the pivot_root more robust. The libvirt lxc driver uses pivot_root instead of chroot, because the latter is trivially escapable. However, the pivot_root(2) system call can fail for several subtle reasons. Depending upon your distro init sequence you may get lucky and have the old recipe work, but on a Fedora 11 standard install, for instance, it will fail. Do a few more steps to make pivot_root hopefully always succeed. We mark / as MS_PRIVATE, create an empty tmpfs, and bind-mount the container root onto /new in that fs. In this way, we ensure two reasons for pivot_root to fail - namely old_root->parent being MS_SHARED and old_root and new_root being on the same fs - won't happen. Signed-off-by: Serge Hallyn <serue(a)us.ibm.com> --- src/lxc_container.c | 108 ++++++++++++++++++++++++++++++++++++++++----------- 1 files changed, 85 insertions(+), 23 deletions(-) diff --git a/src/lxc_container.c b/src/lxc_container.c index 3f17b8d..d3959f6 100644 --- a/src/lxc_container.c +++ b/src/lxc_container.c @@ -264,50 +264,113 @@ static int lxcContainerChildMountSort(const void *a, const void *b) return strcmp(*sb, *sa); } +#ifndef MS_REC +#define MS_REC 16384 +#endif + +#ifndef MNT_DETACH +#define MNT_DETACH 0x00000002 +#endif + +#ifndef MS_PRIVATE +#define MS_PRIVATE 1<<18 +#endif + static int lxcContainerPivotRoot(virDomainFSDefPtr root) { int rc; - char *oldroot; + char *oldroot = NULL, *newroot = NULL; - /* First step is to ensure the new root itself is - a mount point */ - if (mount(root->src, root->src, NULL, MS_BIND, NULL) < 0) { - virReportSystemError(NULL, errno, - _("failed to bind new root %s"), - root->src); - return -1; + /* root->parent must be private, so make / private. */ + if (mount("", "/", NULL, MS_PRIVATE|MS_REC, NULL) < 0) { + virReportSystemError(NULL, errno, "%s", + _("failed to make root private")); + goto err; } if (virAsprintf(&oldroot, "%s/.oldroot", root->src) < 0) { virReportOOMError(NULL); - return -1; + goto err; } if ((rc = virFileMakePath(oldroot)) < 0) { virReportSystemError(NULL, rc, _("failed to create %s"), oldroot); - VIR_FREE(oldroot); - return -1; + goto err; + } + + /* Create a tmpfs root since old and new roots must be + * on separate filesystems */ + if (mount("", oldroot, "tmpfs", 0, NULL) < 0) { + virReportSystemError(NULL, errno, + _("failed to mount empty tmpfs at %s"), + oldroot); + goto err; + } + + /* Create a directory called 'new' in tmpfs */ + if (virAsprintf(&newroot, "%s/new", oldroot) < 0) { + virReportOOMError(NULL); + goto err; + } + + if ((rc = virFileMakePath(newroot)) < 0) { + virReportSystemError(NULL, rc, + _("failed to create %s"), + newroot); + goto err; + } + + /* ... and mount our root onto it */ + if (mount(root->src, newroot, NULL, MS_BIND|MS_REC, NULL) < 0) { + virReportSystemError(NULL, errno, + _("failed to bind new root %s into tmpfs"), + root->src); + goto err; + } + + /* Now we chroot into the tmpfs, then pivot into the + * root->src bind-mounted onto '/new' */ + if (chroot(oldroot) < 0) { + virReportSystemError(NULL, errno, "%s", + _("failed to chroot into tmpfs")); + goto err; + } + + if (chdir("/new") < 0) { + virReportSystemError(NULL, errno, "%s", + _("failed to chdir into /new on tmpfs")); + goto err; } /* The old root directory will live at /.oldroot after * this and will soon be unmounted completely */ - if (pivot_root(root->src, oldroot) < 0) { - virReportSystemError(NULL, errno, - _("failed to pivot root %s to %s"), - oldroot, root->src); - VIR_FREE(oldroot); - return -1; + if (pivot_root(".", ".oldroot") < 0) { + virReportSystemError(NULL, errno, "%s", + _("failed to pivot root")); + goto err; } - VIR_FREE(oldroot); /* CWD is undefined after pivot_root, so go to / */ - if (chdir("/") < 0) { - return -1; + if (chdir("/") < 0) + goto err; + + if (umount2(".oldroot", MNT_DETACH) < 0) { + virReportSystemError(NULL, errno, "%s", + _("failed to lazily unmount old root")); + goto err; } + VIR_FREE(oldroot); + VIR_FREE(newroot); + return 0; + +err: + if (oldroot) VIR_FREE(oldroot); + if (newroot) VIR_FREE(newroot); + return -1; } static int lxcContainerPopulateDevices(void) @@ -349,10 +412,9 @@ static int lxcContainerPopulateDevices(void) _("cannot create /dev/pts")); return -1; } - if (mount("/.oldroot/dev/pts", "/dev/pts", NULL, - MS_MOVE, NULL) < 0) { + if (mount("devpts", "/dev/pts", "devpts", 0, NULL) < 0) { virReportSystemError(NULL, errno, "%s", - _("failed to move /dev/pts into container")); + _("failed to mount /dev/pts in container")); return -1; } -- 1.6.2

2 1

[libvirt] [PATCH] lxc: use chroot instead of pivot_root
by Serge E. Hallyn 06 Apr '09

06 Apr '09

This is an alternative to the pivot_root patch which I just sent. It has the advantage of being much simpler. It also won't have a problem with the container's / being a read-only mount. It has the disadvantage, of course, of being escapable. >From a91bca7f60f27e8fbdb4e3bacf3232a6cbb630d3 Mon Sep 17 00:00:00 2001 From: root <root(a)localhost.localdomain> Date: Fri, 3 Apr 2009 23:35:24 -0400 Subject: [PATCH 1/1] lxc: use chroot instead of pivot_root pivot_root is too fragile. For instance, if the container's / is read-only, we can't create .oldroot. Maybe we're happy telling users that if they can't create .oldroot at container create time, then they must make sure it exists ahead of time. Or, maybe we're ok with chroot being escapable, and should just go this simple route. Signed-off-by: Serge Hallyn <serue(a)us.ibm.com> --- src/lxc_container.c | 75 +++++++++++++-------------------------------------- 1 files changed, 19 insertions(+), 56 deletions(-) diff --git a/src/lxc_container.c b/src/lxc_container.c index 3f17b8d..142ed4d 100644 --- a/src/lxc_container.c +++ b/src/lxc_container.c @@ -264,52 +264,6 @@ static int lxcContainerChildMountSort(const void *a, const void *b) return strcmp(*sb, *sa); } -static int lxcContainerPivotRoot(virDomainFSDefPtr root) -{ - int rc; - char *oldroot; - - /* First step is to ensure the new root itself is - a mount point */ - if (mount(root->src, root->src, NULL, MS_BIND, NULL) < 0) { - virReportSystemError(NULL, errno, - _("failed to bind new root %s"), - root->src); - return -1; - } - - if (virAsprintf(&oldroot, "%s/.oldroot", root->src) < 0) { - virReportOOMError(NULL); - return -1; - } - - if ((rc = virFileMakePath(oldroot)) < 0) { - virReportSystemError(NULL, rc, - _("failed to create %s"), - oldroot); - VIR_FREE(oldroot); - return -1; - } - - /* The old root directory will live at /.oldroot after - * this and will soon be unmounted completely */ - if (pivot_root(root->src, oldroot) < 0) { - virReportSystemError(NULL, errno, - _("failed to pivot root %s to %s"), - oldroot, root->src); - VIR_FREE(oldroot); - return -1; - } - VIR_FREE(oldroot); - - /* CWD is undefined after pivot_root, so go to / */ - if (chdir("/") < 0) { - return -1; - } - - return 0; -} - static int lxcContainerPopulateDevices(void) { int i; @@ -349,10 +303,9 @@ static int lxcContainerPopulateDevices(void) _("cannot create /dev/pts")); return -1; } - if (mount("/.oldroot/dev/pts", "/dev/pts", NULL, - MS_MOVE, NULL) < 0) { + if (mount("devpts", "/dev/pts", "devpts", 0, NULL) < 0) { virReportSystemError(NULL, errno, "%s", - _("failed to move /dev/pts into container")); + _("failed to mount /dev/pts in container")); return -1; } @@ -461,15 +414,25 @@ static int lxcContainerUnmountOldFS(void) } -/* Got a FS mapped to /, we're going the pivot_root - * approach to do a better-chroot-than-chroot - * this is based on this thread http://lkml.org/lkml/2008/3/5/29 - */ -static int lxcContainerSetupPivotRoot(virDomainDefPtr vmDef, +/* Got a FS mapped to /, now chroot. + * pivot_root would work, but requires too much hand-holding + * (especially, old_root->parent must not be shared) */ +static int lxcContainerSetupChroot(virDomainDefPtr vmDef, virDomainFSDefPtr root) { - if (lxcContainerPivotRoot(root) < 0) + if (chdir(root->src) < 0) { + virReportSystemError(NULL, errno, + _("failed to chdir to %s"), + root->src); + return -1; + } + + if (chroot(root->src) < 0) { + virReportSystemError(NULL, errno, + _("failed to chroot to %s"), + root->src); return -1; + } if (virFileMakePath("/proc") < 0 || mount("none", "/proc", "proc", 0, NULL) < 0) { @@ -537,7 +500,7 @@ static int lxcContainerSetupMounts(virDomainDefPtr vmDef) } if (root) - return lxcContainerSetupPivotRoot(vmDef, root); + return lxcContainerSetupChroot(vmDef, root); else return lxcContainerSetupExtraMounts(vmDef); } -- 1.6.2

1 0

[libvirt] VM cpuTime discrepancy
by Zvi Dubitzky 06 Apr '09

06 Apr '09

The cpuTime of a VM reported by kvm72 is ok (real seconds ) while that reported by kvm-84 is not. Are you aware of this . Did you talk to kvm and was it fixed in latest kvm releases since 84 ? I access cpuTime via libvirt . (same version in both cases) . thanks Zvi Dubitzky Virtualization and System Architecture Email:dubi@il.ibm.com IBM Haifa Research Laboratory Phone: +972-4-8296182 Haifa, 31905, ISRAEL

1 0

[libvirt] libvirt.org down
by Daniel Veillard 06 Apr '09

06 Apr '09

As Jim found out there is a problem on the libvirt.org box, I don't know exactly what's is going on, and I will go anc check the box tomorrow at 7am EST. Sorry for the inconvenience, and thanks Jim for raising the issue ! Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel(a)veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/

1 1

[libvirt] win32
by Brecht Sanders 06 Apr '09

06 Apr '09

Hi, Is there any way to compile libvirt with xen some support without depending on libxenstore? The reason I ask is that libxen can be built on Windows, but libxenstore seems to depend on the linux kernel, so I doubt it can be built for Windows. Regards Brecht Sanders

3 3

[libvirt] [PATCH] Openvz: how to use a nondefault config
by Anton Protopopov 06 Apr '09

06 Apr '09

2009/4/2 Daniel P. Berrange <berrange(a)redhat.com> > On Thu, Apr 02, 2009 at 06:36:15PM +0400, Evgeniy Sokolov wrote: > > > > Config /etc/vz/conf/ve-XXX.conf-sample define there are many parameters > > like memory, CPU etc. This parameters are not properties of > <filesystem>. > > > > Daniel, usage of pre-defined configs in really usefull. Can we create > > additional tag inside <domain></domain>? > > The trouble with this is that given the XML config of a guest, you can > no longer determine what its configuration is, because a large amount > of configuration is hidden in this opaque 'template'. And in kvm/qemu case there is a lot of hidden information too :) In OpenVZ case we don't loose any info (see below). > > If we're to support templates, I think we need to make them first class > objects, so you can query what templates exist, and see their associated > config settings. > > eg, expose a simple API > > virDomainTemplatePtr; > > int virConnectListDomainTemplates(virConnectPtr conn, const char > **names); > virDomainTemplatePtr virDomainTemplateLookupbyName(virConnectPtr con, > const char *name) > char *virDomainTemplateGetXMLDesc(virDomainTemplatePtr tmpl); > virDomainTemplatePtr virDomainTemplateDefineXML(virConnectPtr conn, const > char *xml) > int virDomainTemplateUndefine(virDomainTemplatePtr tmpl); > int virDomainTemplateFree(virDomainTemplatePtr tmpl); > > > Then, we could either include a <template>$NAME</template> parameter in > the XML for a guest. Or have an alternate API for creating guests > > virDomainCreateXMLWithTemplate(virConnectPtr conn, > const char *xmlDesc, > const char *template) > > It depends whether we'd want to track the template <-> guest association > forever, or just use it once to fill-in the guest XML and then forget > about the template after that. It doesn't matter in OpenVZ case: template (or, "config", in openvz terminology) is used only once, when container is creating. But then per-container "copy" is created, and it is already used by libvirt to keep information about container. Per-container OpenVZ config keeps the name of the original config (in ORIGIN_SAMPLE variable). Is there need for "Template API" in case of other hypervisors?

2 1

[libvirt] Planning and schedule
by Daniel Veillard 06 Apr '09

06 Apr '09

Trying to keep up the promises from last week: - so 0.6.2 is released and out - I still plan for a new release 0.6.3 around Fri 24 April - which mean we should have some kind of feature commit freeze around the 17th April - and the week 20 - 24 focusing mostly on bug fixes Plannned so far for 0.6.3 are: - API for physical host interface - the VirtualBox driver if in shape and in time but that's not an exhaustive list and there is a couple of drivers submitted I need to look at (OpenNebula for example). And I will provide an update next Friday, Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel(a)veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/

2 1

[libvirt] pypxeboot - libvirt
by Gian Mario 06 Apr '09

06 Apr '09

Hi to all, Can anyone tell me on which version libvirt start to support pypxeboot? tnks so much. GMario

1 0

[libvirt] freecell gives out bytes instead of kilobytes
by Gerrit Slomma 03 Apr '09

03 Apr '09

The virsh-command freecell hands out bytes but affixes those with kB. The error ist found in virsh.c on line 1663 and following. I have corrected this and altered the output to the method i chose for virt-manager - in the days of 96 GB per socket (Nehalem-EP) no one cares even about a fraction of a Megabyte. --- a/src/virsh.c 2009-04-02 17:45:50.000000000 +0200 +++ b/src/virsh.c 2009-04-02 23:35:54.000000000 +0200 @@ -1661,10 +1661,23 @@ } if (cell == -1) - vshPrint(ctl, "%s: %llu kB\n", _("Total"), memory); + if (memory < 10*1024*1204*1024) + { + vshPrint(ctl, "%s: %.0f MB\n", _("Total"), (float)memory/1024/1024); + } + else + { + vshPrint(ctl, "%s: %.2f GB\n", _("Total"), (float)memory/1024/1024/1024); + } else - vshPrint(ctl, "%d: %llu kB\n", cell, memory); - + if (memory < 10*1024*1204*1024) + { + vshPrint(ctl, "%d: %.0f MB\n", cell, (float)memory/1024/1024); + } + else + { + vshPrint(ctl, "%d: %.2f GB\n", cell, (float)memory/1024/1024/1024); + } return TRUE; } eg: rr016# virsh freecell; free -m 0: 24 MB total used free shared buffers cached Mem: 3884 3859 24 0 60 1306 -/+ buffers/cache: 2492 1392 Swap: 2047 248 1798 rr017# virsh freecell; free -m 0: 1490 MB total used free shared buffers cached Mem: 2991 1501 1489 0 100 1283 -/+ buffers/cache: 117 2873 Swap: 2047 0 2047 rr019# virsh freecell; free -m 0: 1616 MB total used free shared buffers cached Mem: 3952 2337 1615 0 5 1209 -/+ buffers/cache: 1121 2831 Swap: 2047 0 2047 Is this okay with you? Or just the fix for the output removing the kB-suffix.

4 5

[libvirt] [PATCH] Don't squash file format on volume refresh
by Cole Robinson 03 Apr '09

03 Apr '09

A while back, code was added to storage_backend.c:virStorageBackendUpdateVolTargetInfoFD to try to determine the volume format for iscsi volumes. Unfortunately this function is also called for refreshing file volumes, which has the effect of setting the format as 'raw' whenever a volume is refreshed (ex. after calling virsh vol-info). The attached patch moves the offending code into a wrapper function in the scsi driver. I haven't played with the scsi support yet so this is untested though it's largely code movement. Thanks, Cole

2 2

[libvirt] [PATCH] Refresh storage volume on dumpxml
by Cole Robinson 03 Apr '09

03 Apr '09

The storage driver refreshes a volume's capacity+allocation data when the 'info' command is called. Seems that we should also update it when dumpxml is called, which also returns size information. Thanks, Cole

2 2

[libvirt] [PATCH] Fix test driver 'restore' return value
by Cole Robinson 03 Apr '09

03 Apr '09

The return value for domain restore in the test driver isn't consistent with the API, and as such virsh will report failure even if the restore succeeds. The attached patch fixes this. Thanks, Cole

2 2

[libvirt] [PATCH] Fix sparse volume allocation reporting
by Cole Robinson 03 Apr '09

03 Apr '09

I have a sparse volume with a capacity of 1000M, and an allocation of a little over 750M. 'du' prints the correct sizes, but 'virsh vol-dumpxml' shows: <capacity>1048576000</capacity> <allocation>6406307840</allocation> This is because we were calculating the allocation size using the requested fs block size, instead of what stat actually uses as a block size (DEV_BSIZE in sys/params.h). sys/params.h looks to be present in mingw32-runtime, so I didn't add a configure check for it. The attached patch fixes allocation listing for me. Thanks, Cole

3 7