May 2008 - Devel - libvirt List Archives

[libvirt] virsh create Guest Crashing
by Kenneth Nagin 21 May '08

21 May '08

An image that comes up successfully is crash when be created with virsh: This is libvirt create config file: <domain type='xen' > <name>ken-30</name> <os> <type>linux</type> <kernel>/data/images/boot/vmlinuz-2.6.21.7-3.fc8xen</kernel> <initrd>/data/images/boot/2.6.21.7-3.fc8xen-fedora.fc8.img</initrd> </os> <memory>131072</memory> <vcpu>1</vcpu> <devices> <disk type='file'> <source file='/data/images/nagin/c1/ken-30/fedora.fc8.img.sd'/> <target dev='sda1'/> </disk> <disk type='file'> <source file='/data/images/nagin/c1/ken-30/fedora.swap'/>. <target dev='sda2'/> </disk> <interface type='bridge'> <source bridge='virbr0'/> <script path='/etc/xen/scripts/vif-bridge'/> </interface> </devices> </domain> This the original xen configuration file: kernel = "/data/images/boot/vmlinuz-2.6.21.7-3.fc8xen" ramdisk = "/data/images/boot/2.6.21.7-3.fc8xen-fedora.fc8.img">. memory = 128 name = "ken-30" vif = [ 'bridge=virbr0' ] disk = ['tap:aio:/data/images/nagin/c1/ken-30/fedora.fc8.img,xvda1,w','tap:aio:/data/images/nagin/c1/ken-30/fedora.swap,xvda2,w'] root = "/dev/xvda1 ro" vfb = [ "type=vnc, vncdisplay=30" ] It crashes shortly after creation. This is the snapshot of the xen log: [2008-05-19 12:00:56 4937] DEBUG (XendDomainInfo:1040) XendDomainInfo.handleShutdownWatch [2008-05-19 12:00:56 4937] DEBUG (DevController:150) Waiting for devices vif. [2008-05-19 12:00:56 4937] DEBUG (DevController:155) Waiting for 0. [2008-05-19 12:00:56 4937] DEBUG (DevController:594) hotplugStatusCallback /local/domain/0/backend/vif/59/0/hotplug-status. [2008-05-19 12:00:56 4937] DEBUG (DevController:608) hotplugStatusCallback 1. [2008-05-19 12:00:56 4937] DEBUG (DevController:150) Waiting for devices usb. [2008-05-19 12:00:56 4937] DEBUG (DevController:150) Waiting for devices vbd. [2008-05-19 12:00:56 4937] DEBUG (DevController:150) Waiting for devices irq. [2008-05-19 12:00:56 4937] DEBUG (DevController:150) Waiting for devices vkbd. [2008-05-19 12:00:56 4937] DEBUG (DevController:150) Waiting for devices vfb.. [2008-05-19 12:00:56 4937] DEBUG (DevController:150) Waiting for devices console. [2008-05-19 12:00:56 4937] DEBUG (DevController:155) Waiting for 0. [2008-05-19 12:00:56 4937] DEBUG (DevController:150) Waiting for devices pci. [2008-05-19 12:00:56 4937] DEBUG (DevController:150) Waiting for devices ioports. [2008-05-19 12:00:56 4937] DEBUG (DevController:150) Waiting for devices tap. [2008-05-19 12:00:56 4937] DEBUG (DevController:155) Waiting for 51713. [2008-05-19 12:00:56 4937] DEBUG (DevController:594) hotplugStatusCallback /local/domain/0/backend/tap/59/51713/hotplug-status. [2008-05-19 12:00:56 4937] DEBUG (DevController:608) hotplugStatusCallback 1. [2008-05-19 12:00:56 4937] DEBUG (DevController:155) Waiting for 51714. [2008-05-19 12:00:56 4937] DEBUG (DevController:594) hotplugStatusCallback /local/domain/0/backend/tap/59/51714/hotplug-status. [2008-05-19 12:00:56 4937] DEBUG (DevController:608) hotplugStatusCallback 1. [2008-05-19 12:00:56 4937] DEBUG (DevController:150) Waiting for devices vtpm. [2008-05-19 12:00:56 4937] INFO (XendDomain:1130) Domain ken-30 (59) unpaused. [2008-05-19 12:01:00 4937] WARNING (XendDomainInfo:1203) Domain has crashed: name=ken-30 id=59. [2008-05-19 12:01:00 4937] DEBUG (XendDomainInfo:1821) XendDomainInfo.destroyDomain(59) I've changed the XML configuration many different ways but nothing seems to help. Any suggestions? --Kenneth Nagin

