August 2011 - Devel - libvirt List Archives

[libvirt] [PATCH] vbox: Support shared folders
by Matthias Bolte 29 Oct '11

29 Oct '11

Shared folders are handled as filesystems and can also be hotplugged. --- Currently this just maps shared folder to a filesystem element with type mount. The filesystem element has an accessmode attribute that is not useful for VirtualBox. Als the target element only has a dir attribute, but VirtualBox shares doen't support that, you can only give them a name. <filesystem type='mount' accessmode='passthrough'> <source dir='/tmp'/> <target dir='foobar'/> <readonly/> </filesystem> I wonder if we should add a shared folder type like this: <filesystem type='sharedfolder'> <source dir='/tmp'/> <target name='foobar'/> <readonly/> </filesystem> Or is this to specific to VirtualBox? VirtualBox 4.0 added the automount option that automatically mounts a shared folder in the guest. On Windows it is mounted to a free drive letter on Linux it's mounted to /media/<prefix>_<shared-folder-name>. The <prefix> is a global configuration option in VirtualBox. I wonder if and how to expose that in libvirt. Matthias docs/drvvbox.html.in | 5 ++ src/vbox/vbox_tmpl.c | 140 ++++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 145 insertions(+), 0 deletions(-) diff --git a/docs/drvvbox.html.in b/docs/drvvbox.html.in index ef55757..1fcafde 100644 --- a/docs/drvvbox.html.in +++ b/docs/drvvbox.html.in @@ -61,6 +61,11 @@ vbox+ssh://user@example.com/session (remote access, SSH tunnelled) <target dev='fda'/> </disk> + <filesystem type='mount'> + <source dir='/home/user/stuff'/> + <target dir='my-shared-folder'/> + </filesystem> +  <interface type='bridge'> <source bridge='eth0'/> diff --git a/src/vbox/vbox_tmpl.c b/src/vbox/vbox_tmpl.c index 2986f5a..13c324f 100644 --- a/src/vbox/vbox_tmpl.c +++ b/src/vbox/vbox_tmpl.c @@ -2249,6 +2249,7 @@ static char *vboxDomainGetXMLDesc(virDomainPtr dom, int flags) { /* Not supported by libvirt yet */ } else if (device == DeviceType_SharedFolder) { /* Not supported by libvirt yet */ + /* Can VirtualBox really boot from a shared folder? */ } } @@ -2752,6 +2753,67 @@ static char *vboxDomainGetXMLDesc(virDomainPtr dom, int flags) { #endif /* VBOX_API_VERSION >= 3001 */ + /* shared folders */ + vboxArray sharedFolders = VBOX_ARRAY_INITIALIZER; + + def->nfss = 0; + + vboxArrayGet(&sharedFolders, machine, + machine->vtbl->GetSharedFolders); + + if (sharedFolders.count > 0) { + if (VIR_ALLOC_N(def->fss, sharedFolders.count) < 0) { + virReportOOMError(); + goto sharedFoldersCleanup; + } + + for (i = 0; i < sharedFolders.count; i++) { + ISharedFolder *sharedFolder = sharedFolders.items[i]; + PRUnichar *nameUtf16 = NULL; + char *name = NULL; + PRUnichar *hostPathUtf16 = NULL; + char *hostPath = NULL; + PRBool writable = PR_FALSE; + + if (VIR_ALLOC(def->fss[i]) < 0) { + virReportOOMError(); + goto sharedFoldersCleanup; + } + + def->fss[i]->type = VIR_DOMAIN_FS_TYPE_MOUNT; + + sharedFolder->vtbl->GetHostPath(sharedFolder, &hostPathUtf16); + VBOX_UTF16_TO_UTF8(hostPathUtf16, &hostPath); + def->fss[i]->src = strdup(hostPath); + VBOX_UTF8_FREE(hostPath); + VBOX_UTF16_FREE(hostPathUtf16); + + if (def->fss[i]->src == NULL) { + virReportOOMError(); + goto sharedFoldersCleanup; + } + + sharedFolder->vtbl->GetName(sharedFolder, &nameUtf16); + VBOX_UTF16_TO_UTF8(nameUtf16, &name); + def->fss[i]->dst = strdup(name); + VBOX_UTF8_FREE(name); + VBOX_UTF16_FREE(nameUtf16); + + if (def->fss[i]->dst == NULL) { + virReportOOMError(); + goto sharedFoldersCleanup; + } + + sharedFolder->vtbl->GetWritable(sharedFolder, &writable); + def->fss[i]->readonly = !writable; + + ++def->nfss; + } + } + +sharedFoldersCleanup: + vboxArrayRelease(&sharedFolders); + /* dump network cards if present */ def->nnets = 0; /* Get which network cards are enabled */ @@ -4790,6 +4852,38 @@ vboxAttachUSB(virDomainDefPtr def, vboxGlobalData *data, IMachine *machine) } } +static void +vboxAttachSharedFolder(virDomainDefPtr def, vboxGlobalData *data, IMachine *machine) +{ + int i; + PRUnichar *nameUtf16; + PRUnichar *hostPathUtf16; + PRBool writable; + + if (def->nfss == 0) + return; + + for (i = 0; i < def->nfss; i++) { + if (def->fss[i]->type != VIR_DOMAIN_FS_TYPE_MOUNT) + continue; + + VBOX_UTF8_TO_UTF16(def->fss[i]->dst, &nameUtf16); + VBOX_UTF8_TO_UTF16(def->fss[i]->src, &hostPathUtf16); + writable = !def->fss[i]->readonly; + +#if VBOX_API_VERSION < 4000 + machine->vtbl->CreateSharedFolder(machine, nameUtf16, hostPathUtf16, + writable); +#else /* VBOX_API_VERSION >= 4000 */ + machine->vtbl->CreateSharedFolder(machine, nameUtf16, hostPathUtf16, + writable, PR_FALSE); +#endif /* VBOX_API_VERSION >= 4000 */ + + VBOX_UTF16_FREE(nameUtf16); + VBOX_UTF16_FREE(hostPathUtf16); + } +} + static virDomainPtr vboxDomainDefineXML(virConnectPtr conn, const char *xml) { VBOX_OBJECT_CHECK(conn, virDomainPtr, NULL); IMachine *machine = NULL; @@ -4927,6 +5021,7 @@ static virDomainPtr vboxDomainDefineXML(virConnectPtr conn, const char *xml) { vboxAttachVideo(def, machine); vboxAttachDisplay(def, data, machine); vboxAttachUSB(def, data, machine); + vboxAttachSharedFolder(def, data, machine); /* Save the machine settings made till now and close the * session. also free up the mchiid variable used. @@ -5271,6 +5366,34 @@ static int vboxDomainAttachDeviceImpl(virDomainPtr dom, if (dev->data.hostdev->source.subsys.type == VIR_DOMAIN_HOSTDEV_SUBSYS_TYPE_USB) { } } + } else if (dev->type == VIR_DOMAIN_DEVICE_FS && + dev->data.fs->type == VIR_DOMAIN_FS_TYPE_MOUNT) { + PRUnichar *nameUtf16; + PRUnichar *hostPathUtf16; + PRBool writable; + + VBOX_UTF8_TO_UTF16(dev->data.fs->dst, &nameUtf16); + VBOX_UTF8_TO_UTF16(dev->data.fs->src, &hostPathUtf16); + writable = !dev->data.fs->readonly; + +#if VBOX_API_VERSION < 4000 + rc = machine->vtbl->CreateSharedFolder(machine, nameUtf16, hostPathUtf16, + writable); +#else /* VBOX_API_VERSION >= 4000 */ + rc = machine->vtbl->CreateSharedFolder(machine, nameUtf16, hostPathUtf16, + writable, PR_FALSE); +#endif /* VBOX_API_VERSION >= 4000 */ + + if (NS_FAILED(rc)) { + vboxError(VIR_ERR_INTERNAL_ERROR, + _("could not attach shared folder '%s', rc=%08x"), + dev->data.fs->dst, (unsigned)rc); + } else { + ret = 0; + } + + VBOX_UTF16_FREE(nameUtf16); + VBOX_UTF16_FREE(hostPathUtf16); } machine->vtbl->SaveSettings(machine); VBOX_RELEASE(machine); @@ -5425,6 +5548,23 @@ static int vboxDomainDetachDevice(virDomainPtr dom, const char *xml) { if (dev->data.hostdev->source.subsys.type == VIR_DOMAIN_HOSTDEV_SUBSYS_TYPE_USB) { } } + } else if (dev->type == VIR_DOMAIN_DEVICE_FS && + dev->data.fs->type == VIR_DOMAIN_FS_TYPE_MOUNT) { + PRUnichar *nameUtf16; + + VBOX_UTF8_TO_UTF16(dev->data.fs->dst, &nameUtf16); + + rc = machine->vtbl->RemoveSharedFolder(machine, nameUtf16); + + if (NS_FAILED(rc)) { + vboxError(VIR_ERR_INTERNAL_ERROR, + _("could not detach shared folder '%s', rc=%08x"), + dev->data.fs->dst, (unsigned)rc); + } else { + ret = 0; + } + + VBOX_UTF16_FREE(nameUtf16); } machine->vtbl->SaveSettings(machine); VBOX_RELEASE(machine); -- 1.7.0.4

