- Devel - libvirt List Archives

[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

[libvirt] PATCH: Pass -name argument to QEMU
by Daniel P. Berrange 19 May '08

19 May '08

This patch makes libvirt pass the -name argumet to QEMU it if it supported by the QEMU binary in question. THis allows QEMU to set the VNC title and allows Xenner to set the Xen guest name in xenstore. src/qemu_conf.c | 19 ++++++++++++++----- src/qemu_conf.h | 5 +++-- tests/qemuxml2argvdata/qemuxml2argv-minimal.args | 2 +- tests/qemuxml2argvtest.c | 23 +++++++++++------------ 4 files changed, 29 insertions(+), 20 deletions(-) Dan. diff -r aab96c0c6974 src/qemu_conf.c --- a/src/qemu_conf.c Fri May 09 19:24:37 2008 -0400 +++ b/src/qemu_conf.c Fri May 09 19:30:26 2008 -0400 @@ -492,10 +492,12 @@ *flags |= QEMUD_CMD_FLAG_KQEMU; if (strstr(help, "-no-reboot")) *flags |= QEMUD_CMD_FLAG_NO_REBOOT; - if (strstr(help, "\n-drive")) - *flags |= QEMUD_CMD_FLAG_DRIVE_OPT; + if (strstr(help, "-name")) + *flags |= QEMUD_CMD_FLAG_NAME; + if (strstr(help, "-drive")) + *flags |= QEMUD_CMD_FLAG_DRIVE; if (strstr(help, "boot=on")) - *flags |= QEMUD_CMD_FLAG_DRIVE_BOOT_OPT; + *flags |= QEMUD_CMD_FLAG_DRIVE_BOOT; if (*version >= 9000) *flags |= QEMUD_CMD_FLAG_VNC_COLON; ret = 0; @@ -2348,6 +2350,7 @@ len = 1 + /* qemu */ 2 + /* machine type */ disableKQEMU + /* Disable kqemu */ + (vm->qemuCmdFlags & QEMUD_CMD_FLAG_NAME ? 2 : 0) + /* -name XXX */ 2 * vm->def->ndisks + /* disks*/ (vm->def->nnets > 0 ? (4 * vm->def->nnets) : 2) + /* networks */ 1 + /* usb */ @@ -2394,6 +2397,12 @@ if (!((*argv)[++n] = strdup(vcpus))) goto no_memory; + if (vm->qemuCmdFlags & QEMUD_CMD_FLAG_NAME) { + if (!((*argv)[++n] = strdup("-name"))) + goto no_memory; + if (!((*argv)[++n] = strdup(vm->def->name))) + goto no_memory; + } /* * NB, -nographic *MUST* come before any serial, or monitor * or parallel port flags due to QEMU craziness, where it @@ -2472,11 +2481,11 @@ } /* If QEMU supports -drive param instead of old -hda, -hdb, -cdrom .. */ - if (vm->qemuCmdFlags & QEMUD_CMD_FLAG_DRIVE_OPT) { + if (vm->qemuCmdFlags & QEMUD_CMD_FLAG_DRIVE) { int bootCD = 0, bootFloppy = 0, bootDisk = 0; /* If QEMU supports boot=on for -drive param... */ - if (vm->qemuCmdFlags & QEMUD_CMD_FLAG_DRIVE_BOOT_OPT) { + if (vm->qemuCmdFlags & QEMUD_CMD_FLAG_DRIVE_BOOT) { for (i = 0 ; i < vm->def->os.nBootDevs ; i++) { switch (vm->def->os.bootDevs[i]) { case QEMUD_BOOT_CDROM: diff -r aab96c0c6974 src/qemu_conf.h --- a/src/qemu_conf.h Fri May 09 19:24:37 2008 -0400 +++ b/src/qemu_conf.h Fri May 09 19:30:26 2008 -0400 @@ -249,8 +249,9 @@ QEMUD_CMD_FLAG_KQEMU = (1 << 0), QEMUD_CMD_FLAG_VNC_COLON = (1 << 1), QEMUD_CMD_FLAG_NO_REBOOT = (1 << 2), - QEMUD_CMD_FLAG_DRIVE_OPT = (1 << 3), - QEMUD_CMD_FLAG_DRIVE_BOOT_OPT = (1 << 4), + QEMUD_CMD_FLAG_DRIVE = (1 << 3), + QEMUD_CMD_FLAG_DRIVE_BOOT = (1 << 4), + QEMUD_CMD_FLAG_NAME = (1 << 5), }; diff -r aab96c0c6974 tests/qemuxml2argvdata/qemuxml2argv-minimal.args --- a/tests/qemuxml2argvdata/qemuxml2argv-minimal.args Fri May 09 19:24:37 2008 -0400 +++ b/tests/qemuxml2argvdata/qemuxml2argv-minimal.args Fri May 09 19:30:26 2008 -0400 @@ -1,1 +1,1 @@ -/usr/bin/qemu -M pc -m 214 -smp 1 -nographic -monitor pty -no-acpi -boot c -hda /dev/HostVG/QEMUGuest1 -net none -serial none -parallel none -usb \ No newline at end of file +/usr/bin/qemu -M pc -m 214 -smp 1 -name QEMUGuest1 -nographic -monitor pty -no-acpi -boot c -hda /dev/HostVG/QEMUGuest1 -net none -serial none -parallel none -usb \ No newline at end of file diff -r aab96c0c6974 tests/qemuxml2argvtest.c --- a/tests/qemuxml2argvtest.c Fri May 09 19:24:37 2008 -0400 +++ b/tests/qemuxml2argvtest.c Fri May 09 19:30:26 2008 -0400 @@ -20,7 +20,7 @@ #define MAX_FILE 4096 -static int testCompareXMLToArgvFiles(const char *xml, const char *cmd, int driveFlag) { +static int testCompareXMLToArgvFiles(const char *xml, const char *cmd, int extraFlags) { char xmlData[MAX_FILE]; char argvData[MAX_FILE]; char *xmlPtr = &(xmlData[0]); @@ -47,10 +47,7 @@ vm.qemuVersion = 0 * 1000 * 100 + (8 * 1000) + 1; vm.qemuCmdFlags = QEMUD_CMD_FLAG_VNC_COLON | QEMUD_CMD_FLAG_NO_REBOOT; - if (driveFlag) { - vm.qemuCmdFlags |= QEMUD_CMD_FLAG_DRIVE_OPT; - vm.qemuCmdFlags |= QEMUD_CMD_FLAG_DRIVE_BOOT_OPT; - } + vm.qemuCmdFlags |= extraFlags; vm.migrateFrom[0] = '\0'; vmdef->vncActivePort = vmdef->vncPort; @@ -100,7 +97,7 @@ struct testInfo { const char *name; - int driveFlag; + int extraFlags; }; static int testCompareXMLToArgvHelper(const void *data) { @@ -111,7 +108,7 @@ abs_srcdir, info->name); snprintf(args, PATH_MAX, "%s/qemuxml2argvdata/qemuxml2argv-%s.args", abs_srcdir, info->name); - return testCompareXMLToArgvFiles(xml, args, info->driveFlag); + return testCompareXMLToArgvFiles(xml, args, info->extraFlags); } @@ -135,15 +132,15 @@ driver.caps = qemudCapsInit(); -#define DO_TEST(name, driveFlag) \ +#define DO_TEST(name, extraFlags) \ do { \ - struct testInfo info = { name, driveFlag }; \ + struct testInfo info = { name, extraFlags }; \ if (virtTestRun("QEMU XML-2-ARGV " name, \ 1, testCompareXMLToArgvHelper, &info) < 0) \ ret = -1; \ } while (0) - DO_TEST("minimal", 0); + DO_TEST("minimal", QEMUD_CMD_FLAG_NAME); DO_TEST("boot-cdrom", 0); DO_TEST("boot-network", 0); DO_TEST("boot-floppy", 0); @@ -152,8 +149,10 @@ DO_TEST("disk-cdrom", 0); DO_TEST("disk-floppy", 0); DO_TEST("disk-many", 0); - DO_TEST("disk-virtio", 1); - DO_TEST("disk-xenvbd", 1); + DO_TEST("disk-virtio", QEMUD_CMD_FLAG_DRIVE | + QEMUD_CMD_FLAG_DRIVE_BOOT); + DO_TEST("disk-xenvbd", QEMUD_CMD_FLAG_DRIVE | + QEMUD_CMD_FLAG_DRIVE_BOOT); DO_TEST("graphics-vnc", 0); DO_TEST("graphics-sdl", 0); DO_TEST("input-usbmouse", 0); -- |: 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 :|

5 9

[libvirt] Re: [Libvir] [PATCH] update from gnulib
by Richard W.M. Jones 19 May '08

19 May '08

Did this huge patch go in? If not, it should because I noticed gnulib problems also with mingw which were fixed by updating. 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

2 1

[Libvir] How to get the memory used by a guest domin
by Pranay Prasoon 19 May '08

19 May '08

Hi, It appears to be no API available to provide the memory used by a guest domin. I looked at the availble libvirt api called "virNodeGetCellsFreeMemory" using which it is possible to get the free mem. But looking further I found that this is free memory of the "whole box" rather than based upon the guest domain. How can I get the memory used by a guest domin. Thanks n Regards, -Pranay.

4 4

[libvirt] [virt-manager] PATCH: Support nonstandard ssh-port for tunnels
by ClaesBas 19 May '08

19 May '08

If you have ssh moved/hidden somewhere else then port 22 this patch makes it possible to open the vnc/console. I have to add the entry from commandline like this: virt-manager -c qemu+ssh://username@some_machine:22222/system If ssh is running on port 22222. I've also submitet this on bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=447070 Regards Claes --- a/src/virtManager/details.py Tue May 13 15:59:25 2008 -0400 +++ b/src/virtManager/details.py Sun May 18 23:07:37 2008 +0200 @@ -975,7 +975,11 @@ class vmmDetails(gobject.GObject): os.close(1) os.dup(fds[1].fileno()) os.dup(fds[1].fileno()) - argv = ["ssh", "ssh", "-p", "22"] + if not server.count(":"): + sshport = 22 + else: + (server, sshport) = server.split(":") + argv = ["ssh", "ssh", "-p", sshport] if username: argv += ['-l', username] argv += [ server, "nc", vncaddr, str(vncport) ]

2 1

[libvirt] libvirtd forgets about domain if started two time
by Thomas Mueller 17 May '08

17 May '08

hi there i filed a bug for debian's libvrit-bin package: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=481619 in short: start 2 times the same domain and "virsh list" will not show it anymore, altough kvm process ist still there. tried also without emulator defined in the xml. same error. now i managed to compile from source (cvs, 2008-05-17). i get the error also with this version of libvirtd. - Thomas

1 0

[libvirt] PATCH: Use -help arg with QEMU probing
by Daniel P. Berrange 17 May '08

17 May '08

This patch makes the code that probes QEMU args explicitly add the -help argument. This works around a problem with certain KVM builds which refuse to run if executed without -help, and no KVM modules are present. It also removes the set of setenv() since that changes libvirtd's environ and instead uses execle() to set the child's environment Dan Index: src/qemu_conf.c =================================================================== RCS file: /data/cvs/libvirt/src/qemu_conf.c,v retrieving revision 1.64 diff -u -p -r1.64 qemu_conf.c --- src/qemu_conf.c 15 May 2008 20:07:34 -0000 1.64 +++ src/qemu_conf.c 16 May 2008 14:34:42 -0000 @@ -447,6 +447,8 @@ static int qemudExtractVersionInfo(const } if (child == 0) { /* Kid */ + const char *const qemuenv[] = { "LANG=C", NULL }; + if (close(STDIN_FILENO) < 0) goto cleanup1; if (close(STDERR_FILENO) < 0) @@ -457,8 +459,7 @@ static int qemudExtractVersionInfo(const goto cleanup1; /* Just in case QEMU is translated someday.. */ - setenv("LANG", "C", 1); - execl(qemu, qemu, (char*)NULL); + execle(qemu, qemu, "-help", (char*)NULL, qemuenv); cleanup1: _exit(-1); /* Just in case */ -- |: 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] [PATCH] plug two leaks
by Jim Meyering 16 May '08

16 May '08

Running "make check" under valgrind exposed at least the first. Then, I spotted the other. * src/qemu_conf.c (qemudParseXML): Free "obj" unconditionally. --- src/qemu_conf.c | 6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/src/qemu_conf.c b/src/qemu_conf.c index ff7c63e..47d49a2 100644 --- a/src/qemu_conf.c +++ b/src/qemu_conf.c @@ -1716,11 +1716,11 @@ static struct qemud_vm_def *qemudParseXML(virConnectPtr conn, (obj->stringval != NULL) && (obj->stringval[0] != 0)) { strncpy(def->os.bootloader, (const char*)obj->stringval, sizeof(def->os.bootloader)); NUL_TERMINATE(def->os.bootloader); - xmlXPathFreeObject(obj); /* Set a default OS type, since <type> is optional with bootloader */ strcpy(def->os.type, "xen"); } + xmlXPathFreeObject(obj); /* Extract OS type info */ obj = xmlXPathEval(BAD_CAST "string(/domain/os/type[1])", ctxt); @@ -1733,9 +1733,9 @@ static struct qemud_vm_def *qemudParseXML(virConnectPtr conn, } } else { strcpy(def->os.type, (const char *)obj->stringval); - xmlXPathFreeObject(obj); - obj = NULL; } + xmlXPathFreeObject(obj); + obj = NULL; if (!virCapabilitiesSupportsGuestOSType(driver->caps, def->os.type)) { qemudReportError(conn, NULL, NULL, VIR_ERR_OS_TYPE, -- 1.5.5.1.249.g26848

2 2