- Devel - libvirt List Archives

[Libvir] storage API and ZFS
by John Levon 18 Oct '07

18 Oct '07

Accidentally deleted your reply Richard, sorry. ZFS 'pools' are aggregates composed of some number of real devices. LVM confuses me so I don't know what they map on to, but the basic idea is that you can carve filesystems out of such pools at will. You can also carve out 'volumes' - these appear as a disk device in /dev/zvol/dsk/poolname/volumename It's the latter that you use in Xen to hold domU root filesystems (or you can use a normal file on whatever file system, or a real device, as desired). What might be tricky is anything that claims to return "space left", depending exactly on what you want it to mean. But (I think) certain LVM setups have similar issues. regards john

2 1

[Libvir] Is it possible to add an interface to intercept the migration process?
by Meng Ran 18 Oct '07

18 Oct '07

Hi All, I'm thinking about if it possible to add an interface to let user specified action to happen on destination during the migration, this should be useful for migrating things that have different paths on source and destination. Allowing specified action(callback) to happen at a time point, e.g., after the config file is transfered and before starting the vm, can bring in a lot of flexibilities considering the migration of devices which are shared but have different paths/views. Giving the dest a chance to recognize these devices and update the config, and then start the vm probably is helpful there. Comment? Thanks, Jack

5 6

[Libvir] CPU pinning of domains at creation time
by Daniel Veillard 18 Oct '07

18 Oct '07

There are a few things I gathered on this issue. This affects NUMA setups, where basically if a domain must be placed on a given cell it is not good to let the hypervisor place it first with its own heuristics and then later migrate it to a different set of CPU, but better to instruct the hypervisor to start said domain on the given set. - For Xen it is possible to instruct the hypervisor by passing (cpus '2,3') in the SExpr where the argument is a list of the physical processors allowed - For KVM I think the standard way would be to select the cpuset using sched_setaffinity() between the fork of the current process and the exec of the qemu process - there is no need (from a NUMA perspective) to do fine grained allocation at that point, as long as the domain can be restricted to a given cell at startup, then if needed virDomainPinVcpu() can be used later to do more precise pinning in order to try to optimize placement - to be able to instruct the hypervisor at creation time adding the information in the domain XML description looks the more natural way (another option would be to force to use virDomainDefineXML, add a call using the resulting virDomainPtr to define the set, and then virDomainCreate would be used to do the actual start) + the good point of having this embedded in the XML is that we still have all informations about the domain settings in the XML, if we want to restart it later + the bad point is that we need to fetch and carry this extra information when doing XML dumps to not loose it for example when manipulating the domain to add or remove devices - extracting a cpuset can still be an heavy operation, for example if using xend on need one RPC per vcpu in the domain, the cpuset being constructed by OR'ing logically all cpumaps used by the vcpus of the domain (though in most case this will be the full map after the first CPU and can be stopped immediately) - for the mapping at the XML level I suggest to use a simple extension to the <vcpu>n</vcpu> and extend it to <vcpu cpuset='2,3'>n</vcpu> with a limited syntax which is just the comma separated list of allowed CPU numbers (if the code actually detects such a cpuset is in effect i.e. in general this won't be added). Internally implementing this should not be too hard, I would probably refactor some of the existing parsing code, provide functions to get the cpuset and the number of physical processors. Does this sounds okay ? Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/

6 13

[Libvir] Problem to compile virt-manager in debian etch
by Marco Sinhoreli 18 Oct '07

18 Oct '07