2 2

[libvirt] [PATCH] xenapi: Improve error reporting in xenapiOpen once again
by Matthias Bolte 29 Oct '11

29 Oct '11

privP->session->error_description is a list and in order to get the complete error message all parts of the list should be concatenated. xenapiSessionErrorHandler does this when its third parameter is NULL. The current code discards all but the first part of the error message resulting in a potentially incomplete error message. This partly reverts 006be75ee214f9b4, that tried to avoid reporting a (null) in the error message. The actual problem is more general in returnErrorFromSession that might return NULL if there is no error. Make sure that returnErrorFromSession return non-NULL always. Also don't skip the last error message part. --- src/xenapi/xenapi_driver.c | 5 +---- src/xenapi/xenapi_utils.c | 4 +++- 2 files changed, 4 insertions(+), 5 deletions(-) diff --git a/src/xenapi/xenapi_driver.c b/src/xenapi/xenapi_driver.c index 97da1d1..77bf82d 100644 --- a/src/xenapi/xenapi_driver.c +++ b/src/xenapi/xenapi_driver.c @@ -193,10 +193,7 @@ xenapiOpen (virConnectPtr conn, virConnectAuthPtr auth, return VIR_DRV_OPEN_SUCCESS; } - xenapiSessionErrorHandler(conn, VIR_ERR_AUTH_FAILED, - *privP->session->error_description != NULL ? - *privP->session->error_description : - _("unknown error")); + xenapiSessionErrorHandler(conn, VIR_ERR_AUTH_FAILED, NULL); error: VIR_FREE(username); diff --git a/src/xenapi/xenapi_utils.c b/src/xenapi/xenapi_utils.c index 342ae5b..79fd946 100644 --- a/src/xenapi/xenapi_utils.c +++ b/src/xenapi/xenapi_utils.c @@ -272,12 +272,14 @@ returnErrorFromSession(xen_session *session) { int i; virBuffer buf = VIR_BUFFER_INITIALIZER; - for (i = 0; i < session->error_description_count - 1; i++) { + for (i = 0; i < session->error_description_count; i++) { if (!i) virBufferEscapeString(&buf, "%s", session->error_description[i]); else virBufferEscapeString(&buf, " : %s", session->error_description[i]); } + if (virBufferUse(&buf) < 1) + virBufferAdd(&buf, _("unknown error"), -1); return virBufferContentAndReset(&buf); } -- 1.7.4.1