4 6

[libvirt] Domain XML format using defined storage volume
by Stefan de Konink 21 May '08

21 May '08

I have now a 'netapp'-pool, and lun-0..4. They all have a path. <disk type='block'> <source dev='?path?'> <target dev='xvda' bus='xen'/> </disk> Now I wonder, is it possible to have here somethinglike storage://netapp/lun-0? Or should I use the path that comes out of the vol-list? >From the standpoint: we make it easy for the user I would prefer not to provide a Linux specific path. Stefan

2 15

[libvirt] PATCH: Write pidfile earlier in startup
by Daniel P. Berrange 21 May '08

21 May '08

When used with the --daemon arg, libvirtd will write out a pid file to /var/run/libvirtd.pid and exit if this file already exists. Unfortuantely it does this quite late in its startup procedure - in particular *after* the call to qemudInitialize(), which in turns initializes the drivers, which in turn autostarts all the VMs and networks. So if you start a 2nd libvirtd instance it would do autostart before it got to checking for existing PID file. This is clearly very bad because the same VM would be started twice resulting in data corruption. Fortunately the Red Hat / Fedora initscript also checks the PID file before even starting the daemon, but this can affect people starting the daemon directly. So this patch makes the goDaemon() / pidfile creation the very first thing the daemon does after parsing command line arguments. This also results in greatly increased startup time for OS, since the initscript doesn't have to wait for it to auto-start all the VMs & networks before it daemonizes. It also initializes the signal handlers before calling qemudInitialize() since these really need to be setup before we start any VMs / child procs. Dan. Index: qemud/qemud.c =================================================================== RCS file: /data/cvs/libvirt/qemud/qemud.c,v retrieving revision 1.100 diff -u -p -r1.100 qemud.c --- qemud/qemud.c 15 May 2008 06:12:32 -0000 1.100 +++ qemud/qemud.c 16 May 2008 15:58:43 -0000 @@ -2143,6 +2143,24 @@ int main(int argc, char **argv) { } } + if (godaemon) { + openlog("libvirtd", 0, 0); + if (qemudGoDaemon() < 0) { + qemudLog(QEMUD_ERR, _("Failed to fork as daemon: %s"), + strerror(errno)); + goto error1; + } + + /* Choose the name of the PID file. */ + if (!pid_file) { + if (REMOTE_PID_FILE[0] != '\0') + pid_file = REMOTE_PID_FILE; + } + + if (pid_file && qemudWritePidFile (pid_file) < 0) + goto error1; + } + if (pipe(sigpipe) < 0 || qemudSetNonBlock(sigpipe[0]) < 0 || qemudSetNonBlock(sigpipe[1]) < 0 || @@ -2154,6 +2172,19 @@ int main(int argc, char **argv) { } sigwrite = sigpipe[1]; + sig_action.sa_sigaction = sig_handler; + sig_action.sa_flags = SA_SIGINFO; + sigemptyset(&sig_action.sa_mask); + + sigaction(SIGHUP, &sig_action, NULL); + sigaction(SIGINT, &sig_action, NULL); + sigaction(SIGQUIT, &sig_action, NULL); + sigaction(SIGTERM, &sig_action, NULL); + sigaction(SIGCHLD, &sig_action, NULL); + + sig_action.sa_handler = SIG_IGN; + sigaction(SIGPIPE, &sig_action, NULL); + if (!(server = qemudInitialize(sigpipe[0]))) { ret = 2; goto error1; @@ -2175,37 +2206,6 @@ int main(int argc, char **argv) { sockdirname); } - if (godaemon) { - openlog("libvirtd", 0, 0); - if (qemudGoDaemon() < 0) { - qemudLog(QEMUD_ERR, _("Failed to fork as daemon: %s"), - strerror(errno)); - goto error1; - } - - /* Choose the name of the PID file. */ - if (!pid_file) { - if (REMOTE_PID_FILE[0] != '\0') - pid_file = REMOTE_PID_FILE; - } - - if (pid_file && qemudWritePidFile (pid_file) < 0) - goto error1; - } - - sig_action.sa_sigaction = sig_handler; - sig_action.sa_flags = SA_SIGINFO; - sigemptyset(&sig_action.sa_mask); - - sigaction(SIGHUP, &sig_action, NULL); - sigaction(SIGINT, &sig_action, NULL); - sigaction(SIGQUIT, &sig_action, NULL); - sigaction(SIGTERM, &sig_action, NULL); - sigaction(SIGCHLD, &sig_action, NULL); - - sig_action.sa_handler = SIG_IGN; - sigaction(SIGPIPE, &sig_action, NULL); - if (virEventAddHandleImpl(sigpipe[0], POLLIN, qemudDispatchSignalEvent, -- |: Red Hat, Engineering, Boston -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 4

