- Devel - libvirt List Archives

[libvirt] [PATCH 0/1] Add support for disk serial number in node device code
by David Allan 11 Jun '09

11 Jun '09

This small patch extends the information for storage devices to include their serial number. This information is useful in figuring out which devices are actually multiple paths to the same backend device, as well as identifying devices uniquely across nodes. This code will be used by the multipath support that I'm working on, but since it's capable of standing alone, and might be useful for other reasons, I'm submitting it separately. Dave

4 7

[libvirt] [PATCH 1/3] Re-factor qemu version parsing
by Mark McLoughlin 11 Jun '09

11 Jun '09

This patch is purely re-factoring without any functional changes to make way for the next patch. The main thing achieved by the refactoring is that we now have easier access to the parenthesised string that KVM folks seem to delight in changing. Signed-off-by: Mark McLoughlin <markmc(a)redhat.com> --- src/qemu_conf.c | 92 +++++++++++++++++++++++++++++++++++++++++++------------ 1 files changed, 72 insertions(+), 20 deletions(-) diff --git a/src/qemu_conf.c b/src/qemu_conf.c index 2c1eefc..f6a8390 100644 --- a/src/qemu_conf.c +++ b/src/qemu_conf.c @@ -412,6 +412,73 @@ virCapsPtr qemudCapsInit(void) { return NULL; } +/* We parse the output of 'qemu -help' to get the QEMU + * version number. The first bit is easy, just parse + * 'QEMU PC emulator version x.y.z'. + * + * With qemu-kvm, however, that is followed by a kvm-XX + * string in parenthesis. + */ +#define QEMU_VERSION_STR "QEMU PC emulator version " +#define KVM_VER_PREFIX " (kvm-" + +static int qemudParseVersionStr(const char *str, + unsigned int *version, + unsigned int *kvm_version) +{ + unsigned major, minor, micro; + const char *p = str; + + *version = *kvm_version = 0; + + if (!STRPREFIX(p, QEMU_VERSION_STR)) + goto fail; + + p += strlen(QEMU_VERSION_STR); + + major = virParseNumber(&p); + if (major == -1 || *p != '.') + goto fail; + + ++p; + + minor = virParseNumber(&p); + if (major == -1 || *p != '.') + goto fail; + + ++p; + + micro = virParseNumber(&p); + if (major == -1) + goto fail; + + if (STRPREFIX(p, KVM_VER_PREFIX)) { + int ret; + + p += strlen(KVM_VER_PREFIX); + + ret = virParseNumber(&p); + if (ret == -1) + goto fail; + + *kvm_version = ret; + } + + *version = (major * 1000 * 1000) + (minor * 1000) + micro; + + qemudDebug("Version %d.%d.%d - cooked version: %d", + major, minor, micro, *version); + if (*kvm_version) + qemudDebug("KVM version %d detected", *kvm_version); + + return 0; + +fail: + qemudReportError(NULL, NULL, NULL, VIR_ERR_INTERNAL_ERROR, + _("cannot parse QEMU version number in '%s'"), + str); + return -1; +} int qemudExtractVersionInfo(const char *qemu, unsigned int *retversion, @@ -421,7 +488,6 @@ int qemudExtractVersionInfo(const char *qemu, pid_t child; int newstdout = -1; int ret = -1, status; - unsigned int major, minor, micro; unsigned int version, kvm_version; unsigned int flags = 0; @@ -443,22 +509,11 @@ int qemudExtractVersionInfo(const char *qemu, goto cleanup2; } - if (sscanf(help, "QEMU PC emulator version %u.%u.%u (kvm-%u)", - &major, &minor, &micro, &kvm_version) != 4) - kvm_version = 0; + char *eol = strchr(help, '\n'); + if (eol) *eol = '\0'; - if (!kvm_version && - sscanf(help, "QEMU PC emulator version %u.%u.%u", - &major, &minor, &micro) != 3) { - char *eol = strchr(help, '\n'); - if (eol) *eol = '\0'; - qemudReportError(NULL, NULL, NULL, VIR_ERR_INTERNAL_ERROR, - _("cannot parse QEMU version number in '%s'"), - help); + if (qemudParseVersionStr(help, &version, &kvm_version) == -1) goto cleanup2; - } - - version = (major * 1000 * 1000) + (minor * 1000) + micro; if (strstr(help, "-no-kqemu")) flags |= QEMUD_CMD_FLAG_KQEMU; @@ -512,10 +567,7 @@ int qemudExtractVersionInfo(const char *qemu, ret = 0; - qemudDebug("Version %d %d %d Cooked version: %d, with flags ? %d", - major, minor, micro, version, flags); - if (kvm_version) - qemudDebug("KVM version %d detected", kvm_version); + qemudDebug("QEMU supported cmdline flags = %d", flags); cleanup2: VIR_FREE(help); -- 1.6.0.6

