[libvirt] [PATCH 1/4] Addition of XenAPI support to libvirt
by Sharadha Prabhakar (3P)
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....
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 \
14 years, 2 months
[libvirt] debugging daemon-conf failure
by Eric Blake
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
14 years, 2 months
[libvirt] [PATCH 0/1] - for comments/help only, nearly working root-squash-domain-save
by Laine Stump
(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.
14 years, 2 months
[libvirt] [PATCH 0/1] Support domain restore from root-squash NFS
by Laine Stump
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 ;-)
14 years, 2 months
[libvirt] [PATCH 1/2] Use AC_SEARCH_LIBS to find the library to use for dlopen().
by Diego Elio Pettenò
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
14 years, 2 months
[libvirt] Update on 0.7.7 release schedule
by Daniel Veillard
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/
14 years, 2 months
[libvirt] [PATCH 0/6] Add more guest clock mods
by Daniel P. Berrange
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.
14 years, 2 months
[libvirt] [PATCH 0/6] SCSI-Disk-Hotremove
by Wolfgang Mauerer
[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(-)
14 years, 2 months
[libvirt] libvirt/dnsmasq integration.
by Simon Kelley
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.
14 years, 2 months
[libvirt] Problems with attach-device/detach-device using libvirt 0.7.6
by Rolf Eike Beer
Hi,
first a short summary of what the situation is:
I'm running qemu 0.12.2, libvirt 0.7.6 on a E5520 based machine with kernel
2.6.33. I also tried 2.6.32.7 as I was using that before and still had the old
kernel around, but kernel version doesn't matter AFAICT. The host is a gentoo
AMD64 installation, the client is SuSE 11.0 (both 32 and 64 bit tested).
This system is our machine to run automated PCIe device tests on, so the idea
is to move PCIe devices from the host to different vms, run some testcases
there and then move them away again. This has worked before (I'm not
absolutely sure, but I would bet a bit of money that it was libvirt 0.7.5).
So, what I'm going to do is simply
virsh # attach-device suse11.0-AMD64 dev-pci-AD1-CL.xml
Device attached successfully
virsh # detach-device suse11.0-AMD64 dev-pci-AD1-CL.xml
Device detached successfully
This is just was I expect and what I now get with the two patches attached.
The original situation was somewhat different (i.e. broken):
-first I got complains in the log stating:
tried to create id "(null)" twice for "device"
Well, adding two devices with the same id is bad, and if that id is a NULL
pointer anyway IMHO it's better to not pass the parameter at all. That's what
the "null-pci-id" patch does.
-next, detaching failed. I found out that the command sent to qemu was "
pci_del pci_addr=fc67add0:7f41:fe38b65a" which is obviously bogus. After some
hours of digging through the command stack up and down I found that it was the
memcpy addressed in the "pci_memcpy" patch.
When the device is attached qemu just replies with an empty string. Afterwards
from the guestAddr the address of the PCI device in the client is copied back
to the info structure. Too bad that this structure was never initialized to
anything useful (at least not for me). When I kick out the memcpy() everything
works fine.
Configuration files of one device and one guest are attached, the others look
similar.
Note: when the client PCI id is passed to qemu anyway it would be cool if that
could be specified in the device XML. For USB devices, too.
Eike
Please keep me CC'ed as I'm not on the list.
14 years, 2 months
