February 2010 - Devel - libvirt List Archives

[libvirt] [PATCH] Fix generation of floppy disk arg for QEMU's -global arg
by Daniel P. Berrange 11 Mar '10

11 Mar '10

* src/qemu/qemu_conf.c: Fix ',' vs '.' typo in floppy disk arg --- src/qemu/qemu_conf.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/qemu/qemu_conf.c b/src/qemu/qemu_conf.c index fb06cd0..beb4386 100644 --- a/src/qemu/qemu_conf.c +++ b/src/qemu/qemu_conf.c @@ -3521,7 +3521,7 @@ int qemudBuildCommandLine(virConnectPtr conn, char *fdc; ADD_ARG_LIT("-global"); - if (virAsprintf(&fdc, "isa-fdc,drive%c=drive-%s", + if (virAsprintf(&fdc, "isa-fdc.drive%c=drive-%s", disk->info.addr.drive.unit ? 'B' : 'A', disk->info.alias) < 0) goto no_memory; -- 1.6.6

3 2

[libvirt] [PATCH 1/4] Addition of XenAPI support to libvirt
by Sharadha Prabhakar (3P) 09 Mar '10

09 Mar '10

Resending patches in plain text. ~/Libvirt/Src/Makefile.am contains some changes suggested by Daniel Veillard. This is a patch to add XenAPI driver support for libvirt version 0.7.6. XenAPI can be used against XenCloud platform and managed through virsh and virt-manger. This patch supports domain related APIs in libvirt. It is possible to get domain information, list active and inactive domains, get Domain XML configuration and Start/stop/pause/shutdown/destroy VMs. There will be more patches after this review to support more libvirt APIs and add remote storage support to XenAPI. In order to run this patch you would require libxenserver library. Libxenserver library can be downloaded from http://community.citrix.com/download/attachments/38633496/libxenserver-5.5.… Copy the libxenserver folder in the same directory level as libvirt. The XenCloud platform can be downloaded from http://xen.org/products/cloudxen.html diff -ur ./libvirt_org/configure.ac ./libvirt/configure.ac --- ./libvirt_org/configure.ac 2010-02-17 17:39:21.000000000 +0000 +++ ./libvirt/configure.ac 2010-02-18 11:51:29.000000000 +0000 @@ -219,6 +219,8 @@ AC_HELP_STRING([--with-libssh2=@<:@PFX@:>@], [libssh2 location @<:@default=/usr/local/lib@:>@]),[],[with_libssh2=yes]) AC_ARG_WITH([phyp], AC_HELP_STRING([--with-phyp], [add PHYP support @<:@default=check@:>@]),[],[with_phyp=check]) +AC_ARG_WITH([xenapi], + AC_HELP_STRING([--with-xenapi], [add XenAPI support @<:@default=yes@:>@]),[],[with_xenapi=check]) AC_ARG_WITH([vbox], AC_HELP_STRING([--with-vbox], [add VirtualBox support @<:@default=yes@:>@]),[],[with_vbox=yes]) AC_ARG_WITH([lxc], @@ -307,6 +309,11 @@ fi AM_CONDITIONAL([WITH_VBOX], [test "$with_vbox" = "yes"]) +if test "$with_xenapi" = "yes"; then + AC_DEFINE_UNQUOTED([WITH_XENAPI], 1, [whether XenAPI driver is enabled]) +fi +AM_CONDITIONAL([WITH_XENAPI], [test "$with_xenapi" = "yes"]) + if test "$with_libvirtd" = "no" ; then with_qemu=no fi @@ -1894,6 +1901,7 @@ AC_MSG_NOTICE([ UML: $with_uml]) AC_MSG_NOTICE([ OpenVZ: $with_openvz]) AC_MSG_NOTICE([ VBox: $with_vbox]) +AC_MSG_NOTICE([ XenAPI: $with_xenapi]) AC_MSG_NOTICE([ LXC: $with_lxc]) AC_MSG_NOTICE([ PHYP: $with_phyp]) AC_MSG_NOTICE([ ONE: $with_one]) Binary files ./libvirt_org/daemon/.libs/libvirtd and ./libvirt/daemon/.libs/libvirtd differ Only in ./libvirt_org/daemon/.libs: lt-libvirtd --- ./libvirt_org/src/Makefile.am 2010-02-17 17:38:13.000000000 +0000 +++ ./libvirt/src/Makefile.am 2010-02-19 10:55:51.000000000 +0000 @@ -3,12 +3,19 @@ # No libraries with the exception of LIBXML should be listed # here. List them against the individual XXX_la_CFLAGS targets # that actually use them + +XENAPI_CFLAGS = -I@top_srcdir@/../libxenserver/include + INCLUDES = \ -I$(top_srcdir)/gnulib/lib \ -I../gnulib/lib \ -I../include \ + -I/usr/include \ -I@top_srcdir@/src/util \ + -I@top_srcdir@/src \ + -I@top_srcdir@/src/xenapi \ -I@top_srcdir@/include \ + $(XENAPI_CFLAGS) \ $(DRIVER_MODULE_CFLAGS) \ $(LIBXML_CFLAGS) \ -DLIBDIR=\""$(libdir)"\" \ @@ -42,6 +49,9 @@ augeastestdir = $(datadir)/augeas/lenses/tests augeastest_DATA = +XENAPI_LIBS = @top_srcdir@/../libxenserver/libxenserver.so +XENAPI_LDFLAGS = -L@top_srcdir@/../libxenserver/ -lxenserver + # These files are not related to driver APIs. Simply generic # helper APIs for various purposes UTIL_SOURCES = \ @@ -205,6 +215,10 @@ qemu/qemu_security_dac.h \ qemu/qemu_security_dac.c +XENAPI_DRIVER_SOURCES = \ + xenapi/xenapi_driver.c xenapi/xenapi_driver.h \ + xenapi/xenapi_utils.c xenapi/xenapi_utils.h + UML_DRIVER_SOURCES = \ uml/uml_conf.c uml/uml_conf.h \ uml/uml_driver.c uml/uml_driver.h @@ -466,6 +480,28 @@ libvirt_driver_vbox_la_SOURCES = $(VBOX_DRIVER_SOURCES) endif +if WITH_XENAPI +if WITH_DRIVER_MODULES +mod_LTLIBRARIES += libvirt_driver_xenapi.la +else +noinst_LTLIBRARIES += libvirt_driver_xenapi.la + +libvirt_la_LIBADD += libvirt_driver_xenapi.la \ + $(XENAPI_LIBS) +endif +#libvirt_driver_xenapi_la_LIBADD = $(XENAPI_LIBS) +libvirt_driver_xenapi_la_CFLAGS = $(XEN_CFLAGS) \ + $(LIBXML_CFLAGS) \ + $(shell curl-config --cflags) +libvirt_driver_xenapi_la_LDFLAGS = $(XENAPI_LDFLAGS) -g $(LIBXML_LIBS) \ + $(shell curl-config --libs) + +if WITH_DRIVER_MODULES +libvirt_driver_xenapi_la_LDFLAGS += -module -avoid-version +endif +libvirt_driver_xenapi_la_SOURCES = $(XENAPI_DRIVER_SOURCES) +endif + if WITH_QEMU if WITH_DRIVER_MODULES mod_LTLIBRARIES += libvirt_driver_qemu.la @@ -722,6 +758,7 @@ $(OPENVZ_DRIVER_SOURCES) \ $(PHYP_DRIVER_SOURCES) \ $(VBOX_DRIVER_SOURCES) \ + $(XENAPI_DRIVER_SOURCES) \ $(ESX_DRIVER_SOURCES) \ $(NETWORK_DRIVER_SOURCES) \ $(INTERFACE_DRIVER_SOURCES) \ diff -ur ./libvirt_org/tools/Makefile.am ./libvirt/tools/Makefile.am --- ./libvirt_org/tools/Makefile.am 2010-02-17 17:36:13.000000000 +0000 +++ ./libvirt/tools/Makefile.am 2010-02-18 11:56:30.000000000 +0000 @@ -40,7 +40,8 @@ $(WARN_CFLAGS) \ ../src/libvirt.la \ ../gnulib/lib/libgnu.la \ - $(VIRSH_LIBS) + $(VIRSH_LIBS) \ + ../../libxenserver/libxenserver.so virsh_CFLAGS = \ -I$(top_srcdir)/gnulib/lib -I../gnulib/lib \ -I../include -I$(top_srcdir)/include \

5 24

[libvirt] debugging daemon-conf failure
by Eric Blake 09 Mar '10

09 Mar '10

Ever since I first started playing with libvirt last month, 'make check' has been failing for me on the same test: $ VIR_TEST_DEBUG=2 make -C tests check TESTS=daemon-conf ... 1) corrupted config listen_tls ... OK 2) corrupted config listen_tcp ... OK 3) corrupted config tls_port ... OK 4) corrupted config tcp_port ... OK 5) corrupted config listen_addr ... OK 6) corrupted config mdns_adv ... FAILED 7) corrupted config mdns_name ... FAILED 8) corrupted config unix_sock_group ... FAILED 9) corrupted config unix_sock_ro_perms ... FAILED 10) corrupted config unix_sock_rw_perms ... FAILED 11) corrupted config unix_sock_dir ... FAILED 12) corrupted config auth_unix_ro ... OK 13) corrupted config auth_unix_rw ... OK 14) corrupted config auth_tcp ... OK 15) corrupted config auth_tls ... FAILED 16) corrupted config key_file ... FAILED 17) corrupted config cert_file ... FAILED 18) corrupted config ca_file ... FAILED 19) corrupted config crl_file ... FAILED 20) corrupted config tls_no_verify_certificate ... FAILED 21) corrupted config tls_allowed_dn_list ... FAILED 22) corrupted config sasl_allowed_username_list ... FAILED 23) corrupted config max_clients ... FAILED 24) corrupted config min_workers ... FAILED 25) corrupted config max_workers ... FAILED 26) corrupted config max_requests ... FAILED 27) corrupted config max_client_requests ... FAILED ./daemon-conf: line 81: kill: (3145) - No such process 28) valid config file (sleeping 2 seconds) ... FAILED FAIL: daemon-conf ================== 1 of 1 test failed ================== Any hints on what I should do to help find the root cause for the failure? Am I missing a package? Does the test need to be made more robust to skip if a prereq is missing? -- Eric Blake eblake(a)redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org