3 19

[libvirt][qemu] Ho to get a 'boot=on' parameter to appear on kvm command line
by Anton Protopopov 10 Jun '09

10 Jun '09

Hi, all. Can someone tell me how to get boot=on parameter to appear on my kvm cmdline? I define domain with the following xml <domain type="kvm"> <name>kvm-1</name> <memory>524288</memory> <vcpu>1</vcpu> <os> <type arch="x86_64" machine="pc">hvm</type> <boot dev="hd"/> </os> <devices> <emulator>/usr/bin/kvm</emulator> <graphics type="vnc" port="-1"/> <disk device="disk" type="file"> <source file="test.img"/> <target dev="sda"/> </disk> <interface type="bridge"> <source bridge="breth0"/> </interface> </devices> </domain> and get /usr/bin/kvm -S -M pc -m 512 -smp 1 -name kvm-1 -uuid b462e575-4044-146c-193a-9a70523b4258 -monitor pty -no-acpi -boot c -drive file=test.img,if=scsi,index=0 -net nic,macaddr=52:54:00:09:9b:19,vlan=0 -net tap,fd=15,vlan=0 -serial none -parallel none -usb But I want to get -drive file=test.img,if=scsi,index=0,boot=on instead.

4 6

[libvirt] [PATCH] Support kvm-img or qemu-img dynamically
by Doug Goldstein 10 Jun '09

10 Jun '09

This patch adds a new function virFindFileInPath() and uses it to find where a binary lives in the PATH environment variable. Using this, we can dynamically find where utility functions exist (and if they even exists). So such we remove the build-time check for qemu-img and make it dynamic for kvm-img and qemu-img. Several distros uses kvm-img over qemu-img when installing KVM. kvm-img also includes several patches which Red Hat is trying to upstream with QEMU so this patch supports those features which are commented out in libvirt when using kvm-img Signed-off-by: Doug Goldstein <cardoe(a)gentoo.org> --- configure.in | 15 --------- src/libvirt_private.syms | 1 + src/storage_backend_fs.c | 74 ++++++++++++++++++++++++++++++++------------- src/util.c | 28 +++++++++++++++++ src/util.h | 2 + 5 files changed, 83 insertions(+), 37 deletions(-)

2 1

[libvirt] PATCH: Fix typo in XML documentation regarding VNC password
by Garry Dolley 10 Jun '09

10 Jun '09

Excuse my previous post, I didn't know the website was in docs/ and I could submit a real patch ;) So here it is: diff --git a/docs/formatdomain.html b/docs/formatdomain.html index 27e42ac..817fd7e 100644 --- a/docs/formatdomain.html +++ b/docs/formatdomain.html @@ -746,7 +746,7 @@ qemu-kvm -net nic,model=? /dev/null auto-allocated). The <code>autoport</code> attribute is the new preferred syntax for indicating autoallocation of the TCP port to use. The <code>listen</code> attribute is an IP address for the server to - listen on. The <code>password</code> attribute provides a VNC password + listen on. The <code>passwd</code> attribute provides a VNC password in clear text. The <code>keymap</code> attribute specifies the keymap to use.</dd></dl> <h4> -- Garry Dolley ARP Networks, Inc. | http://www.arpnetworks.com | (818) 206-0181 Data center, VPS, and IP Transit solutions Member Los Angeles County REACT, Unit 336 | WQGK336 Blog http://scie.nti.st

2 3

[libvirt] [PATCH] (not for inclusion) add virDomainRename API
by Doug Goldstein 09 Jun '09

09 Jun '09

