- Devel - libvirt List Archives

[libvirt] Compiling on Windows with MinGW/MSYS
by Brecht Sanders 15 Jan '09

15 Jan '09

Hi, It's been a long time since I tried to compile libvirt on Windows using the MinGW/MSYS environment. I tried it again and I have good news and bad news. The good news is thet when I disable support for most things (--without-xen --without-qemu --without-openvz --without-uml --without-test --without-libvirtd --with-remote-pid-file=none --with-init-scripts=none --with-depends --without-sasl --without-polkit) it now builds fine and even the DLL was built (libvirt-0.dll). The bad news is that when I enable Xen support, it now depends on the xenstore library. Unfortunately I wasn't able to build this library on Windows. Is this dependancy necessary? Does anyone know of xenstore on Windows? Regards Brecht Sanders

2 1

[libvirt] [ANN] sVirt v0.30
by James Morris 15 Jan '09

15 Jan '09

This is to announce the release of v0.30 of sVirt, a project to add security labeling support to Linux-based virtualization. Project page: http://www.selinuxproject.org/page/SVirt Download: http://namei.org/svirt/svirt-0.30.tar.bz2 This release is an update in response to feedback received on the v0.20 release, per the discussion thread at: https://www.redhat.com/archives/libvir-list/2008-December/msg00260.html Also see the TODO page: http://selinuxproject.org/page/SVirt/TODO Change log for v0.30: --------------------- * Fix SELinux build configuration * Simplify qemudNodeGetSecurityModel * Add "test" security driver * Fix security driver probe logic * Ensure VIR_CONNECT_RO checked where appropriate * Move security model/doi to last fields in virsh dominfo * Change virDomainSecLabel -> virSecurityLabel * similar change to API calls * Change virDomainSecModel -> virSecurityModel * similar change to API calls * general renaming then of seclabel to security * Use CHECK_LIB/HEADER to detect libselinux (and fix build system in general) * Rename virDomainGetSecModel to virNodeGetSecurityModel * Change -2 error returns to -1 * Use remoteDispatchOOMError() for OOM errors * Create virXPathStringLimit() from virDomainSecLabelDefParseXMLString() Comments welcome. - James -- James Morris <jmorris(a)namei.org>

5 9

[libvirt] [PATCH] Improve xend_get error message
by john.levon＠sun.com 15 Jan '09

15 Jan '09

# HG changeset patch # User john.levon(a)sun.com # Date 1231982481 28800 # Node ID 082e0f7d5de236e69bea177c8d4c4204350144c1 # Parent 1a16d4b76232845091c1f800569ec462860cb1fb Improve xend_get error message Signed-off-by: John Levon <john.levon(a)sun.com> diff --git a/src/xend_internal.c b/src/xend_internal.c --- a/src/xend_internal.c +++ b/src/xend_internal.c @@ -394,7 +394,8 @@ xend_get(virConnectPtr xend, const char if (((ret < 0) || (ret >= 300)) && ((ret != 404) || (!STRPREFIX(path, "/xend/domain/")))) { virXendError(xend, VIR_ERR_GET_FAILED, - _("xend_get: error from xen daemon: %s"), content); + _("%d status from xen daemon: %s:%s"), + ret, path, content); } return ret;

2 1

[libvirt] [PATCH] Invoke PortableXDR's rpcgen if available
by Richard W.M. Jones 15 Jan '09

15 Jan '09

We discovered over the new year that the XDR code in glibc, which was derived from some original Sun code, doesn't have an unambiguously free license[1]. Furthermore the rpcgen in glibc is unmaintained and produces such bad code that we have to run a Perl script over it in order to correct some egregious errors. Sun/glibc rpcgen code also contains all sorts of strange micro-optimizations that were probably good back in 1988, but don't make so much sense now. Also rpcgen was implemented directly in C, so we took this chance to use flex/bison for more accurate and faster parsing. For these reasons we are rewriting the XDR code and the rpcgen tool with a free license[2]. I'm pleased to say that as a result of this effort we've rewritten rpcgen already: http://git.et.redhat.com/?p=portablexdr.git;a=summary To avoid conflicts, the new rpcgen will be installed as 'portable-rpcgen'. The attached patch changes libvirt's configure so that if it finds 'portable-rpcgen' on the path, it uses it in preference to 'rpcgen'. Also attached are the updated remote_protocol.[ch] files (ie. the files which are generated from remote_protocol.x by portable-rpcgen). I'm not suggesting we use these quite yet, because (a) they still generate some warnings, and (b) they need a lot more testing. However I think the patch is safe enough. Rich. [1] For more about this, see this message and the reply: https://www.redhat.com/archives/fedora-legal-list/2008-December/msg00022.ht… [2] LGPLv2+ for the library parts and GPLv2+ for the rpcgen program. -- 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 2