4 7

[libvirt] [PATCH 0/1] - for comments/help only, nearly working root-squash-domain-save
by Laine Stump 03 Mar '10

03 Mar '10

(This patch requires that you first apply the virFileOperation patches that I sent to the list yesterday.) I'm hoping someone else's keen eye can see what I'm failing to see here. The patch following this message makes domain save "work" on root-squash NFS (both the libvirt header and the QEMU state are saved to the file), but the files that it saves don't restore properly, even when simply saving to a local directory w/o forking - the guest screen comes up black, or reboots immediately, or some other such thing. I've looked at the data files and the code, and can't see what difference is causing this - at least the header written by libvirt seems to be the same, and the part written by qemu starts in the same place and looks similar. If anyone's got an idea, please let me know! I'd like to get this figured out and a working patch submitted before the day is done.

3 6

[libvirt] [PATCH 0/1] Support domain restore from root-squash NFS
by Laine Stump 03 Mar '10

03 Mar '10

Most of the explanation is in the commit message with the patch proper. When reveiwing please take pains to point out any places where I may not be diligent enough cleaning up loose ends, especially in terms of assuring that the child process always terminates properly no matter what happens. The (unrelated) race condition in qemudDomainRestore() remains - I solved it locally by putting a sleep(10) just before qemuMonitorStartCPUs(), but it needs something with a bit higher comfort factor ;-)