Hello all, I have a problem to compile the virt-manager in a Debian etch (64 bit version). I got the virt-manager source from mercurial repository. Bellow the output autogen.sh command: ./autogen.sh libtoolize: `config.guess' exists: use `--force' to overwrite libtoolize: `config.sub' exists: use `--force' to overwrite libtoolize: `ltmain.sh' exists: use `--force' to overwrite configure.ac:7: required file `./config.rpath' not found man/Makefile.am:6: `%'-style pattern rules are a GNU make extension pixmaps/Makefile.am:3: wildcard $(srcdir: non-POSIX variable name pixmaps/Makefile.am:3: (probably a GNU make extension) src/Makefile.am:15: wildcard $(srcdir: non-POSIX variable name src/Makefile.am:15: (probably a GNU make extension) src/Makefile.am:35: `%'-style pattern rules are a GNU make extension src/Makefile.am:38: `%'-style pattern rules are a GNU make extension src/Makefile.am:41: `%'-style pattern rules are a GNU make extension src/Makefile.am:44: `%'-style pattern rules are a GNU make extension src/Makefile.am:26: variable `schema_SOURCES' is defined but no program or src/Makefile.am:26: library has `schema' as canonic name (possible typo) src/Makefile.am:11: variable `libexec_SOURCES' is defined but no program or src/Makefile.am:11: library has `libexec' as canonic name (possible typo) src/Makefile.am:4: variable `bin_SOURCES' is defined but no program or src/Makefile.am:4: library has `bin' as canonic name (possible typo) src/Makefile.am:18: variable `desktop_SOURCES' is defined but no program or src/Makefile.am:18: library has `desktop' as canonic name (possible typo) src/Makefile.am:8: variable `python_SOURCES' is defined but no program or src/Makefile.am:8: library has `python' as canonic name (possible typo) src/Makefile.am:22: variable `dbus_SOURCES' is defined but no program or src/Makefile.am:22: library has `dbus' as canonic name (possible typo) src/graphWidgets/Makefile.am:5: `:='-style assignments are not portable src/graphWidgets/Makefile.am:5: shell pkg-config --variable=codegendir pygtk-2.0: non-POSIX variable name src/graphWidgets/Makefile.am:5: (probably a GNU make extension) src/graphWidgets/Makefile.am:6: `:='-style assignments are not portable src/graphWidgets/Makefile.am:6: shell pkg-config --variable=defsdir pygtk-2.0: non-POSIX variable name src/graphWidgets/Makefile.am:6: (probably a GNU make extension) src/virtManager/Makefile.am:3: wildcard $(srcdir: non-POSIX variable name src/virtManager/Makefile.am:3: (probably a GNU make extension) src/virtManager/Makefile.am:7: python_DATA:$(srcdir: non-POSIX variable name src/virtManager/Makefile.am:15: `%'-style pattern rules are a GNU make extension Any idea? regards. -- Marco Sinhoreli

2 4

[Libvir] PATCH: Remote protocol receive+dispatch cleanup
by Daniel P. Berrange 18 Oct '07

18 Oct '07

Dating the from time when we had both the QEMU & generic remote protocol there are tiny qemud/protocol.{x,c,h} files basically just containing one struct for the packet header. This is more or less duplicated in the remote protocol & with a few small tweaks can simplify this code. So the attached patch removes the protocol.{x,c,h} files. The qemud.c file in the 'receive header' branch now merely reads a single 4 byte unsigned int to discover the packet length. The rest of the packet is dealt with in the 'receive payload' branch. It immediately dispatches to the remote program. There is no wire format change here - shouuld just be code cleanup a/qemud/protocol.c | 17 -------------- a/qemud/protocol.h | 39 -------------------------------- a/qemud/protocol.x | 40 --------------------------------- qemud/Makefile.am | 5 ---- qemud/internal.h | 1 qemud/qemud.c | 57 +++++++++++++++--------------------------------- qemud/remote.c | 2 - qemud/remote_protocol.h | 1 qemud/remote_protocol.x | 3 ++ src/Makefile.am | 1 10 files changed, 24 insertions(+), 142 deletions(-) Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|

2 1

[Libvir] BuildRequires check
by Jim Meyering 17 Oct '07

17 Oct '07