2 2

[libvirt] [PATCH] Allow use of file images for LXC container filesystems
by Daniel P. Berrange 26 Oct '11

26 Oct '11

From: "Daniel P. Berrange" <berrange(a)redhat.com> A previous commit gave the LXC driver the ability to mount block devices for the container filesystem. Through use of the loopback device functionality, we can build on this to support use of plain file images for LXC filesytems. By setting the LO_FLAGS_AUTOCLEAR flag we can ensure that the loop device automatically disappears when the container dies / shuts down * src/lxc/lxc_container.c: Raise error if we see a file based filesystem, since it should have been turned into a loopback device already * src/lxc/lxc_controller.c: Rewrite any filesystems of type=file, into type=block, by binding the file image to a free loop device --- src/lxc/lxc_container.c | 5 ++ src/lxc/lxc_controller.c | 176 +++++++++++++++++++++++++++++++++++++++++++++- 2 files changed, 179 insertions(+), 2 deletions(-) diff --git a/src/lxc/lxc_container.c b/src/lxc/lxc_container.c index f6ab407..bf772e5 100644 --- a/src/lxc/lxc_container.c +++ b/src/lxc/lxc_container.c @@ -797,6 +797,11 @@ static int lxcContainerMountFS(virDomainFSDefPtr fs, if (lxcContainerMountFSBlock(fs, srcprefix) < 0) return -1; break; + case VIR_DOMAIN_FS_TYPE_FILE: + lxcError(VIR_ERR_INTERNAL_ERROR, + _("Unexpected filesystem type %s"), + virDomainFSTypeToString(fs->type)); + break; default: lxcError(VIR_ERR_CONFIG_UNSUPPORTED, _("Cannot mount filesystem type %s"), diff --git a/src/lxc/lxc_controller.c b/src/lxc/lxc_controller.c index 8848ae2..45b4c70 100644 --- a/src/lxc/lxc_controller.c +++ b/src/lxc/lxc_controller.c @@ -39,6 +39,8 @@ #include <getopt.h> #include <sys/mount.h> #include <locale.h> +#include <linux/loop.h> +#include <dirent.h> #if HAVE_CAPNG # include <cap-ng.h> @@ -63,6 +65,160 @@ struct cgroup_device_policy { int minor; }; + +static int lxcGetLoopFD(char **devname) +{ + int fd = -1; + DIR *dh = NULL; + struct dirent *de; + char *looppath; + struct loop_info64 lo; + + VIR_DEBUG("Looking for loop devices in /dev"); + + if (!(dh = opendir("/dev"))) { + virReportSystemError(errno, "%s", + _("Unable to read /dev")); + goto cleanup; + } + + while ((de = readdir(dh)) != NULL) { + if (!STRPREFIX(de->d_name, "loop")) + continue; + + if (virAsprintf(&looppath, "/dev/%s", de->d_name) < 0) { + virReportOOMError(); + goto cleanup; + } + + VIR_DEBUG("Checking up on device %s", looppath); + if ((fd = open(looppath, O_RDWR)) < 0) { + virReportSystemError(errno, + _("Unable to open %s"), looppath); + goto cleanup; + } + + if (ioctl(fd, LOOP_GET_STATUS64, &lo) < 0) { + /* Got a free device, return the fd */ + if (errno == ENXIO) + goto cleanup; + + VIR_FORCE_CLOSE(fd); + virReportSystemError(errno, + _("Unable to get loop status on %s"), + looppath); + goto cleanup; + } + + /* Oh well, try the next device */ + VIR_FORCE_CLOSE(fd); + VIR_FREE(looppath); + } + + lxcError(VIR_ERR_INTERNAL_ERROR, "%s", + _("Unable to find a free loop device in /dev")); + +cleanup: + if (fd != -1) { + VIR_DEBUG("Got free loop device %s %d", looppath, fd); + *devname = looppath; + } else { + VIR_DEBUG("No free loop devices available"); + VIR_FREE(looppath); + } + if (dh) + closedir(dh); + return fd; +} + +static int lxcSetupLoopDevice(virDomainFSDefPtr fs) +{ + int lofd = -1; + int fsfd = -1; + struct loop_info64 lo; + char *loname = NULL; + int ret = -1; + + if ((lofd = lxcGetLoopFD(&loname)) < 0) + return -1; + + memset(&lo, 0, sizeof(lo)); + lo.lo_flags = LO_FLAGS_AUTOCLEAR; + + if ((fsfd = open(fs->src, O_RDWR)) < 0) { + virReportSystemError(errno, + _("Unable to open %s"), fs->src); + goto cleanup; + } + + if (ioctl(lofd, LOOP_SET_FD, fsfd) < 0) { + virReportSystemError(errno, + _("Unable to attach %s to loop device"), + fs->src); + goto cleanup; + } + + if (ioctl(lofd, LOOP_SET_STATUS64, &lo) < 0) { + virReportSystemError(errno, "%s", + _("Unable to mark loop device as autoclear")); + + if (ioctl(lofd, LOOP_CLR_FD, 0) < 0) + VIR_WARN("Unable to detach %s from loop device", fs->src); + goto cleanup; + } + + VIR_DEBUG("Attached loop device %s %d to %s", fs->src, lofd, loname); + /* + * We now change it into a block device type, so that + * the rest of container setup 'just works' + */ + fs->type = VIR_DOMAIN_FS_TYPE_BLOCK; + VIR_FREE(fs->src); + fs->src = loname; + loname = NULL; + + ret = 0; + +cleanup: + VIR_FREE(loname); + VIR_FORCE_CLOSE(fsfd); + if (ret == -1) + VIR_FORCE_CLOSE(lofd); + return lofd; +} + + +static int lxcSetupLoopDevices(virDomainDefPtr def, size_t *nloopDevs, int **loopDevs) +{ + size_t i; + int ret = -1; + + for (i = 0 ; i < def->nfss ; i++) { + int fd; + + if (def->fss[i]->type != VIR_DOMAIN_FS_TYPE_FILE) + continue; + + fd = lxcSetupLoopDevice(def->fss[i]); + if (fd < 0) + goto cleanup; + + VIR_DEBUG("Saving loop fd %d", fd); + if (VIR_REALLOC_N(*loopDevs, *nloopDevs+1) < 0) { + VIR_FORCE_CLOSE(fd); + virReportOOMError(); + goto cleanup; + } + (*loopDevs)[*nloopDevs++] = fd; + } + + VIR_DEBUG("Setup all loop devices"); + ret = 0; + +cleanup: + return ret; +} + /** * lxcSetContainerResources * @def: pointer to virtual machine structure @@ -641,6 +797,9 @@ lxcControllerRun(virDomainDefPtr def, virDomainFSDefPtr root; char *devpts = NULL; char *devptmx = NULL; + size_t nloopDevs = 0; + int *loopDevs = NULL; + size_t i; if (socketpair(PF_UNIX, SOCK_STREAM, 0, control) < 0) { virReportSystemError(errno, "%s", @@ -654,6 +813,9 @@ lxcControllerRun(virDomainDefPtr def, goto cleanup; } + if (lxcSetupLoopDevices(def, &nloopDevs, &loopDevs) < 0) + goto cleanup; + root = virDomainGetRootFilesystem(def); if (lxcSetContainerResources(def) < 0) @@ -778,8 +940,14 @@ lxcControllerRun(virDomainDefPtr def, goto cleanup; } - /* Now the container is running, there's no need for us to keep - any elevated capabilities */ + /* Now the container is fully setup... */ + + /* ...we can close the loop devices... */ + + for (i = 0 ; i < nloopDevs ; i++) + VIR_FORCE_CLOSE(loopDevs[i]); + + /* ...and reduce our privileges */ if (lxcControllerClearCapabilities() < 0) goto cleanup; @@ -803,6 +971,10 @@ cleanup: VIR_FORCE_CLOSE(containerhandshake[0]); VIR_FORCE_CLOSE(containerhandshake[1]); + for (i = 0 ; i < nloopDevs ; i++) + VIR_FORCE_CLOSE(loopDevs[i]); + VIR_FREE(loopDevs); + if (container > 1) { int status; kill(container, SIGTERM); -- 1.7.6

2 8

[libvirt] qemu-namespace handling?
by Philipp Hahn 19 Oct '11

19 Oct '11

Hello, some time ago I hand to manipulate the domain XML description using Pythons Elemtree XML implementation, which had problems generating the right format for libvirt: elemtree just supports adding Qname elements (that is "{http://libvirt.org/schemas/domain/qemu/1.0}commandline") which internally would create a temporary binding of this namespace to the "ns0" Prefix. My work-around for Elemtree was the add the name-space mapping for "qemu" to "http://libvirt.org/schemas/domain/qemu/1.0" to ETs internal mapping table and add an "xmlns:qemu" attribute by hand: ET._namespace_map[QEMU_URI] = 'qemu' domain.attrib['xmlns:qemu'] = QEMU_URI libvirt on the other hand expects the prefix to be "qemu" and only checks, that this prefix is bound to the URI mentioned above at the root node). The following examples would be XML valid, but are not accepted by libvirt: <domain>... <qemu:commandline xmlns:qemu="http://libvirt.org/schemas/domain/qemu/1.0"> ...</qemu:commandline> </domain> <domain xmlns:ns0="http://libvirt.org/schemas/domain/qemu/1.0">... <ns0:commandline> ...</ns0:commandline> </domain> The following (esoteric) example might be wrongly accepted by libvirt (untested): <domain xmlns:qemu="http://libvirt.org/schemas/domain/qemu/1.0"> <qemu:commandline xmlns:qemu="urn:foo"> ...</qemu:commandline> </domain> I don't know if this is worth fixing, but I still encountered the first two problems myself and had to spend some time to detecting what I did wrong. So at least I want to share my finding with others, so they don't do the same mistake. Sincerely Philipp Hahn -- Philipp Hahn Open Source Software Engineer hahn(a)univention.de Univention GmbH Linux for Your Business fon: +49 421 22 232- 0 Mary-Somerville-Str.1 D-28359 Bremen fax: +49 421 22 232-99 http://www.univention.de/

3 7

Re: [libvirt] [virt-tools-list] virt-manager/libvirt backwards compatibility problem?
by Eric Blake 12 Oct '11

12 Oct '11

[adding libvir-list] On 07/27/2011 10:28 AM, Whit Blauvelt wrote: > Looks like my real problem may be not incorporating a Debian/Ubuntu patch > before building 0.9.x, since netcat differs: > > https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/517478 Reading that bug report, it looks like upstream libvirt.git should be patched to add a runtime test on whether a remote nc supports the -q option, rather than blindly assuming that 'nc -q' exists on the remote side. -- Eric Blake eblake(a)redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org

4 9

[libvirt] Deadlock when using custom handlers
by Guido Günther 04 Oct '11

04 Oct '11

Hi, virt-viewer is using it's own virEventRegisterImpl. With current libvirt this can deadlock when connection to nonexistant URIs like qemu+ssh:///unknownhost.example.com/system like: 23:47:00.338: 1526: debug : doRemoteOpen:503 : proceeding with name = qemu:///system 23:47:00.338: 1526: debug : doRemoteOpen:513 : Connecting with transport 2 23:47:00.338: 1526: debug : virCommandRunAsync:2042 : About to run LC_ALL=C LD_LIBRARY_PATH=/var/scratch/debian/libvirt/upstream/libvirt/src/.libs/ PATH=/usr/local/bin:/usr/bin:/bin:/usr/games:/home/agx/bin:/sbin:/usr/sbin:/usr/lib/git-core HOME=/home/agx USER=agx LOGNAME=agx SSH_AUTH_SOCK=/tmp/keyring-RNvlnT/ssh DISPLAY=:0 ssh pustekiste nc -U /var/run/libvirt/libvirt-sock-ro 23:47:00.339: 1526: debug : virCommandRunAsync:2058 : Command result 0, with PID 1527 23:47:00.339: 1526: debug : virNetSocketNew:115 : localAddr=(nil) remoteAddr=(nil) fd=6 errfd=8 pid=1527 23:47:00.339: 1526: debug : virNetSocketNew:173 : sock=0x8926d20 localAddrStr=(null) remoteAddrStr=(null) ** (virt-viewer:1526): DEBUG: Add handle 6 1 0x8926d20 23:47:00.339: 1526: debug : virNetClientNew:160 : client=0xb5b5f008 refs=2 23:47:00.339: 1526: debug : doRemoteOpen:640 : Trying authentication 23:47:00.339: 1526: debug : virNetMessageNew:44 : msg=0xb5b1e008 23:47:00.340: 1526: debug : virNetMessageEncodePayload:255 : Encode length as 28 23:47:00.340: 1526: debug : virNetClientIO:1035 : program=536903814 version=1 serial=0 proc=66 type=0 length=28 dispatch=(nil) 23:47:00.340: 1526: debug : virNetClientIO:1103 : We have the buck 0x8939940 0x8939940 23:47:00.350: 1526: debug : virNetClientIOEventLoop:979 : Giving up the buck due to I/O error 0x8939940 (nil) 23:47:00.350: 1526: debug : virNetClientIO:1130 : All done with our call (nil) 0x8939940 -1 23:47:00.350: 1526: debug : virNetMessageFree:57 : msg=0xb5b1e008 ** (virt-viewer:1526): DEBUG: Remove handle 1 6 <deadlock> Gdb displays the deadlock nicely: #0 0xb7710424 in __kernel_vsyscall () #1 0xb692cf02 in __lll_lock_wait () at ../nptl/sysdeps/unix/sysv/linux/i386/i686/../i486/lowlevellock.S:142 #2 0xb692839b in _L_lock_728 () from /lib/i386-linux-gnu/i686/cmov/libpthread.so.0 #3 0xb69281c1 in __pthread_mutex_lock (mutex=0x95e1c30) at pthread_mutex_lock.c:61 #4 0xb698fd07 in virMutexLock (m=0x95e1c30) at util/threads-pthread.c:85 #5 0xb6a5dd56 in virNetSocketEventFree (opaque=0x95e1c30) at rpc/virnetsocket.c:1147 #6 0x080514a1 in virt_viewer_events_remove_handle (watch=1) at virt-viewer-events.c:178 #7 0xb697264e in virEventRemoveHandle (watch=1) at util/event.c:84 #8 0xb6a608ed in virNetSocketRemoveIOCallback (sock=0x95e1c30) at rpc/virnetsocket.c:1221 #9 0xb6a57114 in virNetClientClose (client=0xb5b7e008) at rpc/virnetclient.c:280 #10 0xb6a46fc4 in doRemoteOpen (conn=0x95e1aa8, priv=0x95b1370, auth=0xbfc3b178, flags=1) at remote/remote_driver.c:705 #11 0xb6a49612 in remoteOpen (conn=0x95e1aa8, auth=0xbfc3b178, flags=1) at remote/remote_driver.c:820 #12 0xb69f70c6 in do_open (name=0x95aac10 "qemu+ssh://pustekiste:2222/system", auth=0xbfc3b178, flags=1) at libvirt.c:1054 #13 0xb69f9b88 in virConnectOpenAuth (name=0x95aac10 "qemu+ssh://pustekiste:2222/system", auth=0xbfc3b178, flags=1) at libvirt.c:1280 #14 0x080500cf in virt_viewer_start (app=0x95a1010) at virt-viewer.c:483 #15 0x08053be8 in virt_viewer_app_start (self=0x95a1010) at virt-viewer-app.c:1044 #16 0x0804f54d in main (argc=1, argv=0xbfc3b3f4) at virt-viewer-main.c:120 which is the sock->lock: virNetSocketRemoveIOCallback holds sock->lock -> virEventRemoveHandle -> impl_remove_handle -> opaque->ff -> virNetSocketEventFree want to hold sock->lock Working around this by removing the locks from virNetSocketRemoveIOCallback leads to another deadlock: #0 0xb77de424 in __kernel_vsyscall () #1 0xb69faf02 in __lll_lock_wait () at ../nptl/sysdeps/unix/sysv/linux/i386/i686/../i486/lowlevellock.S:142 #2 0xb69f639b in _L_lock_728 () from /lib/i386-linux-gnu/i686/cmov/libpthread.so.0 #3 0xb69f61c1 in __pthread_mutex_lock (mutex=0xb5c4c00c) at pthread_mutex_lock.c:61 #4 0xb6a5dd07 in virMutexLock (m=0xb5c4c00c) at util/threads-pthread.c:85 #5 0xb6b24a98 in virNetClientLock (client=0xb5c4c008) at rpc/virnetclient.c:99 #6 virNetClientFree (client=0xb5c4c008) at rpc/virnetclient.c:243 #7 0xb6b250b7 in virNetClientEventFree (opaque=0xb5c4c008) at rpc/virnetclient.c:117 #8 0xb6b2bd82 in virNetSocketEventFree (opaque=0x8aabc30) at rpc/virnetsocket.c:1156 #9 0x080514a1 in virt_viewer_events_remove_handle (watch=1) at virt-viewer-events.c:178 #10 0xb6a4064e in virEventRemoveHandle (watch=1) at util/event.c:84 #11 0xb6b2e8e5 in virNetSocketRemoveIOCallback (sock=0x8aabc30) at rpc/virnetsocket.c:1219 #12 0xb6b25114 in virNetClientClose (client=0xb5c4c008) at rpc/virnetclient.c:280 #13 0xb6b14fc4 in doRemoteOpen (conn=0x8aabaa8, priv=0x8a7b370, auth=0xbfbf1798, flags=1) at remote/remote_driver.c:705 #14 0xb6b17612 in remoteOpen (conn=0x8aabaa8, auth=0xbfbf1798, flags=1) at remote/remote_driver.c:820 #15 0xb6ac50c6 in do_open (name=0x8a74c10 "qemu+ssh://pustekiste:2222/system", auth=0xbfbf1798, flags=1) at libvirt.c:1054 #16 0xb6ac7b88 in virConnectOpenAuth (name=0x8a74c10 "qemu+ssh://pustekiste:2222/system", auth=0xbfbf1798, flags=1) at libvirt.c:1280 #17 0x080500cf in virt_viewer_start (app=0x8a6b010) at virt-viewer.c:483 #18 0x08053be8 in virt_viewer_app_start (self=0x8a6b010) at virt-viewer-app.c:1044 #19 0x0804f54d in main (argc=1, argv=0xbfbf1a14) at virt-viewer-main.c:120 which is the virNetClient lock: virNetClientClose holds client->lock -> virNetSocketRemoveIOCallback -> virEventRemoveHandle -> impl_remove_handle -> virNetSocketEventFree -> virNetClientEventFree wants the lock I didn't see a simple way to fix this but would welcome any suggestions. Cheers, -- Guido

2 6

[libvirt] LPC2011 Virtualization Micro Conf
by Jes Sorensen 27 Sep '11

27 Sep '11

Hi, With the success of last year's Virtualization micro-conference track at Linux Plumbers 2010, I have accepted to organize a similar track for Linux Plumbers 2011 in Santa Rosa. Please see the official Linux Plumbers 2011 website for full details about the conference: http://www.linuxplumbersconf.org/2011/ The Linux Plumbers 2011 Virtualization track is focusing on general free software Linux Virtualization. It is not reserved for a specific hypervisor, but will focus on general virtualization issues and in particular collaboration amongst projects. This would include KVM, Xen, QEMU, containers etc. Deadline: --------- The deadline for submissions is April 30th. Please visit the following link to submit your proposal: http://www.linuxplumbersconf.org/2011/ocw/events/LPC2011MC/proposals Example topics: --------------- - Kernel and Hypervisor KVM/QEMU/Xen interaction - QEMU integration, sharing of code between the different projects - IO Performance and scalability - Live Migration - Managing and supporting enterprise storage - Support for new hardware features, and/or provide guest access to these features. - Guest agents - Virtualization management tools, libvirt, etc. - Desktop integration - Consumer Electronics device emulation - Custom platform configuration and coordination with the kernel Audience: --------- Virtualization hypervisor developers, developers of virtualization management tools and applications, embedded virtualization developers, vendors and others. Best regards, Jes

1 1

[libvirt] specifying rbd images in libvirt
by Sage Weil 20 Sep '11

20 Sep '11

Hi all, Currently, you can specify an rbd (or nbd, sheepdog) image with xml that looks like so: <disk type='network' device='disk'> <driver name='qemu' type='raw' cache='writeback'/> <source protocol='rbd' name='mypool/myimage'> <host name='monhost1.mydomain.com' port='6789'/> <host name='monhost2.mydomain.com' port='6789'/> <host name='monhost3.mydomain.com' port='6789'/> </source> <target dev='vda' bus='virtio'/> </disk> This works okay if you have authentication disabled and all of the default settings are okay. Usually, though, there are other options you need to specify to librbd to make it do what you want. The current schema can be abused by adding options after the image name like so: <disk type='network' device='disk'> <driver name='qemu' type='raw' cache='writeback'/> <source protocol='rbd' name='mypool/myimage:conf=/etc/ceph/ceph.conf:id=admin:this=that:foo=bar'> <host name='monhost1.mydomain.com' port='6789'/> <host name='monhost2.mydomain.com' port='6789'/> <host name='monhost3.mydomain.com' port='6789'/> </source> <target dev='vda' bus='virtio'/> </disk> This works only because that's what the qemu incantation looks like. In general, though, this is ugly. I also doesn't generalize well to the kernel-level rbd driver, which we'd like to also support, as that will work with hypervisors other than qemu. What about something more like this? <disk type='network' device='disk'> <driver name='qemu' type='raw' cache='writeback'/> <source protocol='rbd' name='mypool/myimage'> <option name='conf'>/etc/ceph/ceph.conf</option> <option name='id'>myusername</option> <option name='foo'>bar</option> <host name='monhost1.mydomain.com' port='6789'/> <host name='monhost2.mydomain.com' port='6789'/> <host name='monhost3.mydomain.com' port='6789'/> </source> <target dev='vda' bus='virtio'/> </disk> I'm not married to any particular syntax/schema, as long as there is a generic way to specify name/value pairs to configure the driver. I think the above would generalize well to other network block devices as well, which presumably also want a way to feed in information other than a server address (e.g. for authentication). Does that look reasonable? If there are no objections we can work up some patches and send them along! Thanks- sage

3 5

[libvirt] [PATCH 0/8] Add virDomainMigrateGetMaxSpeed API
by Jim Fehlig 16 Sep '11

16 Sep '11

As per previous request [1], this patch series introduces virDomainMigrateGetMaxSpeed API. Patches 1-5 contain usual new API stuff. In patch 6, qemuDomainMigrateSetMaxSpeed is made to work with inactive domains and set the new value in domain conf. Patch 7 changes migration speed to unlimited when target is a file *and* no user defined migration speed is set, and reverts to previous value after migration completes. Patch 8 considers user-defined migration speed in qemuMigrationRun() when explicit bandwidth is not provided in 'resource' paramter. Note that a patch to fix the remote protocol generator [2] is required for this patch series. [1] https://www.redhat.com/archives/libvir-list/2011-August/msg00224.html [2] https://www.redhat.com/archives/libvir-list/2011-August/msg01367.html Jim Fehlig (8): Add on_migrate element to domainXML Add public API for getting migration speed Add max migration bandwidth to domain_conf Impl virDomainMigrateGetMaxSpeed in qemu driver virsh: Expose virDomainMigrateGetMaxSpeed API Save migration speed to domain conf in qemuDomainMigrateSetMaxSpeed Set qemu migration speed unlimited when migrating to file Use max speed specified in domain conf when migrating docs/apibuild.py | 3 +- docs/formatdomain.html.in | 21 +++++++ docs/schemas/domain.rng | 13 +++++ include/libvirt/libvirt.h.in | 4 ++ python/generator.py | 1 + python/libvirt-override-api.xml | 6 ++ python/libvirt-override.c | 24 ++++++++ src/conf/domain_conf.c | 11 ++++ src/conf/domain_conf.h | 2 + src/driver.h | 6 ++ src/libvirt.c | 51 ++++++++++++++++++ src/libvirt_public.syms | 5 ++ src/qemu/qemu_driver.c | 76 ++++++++++++++++++++------- src/qemu/qemu_migration.c | 28 +++++++++- src/qemu/qemu_migration.h | 3 + src/remote/remote_driver.c | 1 + src/remote/remote_protocol.x | 13 ++++- src/remote_protocol-structs | 9 +++ src/rpc/gendispatch.pl | 1 + tests/domainschemadata/migration-params.xml | 34 ++++++++++++ tools/virsh.c | 41 ++++++++++++++ tools/virsh.pod | 4 ++ 22 files changed, 333 insertions(+), 24 deletions(-) create mode 100644 tests/domainschemadata/migration-params.xml -- 1.7.5.4

4 26

[libvirt] libvirt(-java): virDomainMigrateSetMaxDowntime
by Thomas Treutner 15 Sep '11

15 Sep '11

Hi, I'm facing some troubles with virDomainMigrate & virDomainMigrateSetMaxDowntime. The core problem is that KVM's default value for the maximum allowed downtime is 30ms (max_downtime in migration.c, it's nanoseconds there; 0.12.3) which is too low for my VMs when they're busy (~50% CPU util and above). Migrations then take literally forever, I had to abort them after 15 minutes or so. I'm using GBit Ethernet, so plenty bandwidth should be available. Increasing the allowed downtime to 50ms seems to help, but I have not tested situations where the VM is completely utilized. Anyways, the default value is too low for me, so I tried virDomainMigrateSetMaxDowntime resp. the Java wrapper function. Here I'm facing a problem I can overcome only with a quite crude hack: org.libvirt.Domain.migrate(..) blocks until the migration is done, which is of course reasonable. So I tried calling migrateSetMaxDowntime(..) before migrating, causing an error: "Requested operation is not valid: domain is not being migrated" This tells me that calling migrateSetMaxDowntime is only allowed during migrations. As I'm migrating VMs automatically and without any user intervention I'd need to create some glue code that runs in an extra thread, waiting "some time" hoping that the migration was kicked off in the main thread yet and then calling migrateSetMaxDowntime. I'd like to avoid such quirks in the long run, if possible. So my question: Would it be possible to extend the migrate() method resp. virDomainMigrate() function with an optional maxDowntime parameter that is passed down as QEMU_JOB_SIGNAL_MIGRATE_DOWNTIME so that qemuDomainWaitForMigrationComplete would set the value? Or are there easier ways? Thanks and regards, -t

3 5