August 2008 - Devel - libvirt List Archives

Re: [libvirt] Error compiling libvirt 0.4.4
by Richard W.M. Jones 28 Aug '08

28 Aug '08

On Thu, Aug 28, 2008 at 11:25:44AM -0300, Everton P. Alexandre wrote: > I managed to do the installation!!! But now, when I > try to use the virsh or to execute a program, the > following message appear: > > libvir: Remote error : No such file or directory > libvir: warning : Failed to find the network: Is the > daemon running? So as the message says, you need to run the daemon (libvirtd). Well, truthfully you don't _need_ to run it, unless you want certain features like remote access, managed networks or QEMU support. If you've got libvirtd running but you still get that message, then it'll probably be either a security or a paths problem. http://libvirt.org/remote.html Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones Read my OCaml programming blog: http://camltastic.blogspot.com/ Fedora now supports 64 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora

1 0

[libvirt] [PATCH] enable parallel builds
by James Morris 28 Aug '08

28 Aug '08

I'm not sure if this is the best way to do this, but it seems to work. ---- Enable parallel compilation of the repository when running the autobuild script and/or via rpmbuild. --- autobuild.sh | 15 ++++++++++++++- libvirt.spec.in | 2 +- 2 files changed, 15 insertions(+), 2 deletions(-) diff --git a/autobuild.sh b/autobuild.sh index 7ae5d1e..1a5413b 100755 --- a/autobuild.sh +++ b/autobuild.sh @@ -21,7 +21,20 @@ rm -rf coverage --with-lxc \ --with-xen-proxy -make +# from the gdc spec file +# if RPM_BUILD_NCPUS unset, set it +if [ -z "$RPM_BUILD_NCPUS" ] ; then + if [ -x /usr/bin/getconf ] ; then + RPM_BUILD_NCPUS=$(/usr/bin/getconf _NPROCESSORS_ONLN) + if [ $RPM_BUILD_NCPUS -eq 0 ]; then + RPM_BUILD_NCPUS=1 + fi + else + RPM_BUILD_NCPUS=1 + fi +fi + +make -j$RPM_BUILD_NCPUS make install set -o pipefail diff --git a/libvirt.spec.in b/libvirt.spec.in index d37c0e0..cd8e937 100644 --- a/libvirt.spec.in +++ b/libvirt.spec.in @@ -169,7 +169,7 @@ of recent versions of Linux (and other OSes). --with-init-script=redhat \ --with-qemud-pid-file=%{_localstatedir}/run/libvirt_qemud.pid \ --with-remote-file=%{_localstatedir}/run/libvirtd.pid -make +make %{?_smp_mflags} %install rm -fr %{buildroot}

3 4

[libvirt] Exposing some unique features?
by Nguyen Anh Quynh 28 Aug '08

28 Aug '08

Hi, Though libvirt tries very hard to hide the difference between hypervisors behind an abstraction layer, there are still differences that we might want to expose to the users. For example, QEMU has the monitor interface, which provides some unique functions. Users might want to have access to the monitor interface and send command to it (like "gdbserver" command?). So how can we expose such information? We can have a new driver function, which return an opaque structure. The content of the structure is of course depends on the hypervisor type. One problem is that this might be dangerous if users relies on the QEMU monitor to execute some functions that should be done under control. Idea? Thanks, Quynh

3 5

[libvirt] Writing a new driver for libvirt
by Orr, David-P64407 27 Aug '08

27 Aug '08

Hey all, I am new to libvirt and have been asked to look at the possibility of writing a libvirt driver for a hypervisor we are using. I am wondering if someone can give me the basics on what is involved in accomplishing this task, what are the basics of writing a new driver? I have looked at the documentation posted and been poking around the code and just wanted to ask someone to point me in the right direction. Thanks in advance. David Orr General Dynamics Software Engineer David.Orr(a)gdc4s.com

2 3

[libvirt] [PATCH] storage pool discovery
by David Lively 27 Aug '08

27 Aug '08

Hi Folks - Here's my second pass at storage pool discovery. I've taken Daniel's suggestion and made it return a single XML doc containing <source> elements rather than an array of <pool> docs (and also incorporated suggestions from Daniel V and Jim M). Note that the storage <source> <name> patch is closely related (without it, the <source> docs returned for logical pools aren't correct). Dave