The following patch stubs out virDomainRename() as an available API function. I'm just making sure I'm doing this right. I know there were some plans to include documentation about adding API to the website but I don't see it. The included patch does not include my example driver for qemu and test. Just looking for a thumbs up/down whether I should continue or not and whether I'm adding it right. -- Doug Goldstein

4 4

[libvirt] Typo in XML documentation regarding VNC password
by Garry Dolley 09 Jun '09

09 Jun '09

On this page: http://libvirt.org/formatdomain.html#elementsGraphics There is a typo stating how to set VNC passwords per domain. Patch: -The password attribute provides a VNC password in clear text. +The passwd attribute provides a VNC password in clear text. -- Garry Dolley ARP Networks, Inc. | http://www.arpnetworks.com | (818) 206-0181 Data center, VPS, and IP Transit solutions Member Los Angeles County REACT, Unit 336 | WQGK336 Blog http://scie.nti.st

2 1

[libvirt] Remote Xen and libvirt >= 0.5.0 Issues
by Hany Fahim 08 Jun '09

08 Jun '09

Hi, I'm currently running a few servers with CentOS 5.3 (i386) with the stock Xen version: # rpm -q kernel-xen xen libvirt kernel-xen-2.6.18-92.1.22.el5 kernel-xen-2.6.18-128.1.6.el5 xen-3.0.3-80.el5_3.2 libvirt-0.6.3-1 libvirt was compiled from the src RPM from libvirt.org to run on i386 architecture without issue. I'm having a problem when trying to connect to remote Xen installations using versions of libvirt starting from 0.5.0 and above. When issuing virsh commands to query the local instance, it works without issue, but any remote sources gives 'error: failed to connect to the hypervisor'. Here's what LIBVIRT_DEBUG reveals: # LIBVIRT_DEBUG=6 virsh -d 5 -c xen://node3/ list command: "list " 13:53:17.132: debug : virInitialize:290 : register drivers 13:53:17.132: debug : virRegisterDriver:667 : registering Test as driver 0 13:53:17.132: debug : virRegisterNetworkDriver:567 : registering Test as network driver 0 13:53:17.132: debug : virRegisterStorageDriver:598 : registering Test as storage driver 0 13:53:17.132: debug : virRegisterDeviceMonitor:629 : registering Test as device driver 0 13:53:17.132: debug : xenHypervisorInit:1922 : Using new hypervisor call: 30001 13:53:17.132: debug : xenHypervisorInit:1991 : Using hypervisor call v2, sys ver3 dom ver5 13:53:17.132: debug : virRegisterDriver:667 : registering Xen as driver 1 13:53:17.132: debug : virRegisterDriver:667 : registering OPENVZ as driver 2 13:53:17.133: debug : vboxRegister:68 : VBoxCGlueInit failed: 0.0.0, errorval=-1 13:53:17.133: debug : virRegisterDriver:667 : registering VBOX as driver 3 13:53:17.133: debug : virRegisterDriver:667 : registering remote as driver 4 13:53:17.133: debug : virRegisterNetworkDriver:567 : registering remote as network driver 1 13:53:17.133: debug : virRegisterStorageDriver:598 : registering remote as storage driver 1 13:53:17.133: debug : virRegisterDeviceMonitor:629 : registering remote as device driver 1 13:53:17.133: debug : virConnectOpenAuth:1100 : name=xen://node3/, auth=0x67d0080, flags=0 13:53:17.133: debug : do_open:920 : name "xen://node3/" to URI components: scheme xen opaque (null) authority (null) server node3 user (null) port 0 path / 13:53:17.133: debug : do_open:930 : trying driver 0 (Test) ... 13:53:17.133: debug : do_open:936 : driver 0 Test returned DECLINED 13:53:17.133: debug : do_open:930 : trying driver 1 (Xen) ... 13:53:17.133: debug : do_open:936 : driver 1 Xen returned DECLINED 13:53:17.133: debug : do_open:930 : trying driver 2 (OPENVZ) ... 13:53:17.133: debug : do_open:936 : driver 2 OPENVZ returned DECLINED 13:53:17.133: debug : do_open:930 : trying driver 3 (VBOX) ... 13:53:17.133: debug : do_open:936 : driver 3 VBOX returned DECLINED 13:53:17.133: debug : do_open:930 : trying driver 4 (remote) ... 13:53:17.133: debug : do_open:936 : driver 4 remote returned DECLINED 13:53:17.133: debug : virUnrefConnect:210 : unref connection 0x93275d0 1 13:53:17.134: debug : virReleaseConnect:171 : release connection 0x93275d0 error: failed to connect to the hypervisor But when connecting to localhost, it works just fine: # LIBVIRT_DEBUG=6 virsh -d 5 -c xen:/// list command: "list " 13:53:23.558: debug : virInitialize:290 : register drivers 13:53:23.558: debug : virRegisterDriver:667 : registering Test as driver 0 13:53:23.558: debug : virRegisterNetworkDriver:567 : registering Test as network driver 0 13:53:23.558: debug : virRegisterStorageDriver:598 : registering Test as storage driver 0 13:53:23.558: debug : virRegisterDeviceMonitor:629 : registering Test as device driver 0 13:53:23.559: debug : xenHypervisorInit:1922 : Using new hypervisor call: 30001 13:53:23.559: debug : xenHypervisorInit:1991 : Using hypervisor call v2, sys ver3 dom ver5 13:53:23.559: debug : virRegisterDriver:667 : registering Xen as driver 1 13:53:23.559: debug : virRegisterDriver:667 : registering OPENVZ as driver 2 13:53:23.559: debug : vboxRegister:68 : VBoxCGlueInit failed: 0.0.0, errorval=-1 13:53:23.559: debug : virRegisterDriver:667 : registering VBOX as driver 3 13:53:23.559: debug : virRegisterDriver:667 : registering remote as driver 4 13:53:23.559: debug : virRegisterNetworkDriver:567 : registering remote as network driver 1 13:53:23.560: debug : virRegisterStorageDriver:598 : registering remote as storage driver 1 13:53:23.560: debug : virRegisterDeviceMonitor:629 : registering remote as device driver 1 13:53:23.560: debug : virConnectOpenAuth:1100 : name=xen:///, auth=0x67d0080, flags=0 13:53:23.560: debug : do_open:920 : name "xen:///" to URI components: scheme xen opaque (null) authority (null) server (null) user (null) port 0 path / 13:53:23.560: debug : do_open:930 : trying driver 0 (Test) ... 13:53:23.560: debug : do_open:936 : driver 0 Test returned DECLINED 13:53:23.560: debug : do_open:930 : trying driver 1 (Xen) ... 13:53:23.560: debug : xenUnifiedOpen:295 : Trying hypervisor sub-driver 13:53:23.560: debug : xenUnifiedOpen:298 : Activated hypervisor sub-driver 13:53:23.560: debug : xenUnifiedOpen:306 : Trying XenD sub-driver 13:53:23.563: debug : xenUnifiedOpen:309 : Activated XenD sub-driver 13:53:23.563: debug : xenUnifiedOpen:315 : Trying XM sub-driver 13:53:23.563: debug : xenUnifiedOpen:318 : Activated XM sub-driver 13:53:23.563: debug : xenUnifiedOpen:322 : Trying XS sub-driver 13:53:23.564: debug : xenStoreOpen:346 : Failed to add event handle, disabling events 13:53:23.564: debug : xenUnifiedOpen:325 : Activated XS sub-driver 13:53:23.570: debug : xenUnifiedOpen:361 : Trying Xen inotify sub-driver 13:53:23.571: debug : xenInotifyOpen:439 : Adding a watch on /etc/xen 13:53:23.571: debug : xenInotifyOpen:451 : Building initial config cache 13:53:23.571: debug : xenXMConfigCacheAddFile:387 : Adding file /etc/xen/centos 13:53:23.571: debug : xenXMConfigCacheAddFile:436 : Failed to read /etc/xen/centos 13:53:23.571: debug : xenXMConfigCacheAddFile:387 : Adding file /etc/xen/test3 13:53:23.571: debug : xenXMConfigCacheAddFile:465 : Added config test3 /etc/xen/test3 13:53:23.571: debug : xenXMConfigCacheAddFile:387 : Adding file /etc/xen/hany 13:53:23.571: debug : xenXMConfigCacheAddFile:465 : Added config hany /etc/xen/hany 13:53:23.572: debug : xenXMConfigCacheAddFile:387 : Adding file /etc/xen/hany2 13:53:23.572: debug : xenXMConfigCacheAddFile:465 : Added config hany4 /etc/xen/hany2 13:53:23.572: debug : xenInotifyOpen:458 : Registering with event loop 13:53:23.572: debug : xenInotifyOpen:462 : Failed to add inotify handle, disabling events 13:53:23.572: debug : virConnectRef:1165 : conn=0x996b5c8 refs=3 13:53:23.572: debug : xenUnifiedOpen:364 : Activated Xen inotify sub-driver 13:53:23.572: debug : do_open:936 : driver 1 Xen returned SUCCESS 13:53:23.572: debug : do_open:956 : network driver 0 Test returned DECLINED 13:53:23.572: debug : doRemoteOpen:511 : proceeding with name = xen:/// 13:53:23.572: debug : call:6543 : Doing call 66 (nil) 13:53:23.573: debug : call:6613 : We have the buck 66 0xb736c008 0xb736c008 13:53:23.573: debug : processCallRecvLen:6201 : Got length, now need 36 total (32 more) 13:53:23.573: debug : processCalls:6469 : Giving up the buck 66 0xb736c008 (nil) 13:53:23.573: debug : call:6644 : All done with our call 66 (nil) 0xb736c008 13:53:23.573: debug : call:6543 : Doing call 1 (nil) 13:53:23.573: debug : call:6613 : We have the buck 1 0x997f3b0 0x997f3b0 13:53:23.584: debug : processCallRecvLen:6201 : Got length, now need 28 total (24 more) 13:53:23.585: debug : processCalls:6469 : Giving up the buck 1 0x997f3b0 (nil) 13:53:23.585: debug : call:6644 : All done with our call 1 (nil) 0x997f3b0 13:53:23.585: debug : doRemoteOpen:822 : Adding Handler for remote events 13:53:23.585: debug : doRemoteOpen:829 : virEventAddHandle failed: No addHandleImpl defined. continuing without events. 13:53:23.585: debug : do_open:956 : network driver 1 remote returned SUCCESS 13:53:23.585: debug : do_open:978 : storage driver 0 Test returned DECLINED 13:53:23.585: debug : do_open:978 : storage driver 1 remote returned SUCCESS 13:53:23.585: debug : do_open:999 : node driver 0 Test returned DECLINED 13:53:23.585: debug : do_open:999 : node driver 1 remote returned SUCCESS 13:53:23.585: debug : virConnectNumOfDomains:1440 : conn=0x996b5c8 13:53:23.585: debug : virConnectListDomains:1401 : conn=0x996b5c8, ids=0x997a6d0, maxids=1 Id Name State ---------------------------------- 13:53:23.586: debug : virDomainLookupByID:1576 : conn=0x996b5c8, id=0 13:53:23.586: debug : virGetDomain:271 : New hash entry 0x997b300 13:53:23.586: debug : virDomainGetInfo:2569 : domain=0x997b300, info=0xbfc34c64 13:53:23.586: debug : virDomainGetName:2268 : domain=0x997b300 13:53:23.586: debug : virDomainGetID:2361 : domain=0x997b300 0 Domain-0 running 13:53:23.586: debug : virDomainFree:1806 : domain=0x997b300 13:53:23.586: debug : virUnrefDomain:345 : unref domain 0x997b300 Domain-0 1 13:53:23.586: debug : virReleaseDomain:303 : release domain 0x997b300 Domain-0 13:53:23.587: debug : virReleaseDomain:315 : unref connection 0x996b5c8 5 13:53:23.587: debug : virConnectClose:1118 : conn=0x996b5c8 13:53:23.587: debug : call:6543 : Doing call 2 (nil) 13:53:23.587: debug : call:6613 : We have the buck 2 0x997f3b0 0x997f3b0 13:53:23.588: debug : processCallRecvLen:6201 : Got length, now need 28 total (24 more) 13:53:23.588: debug : processCalls:6469 : Giving up the buck 2 0x997f3b0 (nil) 13:53:23.588: debug : call:6644 : All done with our call 2 (nil) 0x997f3b0 13:53:23.588: debug : virUnrefConnect:210 : unref connection 0x996b5c8 4 13:53:23.588: debug : virUnrefConnect:210 : unref connection 0x996b5c8 3 13:53:23.589: debug : virUnrefConnect:210 : unref connection 0x996b5c8 2 13:53:23.589: debug : virUnrefConnect:210 : unref connection 0x996b5c8 1 13:53:23.589: debug : virReleaseConnect:171 : release connection 0x996b5c8 Anybody else run into this? Any help would be greatly appreciated. Thanks, Hany

