- Devel - libvirt List Archives

[libvirt] [PATCH 1/2]: Give /dev/disk/by-{id, path} a chance to exist
by Chris Lalancette 28 Nov '08

28 Nov '08

This patch is the same idea as my previous patch for giving /dev/disk/by-{id,path} a chance to exist. Currently libvirt can race with udev creation of /dev/disk/by-{id,path}, so if we fail to open the directory, retry up to 5 seconds. This is only likely to happen on hosts that are: 1) diskless (so /dev/disk/by-{id,path} doesn't exist already), and 2) slow, and/or heavily loaded (meaning that udev can take some time to create the /dev nodes). Based on the feedback from Dan and Jim, I updated the patch to look more like what is elsewhere in libvirt. Signed-off-by: Chris Lalancette <clalance(a)redhat.com> Index: src/storage_backend.c =================================================================== RCS file: /data/cvs/libvirt/src/storage_backend.c,v retrieving revision 1.29 diff -u -r1.29 storage_backend.c --- a/src/storage_backend.c 17 Nov 2008 11:19:33 -0000 1.29 +++ b/src/storage_backend.c 26 Nov 2008 12:09:36 -0000 @@ -291,6 +291,7 @@ DIR *dh; struct dirent *dent; char *stablepath; + int opentries = 0; /* Short circuit if pool has no target, or if its /dev */ if (pool->def->target.path == NULL || @@ -304,12 +305,17 @@ if (!STRPREFIX(pool->def->target.path, "/dev")) goto ret_strdup; - /* The pool is pointing somewhere like /dev/disk/by-path - * or /dev/disk/by-id, so we need to check all symlinks in - * the target directory and figure out which one points - * to this device node + /* We loop here because /dev/disk/by-{id,path} may not have existed + * before we started this operation, so we have to give it some time to + * get created. */ + reopen: if ((dh = opendir(pool->def->target.path)) == NULL) { + opentries++; + if (errno == ENOENT && opentries < 50) { + usleep(100 * 1000); + goto reopen; + } virStorageReportError(conn, VIR_ERR_INTERNAL_ERROR, _("cannot read dir %s: %s"), pool->def->target.path, @@ -317,6 +323,11 @@ return NULL; } + /* The pool is pointing somewhere like /dev/disk/by-path + * or /dev/disk/by-id, so we need to check all symlinks in + * the target directory and figure out which one points + * to this device node + */ while ((dent = readdir(dh)) != NULL) { if (dent->d_name[0] == '.') continue;

2 2

[libvirt] PATCH: Allow automatic driver probe for remote TCP connections
by Daniel P. Berrange 27 Nov '08

27 Nov '08

When connecting to a local libvirt you can let it automatically probe the hypervisor URI if you don't know it ahead of time. This doesn't work with remote URIs because you need to have something to put in the URI scheme before the hostname qemu+ssh://somehost/system xen+tcp://somehost/system This is then translated into the URI qemu:///system xen:/// It occurred to me that we can trivially enable probing with all existing libvirtd daemon releases, simply by fixing the client side. All we need todo is invent a new generic URI scheme, and convert that to empty string This patch adds a 'remote' URI scheme, usable like this remote+ssh://somehost/ remote+tcp://somehost/ remote://somehost/ remote+tls://somehost/ remote+ext://somehost/ In all these styles, the URI passed to the remote daemon is "", causing it to probe. As a demonstration, here's an example using virsh and two hosts I have, one running Xen, the other QEMU See it automatically choosing QEMU.... $ virsh --connect remote+ssh://root@lettuce/ version Compiled against library: libvir 0.5.0 Using library: libvir 0.5.0 Running hypervisor: QEMU 0.9.1 And choosing Xen.... $ virsh --connect remote+ssh://root@pumpkin/ version Compiled against library: libvir 0.5.0 Using library: libvir 0.5.0 Running hypervisor: Xen 3.1.0 This finally makes the Avahi broadcasts useful - they only include info on the hostname + data transport (SSH, TCP, TLS), not the HV type. So letting us use auto-probing remotely is the missing link. NB. we've got a small problem with the virGetVersion() API - it does not take a connection URI - just a hypervisor type. It then directly checks the statically declared 'version' field in the virDriverPtr struct. This no longer works now that some drivers are linked directly into the libvirt daemon. I'm thinking that perhaps we can just change the virGetVersion() apis so that instead of looking in virDriverPtr struct, we just include the version numbers directly in virGetVersion as a static const lookup table. Meanwhile, this patch also includes a change to virsh to stop it calling virGetVersion(), though this hunk instead intended to apply to CVS. Daniel Index: remote_internal.c =================================================================== RCS file: /data/cvs/libvirt/src/remote_internal.c,v retrieving revision 1.108 diff -u -p -r1.108 remote_internal.c --- remote_internal.c 21 Nov 2008 12:31:04 -0000 1.108 +++ remote_internal.c 26 Nov 2008 21:58:47 -0000 @@ -430,28 +430,40 @@ doRemoteOpen (virConnectPtr conn, /* Construct the original name. */ if (!name) { - xmlURI tmpuri = { - .scheme = conn->uri->scheme, + if (STREQ(conn->uri->scheme, "remote") || + STRPREFIX(conn->uri->scheme, "remote+")) { + /* Allow remote serve to probe */ + name = strdup(""); + } else { + xmlURI tmpuri = { + .scheme = conn->uri->scheme, #ifdef HAVE_XMLURI_QUERY_RAW - .query_raw = qparam_get_query (vars), + .query_raw = qparam_get_query (vars), #else - .query = qparam_get_query (vars), + .query = qparam_get_query (vars), #endif - .path = conn->uri->path, - .fragment = conn->uri->fragment, - }; - - /* Evil, blank out transport scheme temporarily */ - if (transport_str) { - assert (transport_str[-1] == '+'); - transport_str[-1] = '\0'; - } + .path = conn->uri->path, + .fragment = conn->uri->fragment, + }; + + /* Evil, blank out transport scheme temporarily */ + if (transport_str) { + assert (transport_str[-1] == '+'); + transport_str[-1] = '\0'; + } + + name = (char *) xmlSaveUri (&tmpuri); - name = (char *) xmlSaveUri (&tmpuri); +#ifdef HAVE_XMLURI_QUERY_RAW + VIR_FREE(tmpuri.query_raw); +#else + VIR_FREE(tmpuri.query); +#endif - /* Restore transport scheme */ - if (transport_str) - transport_str[-1] = '+'; + /* Restore transport scheme */ + if (transport_str) + transport_str[-1] = '+'; + } } free_qparam_set (vars); Index: virsh.c =================================================================== RCS file: /data/cvs/libvirt/src/virsh.c,v retrieving revision 1.175 diff -u -p -r1.175 virsh.c --- virsh.c 24 Nov 2008 07:13:30 -0000 1.175 +++ virsh.c 26 Nov 2008 21:58:51 -0000 @@ -4357,7 +4357,6 @@ cmdVersion(vshControl *ctl, const vshCmd const char *hvType; unsigned long libVersion; unsigned long includeVersion; - unsigned long apiVersion; int ret; unsigned int major; unsigned int minor; @@ -4380,7 +4379,8 @@ cmdVersion(vshControl *ctl, const vshCmd vshPrint(ctl, _("Compiled against library: libvir %d.%d.%d\n"), major, minor, rel); - ret = virGetVersion(&libVersion, hvType, &apiVersion); + + ret = virGetVersion(&libVersion, NULL, NULL); if (ret < 0) { vshError(ctl, FALSE, "%s", _("failed to get the library version")); return FALSE; @@ -4392,13 +4392,6 @@ cmdVersion(vshControl *ctl, const vshCmd vshPrint(ctl, _("Using library: libvir %d.%d.%d\n"), major, minor, rel); - major = apiVersion / 1000000; - apiVersion %= 1000000; - minor = apiVersion / 1000; - rel = apiVersion % 1000; - vshPrint(ctl, _("Using API: %s %d.%d.%d\n"), hvType, - major, minor, rel); - ret = virConnectGetVersion(ctl->conn, &hvVersion); if (ret < 0) { vshError(ctl, FALSE, "%s", _("failed to get the hypervisor version")); -- |: 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] [PATCH] Prefer xend setmaxmem interface
by Jim Fehlig 27 Nov '08

27 Nov '08

As discussed in [1], prefer xend interface for setting max memory. Regards, Jim [1] https://www.redhat.com/archives/libvir-list/2008-November/msg00339.html

3 3

[libvirt] [PATCH 0/2]: Make storage_backend device scanning more reliable
by Chris Lalancette 26 Nov '08

26 Nov '08

All, This is a 2 part patch series to make libvirt backend device scanning more reliable. In particular, this is important for things that can create/destroy udev /dev nodes, since at present we can race with the udev creation. Note that this takes over the previous patch that I posted to retry /dev/disk/by-{id,path} scanning. Signed-off-by: Chris Lalancette <clalance(a)redhat.com>

2 1

[libvirt] make not invoking rpcgen remote_protocol.x
by Kenneth Nagin 26 Nov '08

26 Nov '08

I am attempting to add some new libvirt functions that I intend to submit for your approval. I have made changes to remote_protocol.x. Initially it generated the expected files. However, after making a few changes the make no causes it to generate files. Manually invoke rpcgen -c remote_protocol.x > remote_protocol.c seems to get around the compile problem. But now I'm getting a "Remote error : marshaling args" I 'm think there is a problem in the make. Kenneth Nagin

3 4

[libvirt] libvirt_low_level_storage_api
by shahar＠compal1.qumranet.com 26 Nov '08

26 Nov '08

Hi All, here is an initial version of the operations required for SolidICE and the proposed high level interface. I would like to discuss how to map it to libvirt calls and what libvirt calls are missing. Thanks, Shahar Frank HostLevel --------- enumarateLuns(): return: returns all luns visible by the host. In case multipathing is enabled then only the multipath device should be in the return list. enumerateISCSILuns(target): params: target - ISCSI target Description: enumerate all ISCSI luns on a specific target return: list of getBlockInfo(name or UUID): return: at least uuid & size enumerateVGs(): return: VG UUID list open issues - should we assume ISCSI auto connect or FC login? StoragePool level ----------------- createVolumeGroup(name, devices): params: name = name devices - a list of UUIDs description: Should create a volume group out of the UUID list In case multipathing is enabled then only the multipath device should be used In case it is not a PV yet then a PV is to be created. Return: Uuid of the VG removeVolumeGroup(VG): params: VG - uuid of the Volume group Description: Remove all remains for the VolumeGroup (LVs, PVs ...) Return: Sucsess/failure mountNFS(server, remotePath, localPath, params) params: server - the NFS server name or IP temotePath - remote server export path localPath - local path to mount on params - nfs mount params description: mounts the remote export onto the local path using the mount params return: success/failure unmount(localPath, forceFlag) params: localPath - the local path to unmount forceFlag - a flag indicating whether to force unmount description: unmounts local path (trivial) return: success/failure Open issues: 1. NFS configuration persistency? 2. What happens in case the libvirt is restarted should it be reconfigured? VolumeGroup level ----------------- listPV(VG): params: VG - Volume group UUID Description: Lists all PV in a specific volume group Return: A list of PV UUIDs infoPV(VG, PV) params: VG - Volume group UUID PV - Physical volume UUID description: trivial return: returns the PV information (at least size & path) extendVolumeGroup(VG, devices): params: VG - Volume Group UUID devices - a list of UUIDs description: This function adds Phisical Volume to the VolumeGroup. Each UUID device is checked, In case multipathing is enabled then only the multipath device should be used (PV create in case it's not) and added to the volume group return: success/fauilure removePV(VG, PV): params: VG - Volume Group UUID PV - Physical volume's UUID to be removed description: removes the physical volume return: success failure LV operations -------------- listLVs(VG): params: VG - Volume Group UUID description: trivial return: list of all LV UUIDs infoLV(VG, LV): params: VG - Volume Group UUID LV - Logical Volume UUID description: trivial return: returns LV information (at least size and path) createLV(VG, LvName, size): params: VG - Volume Group UUID LvName - name of the logical volume Size - size of logical volume description: creates a logical volume with name LvName and the requested size return: LV UUID extendLV(VG, LV, size): params: VG - Volume Group UUID LV - Logical Volume UUID description: extends LV with additional size return: success/failure removeLV(VG,LV): params: VG - Volume Group UUID LV - Logical Volume UUID description: return: snapshotLV(VG, LV, size): params: VG - Volume Group UUID LV - Logical Volume UUID size - Initial size of snapshot volume description: creeates a snapshot of LV return: UUID of snapshot

2 1

[libvirt] serial console runs out of buffer and console messages soft lock the CPU
by Bryan McLellan 26 Nov '08

26 Nov '08

I recently started configuring guests to use both a serial console and a graphics element. One of the nodes with this configuration kept locking up after running for some time. Trying to access the guest through virt-manager would leave virt-viewer hung at the connecting to screen. The guest would not respond to any network traffic including icmp. The user would destroy the domain and restart it to recover. Eventually the problem came to me and I found that immediately upon running 'virsh console domain' the guest would recover. The console contained: BUG: soft lockup - CPU#0 stuck for 94393s! [postgresql-8.3:4975] I discovered a bug in a puppet recipe caused postgres to reload regularly, printing a message to the console each time. Running puppet in a loop to continue producing these messages to the console caused another lockup that was recoverable by accessing the serial console in the same manner. I have since fixed that recipe, but I'm uncomfortable about the possibility of this happening again. Is there a way to configure libvirt to cache the serial console on the host so the buffer on the guest does not fill up when you aren't connected to the console, or should I disable the serial console? Bryan https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/301897

3 2

[libvirt] Packages in the path to getting a Windows binary of libvirt, built from Fedora
by Richard W.M. Jones 26 Nov '08

26 Nov '08

It seems like we should have the base MinGW (Windows cross-compiler) packages in Fedora 11 by the end of this week. This email is to document the additional packages we need to get approved, in order to get the cross-compiled libvirt and virt tools into (or buildable by) Fedora 11. If you want to help out, please start reviewing by following the Bugzilla links, and looking at the approved packaging guidelines at http://fedoraproject.org/wiki/Packaging/MinGW. ** For libvirt itself: mingw32-libgpg-error https://bugzilla.redhat.com/show_bug.cgi?id=467403 mingw32-libgcrypt https://bugzilla.redhat.com/show_bug.cgi?id=467410 mingw32-gnutls https://bugzilla.redhat.com/show_bug.cgi?id=467414 mingw32-gettext https://bugzilla.redhat.com/show_bug.cgi?id=467398 mingw32-libxml2 https://bugzilla.redhat.com/show_bug.cgi?id=467405 mingw32-portablexdr https://bugzilla.redhat.com/show_bug.cgi?id=467324 mingw32-readline https://bugzilla.redhat.com/show_bug.cgi?id=467399 mingw32-termcap https://bugzilla.redhat.com/show_bug.cgi?id=467329 OR a very brave person can try porting ncurses to Windows. mingw32-iconv https://bugzilla.redhat.com/show_bug.cgi?id=467325 mingw32-zlib https://bugzilla.redhat.com/show_bug.cgi?id=454416 mingw32-libvirt https://bugzilla.redhat.com/show_bug.cgi?id=467418 ** For the C based tools (gtk-vnc, virt-viewer, ovirt-viewer, vinagre): All of the above plus: mingw32-gtk2 https://bugzilla.redhat.com/show_bug.cgi?id=467420 mingw32-glib2 https://bugzilla.redhat.com/show_bug.cgi?id=467402 mingw32-cairo https://bugzilla.redhat.com/show_bug.cgi?id=467416 mingw32-jasper https://bugzilla.redhat.com/show_bug.cgi?id=467408 mingw32-libpng https://bugzilla.redhat.com/show_bug.cgi?id=467397 mingw32-libjpeg https://bugzilla.redhat.com/show_bug.cgi?id=467401 mingw32-libtiff (?) Optional dependency for GTK2, but not yet packaged. mingw32-pango https://bugzilla.redhat.com/show_bug.cgi?id=467419 mingw32-atk https://bugzilla.redhat.com/show_bug.cgi?id=467409 mingw32-pixman https://bugzilla.redhat.com/show_bug.cgi?id=467376 mingw32-freetype https://bugzilla.redhat.com/show_bug.cgi?id=467396 mingw32-fontconfig https://bugzilla.redhat.com/show_bug.cgi?id=467413 mingw32-libidn No Bugzilla Review Request yet, see the mercurial repository. http://hg.et.redhat.com/misc/fedora-mingw--devel mingw32-openssl https://bugzilla.redhat.com/show_bug.cgi?id=467395 mingw32-libssh2 No Bugzilla Review Request yet, see the mercurial repository. http://hg.et.redhat.com/misc/fedora-mingw--devel mingw32-gtk-vnc https://bugzilla.redhat.com/show_bug.cgi?id=467421 mingw32-curl No Bugzilla Review Request yet, see the mercurial repository. http://hg.et.redhat.com/misc/fedora-mingw--devel ** For the Python based tools (virt-install, virt-manager etc), we're hoping to go straight to Python 3 on the basis that it will be easier to contribute patches upstream, and it seems the build system for Python 3 will be a bit saner than for Python 2.x. You can help by making sure that all Python software is "Python 3 clean". If you have python 2.6, then just add the '-3' flag to the command line in order to warn about features which are deprecated and will be removed in Python 3. ** For the OCaml based tools (virt-df, virt-top): mingw32-ocaml mingw32-ocaml-calendar mingw32-ocaml-csv mingw32-ocaml-curses mingw32-ocaml-extlib mingw32-ocaml-findlib mingw32-ocaml-lablgl mingw32-ocaml-lablgtk mingw32-ocaml-libvirt mingw32-ocaml-xml-light (None of these are in Bugzilla yet, and for good reason because I may just do them as subpackages of the OCaml packages already in Fedora). ** I haven't had any particular requests for Ruby tools yet. OVirt itself is a standalone appliance and it doesn't need porting to Windows. ovirt-viewer is a C application and is being written concurrently on Linux and Windows anyway. I'm not sure if there are other standalone bits of ovirt which would make sense being ported to Windows. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v

1 0

[libvirt] Are there interfaces to change IP address of given domain before it runn
by Ian jonhson 26 Nov '08

26 Nov '08

Dear all, I has created a image file in local filesystem. And now, I wrote a program based on libvirt to run two instances of given image file. But I found they are using the same IP address which make them cut off the network. So, I wonder there are any solution to guarantee that both VM instances would be given different IP address after they are started. Thanks in advance, Ian

3 5

[libvirt] [PATCH] small fixes for the spec file
by Daniel Veillard 26 Nov '08

26 Nov '08

While sarting to build the RPMs for Fedora I noticed that there were a couple of cleanup patches missing about the handling of configuration files, and we forgot to add the dependancy on hal/hal-devel. We should also probably list hal and devkit support as modular options in the spec too. But this patch is just to harmonize with Fedora, 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/

3 2