[libvirt] PATCH: Don't rely on host binaries in QEMU tests
by Daniel P. Berrange 21 May '08

21 May '08

The QEMU test suites rely on the QEMU/KVM/Xenner binaries being present in /usr/bin. This has obvious problems and is unneccessary. The solution is to not use the qemudCapsInit() function which initializes capabilities based on binaries present. Instead I add a custom impl just for the test cases which adds a pre-defined stable set of capabilities. I also had to move a stat() check out of qemudBuildCommandLine() and into its caller. It probably should have been there in the first place anyway src/qemu_conf.c | 13 -------- src/qemu_driver.c | 14 +++++++++ tests/Makefile.am | 4 +- tests/qemuxml2argvtest.c | 4 +- tests/qemuxml2xmltest.c | 3 + tests/testutilsqemu.c | 71 +++++++++++++++++++++++++++++++++++++++++++++++ tests/testutilsqemu.h | 5 +++ 7 files changed, 97 insertions(+), 17 deletions(-) Dan. Index: src/qemu_conf.c =================================================================== RCS file: /data/cvs/libvirt/src/qemu_conf.c,v retrieving revision 1.66 diff -u -p -u -p -r1.66 qemu_conf.c --- src/qemu_conf.c 16 May 2008 09:37:44 -0000 1.66 +++ src/qemu_conf.c 16 May 2008 15:15:05 -0000 @@ -2326,7 +2326,6 @@ int qemudBuildCommandLine(virConnectPtr char memory[50]; char vcpus[50]; char boot[QEMUD_MAX_BOOT_DEVS+1]; - struct stat sb; struct qemud_vm_disk_def *disk = vm->def->disks; struct qemud_vm_net_def *net = vm->def->nets; struct qemud_vm_input_def *input = vm->def->inputs; @@ -2336,18 +2335,6 @@ int qemudBuildCommandLine(virConnectPtr struct utsname ut; int disableKQEMU = 0; - /* Make sure the binary we are about to try exec'ing exists. - * Technically we could catch the exec() failure, but that's - * in a sub-process so its hard to feed back a useful error - */ - if (stat(vm->def->os.binary, &sb) < 0) { - qemudReportError(conn, NULL, NULL, VIR_ERR_INTERNAL_ERROR, - _("Cannot find QEMU binary %s: %s"), - vm->def->os.binary, - strerror(errno)); - return -1; - } - if (vm->qemuVersion == 0) { if (qemudExtractVersionInfo(vm->def->os.binary, &(vm->qemuVersion), Index: src/qemu_driver.c =================================================================== RCS file: /data/cvs/libvirt/src/qemu_driver.c,v retrieving revision 1.75 diff -u -p -u -p -r1.75 qemu_driver.c --- src/qemu_driver.c 16 May 2008 09:37:44 -0000 1.75 +++ src/qemu_driver.c 16 May 2008 15:15:05 -0000 @@ -646,6 +646,7 @@ static int qemudStartVMDaemon(virConnect char **argv = NULL, **tmp; int i, ret; char logfile[PATH_MAX]; + struct stat sb; if (qemudIsActiveVM(vm)) { qemudReportError(conn, NULL, NULL, VIR_ERR_INTERNAL_ERROR, @@ -702,6 +703,19 @@ static int qemudStartVMDaemon(virConnect return -1; } + /* Make sure the binary we are about to try exec'ing exists. + * Technically we could catch the exec() failure, but that's + * in a sub-process so its hard to feed back a useful error + */ + if (stat(vm->def->os.binary, &sb) < 0) { + qemudReportError(conn, NULL, NULL, VIR_ERR_INTERNAL_ERROR, + _("Cannot find QEMU binary %s: %s"), + vm->def->os.binary, + strerror(errno)); + return -1; + } + + if (qemudBuildCommandLine(conn, driver, vm, &argv) < 0) { close(vm->logfile); vm->logfile = -1; Index: tests/Makefile.am =================================================================== RCS file: /data/cvs/libvirt/tests/Makefile.am,v retrieving revision 1.42 diff -u -p -u -p -r1.42 Makefile.am --- tests/Makefile.am 28 Apr 2008 13:36:48 -0000 1.42 +++ tests/Makefile.am 16 May 2008 15:15:05 -0000 @@ -100,12 +100,12 @@ xmconfigtest_SOURCES = \ xmconfigtest_LDADD = $(LDADDS) qemuxml2argvtest_SOURCES = \ - qemuxml2argvtest.c \ + qemuxml2argvtest.c testutilsqemu.c testutilsqemu.h \ testutils.c testutils.h qemuxml2argvtest_LDADD = $(LDADDS) qemuxml2xmltest_SOURCES = \ - qemuxml2xmltest.c \ + qemuxml2xmltest.c testutilsqemu.c testutilsqemu.h \ testutils.c testutils.h qemuxml2xmltest_LDADD = $(LDADDS) Index: tests/qemuxml2argvtest.c =================================================================== RCS file: /data/cvs/libvirt/tests/qemuxml2argvtest.c,v retrieving revision 1.22 diff -u -p -u -p -r1.22 qemuxml2argvtest.c --- tests/qemuxml2argvtest.c 15 May 2008 16:21:11 -0000 1.22 +++ tests/qemuxml2argvtest.c 16 May 2008 15:15:05 -0000 @@ -14,6 +14,8 @@ #include "testutils.h" #include "qemu_conf.h" +#include "testutilsqemu.h" + static char *progname; static char *abs_srcdir; static struct qemud_driver driver; @@ -130,7 +132,7 @@ main(int argc, char **argv) if (!abs_srcdir) abs_srcdir = getcwd(cwd, sizeof(cwd)); - driver.caps = qemudCapsInit(); + driver.caps = testQemuCapsInit(); #define DO_TEST(name, extraFlags) \ do { \ Index: tests/qemuxml2xmltest.c =================================================================== RCS file: /data/cvs/libvirt/tests/qemuxml2xmltest.c,v retrieving revision 1.17 diff -u -p -u -p -r1.17 qemuxml2xmltest.c --- tests/qemuxml2xmltest.c 15 May 2008 16:21:11 -0000 1.17 +++ tests/qemuxml2xmltest.c 16 May 2008 15:15:05 -0000 @@ -13,6 +13,7 @@ #include "internal.h" #include "testutils.h" #include "qemu_conf.h" +#include "testutilsqemu.h" static char *progname; static char *abs_srcdir; @@ -86,7 +87,7 @@ main(int argc, char **argv) if (!abs_srcdir) abs_srcdir = getcwd(cwd, sizeof(cwd)); - driver.caps = qemudCapsInit(); + driver.caps = testQemuCapsInit(); #define DO_TEST(name) \ if (virtTestRun("QEMU XML-2-XML " name, \ Index: tests/testutilsqemu.c =================================================================== RCS file: tests/testutilsqemu.c diff -N tests/testutilsqemu.c --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ tests/testutilsqemu.c 16 May 2008 15:15:05 -0000 @@ -0,0 +1,71 @@ + +#include <sys/utsname.h> +#include <stdlib.h> + +#include "testutilsqemu.h" + +virCapsPtr testQemuCapsInit(void) { + struct utsname utsname; + virCapsPtr caps; + virCapsGuestPtr guest; + static const char *const x86_machines[] = { + "pc", "isapc" + }; + static const char *const xen_machines[] = { + "xenner" + }; + + uname (&utsname); + if ((caps = virCapabilitiesNew(utsname.machine, + 0, 0)) == NULL) + return NULL; + + if ((guest = virCapabilitiesAddGuest(caps, "hvm", "i686", 32, + "/usr/bin/qemu", NULL, + 2, x86_machines)) == NULL) + goto cleanup; + if (virCapabilitiesAddGuestDomain(guest, + "qemu", + NULL, + NULL, + 0, + NULL) == NULL) + goto cleanup; + + if ((guest = virCapabilitiesAddGuest(caps, "hvm", "x86_64", 64, + "/usr/bin/qemu-system-x86_64", NULL, + 2, x86_machines)) == NULL) + goto cleanup; + if (virCapabilitiesAddGuestDomain(guest, + "qemu", + NULL, + NULL, + 0, + NULL) == NULL) + goto cleanup; + if (virCapabilitiesAddGuestDomain(guest, + "kvm", + "/usr/bin/kvm", + NULL, + 0, + NULL) == NULL) + goto cleanup; + + if ((guest = virCapabilitiesAddGuest(caps, "xen", "x86_64", 64, + "/usr/bin/xenner", NULL, + 1, xen_machines)) == NULL) + goto cleanup; + if (virCapabilitiesAddGuestDomain(guest, + "kvm", + "/usr/bin/kvm", + NULL, + 0, + NULL) == NULL) + goto cleanup; + + return caps; + +cleanup: + virCapabilitiesFree(caps); + return NULL; +} Index: tests/testutilsqemu.h =================================================================== RCS file: tests/testutilsqemu.h diff -N tests/testutilsqemu.h --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ tests/testutilsqemu.h 16 May 2008 15:15:05 -0000 @@ -0,0 +1,5 @@ + +#include "capabilities.h" + +virCapsPtr testQemuCapsInit(void); + -- |: Red Hat, Engineering, Boston -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 2

[libvirt] listen_tls not enabling libvirtd to listen for tls
by Kenneth Nagin 21 May '08

21 May '08

libvirtd is not listening for TLS connection by default. Setting 'listen_tls = 1' in /etc/libvirt/libvirtd.conf does not help either. However, starting 'libvirtd --listen' does work. I'm running Fedora 8. I prefer to use the configuration file since it is automatically started when the system reboots. Does anyone know how to configure libvirtd to listen for tls? Kenneth Nagin

4 6

[libvirt] autostarting xend domains
by Wolfgang Rosenauer 20 May '08

20 May '08

Hi, I found that support for setting autostart parameters for xend managed guests has been added to libvirt (https://www.redhat.com/archives/libvir-list/2008-May/msg00060.html) So I tried that but failed with virsh's autostart command (and also virt-manager) like this: virsh # autostart saruman libvir: Xen Daemon error : POST operation failed: (xend.err "Error creating domain: VM name 'saruman' already exists as domain 32") libvir: Xen Daemon error : failed Xen syscall Failed to redefine sexpr 6508560 error: Failed to mark domain saruman as autostarted So yes, the domain is indeed running but I understood it should be changeable during a domain's lifetime. Any ideas? That is a libvirt CVS snapshot from yesterday and a Xen 3.1 installation. Thanks, Wolfgang

3 5

[libvirt] libvirt & VServer?
by Richard W.M. Jones 20 May '08

20 May '08

Does anyone know what the current status of Linux VServer support is? Last message I can find is a patch for it, which didn't make it into libvirt: http://www.redhat.com/archives/libvir-list/2007-October/msg00273.html 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

3 4

[libvirt] VMware ESX
by drew einhorn 20 May '08

20 May '08

Hi, I have some code that can probably be hacked into a libvirt driver for VMware ESX. Is there a template with stubs for all the necessary routines for the API that I can use as a starting point? -- Drew Einhorn

4 5

[libvirt] [RFC] Comfortable lookup functions interface/block stats
by Stefan de Konink 20 May '08

20 May '08

Hi, Wouldn't it be much nicer for Joe Programmer if the API facilitated the functions: char ** virDomainInterfacePaths(virDomainPtr dom); char ** virDomainBlockPaths(virDomainPtr dom); I really don't get why XML parsing should be done for something that is almost too trivial to export. Any reasons why not to do implement this? Stefan

4 5

[Libvir] KVM migration
by Richard W.M. Jones 20 May '08

20 May '08

It turns out that the general migration strategy I defined[1] in reference to Xen, ie. the 3 steps of Prepare/Perform/Finish, isn't sufficient to support KVM migration. The problem is that the destination needs to start qemu-kvm with pretty much the exact same configuration / command line parameters as were used at the source[2]. eg. If the source qemu-kvm has 512 MB of RAM, then the destination had better have exactly 512 MB of RAM also. (This is not the same as Xen where the migration protocol itself carries this information between the two xend daemons). We can modify the Prepare step to pass this information -- I'm suggesting that we just pass the domain XML of the source domain. Thus the Prepare step would change from: static int qemudDomainMigratePrepare (virConnectPtr dconn, char **cookie, int *cookielen, const char *uri_in, char **uri_out, unsigned long flags, const char *dname, unsigned long resource) to: static int qemudDomainMigratePreparev2 (virConnectPtr dconn, char **cookie, int *cookielen, const char *uri_in, char **uri_out, + const char *dom_xml, unsigned long flags, const char *dname, unsigned long resource) As hinted there, we also need a new version of the migration protocol, and a new remote call (Preparev2). So questions: (a) Does anyone have any objections? (b) Does anyone see a simpler way to do this? (c) Since we're adding a second version of the protocol, does anyone want anything else added? (d) Will the domain XML alone be sufficient to recreate the exact qemu command line? (Seems to be the case, and in fact KVM suspend/ restore support seems to implicitly rely on this too). Rich. Notes: [1] https://www.redhat.com/archives/libvir-list/2007-July/msg00357.html and https://www.redhat.com/archives/libvir-list/2007-July/msg00304.html [2] http://kvm.qumranet.com/kvmwiki/Migration#head-71900dbcf45d8ac81649fe4f031c… -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top

3 6