2 6

[libvirt] Checkpoint VMs
by Maximilian Wilhelm 08 Jun '09

08 Jun '09

Hi! Some months ago there were some mails about ideas of adding new API functions for checkpointing of domains. For the project group Virtualized SuperComputer (the crazy guys with the ESX driver) we would like to have such a feature and would be willing to propose API patches and anything the like. As we have to deal with many VMs at the same time which belong to one computation job (think: virtualized HPC cluster) we are facing the problem to checkpoint a set of VMs at the same time. So besides a usual checkpoint we would be interested in something like checkpointAt (host, vm, timestamp) restoreFromCheckpointAt (host, vm, timestamp) an let the hypervisor / libvirtd / whatever piece of software on the host face the problem to execute the checkpoint/restore command at <timestamp>. The main idea behind this is to checkpoint or restore the set of VMs as simultaniously as possible. As far as I got it ESX for examples is able to execute tasks at a given point of time once or recurring as far as you have a Virtual Center with all your hosts belong^Wconnected to it. Any opinions on such new functions? I guess more people could be interested in this functionality. Comments welcome. Ciao Max -- Follow the white penguin.

2 1

[libvirt] Can't Pass Through USB Device To Ubuntu 9.05 Guest OS
by Robert L Cochran 08 Jun '09