5 11

[libvirt] [PATCH 1/2] Use AC_SEARCH_LIBS to find the library to use for dlopen().
by Diego Elio Pettenò 03 Mar '10

03 Mar '10

Instead of using AC_CHECK_LIB and hardcoding -ldl, search for the library needed to get dlopen() and then use the cached value. --- configure.ac | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/configure.ac b/configure.ac index 5b1eb5f..a3f28c4 100644 --- a/configure.ac +++ b/configure.ac @@ -1705,7 +1705,7 @@ if test "x$with_driver_modules" = "xyes" ; then old_libs="$LIBS" fail=0 AC_CHECK_HEADER([dlfcn.h],[],[fail=1]) - AC_CHECK_LIB([dl], [dlopen],[],[fail=1]) + AC_SEARCH_LIBS([dlopen], [dl], [], [fail=1]) test $fail = 1 && AC_MSG_ERROR([You must have dlfcn.h / dlopen() support to build driver modules]) @@ -1714,7 +1714,7 @@ if test "x$with_driver_modules" = "xyes" ; then fi if test "$with_driver_modules" = "yes"; then DRIVER_MODULES_CFLAGS="-export-dynamic" - DRIVER_MODULES_LIBS="-ldl" + DRIVER_MODULES_LIBS="$ac_cv_search_dlopen" AC_DEFINE_UNQUOTED([WITH_DRIVER_MODULES], 1, [whether to build drivers as modules]) fi AM_CONDITIONAL([WITH_DRIVER_MODULES], [test "$with_driver_modules" != "no"]) -- 1.7.0

4 5

[libvirt] Update on 0.7.7 release schedule
by Daniel Veillard 02 Mar '10