[libvirt] xenUnifiedDomainLookupByName error handling
by John Levon 15 Jan '09

15 Jan '09

We do: 700 /* Not found. */ 701 xenUnifiedError (conn, VIR_ERR_NO_DOMAIN, __FUNCTION__); But: # virsh start domu-defefe 12:09:30.581: error : Domain not found: xenUnifiedDomainLookupByName libvir: Xen error : Domain not found: xenUnifiedDomainLookupByName libvir: Xen error : Domain not found: xenUnifiedDomainLookupByName error: failed to get domain 'domu-defefe' It doesn't seem right to be reporting errors like this. What's the intent? Most of xenUnifiedError() seems to be internal errors, but many of them are just clients doing the wrong thing... regards john

2 2

[libvirt] [PATCH] Fix activeDomainList handling
by john.levon＠sun.com 14 Jan '09

14 Jan '09

# HG changeset patch # User john.levon(a)sun.com # Date 1231958879 28800 # Node ID 1fca4b0dd4c6ab3c0030b4986de6fe5cb7c94631 # Parent 097f5b4497d7ecc5cce14d10559244313d26ce46 Fix activeDomainList handling It must be NULLed out after free()ing. Signed-off-by: John Levon <john.levon(a)sun.com> diff --git a/src/xs_internal.c b/src/xs_internal.c --- a/src/xs_internal.c +++ b/src/xs_internal.c @@ -388,8 +388,10 @@ xenStoreClose(virConnectPtr conn) } xenStoreWatchListFree(priv->xsWatchList); + priv->xsWatchList = NULL; #ifndef PROXY xenUnifiedDomainInfoListFree(activeDomainList); + activeDomainList = NULL; #endif if (priv->xshandle == NULL) return(-1);

4 5

[libvirt] [PATCH] Fix xs_unwatch() to correctly pass the token
by john.levon＠sun.com 14 Jan '09

14 Jan '09

# HG changeset patch # User john.levon(a)sun.com # Date 1231958879 28800 # Node ID 672cdb87a32fb0b275bb7cdc9abb9c2d506ec1b0 # Parent 46dc909bda5b20d11f08d1516f21c05f27b6648f Fix xs_unwatch() to correctly pass the token Signed-off-by: John Levon <john.levon(a)sun.com> diff --git a/src/xs_internal.c b/src/xs_internal.c --- a/src/xs_internal.c +++ b/src/xs_internal.c @@ -1106,7 +1106,7 @@ int xenStoreRemoveWatch(virConnectPtr co if (!xs_unwatch(priv->xshandle, list->watches[i]->path, - list->watches[i]->path)) + list->watches[i]->token)) { DEBUG0("WARNING: Could not remove watch"); /* Not fatal, continue */

2 1

[libvirt] [PATCH] Fix ref-counting for Xen driver event registration
by john.levon＠sun.com 14 Jan '09

14 Jan '09

# HG changeset patch # User john.levon(a)sun.com # Date 1231958879 28800 # Node ID 46dc909bda5b20d11f08d1516f21c05f27b6648f # Parent 1fca4b0dd4c6ab3c0030b4986de6fe5cb7c94631 Fix ref-counting for Xen driver event registration Signed-off-by: John Levon <john.levon(a)sun.com> diff --git a/src/xen_unified.c b/src/xen_unified.c --- a/src/xen_unified.c +++ b/src/xen_unified.c @@ -1359,15 +1359,21 @@ xenUnifiedDomainEventRegister (virConnec void *opaque, void (*freefunc)(void *)) { + int ret; + GET_PRIVATE (conn); if (priv->xsWatch == -1) { xenUnifiedError (conn, VIR_ERR_NO_SUPPORT, __FUNCTION__); return -1; } - conn->refs++; - return virDomainEventCallbackListAdd(conn, priv->domainEventCallbacks, - callback, opaque, freefunc); + ret = virDomainEventCallbackListAdd(conn, priv->domainEventCallbacks, + callback, opaque, freefunc); + + if (ret == 0) + conn->refs++; + + return (ret); } static int @@ -1382,8 +1388,10 @@ xenUnifiedDomainEventDeregister (virConn } ret = virDomainEventCallbackListRemove(conn, priv->domainEventCallbacks, - callback); - virUnrefConnect(conn); + callback); + + if (ret == 0) + virUnrefConnect(conn); return ret; }

