- Devel - libvirt List Archives

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

20 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 20 May '08

20 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 20 May '08

20 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

[libvirt] Serial console on a qemu image through virt-manager
by ClaesBas 19 May '08

19 May '08

I give up! How should the xml-file look? In http://libvirt.org/formatdomain.html#elementsConsole it says something like: </devices> <console type='pty'> <source path='/dev/pts/4'/> <target port='0'/> </console> </devices> But in Xen example (http://libvirt.org/drvxen.html) it looks like: <devices> <console tty='/dev/pts/5'/> </devices> I have latest versions from source on both libvirt (Mercurial) and virt-manager (CVS). Before I updated virt-manager (from Ubuntus Hardy-version) I had a choice for serial console which opened a console window which was all "Black" inside. After upgrade of virt-manager I got no contact with any serial console at all. My guest is a qemu image of OpenBSD with console configured to first serial port. I could see that the image is ok, if I reconfig the xml-file to use vnc instead. Then I see that OpenBSD is trying to use serial port as console. Output from /var/log/libvirt/qemu/obsd64.log: /usr/bin/kvm -M pc -m 512 -smp 1 -name obsd64 -nographic -monitor pty -no-acpi -boot c -drive file=/home/cs/kvm/OpenBSD/obsd64.hda,if=ide,index=0,boot=on -net nic,macaddr=00:16:3e:17:9d:f7,vlan=0 -net user,vlan=0 -serial pty -parallel none -usb char device redirected to /dev/pts/1 char device redirected to /dev/pts/2 When I have the following xml-fil (/etc/libvirt/qemu/obsd64.xml): <domain type='qemu'> <name>obsd64</name> <uuid>5b315a1a-530a-1f13-fcb7-54098c9968a7</uuid> <memory>524288</memory> <currentMemory>524288</currentMemory> <vcpu>1</vcpu> <os> <type arch='x86_64' machine='pc'>hvm</type> <boot dev='hd'/> </os> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> <on_reboot>restart</on_reboot> <on_crash>destroy</on_crash> <devices> <emulator>/usr/bin/kvm</emulator> <disk type='file' device='disk'> <source file='/home/cs/kvm/OpenBSD/obsd64.hda'/> <target dev='hda' bus='ide'/> </disk> <interface type='user'> <mac address='00:16:3e:17:9d:f7'/> </interface> <console tty='/dev/pts/1'/> </devices> </domain> And the log from virt-manager says: [Mon, 19 May 2008 13:11:32 virt-manager 3973] DEBUG (manager:413) VM obsd64 started [Mon, 19 May 2008 13:11:36 virt-manager 3973] DEBUG (details:1010) Trying console login [Mon, 19 May 2008 13:11:36 virt-manager 3973] DEBUG (details:1015) No graphics configured in guest [Mon, 19 May 2008 13:11:36 virt-manager 3973] DEBUG (details:528) In hw_selected with null tree iter [Mon, 19 May 2008 13:11:36 virt-manager 3973] DEBUG (details:528) In hw_selected with null tree iter [Mon, 19 May 2008 13:11:36 virt-manager 3973] DEBUG (details:1010) Trying console login [Mon, 19 May 2008 13:11:37 virt-manager 3973] DEBUG (details:1015) No graphics configured in guest Is this working/tested? Regards Claes PS I have tried many many variants on <console>.......

2 1

[libvirt] [RFC] API vs XML
by Stefan de Konink 19 May '08

19 May '08

Hi, In my previous email Daniel made clear that for many functions it is preferable to have access to the XML output. I would like to know what the general opinion is about defining a domain. I can understand that people don't mind to define a domain manually or with tools and pump it inside libvirt with the virDomainDefineXML call. But why are the XML tree manipulating features not incorporated into the API? Slightly more 'semantics based' than Attach/Detach Device. Allowing to specify the information that is going into the XML. So for example: domainptr = virDomainDefine(name) virDomainSetName(domainptr, name) virDomainSetBootloader(domainptr, path) virDomainSetOS(domainptr, type) virDomainSetMemory(domainptr, amount, live) virDomainSetVCPU(domainptr, amount, live) virDomainAttachDisk(domainptr, type, sourceptr, targetptr, live) virDomainDetachDevice(domainptr, deviceptr, live) I know there are people that love XML here, but can someone give a reasonable statement why not to support the above? (More clean, less parsing) Stefan

3 2