02 Mar '10

As you can have noticed we still have patches queued up and not yet pushed, plus added a new interface yesterday. I'm travelling all of this week, so my bandwidth is limited. Plus February is a short month and we skipped a bit for 0.7.6, so time to validate and push patches has been shorter than usual. So I suggest to still push patches today and tomorrow for features, and start the freeze on thusday evening, and delaying the release to mid of next week. But still try to keep the expected cycle for 0.7.8 with a freeze on March 19 and a release on the 26 :-) Hope this doesn't disrupt other people schedules ! Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel(a)veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/

1 1

[libvirt] [PATCH 0/6] Add more guest clock mods
by Daniel P. Berrange 02 Mar '10

02 Mar '10

An update of http://www.redhat.com/archives/libvir-list/2010-February/msg00104.html The two current options are: <clock offset='utc'/> <clock offset='localtime'/> This introduces a way to set a specific timezone <clock offset='timezone' timezone='Europe/Paris'/> And a way to set a completely arbitrary time, by giving the number of seconds offset from UTC. <clock offset='variable' adjustment='123456'/> Since last time, I removed the 'timezone' attribute from the existing offset='localtime' option, and introduced the new explicit option offset='timezone'. That way we don't change semantics of the existing options at all.

4 22

[libvirt] [PATCH 0/6] SCSI-Disk-Hotremove
by Wolfgang Mauerer 02 Mar '10

02 Mar '10

[PATCH 0/6] SCSI-Disk-Hotremove This series adds support for hot-removing SCSI disks when qemu supports the drive/device model. It also contains fixes for SCSI controller hotremoval and the build process. Cheers, Wolfgang --- Siemens AG, Corporate Technology, CT T TC 4 Corporate Competence Centre Embedded Linux Makefile.am | 7 +-- qemu/qemu_driver.c | 97 +++++++++++++++++++++++++++++++++++++++++++---- qemu/qemu_monitor.c | 13 ++++++ qemu/qemu_monitor.h | 3 + qemu/qemu_monitor_json.c | 24 +++++++++++ qemu/qemu_monitor_json.h | 3 + qemu/qemu_monitor_text.c | 40 +++++++++++++++++++ qemu/qemu_monitor_text.h | 3 + 8 files changed, 180 insertions(+), 10 deletions(-)

4 19

[libvirt] libvirt/dnsmasq integration.
by Simon Kelley 01 Mar '10

01 Mar '10