3 2

[libvirt] libvirt-qpid and migrate issue
by Ian Main 14 Jan '09

14 Jan '09

Howdy all! So in working with libvirt-qpid, I've come to realize that it imposes a new difficulty in doing migrations. Traditionally you would connect out to each individual libvirt instance from a central location and be able to pass the destination connection pointer to the virDomainMigrate function. However in libvirt-qpids case, since it's running on each physical host, it does not necessarily have access to the destination host due to authentication requirements. So I'd like to discuss possible ways of resolving this issue. I'm not sure how much support libvirt proper wants to extend to allowing this case to work, but I'm hoping we can figure something out that will make everyone happy. I see that in the implementation of virDomainMigrate, it is already split up into prepare and preform functions. I'm thinking that, if agreeable by the libvirt team, it'd be nice to have an API which allowed us to call into destination and source nodes separately. Something like: char * virConnectMigratePrepare(virConnectPtr conn, unsigned long flags, const char *dname); which would set up the destination node to receive a migrating domain and return an xml document containing the information required to perform the migration (host name, port, maybe even capabilities and/or encryption keys in the future etc.), coupled with: int virDomainMigratePerform(virDomainPtr dom, const char *prepare_description, unsigned long bandwidth); which would initiate the transfer of the domain to the destination host. Or something along those lines.. this is just off the top of my head but I wanted to get the discussion going. Note I'm using the same internal names prepare/perform but we can rename them if appropriate. Anyway this would allow us to hook these up in qpid where we have access to both systems and call them in sequence. Let me know what you think. Thanks, Ian

1 0

[libvirt] [PATCH] Implement capabilities for Solaris
by john.levon＠sun.com 14 Jan '09

14 Jan '09