3 15

Re: [libvirt] Error compiling libvirt 0.4.4
by Richard W.M. Jones 27 Aug '08

27 Aug '08

On Wed, Aug 27, 2008 at 10:42:38AM -0300, Everton P. Alexandre wrote: > > "Richard W.M. Jones" <rjones(a)redhat.com> escreveu: On Thu, Aug 21, 2008 at 06:57:40PM -0300, Everton P. Alexandre wrote: > > > In file included from /usr/include/xen/dom0_ops.h:31, > > > from xen_unified.c:29: > > > /usr/include/xen/xen.h:578: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'char' > > > > Did you find out what was causing this? > > No, I don't. Did this problem happen with you? No. Does it still happen for you? Have you tried the latest version from CVS? Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones Read my OCaml programming blog: http://camltastic.blogspot.com/ Fedora now supports 64 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora

1 0

[libvirt] PATCH: Handle case of no domains in openvz driver
by Daniel P. Berrange 27 Aug '08

27 Aug '08

If running the openvz driver on a machine with no containers currently defined, it throws an error # ./src/virsh --connect openvz:///system list libvir: OpenVZ error : internal error Failed to parse vzlist output Id Name State ---------------------------------- This is because of a failure to check for the EOF condition. This patch adds the missing check Daniel diff -r 1fc0d8258838 src/openvz_conf.c --- a/src/openvz_conf.c Tue Aug 19 13:58:56 2008 +0100 +++ b/src/openvz_conf.c Tue Aug 19 13:59:51 2008 +0100 @@ -534,6 +534,9 @@ openvzGetVPSInfo(virConnectPtr conn) { vm = *pnext; if (fscanf(fp, "%d %s\n", &veid, status) != 2) { + if (feof(fp)) + break; + openvzError(conn, VIR_ERR_INTERNAL_ERROR, _("Failed to parse vzlist output")); goto error; -- |: 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: REmove bogus call to virStateInit in openvz driver
by Daniel P. Berrange 27 Aug '08

27 Aug '08

For some unknown reason there is a call to virStateInitialize() in the openvz driver's open method. This is absolutely forbidden - this API is only intended for use by the daemon. This patch removes this bogus call and makes it call the openvz setup APIs directly. Daniel diff -r c2e95cd51bc3 src/openvz_driver.c --- a/src/openvz_driver.c Wed Aug 13 12:50:55 2008 +0000 +++ b/src/openvz_driver.c Tue Aug 19 12:11:37 2008 +0100 @@ -81,10 +81,6 @@ static int openvzNumDomains(virConnectPt static int openvzNumDomains(virConnectPtr conn); static int openvzListDefinedDomains(virConnectPtr conn, char **const names, int nnames); static int openvzNumDefinedDomains(virConnectPtr conn); -static int openvzStartup(void); -static int openvzShutdown(void); -static int openvzReload(void); -static int openvzActive(void); static virDomainPtr openvzDomainDefineXML(virConnectPtr conn, const char *xml); static virDomainPtr openvzDomainCreateLinux(virConnectPtr conn, const char *xml, @@ -697,7 +693,8 @@ static virDrvOpenStatus openvzOpen(virCo conn->privateData = &ovz_driver; - virStateInitialize(); + openvzAssignUUIDs(); + vms = openvzGetVPSInfo(conn); ovz_driver.vms = vms; @@ -849,27 +846,6 @@ Version: 2.2 static int openvzNumDefinedDomains(virConnectPtr conn ATTRIBUTE_UNUSED) { return ovz_driver.num_inactive; -} - -static int openvzStartup(void) { - openvzAssignUUIDs(); - - return 0; -} - -static int openvzShutdown(void) { - - return 0; -} - -static int openvzReload(void) { - - return 0; -} - -static int openvzActive(void) { - - return 1; } static virDriver openvzDriver = { @@ -934,17 +910,8 @@ static virDriver openvzDriver = { NULL, /* nodeGetFreeMemory */ }; -static virStateDriver openvzStateDriver = { - openvzStartup, - openvzShutdown, - openvzReload, - openvzActive, - NULL, /* sigHandler */ -}; - int openvzRegister(void) { virRegisterDriver(&openvzDriver); - virRegisterStateDriver(&openvzStateDriver); return 0; } -- |: 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: Allow specific FDs to be kept open in virExec()
by Daniel P. Berrange 27 Aug '08