Hi, I tried to configure libvirt from cvs on a just-built rawhide system and it failed like this, since I hadn't installed the "check" package, which defines PKG_CHECK_EXISTS: checking for init script flavor... redhat checking for iptables... /sbin/iptables ./configure: line 12187: syntax error near unexpected token `libxml-2.0,LIBXML_FOUND=yes' ./configure: line 12187: ` PKG_CHECK_EXISTS(libxml-2.0,LIBXML_FOUND=yes)' Here's a fix: 2007-10-17 Jim Meyering <meyering(a)redhat.com> * libvirt.spec.in (BuildRequires): Add "check". Index: libvirt.spec.in =================================================================== RCS file: /data/cvs/libvirt/libvirt.spec.in,v retrieving revision 1.65 diff -u -p -r1.65 libvirt.spec.in --- libvirt.spec.in 12 Oct 2007 19:54:15 -0000 1.65 +++ libvirt.spec.in 17 Oct 2007 10:03:22 -0000 @@ -16,6 +16,7 @@ Requires: ncurses Requires: dnsmasq Requires: bridge-utils Requires: iptables +BuildRequires: check BuildRequires: xen-devel BuildRequires: libxml2-devel BuildRequires: readline-devel

2 2

[Libvir] "make check" requires qemu
by Jim Meyering 17 Oct '07

17 Oct '07

So perhaps libvirt should BuildRequire qemu, too? When I ran "make check" on a system without qemu, I got lots of failures: ... QEMU XML-2-ARGV Misc ACPI ... FAILED libvir: QEMU error : Cannot find QEMU binary /usr/bin/qemu: No such file or directory QEMU XML-2-ARGV Misc No Reboot ... FAILED libvir: QEMU error : Cannot find QEMU binary /usr/bin/qemu: No such file or directory QEMU XML-2-ARGV Net User ... FAILED FAIL: qemuxml2argvtest Here's a patch: 2007-10-17 Jim Meyering <meyering(a)redhat.com> * libvirt.spec.in (BuildRequires): Add "qemu". Index: libvirt.spec.in =================================================================== RCS file: /data/cvs/libvirt/libvirt.spec.in,v retrieving revision 1.65 diff -u -p -r1.65 libvirt.spec.in --- libvirt.spec.in 12 Oct 2007 19:54:15 -0000 1.65 +++ libvirt.spec.in 17 Oct 2007 10:11:33 -0000 @@ -25,6 +25,7 @@ BuildRequires: gnutls-devel BuildRequires: avahi-devel BuildRequires: dnsmasq BuildRequires: bridge-utils +BuildRequires: qemu Obsoletes: libvir ExclusiveArch: i386 x86_64 ia64

2 1

[Libvir] sexpr_get: add __printf__ attribute
by Jim Meyering 17 Oct '07

17 Oct '07

I noticed sexpr_get takes a printf-style format, yet it is declared with no printf attribute. Here's the fix: 2007-10-17 Jim Meyering <meyering(a)redhat.com> * src/xend_internal.c (sexpr_get): Declare with gcc's printf attribute. Index: src/xend_internal.c =================================================================== RCS file: /data/cvs/libvirt/src/xend_internal.c,v retrieving revision 1.148 diff -u -p -r1.148 xend_internal.c --- src/xend_internal.c 15 Oct 2007 21:38:56 -0000 1.148 +++ src/xend_internal.c 17 Oct 2007 08:29:26 -0000 @@ -692,6 +692,10 @@ xend_op(virConnectPtr xend, const char * */ static struct sexpr * sexpr_get(virConnectPtr xend, const char *fmt, ...) + __attribute__ ((__format__ (__printf__, 2, 3))); + +static struct sexpr * +sexpr_get(virConnectPtr xend, const char *fmt, ...) { char buffer[4096]; char path[1024];

2 2

[Libvir] FYI: bug in remote code
by Mark Johnson 16 Oct '07

16 Oct '07

I ran into a bug in the remote code... I was doing # virsh -c xen_tcp://<ip_addr>/ It you don't have qemu compiled in, you will hang in in libvirtd in do_open() res = virNetworkDriverTab[i]->open (ret, name, flags); when trying to open the remote network driver. Usually qemu returns success and you fall out of the loop before you call this (which is why you won't see it with qemu support built in). You hang in libvirtd trying to read from the libvirtd PF_UNIX socket. You read from the socket because you hit this code path in doRemoteOpen() if (!uri->server && !transport_str) { if (flags & VIR_DRV_OPEN_REMOTE_UNIX) { transport = trans_unix; No idea what it should be doing? :-) I reproduced it on todays CVS bits on FC7 by commenting out qemu's network register.. int qemudRegister(void) { virRegisterDriver(&qemuDriver); /* virRegisterNetworkDriver(&qemuNetworkDriver); */ virRegisterStateDriver(&qemuStateDriver); return 0; } MRJ

2 4

[Libvir] [for discussion only] virDomainBlockPeek preliminary implementation
by Richard W.M. Jones 16 Oct '07

16 Oct '07

The attached patch (for discussion only) adds a virDomainBlockPeek call, allowing callers to peek into the block devices of domains. +/** + * virDomainBlockPeek: + * @dom: pointer to the domain object + * @path: path to the block device + * @offset: offset within block device + * @size: size to read + * @buffer: return buffer (must be at least size bytes) + * + * This function allows you to read the contents of a domain's + * disk device. + * + * Typical uses for this are to determine if the domain has + * written a Master Boot Record (indicating that the domain + * has completed installation), or to try to work out the state + * of the domain's filesystems. + * + * (Note that in the local case you might try to open the + * block device or file directly, but that won't work in the + * remote case, nor if you don't have sufficient permission. + * Hence the need for this call). + * + * 'path' must be a device or file corresponding to the domain. + * In other words it must be the precise string returned in + * a <disk><source dev='...'/></disk> from + * virDomainGetXMLDesc. + * + * 'offset' and 'size' represent an area which must lie entirely + * within the device or file. 'size' may be 0 to test if the + * call would succeed. + * + * 'buffer' is the return buffer and must be at least 'size' bytes. + * + * Returns: 0 in case of success or -1 in case of failure. + */ +int +virDomainBlockPeek (virDomainPtr dom, + const char *path, + long long offset /* really 64 bits */, + size_t size, + void *buffer) The patch doesn't include: - remote - qemu - Xen < 3.0.3 inactive domains I will add these if I get favourable feedback. Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903

2 3