08 Jun '09

Greetings! I created Bug 504444 <https://bugzilla.redhat.com/show_bug.cgi?id=504444> which is partially quoted in this post: ---------------------------------------------------------------- Coding this xml: <hostdev mode='subsystem' type='usb'> <source> <vendor id='0x0403'/> <product id='0x6001'/> </source> </hostdev> should let my Ubuntu 9.04 guest have access to the device, which in this case is a USB-to-Serial UART (based on an FTDI FT232RL chip.) However the guest does not "see" the device or recognize it in any way. It does not show up in the guest's /var/log/messages or in the output of lsusb. I would like the guest to have access to this device. This is what virsh seems to be seeing: # virsh dumpxml Ubuntu9 <domain type='kvm'> <name>Ubuntu9</name> <uuid>cb8c3d15-fe92-1bf2-5676-03370743e815</uuid> <memory>1572864</memory> <currentMemory>1572864</currentMemory> <vcpu>1</vcpu> <os> <type arch='x86_64' machine='pc'>hvm</type> <boot dev='hd'/> </os> <features> <acpi/> <apic/> <pae/> </features> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> <on_reboot>restart</on_reboot> <on_crash>restart</on_crash> <devices> <emulator>/usr/bin/qemu-kvm</emulator> <disk type='file' device='cdrom'> <target dev='hdc' bus='ide'/> <readonly/> </disk> <disk type='file' device='disk'> <source file='/var/lib/libvirt/images/Ubuntu9.img'/> <target dev='vda' bus='virtio'/> </disk> <interface type='network'> <mac address='54:52:00:74:32:2f'/> <source network='default'/> <model type='virtio'/> </interface> <serial type='pty'> <target port='0'/> </serial> <console type='pty'> <target port='0'/> </console> <input type='mouse' bus='ps2'/> <graphics type='vnc' port='-1' autoport='yes'/> <sound model='es1370'/> <hostdev mode='subsystem' type='usb' managed='no'> <source> <vendor id='0x0403'/> <product id='0x6001'/> </source> </hostdev> </devices> </domain> Version-Release number of selected component (if applicable): libvirt-0.6.2-11.fc11.x86_64 ---------------------------------- Any suggestions for fixing this problem? Is there a clear procedure for getting a Fedora virtualization guest to recognize a USB device? Thanks for your help! Bob Cochran

2 1