27 Aug '08

With my recent patches to virExec(), all FDs except stdin/out/err are closed before the child is exec'd to prevent accidental leaks. Of course I forgot the one key place where we need to propagate FDs... The TAP devices passed to QEMU. This patch adds a 'keepfd' parameter to virExec() which allows the caller to specify a bitset of file descriptors to keep open, and updates the callers to use this as required. The QEMU driver specifies any TAP fds and the LXC driver specifies its PTY this way removing a previous hack. QEMU networking works again with fix.... lxc_driver.c | 17 ++++++++++++++--- openvz_driver.c | 6 ++++-- qemu_driver.c | 26 +++++++++++++++++++------- storage_backend.c | 6 ++++-- util.c | 8 ++++++-- util.h | 7 +++++++ 6 files changed, 54 insertions(+), 16 deletions(-) Daniel Index: src/lxc_driver.c =================================================================== RCS file: /data/cvs/libvirt/src/lxc_driver.c,v retrieving revision 1.23 diff -u -p -r1.23 lxc_driver.c --- src/lxc_driver.c 20 Aug 2008 20:55:32 -0000 1.23 +++ src/lxc_driver.c 21 Aug 2008 13:52:25 -0000 @@ -615,6 +615,8 @@ static int lxcControllerStart(virConnect const char **largv = NULL; pid_t child; int status; + char *keepfd = NULL; + char appPtyStr[30]; #define ADD_ARG_SPACE \ do { \ @@ -638,11 +640,13 @@ static int lxcControllerStart(virConnect goto no_memory; \ } while (0) + snprintf(appPtyStr, sizeof(appPtyStr), "%d", appPty); + ADD_ARG_LIT(vm->def->emulator); ADD_ARG_LIT("--name"); ADD_ARG_LIT(vm->def->name); ADD_ARG_LIT("--console"); - ADD_ARG_LIT("0"); /* Passing console master PTY as FD 0 */ + ADD_ARG_LIT(appPtyStr); ADD_ARG_LIT("--background"); for (i = 0 ; i < nveths ; i++) { @@ -652,10 +656,15 @@ static int lxcControllerStart(virConnect ADD_ARG(NULL); - vm->stdin_fd = appPty; /* Passing console master PTY as FD 0 */ + vm->stdin_fd = -1; vm->stdout_fd = vm->stderr_fd = logfd; - if (virExec(conn, largv, NULL, &child, + if (VIR_ALLOC_N(keepfd, VIR_EXEC_FDSET_SIZE()) < 0) + goto no_memory; + + VIR_EXEC_FDSET_ON(keepfd, appPty); + + if (virExec(conn, largv, NULL, keepfd, &child, vm->stdin_fd, &vm->stdout_fd, &vm->stderr_fd, VIR_EXEC_NONE) < 0) goto cleanup; @@ -686,6 +695,8 @@ static int lxcControllerStart(virConnect ret = 0; cleanup: + VIR_FREE(keepfd); + for (i = 0 ; i < largc ; i++) VIR_FREE(largv[i]); Index: src/openvz_driver.c =================================================================== RCS file: /data/cvs/libvirt/src/openvz_driver.c,v retrieving revision 1.43 diff -u -p -r1.43 openvz_driver.c --- src/openvz_driver.c 20 Aug 2008 20:48:36 -0000 1.43 +++ src/openvz_driver.c 21 Aug 2008 13:52:25 -0000 @@ -807,7 +807,8 @@ static int openvzListDomains(virConnectP char *endptr; const char *cmd[] = {VZLIST, "-ovpsid", "-H" , NULL}; - ret = virExec(conn, cmd, NULL, &pid, -1, &outfd, &errfd, VIR_EXEC_NONE); + ret = virExec(conn, cmd, NULL, NULL, + &pid, -1, &outfd, &errfd, VIR_EXEC_NONE); if(ret == -1) { openvzError(conn, VIR_ERR_INTERNAL_ERROR, _("Could not exec %s"), VZLIST); @@ -844,7 +845,8 @@ static int openvzListDefinedDomains(virC const char *cmd[] = {VZLIST, "-ovpsid", "-H", "-S", NULL}; /* the -S options lists only stopped domains */ - ret = virExec(conn, cmd, NULL, &pid, -1, &outfd, &errfd, VIR_EXEC_NONE); + ret = virExec(conn, cmd, NULL, NULL, + &pid, -1, &outfd, &errfd, VIR_EXEC_NONE); if(ret == -1) { openvzError(conn, VIR_ERR_INTERNAL_ERROR, _("Could not exec %s"), VZLIST); Index: src/qemu_driver.c =================================================================== RCS file: /data/cvs/libvirt/src/qemu_driver.c,v retrieving revision 1.111 diff -u -p -r1.111 qemu_driver.c --- src/qemu_driver.c 20 Aug 2008 20:48:36 -0000 1.111 +++ src/qemu_driver.c 21 Aug 2008 13:52:26 -0000 @@ -847,6 +847,7 @@ static int qemudStartVMDaemon(virConnect int *tapfds = NULL; int ntapfds = 0; int qemuCmdFlags; + char *keepfd = NULL; if (virDomainIsActive(vm)) { qemudReportError(conn, NULL, NULL, VIR_ERR_INTERNAL_ERROR, @@ -950,12 +951,22 @@ static int qemudStartVMDaemon(virConnect vm->stdout_fd = -1; vm->stderr_fd = -1; - ret = virExec(conn, argv, NULL, &vm->pid, - vm->stdin_fd, &vm->stdout_fd, &vm->stderr_fd, - VIR_EXEC_NONBLOCK); - if (ret == 0) { - vm->def->id = driver->nextvmid++; - vm->state = migrateFrom ? VIR_DOMAIN_PAUSED : VIR_DOMAIN_RUNNING; + if (VIR_ALLOC_N(keepfd, VIR_EXEC_FDSET_SIZE()) < 0) { + ret = -1; + qemudReportError(conn, NULL, NULL, VIR_ERR_NO_MEMORY, NULL); + } else { + for (i = 0 ; i < ntapfds ; i++) + VIR_EXEC_FDSET_ON(keepfd, tapfds[i]); + + ret = virExec(conn, argv, NULL, keepfd, &vm->pid, + vm->stdin_fd, &vm->stdout_fd, &vm->stderr_fd, + VIR_EXEC_NONBLOCK); + if (ret == 0) { + vm->def->id = driver->nextvmid++; + vm->state = migrateFrom ? VIR_DOMAIN_PAUSED : VIR_DOMAIN_RUNNING; + } + + VIR_FREE(keepfd); } for (i = 0 ; argv[i] ; i++) @@ -1219,7 +1230,8 @@ dhcpStartDhcpDaemon(virConnectPtr conn, if (qemudBuildDnsmasqArgv(conn, network, &argv) < 0) return -1; - ret = virExec(conn, argv, NULL, &network->dnsmasqPid, -1, NULL, NULL, VIR_EXEC_NONBLOCK); + ret = virExec(conn, argv, NULL, NULL, + &network->dnsmasqPid, -1, NULL, NULL, VIR_EXEC_NONBLOCK); for (i = 0; argv[i]; i++) VIR_FREE(argv[i]); Index: src/storage_backend.c =================================================================== RCS file: /data/cvs/libvirt/src/storage_backend.c,v retrieving revision 1.19 diff -u -p -r1.19 storage_backend.c --- src/storage_backend.c 20 Aug 2008 09:24:14 -0000 1.19 +++ src/storage_backend.c 21 Aug 2008 13:52:26 -0000 @@ -403,7 +403,8 @@ virStorageBackendRunProgRegex(virConnect /* Run the program and capture its output */ - if (virExec(conn, prog, NULL, &child, -1, &fd, NULL, VIR_EXEC_NONE) < 0) { + if (virExec(conn, prog, NULL, NULL, + &child, -1, &fd, NULL, VIR_EXEC_NONE) < 0) { goto cleanup; } @@ -537,7 +538,8 @@ virStorageBackendRunProgNul(virConnectPt v[i] = NULL; /* Run the program and capture its output */ - if (virExec(conn, prog, NULL, &child, -1, &fd, NULL, VIR_EXEC_NONE) < 0) { + if (virExec(conn, prog, NULL, NULL, + &child, -1, &fd, NULL, VIR_EXEC_NONE) < 0) { goto cleanup; } Index: src/util.c =================================================================== RCS file: /data/cvs/libvirt/src/util.c,v retrieving revision 1.53 diff -u -p -r1.53 util.c --- src/util.c 20 Aug 2008 19:42:36 -0000 1.53 +++ src/util.c 21 Aug 2008 13:52:26 -0000 @@ -132,6 +132,7 @@ int virExec(virConnectPtr conn, const char *const*argv, const char *const*envp, + const char *keepfd, int *retpid, int infd, int *outfd, int *errfd, int flags) { @@ -293,7 +294,9 @@ virExec(virConnectPtr conn, if (i != infd && i != null && i != childout && - i != childerr) + i != childerr && + (!keepfd || + !VIR_EXEC_FDSET_ISON(keepfd, i))) close(i); if (flags & VIR_EXEC_DAEMON) { @@ -403,7 +406,8 @@ virRun(virConnectPtr conn, int *status) { int childpid, exitstatus, ret; - if ((ret = virExec(conn, argv, NULL, &childpid, -1, NULL, NULL, VIR_EXEC_NONE)) < 0) + if ((ret = virExec(conn, argv, NULL, NULL, + &childpid, -1, NULL, NULL, VIR_EXEC_NONE)) < 0) return ret; while ((ret = waitpid(childpid, &exitstatus, 0) == -1) && errno == EINTR); Index: src/util.h =================================================================== RCS file: /data/cvs/libvirt/src/util.h,v retrieving revision 1.25 diff -u -p -r1.25 util.h --- src/util.h 20 Aug 2008 19:42:36 -0000 1.25 +++ src/util.h 21 Aug 2008 13:52:26 -0000 @@ -33,9 +33,16 @@ enum { VIR_EXEC_DAEMON = (1 << 1), }; +#define VIR_EXEC_FDSET_SIZE() (sysconf(_SC_OPEN_MAX)/8) +#define VIR_EXEC_FDSET_CLEAR(set) memset((set), 0, VIR_EXEC_FDSET_SIZE()) +#define VIR_EXEC_FDSET_ON(set, fd) (set[(fd)/8] |= (1 << ((fd)%8))) +#define VIR_EXEC_FDSET_OFF(set, fd) (set[(fd)/8] &= ~(1 << ((fd)%8))) +#define VIR_EXEC_FDSET_ISON(set, fd) (set[(fd)/8] & (1 << ((fd)%8))) + int virExec(virConnectPtr conn, const char *const*argv, const char *const*envp, + const char *keepfd, int *retpid, int infd, int *outfd, -- |: 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 :|