# HG changeset patch # User John Levon <john.levon(a)sun.com> # Date 1231940906 28800 # Node ID a0d98d39955f4f304d318c7c780742ab929eb351 # Parent ddfcba6b4181ab433dce345d66dc399a81c92a3b Implement capabilities for Solaris Use Solaris interfaces to derive the hypervisor capabilities. Signed-off-by: John Levon <john.levon(a)sun.com> diff --git a/src/xen_internal.c b/src/xen_internal.c --- a/src/xen_internal.c +++ b/src/xen_internal.c @@ -35,6 +35,10 @@ #ifdef HAVE_XEN_SYS_PRIVCMD_H #include <xen/sys/privcmd.h> #endif +#endif + +#ifdef __sun +#include <sys/systeminfo.h> #endif /* required for shutdown flags */ @@ -662,11 +666,8 @@ typedef struct xen_op_v2_dom xen_op_v2_d #ifdef __linux__ #define XEN_HYPERVISOR_SOCKET "/proc/xen/privcmd" #define HYPERVISOR_CAPABILITIES "/sys/hypervisor/properties/capabilities" -#define CPUINFO "/proc/cpuinfo" #elif defined(__sun) #define XEN_HYPERVISOR_SOCKET "/dev/xen/privcmd" -#define HYPERVISOR_CAPABILITIES "" -#define CPUINFO "/dev/cpu/self/cpuid" #else #error "unsupported platform" #endif @@ -2123,7 +2124,7 @@ xenHypervisorBuildCapabilities(virConnec xenHypervisorBuildCapabilities(virConnectPtr conn, const char *hostmachine, int host_pae, - char *hvm_type, + const char *hvm_type, struct guest_arch *guest_archs, int nr_guest_archs) { virCapsPtr caps; @@ -2227,8 +2228,126 @@ xenHypervisorBuildCapabilities(virConnec return NULL; } -/** - * xenHypervisorGetCapabilities: +#ifdef __sun + +static int +get_cpu_flags(virConnectPtr conn, const char **hvm, int *pae, int *longmode) +{ + struct { + uint32_t r_eax, r_ebx, r_ecx, r_edx; + } regs; + + char tmpbuf[20]; + int fd = -1; + int ret = 0; + + /* returns -1, errno 22 if in 32-bit mode */ + *longmode = (sysinfo(SI_ARCHITECTURE_64, tmpbuf, 20) != -1); + + if ((fd = open("/dev/cpu/self/cpuid", O_RDONLY)) == -1 || + pread(fd, &regs, sizeof(regs), 0) != sizeof(regs)) { + virXenError(conn, VIR_ERR_SYSTEM_ERROR, + "couldn't read CPU flags: %s", strerror(errno)); + goto out; + } + + *pae = 0; + *hvm = ""; + + if (strncmp((const char *)&regs.r_ebx, "AuthcAMDenti", 12) == 0) { + if (pread(fd, &regs, sizeof (regs), 0x80000001) == sizeof (regs)) { + /* Read secure virtual machine bit (bit 2 of ECX feature ID) */ + if ((regs.r_ecx >> 2) & 1) { + *hvm = "svm"; + } + if ((regs.r_edx >> 6) & 1) + *pae = 1; + } + } else if (strncmp((const char *)&regs.r_ebx, "GenuntelineI", 12) == 0) { + if (pread(fd, &regs, sizeof (regs), 0x00000001) == sizeof (regs)) { + /* Read VMXE feature bit (bit 5 of ECX feature ID) */ + if ((regs.r_ecx >> 5) & 1) + *hvm = "vmx"; + if ((regs.r_edx >> 6) & 1) + *pae = 1; + } + } + + ret = 1; + +out: + if (fd != -1) + close(fd); + return ret; +} + +static virCapsPtr +xenHypervisorMakeCapabilitiesSunOS(virConnectPtr conn) +{ + struct guest_arch guest_arches[32]; + int i = 0; + virCapsPtr caps = NULL; + struct utsname utsname; + int pae, longmode; + const char *hvm; + + if (!get_cpu_flags(conn, &hvm, &pae, &longmode)) + return NULL; + + /* Really, this never fails - look at the man-page. */ + uname (&utsname); + + guest_arches[i].model = "i686"; + guest_arches[i].bits = 32; + guest_arches[i].hvm = 0; + guest_arches[i].pae = pae; + guest_arches[i].nonpae = 1; + guest_arches[i].ia64_be = 0; + i++; + + if (longmode) { + guest_arches[i].model = "x86_64"; + guest_arches[i].bits = 64; + guest_arches[i].hvm = 0; + guest_arches[i].pae = 0; + guest_arches[i].nonpae = 1; + guest_arches[i].ia64_be = 0; + i++; + } + + if (hvm[0] != '\0') { + guest_arches[i].model = "i686"; + guest_arches[i].bits = 32; + guest_arches[i].hvm = 1; + guest_arches[i].pae = pae; + guest_arches[i].nonpae = 1; + guest_arches[i].ia64_be = 0; + i++; + + if (longmode) { + guest_arches[i].model = "x86_64"; + guest_arches[i].bits = 64; + guest_arches[i].hvm = 1; + guest_arches[i].pae = 0; + guest_arches[i].nonpae = 1; + guest_arches[i].ia64_be = 0; + i++; + } + } + + if ((caps = xenHypervisorBuildCapabilities(conn, + utsname.machine, + pae, hvm, + guest_arches, i)) == NULL) + virXenError(NULL, VIR_ERR_NO_MEMORY, NULL); + + return caps; +} + +#endif /* __sun */ + +/** + * xenHypervisorMakeCapabilitiesInternal: * @conn: pointer to the connection block * @cpuinfo: file handle containing /proc/cpuinfo data, or NULL * @capabilities: file handle containing /sys/hypervisor/properties/capabilities data, or NULL @@ -2394,6 +2513,9 @@ virCapsPtr virCapsPtr xenHypervisorMakeCapabilities(virConnectPtr conn) { +#ifdef __sun + return xenHypervisorMakeCapabilitiesSunOS(conn); +#else virCapsPtr caps; FILE *cpuinfo, *capabilities; struct utsname utsname; @@ -2432,6 +2554,7 @@ xenHypervisorMakeCapabilities(virConnect fclose(capabilities); return caps; +#endif /* __sun */ }

4 3