As the principal maintainer of dnsmasq, I'm seeing increasing reports of problems on systems which run both dnsmasq and libvirt. I'm fairly sure I understand what's going on in these cases, and I have a few proposals for changes in libvir and dnsmasq that should fix things. The problem is that libvirt runs a private instance of dnsmasq: on machines which are also running a "system" dnsmasq daemon, this can cause problems. Some background: dnsmasq can run in two modes. Default mode: dnsmasq binds the wildcard address and does network magic to determine which interface request packets actually come from, so that the results can be sent back with the correct source address. This has the advantage that network interfaces can come and go and change IP address and dnsmasq will keep working. It's possible to restrict dnsmasq to only reply to requests on some interfaces; requests from other interfaces will be read by dnsmasq and then silently dropped. Telling dnsmasq to use an interface which doesn't exist but might in the future will result in a logged warning, but dnsmasq will still start and when the interface comes up it will work. Bind-interfaces mode: This is the traditional way to do UDP servers. At startup dnsmasq enumerates all the extant interfaces and then opens a socket for each one, listening on the interfaces's IP address. Interfaces may be skipped if excluded by the --interface and --except-interface flags, and any interface specified in --interface which doesn't exist at start-up will generate a fatal error. In almost all cases, default mode is better: --bind-interfaces is only there to cope with old platforms which don't support enough socket options to do default mode. The only time when --bind-interfaces works better is when it's desirable to run more than one instance of dnsmasq or have dnsmasq co-exist with another DNS server. This is not possible in default mode, but it does work in bind-interfaces mode, providing than _all_ instances of dnsmasq are in bind-interfaces mode, and that they listen on a disjoint set of interfaces. Therefore, to allow multiple dnsmasq instances libvirt's private dnsmasq instance is started in bind-interfaces mode: that forces one of the dnsmasq instances to do bind-interfaces. Many of the Linux distibution dnsmasq packages have now implemented an /etc/dnsmasq.d directory where configuration fragments can be dropped. Their libvirt packages are putting a file there which contains a bind-interfaces command, so that the "system" dnsmasq is automatically forced into the same mode, and the two can co-exist. This works, sort-of, but there some disadvantages. Installing libvirt drops the configuration change for the system dnsmasq, but the packages frequently don't restart the system daemon, so that things transiently fail until everything has rebooted. Much worse, the system dnsmasq is forced into bind-interfaces mode and then service to transient interfaces (usb, ad-hoc wifi) no longer works, or, because those interfaces are mentioned in the dnsmasq configuration, dnsmasq now fails at start-up when the interfaces don't exist. I don't think there is a solution to this problem wholly within dnsmasq: the nature of the BSD-sockets universe means that there never be two instances of dnsmasq without bind-interfaces, and it's, at best, difficult to get round the limitations of that WRT transient network interfaces. There is, an alternative solution, which would involve changes to both dnsmasq, libvirt and their packaging. Hence this mail. My proposal is to get rid of the necessity for two dnsmasq instances. Libvirt should check for the existance of a "system" dnsmasq and, if the system daemon exists, libvirt should drop the required configuration into /etc/dnsmasq.d and then restart it. If the system daemon is not installed or enabled, libvirt can start a private instance as now. The difficulty with this scheme is that libvirt needs to create some configuration which enables the services it needs on the virtual network without disturbing, or being disturbed by, whatever configuration exists for the system daemon. That's not currently possible, but it can be made possible. I'm assuming that libvirt needs to provide a set of IP address / MAC address mappings, and range of IP addresses on a virtual network. It needs DHCP and DNS service on the virtual network. The dhcp-host IP/MAC mappings are a non-problem: they will be ignored for any other subnet where the IP addresses don't fit, and any other dhcp-hosts in the system configuration will be similarly ignored for DHCP on the virtual network subnet. The dhcp-range is more of a problem. Service to particular networks in dnsmasq is controlled by interface=<interface name"> lines in the configuration. If there are none of these, service is provided to all interfaces. If they exist, service is limited to the interfaces specified. The existence of any dhcp-range line in dnsmasq's configuration enables the DHCP server for any subnet unless explicitly limited to particular interfaces. So a default dnsmasq installation, (with no interface=<interface>) which provides DNS everywhere but DHCP nowhere would be turned into one which provided DHCP on every interface by libvirt adding a dhcp-range. Since there wouldn't be a suitable DHCP range for most subnets, this would only result in logged errors, but it is still not good. Worse, there's no good answer to the question 'should libvirt include interface=virt0"' in the configuration it supplies? If it does, then the "enable DHCP on all interfaces" problem is solved, but a default system configuration with no interface declaration is transformed from one which provides DNS everywhere to one which provides DNS only to the virtual interface. If libvirt doesn't provide "interface=virt0" and the system configuration includes interface declarations, then there will be no DNS or DHCP service to the virtual network. To solve this, I propose to add an optional interface name to the dhcp-range declaration. The semantics of this would be rather odd, but solve the problem perfectly. 1) for DHCP, if any other dhcp-range exists _without_ an interface name, them the interface name is ignored and and things behave as before, otherwise DHCP is only provided to interfaces mentioned in dhcp-range declarations. 2) for DNS, if there are no interface declarations, things work as before. If there are interface declarations, the interfaces mentioned in dhcp-ranges are added to the set which get DNS service. With these rules, it should be possible for libvirt to drop eg dhcp-range=interface:virt0,192.168.0.1,192.168.0.240 into the configuration of the system dnsmasq and get DHCP and DNS service for virt0, irrespective of any other configuration in the system dnsmasq, and doing so shouldn't affect the services supplied elsewhere. The code in libvirt to make this work looks like this: echo dhcp-range=interface:virt0,<ip range> >>/etc/dnsmasq.d/libvirt if <system dnsmasq is not installed or not enabled> dnsmasq --interface=virt0\ --bind-interfaces --conf-file=/etc/dnsmasq.d/libvirt else /etc/init.d/dnsmasq restart (The --bind-interfaces in the private-dnsmasq instance keeps dnsmasq from clashing with other nameservers eg BIND which may be running.) The system dnsmasq package has to ensure that /etc/dnsmasq.d is read for configuration fragments, and the dnsmasq package and the libvirt package will have to co-operate to manage transitions between private and system dnsmasq mode caused by package installation or removal. Does that make sense? It's a long and involved explanation to come to cold. I fear I may have over-simplified what libvirt is doing with dnsmasq, in which case please enlighten me and I'll modify my scheme to take that into account. If this looks good I can easily have the necessary dnsmasq changes in the next release. Cheers, Simon.

3 8