- Devel - libvirt List Archives

[libvirt] [PATCH 0/1] API extension tutorial
by David Allan 28 May '09

28 May '09

Here is a document describing the process for extending the libvirt API. Note that the patch includes 8 sample patches that go with the document that should be included in and not applied to the tree. Dave

4 7

[libvirt] PATCH: Fix misc bugs in QEMU ARGV -> XML convertor
by Daniel P. Berrange 28 May '09

28 May '09

Having just tried out the QEMU ARGV -> XML convertor on a random set of args posted on the mailing list I found a few bugs. It didn't cope with a -net arg without a vlan=XX option set - this should assume vlan=0 if not set. It didn't cope with quoting of args with spaces in them. It finally did not generate a random UUID or MAC address if omitted. Regards, Daniel diff -r eb060781cfb9 src/qemu_conf.c --- a/src/qemu_conf.c Wed May 27 21:07:37 2009 +0100 +++ b/src/qemu_conf.c Wed May 27 22:56:55 2009 +0100 @@ -1565,14 +1565,27 @@ static int qemuStringToArgvEnv(const cha /* Iterate over string, splitting on sequences of ' ' */ while (curr && *curr != '\0') { char *arg; - const char *next = strchr(curr, ' '); + const char *next; + if (*curr == '\'') { + curr++; + next = strchr(curr, '\''); + } else if (*curr == '"') { + curr++; + next = strchr(curr, '"'); + } else { + next = strchr(curr, ' '); + } if (!next) next = strchr(curr, '\n'); - if (next) + if (next) { arg = strndup(curr, next-curr); - else + if (*next == '\'' || + *next == '"') + next++; + } else { arg = strdup(curr); + } if (!arg) goto no_memory; @@ -1644,7 +1657,7 @@ static const char *qemuFindEnv(const cha int i; int len = strlen(name); - for (i = 0 ; progenv[i] ; i++) { + for (i = 0 ; progenv && progenv[i] ; i++) { if (STREQLEN(progenv[i], name, len) && progenv[i][len] == '=') return progenv[i] + len + 1; @@ -1883,8 +1896,10 @@ qemuFindNICForVLAN(virConnectPtr conn, int gotvlan; const char *tmp = strstr(nics[i], "vlan="); char *end; - if (tmp) - tmp += strlen("vlan="); + if (!tmp) + continue; + + tmp += strlen("vlan="); if (virStrToLong_i(tmp, &end, 10, &gotvlan) < 0) { qemudReportError(conn, NULL, NULL, VIR_ERR_INTERNAL_ERROR, @@ -1896,6 +1911,9 @@ qemuFindNICForVLAN(virConnectPtr conn, return nics[i]; } + if (wantvlan == 0 && nnics > 0) + return nics[0]; + qemudReportError(conn, NULL, NULL, VIR_ERR_INTERNAL_ERROR, _("cannot find NIC definition for vlan %d"), wantvlan); return NULL; @@ -1909,32 +1927,33 @@ qemuFindNICForVLAN(virConnectPtr conn, */ static virDomainNetDefPtr qemuParseCommandLineNet(virConnectPtr conn, + virCapsPtr caps, const char *val, int nnics, const char **nics) { virDomainNetDefPtr def = NULL; - char **keywords; - char **values; + char **keywords = NULL; + char **values = NULL; int nkeywords; const char *nic; int wantvlan = 0; const char *tmp; + int genmac = 1; int i; tmp = strchr(val, ','); - if (!tmp) { - qemudReportError(conn, NULL, NULL, VIR_ERR_INTERNAL_ERROR, - _("cannot extract NIC type from '%s'"), val); - return NULL; + + if (tmp) { + if ((nkeywords = qemuParseCommandLineKeywords(conn, + tmp+1, + &keywords, + &values)) < 0) + return NULL; + } else { + nkeywords = 0; } - if ((nkeywords = qemuParseCommandLineKeywords(conn, - tmp+1, - &keywords, - &values)) < 0) - return NULL; - if (VIR_ALLOC(def) < 0) { virReportOOMError(conn); goto cleanup; @@ -1983,7 +2002,9 @@ qemuParseCommandLineNet(virConnectPtr co goto cleanup; } - if (!STRPREFIX(nic, "nic,")) { + if (!STRPREFIX(nic, "nic")) { + qemudReportError(conn, NULL, NULL, VIR_ERR_INTERNAL_ERROR, + _("cannot parse NIC definition '%s'"), nic); virDomainNetDefFree(def); def = NULL; goto cleanup; @@ -1996,17 +2017,22 @@ qemuParseCommandLineNet(virConnectPtr co VIR_FREE(keywords); VIR_FREE(values); - if ((nkeywords = qemuParseCommandLineKeywords(conn, - nic + strlen("nic,"), - &keywords, - &values)) < 0) { - virDomainNetDefFree(def); - def = NULL; - goto cleanup; + if (STRPREFIX(nic, "nic,")) { + if ((nkeywords = qemuParseCommandLineKeywords(conn, + nic + strlen("nic,"), + &keywords, + &values)) < 0) { + virDomainNetDefFree(def); + def = NULL; + goto cleanup; + } + } else { + nkeywords = 0; } for (i = 0 ; i < nkeywords ; i++) { if (STREQ(keywords[i], "macaddr")) { + genmac = 0; virParseMacAddr(values[i], def->mac); } else if (STREQ(keywords[i], "model")) { def->model = values[i]; @@ -2014,6 +2040,9 @@ qemuParseCommandLineNet(virConnectPtr co } } + if (genmac) + virCapabilitiesGenerateMac(caps, def->mac); + cleanup: for (i = 0 ; i < nkeywords ; i++) { VIR_FREE(keywords[i]); @@ -2283,6 +2312,7 @@ error: * as is practical. This is not an exact science.... */ virDomainDefPtr qemuParseCommandLine(virConnectPtr conn, + virCapsPtr caps, const char **progenv, const char **progargv) { @@ -2303,6 +2333,8 @@ virDomainDefPtr qemuParseCommandLine(vir if (VIR_ALLOC(def) < 0) goto no_memory; + virUUIDGenerate(def->uuid); + def->id = -1; def->memory = def->maxmem = 64 * 1024; def->vcpus = 1; @@ -2604,7 +2636,7 @@ virDomainDefPtr qemuParseCommandLine(vir WANT_VALUE(); if (!STRPREFIX(val, "nic") && STRNEQ(val, "none")) { virDomainNetDefPtr net; - if (!(net = qemuParseCommandLineNet(conn, val, nnics, nics))) + if (!(net = qemuParseCommandLineNet(conn, caps, val, nnics, nics))) goto error; if (VIR_REALLOC_N(def->nets, def->nnets+1) < 0) { virDomainNetDefFree(net); @@ -2741,6 +2773,7 @@ error: virDomainDefPtr qemuParseCommandLineString(virConnectPtr conn, + virCapsPtr caps, const char *args) { const char **progenv = NULL; @@ -2751,7 +2784,7 @@ virDomainDefPtr qemuParseCommandLineStri if (qemuStringToArgvEnv(args, &progenv, &progargv) < 0) goto cleanup; - def = qemuParseCommandLine(conn, progenv, progargv); + def = qemuParseCommandLine(conn, caps, progenv, progargv); cleanup: for (i = 0 ; progargv && progargv[i] ; i++) diff -r eb060781cfb9 src/qemu_conf.h --- a/src/qemu_conf.h Wed May 27 21:07:37 2009 +0100 +++ b/src/qemu_conf.h Wed May 27 22:56:55 2009 +0100 @@ -127,9 +127,11 @@ int qemudBuildCommandLine const char *migrateFrom); virDomainDefPtr qemuParseCommandLine(virConnectPtr conn, + virCapsPtr caps, const char **progenv, const char **progargv); virDomainDefPtr qemuParseCommandLineString(virConnectPtr conn, + virCapsPtr caps, const char *args); #endif /* __QEMUD_CONF_H */ diff -r eb060781cfb9 src/qemu_driver.c --- a/src/qemu_driver.c Wed May 27 21:07:37 2009 +0100 +++ b/src/qemu_driver.c Wed May 27 22:56:55 2009 +0100 @@ -3418,6 +3418,7 @@ static char *qemuDomainXMLFromNative(vir const char *format, const char *config, unsigned int flags ATTRIBUTE_UNUSED) { + struct qemud_driver *driver = conn->privateData; virDomainDefPtr def = NULL; char *xml = NULL; @@ -3427,7 +3428,7 @@ static char *qemuDomainXMLFromNative(vir goto cleanup; } - def = qemuParseCommandLineString(conn, config); + def = qemuParseCommandLineString(conn, driver->caps, config); if (!def) goto cleanup; diff -r eb060781cfb9 tests/qemuargv2xmltest.c --- a/tests/qemuargv2xmltest.c Wed May 27 21:07:37 2009 +0100 +++ b/tests/qemuargv2xmltest.c Wed May 27 22:56:55 2009 +0100 @@ -49,7 +49,7 @@ static int testCompareXMLToArgvFiles(con if (virtTestLoadFile(xml, &expectxml, MAX_FILE) < 0) goto fail; - if (!(vmdef = qemuParseCommandLineString(NULL, cmd))) + if (!(vmdef = qemuParseCommandLineString(NULL, driver.caps, cmd))) goto fail; if (!(actualxml = virDomainDefFormat(NULL, vmdef, 0))) @@ -109,6 +109,8 @@ mymain(int argc, char **argv) if (!abs_srcdir) abs_srcdir = getcwd(cwd, sizeof(cwd)); + virRandomInitialize(0); + if ((driver.caps = testQemuCapsInit()) == NULL) return EXIT_FAILURE; if((driver.stateDir = strdup("/nowhere")) == NULL) -- |: 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 1

[libvirt] PATCH: Don't set ifname or script args for QEMU tap devices
by Daniel P. Berrange 28 May '09

28 May '09

When running QEMU with a type=bridge or type=network interface config, we pass a pre-created TAP device file descriptor, eg -net tap,fd=17,script=,vlan=0,ifname=vnet0 The ifname and script args have always been ignored by all QEMU versions we support. Latest QEMU will now error out if they are set. So this patch drops those two redundant options. NB, then are still set for type=ethernet inteface configs, because in that config we're not creating a TAP device. -net tap,fd=17,vlan=0 There is no impact on test cases, because live TAP devices is something that you can exercise in the test cases. Daniel diff -r b9dc4ea7f6aa src/qemu_conf.c --- a/src/qemu_conf.c Tue May 26 16:16:28 2009 +0100 +++ b/src/qemu_conf.c Tue May 26 22:56:09 2009 +0100 @@ -662,8 +662,8 @@ qemudNetworkIfaceConnect(virConnectPtr c } snprintf(tapfdstr, sizeof(tapfdstr), - "tap,fd=%d,script=,vlan=%d,ifname=%s", - tapfd, vlan, net->ifname); + "tap,fd=%d,vlan=%d", + tapfd, vlan); if (!(retval = strdup(tapfdstr))) goto no_memory; -- |: 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 1

[libvirt] PATCH: Always log source location if available.
by Daniel P. Berrange 28 May '09

28 May '09

Currently, even though all the logging functions get given the source function and line number, it is just discarded unless priority == DEBUG. As an example, run virsh with logging enabled, and a bogus URI LIBVIRT_DEBUG=1 LIBVIRT_LOG_OUTPUTS=1:stderr virsh -c foo://bar 13:12:06.252: debug : do_open:993 : trying driver 4 (remote) ... 13:12:06.252: debug : do_open:999 : driver 4 remote returned DECLINED 13:12:06.252: error : could not connect to foo://bar 13:12:06.252: debug : virUnrefConnect:232 : unref connection 0x99617b0 1 13:12:06.252: debug : virReleaseConnect:191 : release connection 0x99617b0 Notice how it doesn't tell the user where the log message with 'error' priority came from. The same happens for info & warn levels. With the following patch applied, we always report function if it was passed into virLogMessage() 13:15:00.456: debug : do_open:993 : trying driver 4 (remote) ... 13:15:00.456: debug : do_open:999 : driver 4 remote returned DECLINED 13:15:00.456: error : virLibConnError:390 : could not connect to foo://bar 13:15:00.456: debug : virUnrefConnect:232 : unref connection 0x8dd87b0 1 13:15:00.456: debug : virReleaseConnect:191 : release connection 0x8dd87b0 So, we now see that the error came from virLibConnError at line 390 Daniel diff -r b9dc4ea7f6aa src/logging.c --- a/src/logging.c Tue May 26 16:16:28 2009 +0100 +++ b/src/logging.c Wed May 27 13:15:55 2009 +0100 @@ -516,7 +516,7 @@ void virLogMessage(const char *category, gettimeofday(&cur_time, NULL); localtime_r(&cur_time.tv_sec, &time_info); - if ((funcname != NULL) && (priority == VIR_LOG_DEBUG)) { + if ((funcname != NULL)) { ret = virAsprintf(&msg, "%02d:%02d:%02d.%03d: %s : %s:%lld : %s\n", time_info.tm_hour, time_info.tm_min, time_info.tm_sec, (int) cur_time.tv_usec / 1000, -- |: 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 1

[libvirt] [PATCH 1/2] (Updated & fixed) OpenNebula driver, libvirt-0.6.2
by "Abel Míguez Rodríguez" 27 May '09

27 May '09

Hi all, Here is the One driver & patches for the current git's master commit "9e9527 - Remove stale QEMU pidfiles". [PATCH 1/2] Patch to be applied to libvirt-0.6.2 sources and building files. [PATCH 2/2] Driver source code. Thanks for all the comments about the patches. We waited for the libvirt's release to update the driver's structure to 0.6.2 and apply the improvements. Here is a short list of the main changes applied: - Included driver's files in a different directory "src/opennebula" - Added Capabilities "virCapabilitiesAddGuest" for "x86_64" and "i686" guests and used "one" as hypervisor at "virCapabilitiesAddGuestDomain". - Instead creating a temporal file to send the VM definition we have updated the API we were using to being able to do everything in memory, so making use of "virBuffer" to create the VM definition Template. - Added previously unsupported features to the ONE Template, other types of disks and graphics (vnc,sdl) settings. - Fixed up warnings at compilation and make 'syntax-check' test passed. thanks, Abel Miguez. [PATCH 1/2] diff --git a/configure.in b/configure.in index dcacc7f..ab14303 100644 --- a/configure.in +++ b/configure.in @@ -186,6 +186,8 @@ AC_ARG_WITH([vbox], [ --with-vbox add VirtualBox support (on)],[],[with_vbox=yes]) AC_ARG_WITH([lxc], [ --with-lxc add Linux Container support (on)],[],[with_lxc=yes]) +AC_ARG_WITH([one], +[ --with-one add ONE support (on)],[],[with_one=no]) AC_ARG_WITH([test], [ --with-test add test driver support (on)],[],[with_test=yes]) AC_ARG_WITH([remote], @@ -305,6 +307,11 @@ if test "$with_uml" = "yes" ; then fi AM_CONDITIONAL([WITH_UML], [test "$with_uml" = "yes"]) +if test "$with_one" = "yes" ; then + AC_DEFINE_UNQUOTED([WITH_ONE],1,[whether ONE driver is enabled]) +fi +AM_CONDITIONAL([WITH_ONE],[test "$with_one" = "yes"]) + if test "$with_test" = "yes" ; then AC_DEFINE_UNQUOTED([WITH_TEST], 1, [whether Test driver is enabled]) fi @@ -406,6 +413,15 @@ dnl check for kvm headers dnl AC_CHECK_HEADERS([linux/kvm.h]) +dnl OpenNebula driver Compilation setting +dnl + +if test "$with_one" = "yes" ; then + CFLAGS="$CFLAGS -I$ONE_LOCATION/include" + ONE_LIBS="-L/usr/local/lib -lxmlrpc_client++ -lxmlrpc -lxmlrpc_util -lxmlrpc_xmlparse -lxmlrpc_xmltok -lxmlrpc++ -lxmlrpc_client -L$ONE_LOCATION/lib -loneapi" + AC_SUBST([ONE_LIBS]) +fi + dnl Need to test if pkg-config exists PKG_PROG_PKG_CONFIG @@ -1372,6 +1388,7 @@ AC_MSG_NOTICE([ UML: $with_uml]) AC_MSG_NOTICE([ OpenVZ: $with_openvz]) AC_MSG_NOTICE([ VBox: $with_vbox]) AC_MSG_NOTICE([ LXC: $with_lxc]) +AC_MSG_NOTICE([ ONE: $with_one]) AC_MSG_NOTICE([ Test: $with_test]) AC_MSG_NOTICE([ Remote: $with_remote]) AC_MSG_NOTICE([ Network: $with_network]) diff --git a/include/libvirt/virterror.h b/include/libvirt/virterror.h index faf3f61..abe54b2 100644 --- a/include/libvirt/virterror.h +++ b/include/libvirt/virterror.h @@ -63,6 +63,7 @@ typedef enum { VIR_FROM_XEN_INOTIFY, /* Error from xen inotify layer */ VIR_FROM_SECURITY, /* Error from security framework */ VIR_FROM_VBOX, /* Error from VirtualBox driver */ + VIR_FROM_ONE, /* Error from ONE driver */ } virErrorDomain; diff --git a/qemud/Makefile.am b/qemud/Makefile.am index 924e8ad..9d7f61f 100644 --- a/qemud/Makefile.am +++ b/qemud/Makefile.am @@ -120,6 +120,10 @@ if WITH_UML libvirtd_LDADD += ../src/libvirt_driver_uml.la endif +if WITH_ONE + libvirtd_LDADD += ../src/libvirt_driver_one.la +endif + if WITH_STORAGE_DIR libvirtd_LDADD += ../src/libvirt_driver_storage.la endif diff --git a/qemud/qemud.c b/qemud/qemud.c index 829a4bc..a069f38 100644 --- a/qemud/qemud.c +++ b/qemud/qemud.c @@ -75,6 +75,9 @@ #ifdef WITH_UML #include "uml_driver.h" #endif +#ifdef WITH_ONE +#include "opennebula/one_driver.h" +#endif #ifdef WITH_NETWORK #include "network_driver.h" #endif @@ -841,6 +844,7 @@ static struct qemud_server *qemudInitialize(int sigread) { virDriverLoadModule("qemu"); virDriverLoadModule("lxc"); virDriverLoadModule("uml"); + virDriverLoadModule("one"); #else #ifdef WITH_NETWORK networkRegister(); @@ -861,6 +865,9 @@ static struct qemud_server *qemudInitialize(int sigread) { #ifdef WITH_UML umlRegister(); #endif +#ifdef WITH_ONE + oneRegister(); +#endif #endif virEventRegisterImpl(virEventAddHandleImpl, diff --git a/src/Makefile.am b/src/Makefile.am index fd692b4..17ae0e7 100644 --- a/src/Makefile.am +++ b/src/Makefile.am @@ -144,6 +144,12 @@ UML_DRIVER_SOURCES = \ uml_conf.c uml_conf.h \ uml_driver.c uml_driver.h +ONE_DRIVER_SOURCES = \ + ./opennebula/one_conf.c \ + ./opennebula/one_conf.h \ + ./opennebula/one_driver.c \ + ./opennebula/one_driver.h + NETWORK_DRIVER_SOURCES = \ network_driver.h network_driver.c @@ -337,6 +342,25 @@ endif libvirt_driver_uml_la_SOURCES = $(UML_DRIVER_SOURCES) endif +if WITH_ONE +if WITH_DRIVER_MODULES +mod_LTLIBRARIES += libvirt_driver_one.la +else +noinst_LTLIBRARIES += libvirt_driver_one.la +# Stateful, so linked to daemon instead +#libvirt_la_LIBADD += libvirt_driver_one.la +endif +libvirt_driver_one_la_LDFLAGS = $(ONE_LIBS) + +if WITH_DRIVER_MODULES +libvirt_driver_one_la_LDFLAGS += -module -avoid-version +endif +libvirt_driver_one_la_SOURCES = $(ONE_DRIVER_SOURCES) +endif + + + + if WITH_NETWORK if WITH_DRIVER_MODULES mod_LTLIBRARIES += libvirt_driver_network.la @@ -429,6 +453,7 @@ EXTRA_DIST += \ $(QEMU_DRIVER_SOURCES) \ $(LXC_DRIVER_SOURCES) \ $(UML_DRIVER_SOURCES) \ + $(ONE_DRIVER_SOURCES) \ $(OPENVZ_DRIVER_SOURCES) \ $(VBOX_DRIVER_SOURCES) \ $(NETWORK_DRIVER_SOURCES) \ diff --git a/src/domain_conf.c b/src/domain_conf.c index 648d9e9..06b9713 100644 --- a/src/domain_conf.c +++ b/src/domain_conf.c @@ -55,7 +55,8 @@ VIR_ENUM_IMPL(virDomainVirt, VIR_DOMAIN_VIRT_LAST, "test", "vmware", "hyperv", - "vbox") + "vbox", + "one") VIR_ENUM_IMPL(virDomainBoot, VIR_DOMAIN_BOOT_LAST, "fd", diff --git a/src/domain_conf.h b/src/domain_conf.h index f4eea6b..c91a245 100644 --- a/src/domain_conf.h +++ b/src/domain_conf.h @@ -49,6 +49,7 @@ enum virDomainVirtType { VIR_DOMAIN_VIRT_VMWARE, VIR_DOMAIN_VIRT_HYPERV, VIR_DOMAIN_VIRT_VBOX, + VIR_DOMAIN_VIRT_ONE, VIR_DOMAIN_VIRT_LAST, }; diff --git a/src/driver.h b/src/driver.h index 39dc413..5685783 100644 --- a/src/driver.h +++ b/src/driver.h @@ -21,6 +21,7 @@ typedef enum { VIR_DRV_LXC = 6, VIR_DRV_UML = 7, VIR_DRV_VBOX = 8, + VIR_DRV_ONE = 9, } virDrvNo; diff --git a/src/libvirt.c b/src/libvirt.c index 95a861e..4b1610a 100644 --- a/src/libvirt.c +++ b/src/libvirt.c @@ -845,6 +845,10 @@ virGetVersion(unsigned long *libVer, const char *type, if (STRCASEEQ(type, "UML")) *typeVer = LIBVIR_VERSION_NUMBER; #endif +#if WITH_ONE + if (STRCASEEQ(type, "ONE")) + *typeVer = LIBVIR_VERSION_NUMBER; +#endif #if WITH_REMOTE if (STRCASEEQ(type, "Remote")) *typeVer = remoteVersion(); diff --git a/src/virterror.c b/src/virterror.c index 2d34ed7..d4b429c 100644 --- a/src/virterror.c +++ b/src/virterror.c @@ -156,6 +156,8 @@ static const char *virErrorDomainName(virErrorDomain domain) { break; case VIR_FROM_VBOX: dom = "VBOX "; + case VIR_FROM_ONE: + dom = "ONE "; break; } return(dom); ---- Distributed System Architecture Group (http://dsa-research.org) GridWay, http://www.gridway.org OpenNEbula, http://www.opennebula.org

5 14

[libvirt] libvirtd 0.6.3 - Kernel Panic - 2.6.27-openvz-briullov.1
by Evan Borgstrom 27 May '09

27 May '09

Hi, I have a machine running 4 OpenVZ VE's and am looking at libvirt as a management tool. My machine is a Sun Fire X2250 with 1 CPU and 4GB of RAM running Gentoo. When I start libvirtd the output below appears in the dmesg output and the machine continues to function for about 30s longer before it starts dumping piles of continuous backtrace onto the console. Can I provide anymore info that will help diagnose this problem or should I open a bug about this? Thanks! -Evan [ 426.613841] WARNING: at fs/sysfs/dir.c:463 sysfs_add_one+0x2a/0x36() [ 426.613843] sysfs: duplicate filename 'lo' can not be created [ 426.613845] Modules linked in: ipt_MASQUERADE iptable_nat nf_nat nf_conntrack_ipv4 xt_state nf_conntrack ipt_REJECT iptable_filter ip_tables simfs vznetdev vzrst vzcpt tun vzdquota vzethdev vzmon vzdev 8021q bridge stp llc [ 426.613859] Pid: 17966, comm: libvirtd Not tainted 2.6.27-openvz- briullov.1-r1-fb3 #1 [ 426.613863] [<c022291e>] warn_slowpath+0x4b/0x6c [ 426.613869] [<c0333d00>] ? vsnprintf+0x233/0x531 [ 426.613874] [<c02294d1>] ? __sysctl_head_next+0x14/0x99 [ 426.613878] [<c032f826>] ? idr_get_empty_slot+0x13c/0x1f0 [ 426.613883] [<c032f9aa>] ? ida_get_new_above+0xd0/0x171 [ 426.613887] [<c028f9ca>] ? find_inode+0x1f/0x5b [ 426.613891] [<c02bbf5c>] ? sysfs_ilookup_test+0x0/0x11 [ 426.613894] [<c028fac5>] ? ifind+0x32/0x71 [ 426.613897] [<c02bc129>] ? sysfs_find_dirent+0x16/0x27 [ 426.613900] [<c02bc2b9>] sysfs_add_one+0x2a/0x36 [ 426.613903] [<c02bc773>] create_dir+0x43/0x72 [ 426.613906] [<c02bc7e9>] sysfs_create_dir+0x47/0x5b [ 426.613909] [<c033028b>] ? kobject_get+0x12/0x17 [ 426.613912] [<c0330390>] kobject_add_internal+0xb2/0x153 [ 426.613915] [<c03304dc>] kobject_add_varg+0x35/0x41 [ 426.613919] [<c033054d>] kobject_add+0x43/0x49 [ 426.613921] [<c03888e8>] device_add+0x7f/0x470 [ 426.613926] [<c027cd9d>] ? __percpu_alloc_mask+0xb6/0xd5 [ 426.613931] [<c023e5e7>] ? ub_slab_charge+0x4c/0x65 [ 426.613935] [<c03330fe>] ? strlcpy+0x17/0x49 [ 426.613938] [<c045a40c>] netdev_register_kobject+0x59/0x5c [ 426.613943] [<c0451afe>] register_netdevice+0x270/0x332 [ 426.613947] [<c0451bf2>] register_netdev+0x32/0x3f [ 426.613950] [<c03ad540>] loopback_net_init+0x34/0x63 [ 426.613955] [<c044d1eb>] setup_net+0x71/0xbb [ 426.613958] [<c044d534>] copy_net_ns+0x3d/0x99 [ 426.613960] [<c023712b>] create_new_namespaces+0x109/0x196 [ 426.613965] [<c0237370>] copy_namespaces+0x62/0x92 [ 426.613967] [<c0221a50>] copy_process+0x8df/0x105a [ 426.613971] [<c02222b6>] do_fork_pid+0xeb/0x25a [ 426.613973] [<c027f8a2>] ? __fput+0x138/0x140 [ 426.613977] [<c0222438>] do_fork+0x13/0x15 [ 426.613980] [<c02023cb>] sys_clone+0x1f/0x21 [ 426.613983] [<c020399e>] syscall_call+0x7/0xb [ 426.613986] [<c04f0000>] ? init_scattered_cpuid_features+0x4f/0x7d [ 426.613992] ======================= [ 426.613994] ---[ end trace 3809b0ba52b812c7 ]--- [ 426.613997] kobject_add_internal failed for lo with -EEXIST, don't try to register things with the same name in the same directory. [ 426.614001] Pid: 17966, comm: libvirtd Tainted: G W 2.6.27- openvz-briullov.1-r1-fb3 #1 [ 426.614004] [<c033041f>] kobject_add_internal+0x141/0x153 [ 426.614008] [<c03304dc>] kobject_add_varg+0x35/0x41 [ 426.614011] [<c033054d>] kobject_add+0x43/0x49 [ 426.614014] [<c03888e8>] device_add+0x7f/0x470 [ 426.614017] [<c027cd9d>] ? __percpu_alloc_mask+0xb6/0xd5 [ 426.614020] [<c023e5e7>] ? ub_slab_charge+0x4c/0x65 [ 426.614024] [<c03330fe>] ? strlcpy+0x17/0x49 [ 426.614027] [<c045a40c>] netdev_register_kobject+0x59/0x5c [ 426.614030] [<c0451afe>] register_netdevice+0x270/0x332 [ 426.614033] [<c0451bf2>] register_netdev+0x32/0x3f [ 426.614036] [<c03ad540>] loopback_net_init+0x34/0x63 [ 426.614040] [<c044d1eb>] setup_net+0x71/0xbb [ 426.614042] [<c044d534>] copy_net_ns+0x3d/0x99 [ 426.614045] [<c023712b>] create_new_namespaces+0x109/0x196 [ 426.614048] [<c0237370>] copy_namespaces+0x62/0x92 [ 426.614051] [<c0221a50>] copy_process+0x8df/0x105a [ 426.614054] [<c02222b6>] do_fork_pid+0xeb/0x25a [ 426.614057] [<c027f8a2>] ? __fput+0x138/0x140 [ 426.614060] [<c0222438>] do_fork+0x13/0x15 [ 426.614063] [<c02023cb>] sys_clone+0x1f/0x21 [ 426.614066] [<c020399e>] syscall_call+0x7/0xb [ 426.614068] [<c04f0000>] ? init_scattered_cpuid_features+0x4f/0x7d [ 426.614073] ======================= -- Evan Borgstrom <evan(a)fatbox.ca> - FatBox Inc. Find me on LinkedIn - http://www.linkedin.com/in/evanb

2 1

[libvirt] staggered guest startup / startup order
by Gerry Reno 26 May '09

26 May '09

Is there a way that you can set the guests startup order and stagger their startup at boot? Regards, Gerry

6 8

[libvirt] RFC / Braindump: public APIs needing data streams
by Daniel P. Berrange 26 May '09

26 May '09

The patches for secure migration raise an interesting question wrt the handling of data streams and their effects on the internal driver API and the public API. Although the migration helper APIs are not technically public, they do map onto the remote wire protocol and as such we have the same long term compatability issues to worry about. The way the migration APIs fit together are obscuring the picture a little, so for the sake of clarity, the remainder of this mail is going to talk about a ficticious public API 'virDomainRestoreStream' which allows a guest domain to be restored from a generic data stream, rather than a named file. If we can solve this API problem, then the design will trivially apply to secure migration. I'll now outline some possible approaches at public API level: 1. Pass a file handle to the public API Application usage: fd = open(filename); ret = virDomainRestoreStream(dom, fd); Driver internal usage: int virDomainRestoreStreamImpl(virDomainPtr dom, int fd) char buf[4096]; int ret; int qemuFD; qemuFD = runQEMUWithIncomingFD(dom); do { ret = read(fd, buf, sizeof buf); if (ret > 0) write(qemuFD, buf, ret); } while (ret > 0); } Good: Restore functionality all in one driver method Good: Public API is very simple Good: Internal driver can poll() on the FD to avoid blocking Bad: Application API is blocked Bad: Data read from FD might need transformation eg, uncompress, or decrypt TLS/SASL. 2. Provide public APIs for starting restore, feeding data, and completing. This matches proposal for secure migration patchset. Application usage: fd = open(filename); ret = virDomainRestorePrepare(dom); do { char buf[4096]; ret = read(fd, buf, sizeof buf); virDomainRestoreData(dom, buf, ret); } while (ret > 0); virDomainRestoreFinish(dom, ret == 0 ? 0 : 1); Driver internal usage: int virDomainRestorePrepareImpl(virDomainPtr dom) { qemuFD = runQEMUWithIncomingFD(dom); } int virDomainRestoreDataImpl(virDomainPtr dom, const char *buf, int buflen) { qemudFD = ...find previously opened qemuFD ... write(qemuFD, buf, buflen) } int virDomainRestoreFinishImpl(virDomainPtr dom, int error) { if (error) ...kill QEMU ... else qemuFD = ...find previously opened qemuFD ... close(qemuFD); } Good: Application can easily decrypt input data Good: Application can use an event loop to feed in data as it becomes available. eg poll in socket() Good: Application API never blocks execution for long time Bad: Driver has to maintain state across calls indefinitely Bad: Cannot guarentee that same client calls prepare/data. ie Different clients can get mixed up feeding data. Bad: Public API is fairly complex Bad: Lots of public API entry points for each method needing streams. 3. Provide a stream object for feeding data to driver from application. Similar to option 2, but provides easier state mgmt for driver. The driver will set callbacks on the data stream to receive data from client. Application usage: virDataStream stream = virDataStreamNew(); ret = virDomainRestore(dom, stream); do { char buf[4096]; ret = read(fd, buf, sizeof buf); virDataStreamWrite(stream, buf, ret); } while (ret > 0); virDataStreamFinish(dom, ret == 0 ? 0 : 1); Driver internal usage: int virDomainRestoreStreamImpl(virDomainPtr dom, virDataStream stream) { qemuFD = runQEMUWithIncomingFD(dom); virDataStreamSetCallbacks(stream, virDomainRestoreDataImpl, virDomainRestoreFinishImpl, (void *)qemudFD); } int virDomainRestoreDataImpl(virDomainPtr dom, const char *buf, int buflen, void *opaque) { int qemudFD = (int)opaque; write(qemuFD, buf, buflen) } int virDomainRestoreFinishImpl(virDomainPtr dom, int error, void *opaque) { if (error) ...kill QEMU ... else int qemudFD = (int)opaque; close(qemuFD); } Good: Application can easily decrypt input data Good: Application can use an event loop to feed in data as it becomes available. eg poll in socket() Good: Application API never blocks execution for long time Good: New APIs reusable for any public API with data stream Bad: Public API is fairly complex Bad: Driver has to maintain state across calls indefinitely 4. Provide a callback for driver to fetch data from the client app. Similar to option 1, but avoids need to expose concept of a 'fd' in public API directly. Application usage: int appreader(virDomainPtr dom, char *buf, int buflen, void *opaque) { int fd = (int)opaque; return read(fd, buf, buflen) } fd = open(filename); ret = virDomainRestoreStream(dom, appreader, (void *)fd); Driver internal usage int virDomainRestoreStreamImpl(virDomainPtr dom, int (*reader)(virDomainPtr, char *, int, voi d*), void *opaque) char buf[4096]; int ret; int qemuFD; qemuFD = runQEMUWithIncomingFD(dom); do { ret = (*reader)(dom, buf, sizeof buf, opaque); if (ret > 0) write(qemuFD, buf, ret); } while (ret > 0); } Good: Restore functionality all in one driver method Good: Public API is very simple Good: Client app callback can decrypt data Bad: Application API is blocked Bad: Internal driver code will block on executing callback if not data is available. Can't integrate with event loop. 5. Provide a generic public stream API to fetch data from the client app. Similar to option 4, but adding an stream object to manage the callback - allows more functionality to be added to public API later without changing restore API contract. Application usage: int appreader(virDomainPtr dom, char *buf, int buflen, void *opaque) { int fd = (int)opaque; return read(fd, buf, buflen) } fd = open(filename); stream = virDataStreamNewReader(appreader, (void*)fd); ret = virDomainRestoreStream(dom, stream); Driver internal usage int virDomainRestoreStreamImpl(virDomainPtr dom, virDataStream stream) { char buf[4096]; int ret; int qemuFD; qemuFD = runQEMUWithIncomingFD(dom); do { ret = virDataStreamRead(dom, buf, sizeof buf); if (ret > 0) write(qemuFD, buf, ret); } while (ret > 0); } Good: Restore functionality all in one driver method Good: Public API is fairly simple Good: Client app callback can decrypt data Bad: Application API is blocked Bad: Internal driver code will block on executing callback if not data is available. Can't integrate with event loop. All the APIs have good and bad points to them, in particular there is a difficult tradeoff between simplicity of the public API application code, vs the internal API implementation code. Some important goals though: - There must be a way to invoke the public API without blocking the application code - The driver must be able to receive data from an encrypted channel, because in libvirtd the FD might be the SASL/TLS socket - Internal driver API should not block on callbacks to app code, since it might need to be polling on another FD concurrently with reading data. - The number of new APIs to support streaming should not increase for each new method needing stream support. Ultimately I think options 3 or 5 are the most promising, because the addition of a generic 'virDataStream' public object makes it easier to manage the processing of the data stream without adding huge numbers of new APIs. Option 3 is a little more cumbersome to use from application code, but it avoids blocking either the client app, or the internal driver. The downside is the driver impl code is split across several methods. With option 5 it is harder to avoid blocking the client and internal driver, since it'd require the driver to integrate with an event loop, but there is no direct FD for the driver to poll() on. The choices made also have possible implications on the design of the remote wire protocol to support these methods. Ignoring the design of the public API, there are a handful of ways to stream data between client and server 1. Invoke primary method eg "restore domain", then feed the data in a sequence of following RPC calls. C --------------> S Restore domain call C <-------------- S Restore domain reply C --------------> S Restore data call 1 C <-------------- S Restore data reply 1 C --------------> S Restore data call 2 C <-------------- S Restore data reply 2 ............... C --------------> S Restore data call n C <-------------- S Restore data reply n C --------------> S Restore data complete C <-------------- S Restore data reply If server wants to abort a restore operation, it'll send an error on one of the replies. 2. Invoke primary method eg "restore domain", then feed the data in a sequence of following async messages. C --------------> S Restore domain call C <-------------- S Restore domain reply C --------------> S Restore data msg 1 C --------------> S Restore data msg 2 ............... C --------------> S Restore data msg n C --------------> S Restore data complete C <-------------- S Restore data reply If server wants to stop the client without closing the socket, it needs an async 'stop' message from server to client. This is prety much same as option 2, but is killing off the explicit replies for each data packet. 3. Invoke primary method eg "restore domain", but require the data to be stream to server, before the reply is sent back C --------------> S Restore domain call C --------------> S Stream data msg 1 C --------------> S Stream data msg 2 ............... C --------------> S Stream data msg n C --------------> S Stream finish msg C <-------------- S Restore domain reply If server wants to stop the client without closing the socket, it simply sends back the 'restore domain reply' message as an error before client finishes sending data, and ignore any further data messages. Options 2 or 3 have potential benefits on links with noticable latency, since they're not blocking the client on synchronous replies from the server. That said, the remote protocol does allow for interleaving of calls & replies, so with Option 1 the client could send multiple data packets without waiting for their replies, and deal with possible delayed error replies. If doing that though, the benefit of having a 1-to-1 call-to-reply ratio is minimal, miht as well go for a n-to-1, call-to-reply approach. It is hard to match public API option 3, with wire protocol option 3, because of the delayed 'restore domain reply' message. The options I'm really thinking are most viable are - Public API 3 + RPC 2 - Public API 5 + RPC 3 Both of these are a little more complex to implement in the libvirtd daemon that Chris' current secure migration patches, but then then also have functional & design benefits Daniel -- |: 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] suspend/hibernate guests on host shutdown
by Gerry Reno 26 May '09

26 May '09

There are times when you just have to reboot the host machine to clear a problem or after some maintenance. The problem right now is that this forces all the guests to go through an entire reboot as well. What would be good is if the host shutdown would invoke a suspend/hibernate of the guests and then restore the guests to their same condition on the reboot. The guests should notice nothing other that a small loss of wallclock time. Regards, Gerry

1 0

[libvirt] HELP: after host upgrade to F11, guest runs extremely slow
by Gerry Reno 26 May '09

26 May '09

I upgraded the host from F10 to F11 (x86_64) with no issues. Now when I start a F10 (i386) guest it runs very very slow. I also see messages on the guest boot console about "clocksource tsc unstable" and some kernel oops. Once it got far enough to start network I logged in and checked the clocksource and it currently is 'acpi_pm' even though the kernel line says clocksource=pit. The available clocksources are acpi_pm, jiffies, and tsc. I do not see 'pit' in the list. How do I fix this issue? Regards, Gerry

4 7