3 8

[libvirt] Proposed functionality: API to extract host description from saved state, restore with modified XML
by Charles Duffy 27 Aug '08

27 Aug '08

Per subject. Obviously only for use by folks who *really* know what they're doing. :) I'm looking for the ability to restore a snapshot saved with domain.save(), with disk images pointing at a different location (in my particular use case, pointing at a an empty copy-and-write image backending into a snapshot of the old disk state). Further, as I may run multiple copies of the same host at once (from the same initial state, against different copy-on-write disk images backending into the same read-only store, into different disconnected networks), the UUID as well as the name may need to be changed. I could just rewrite the header of the saved-state file, but this has a few disadvantages: - To mimic the copy-on-write behavior of the disk images, I would need to copy the entire saved-domain file. I'm trying to minimize the time and disk penalty of snapshot/restore, so this is suboptimal. - My code is dependent on the file format used by the particular backend, and may break when that backend is revved. Would a patch adding API calls to - return the XML description of a saved host, given the name - restore a saved host with a different description be considered welcome? I presume that to maintain backwards compatibility, the latter would be expected to be exposed to clients via a new call, rather than adding a parameter to virDomainRestore(); in communicating with the drivers, on the other hand, my first instinct would be to add an extra parameter to virDrvDomainRestore. Thanks!

3 2