- Devel - libvirt List Archives

[libvirt] libvirt/dnsmasq integration (formatting fixed).
by Simon Kelley 24 Feb '10

24 Feb '10

(apologies for first attempt: I was using a strange mailer.) 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.

1 0

[libvirt] [PATCH] build: avoid non-srcdir "make distcheck" failures (srcdir vs wildcard)
by Jim Meyering 24 Feb '10

24 Feb '10

With this, I'm down to 3 of 43 test failures. >From dd6f73de8afe2bcac80cc0a5b7f60bc83e0e30fc Mon Sep 17 00:00:00 2001 From: Jim Meyering <meyering(a)redhat.com> Date: Wed, 24 Feb 2010 15:18:51 +0100 Subject: [PATCH] build: avoid non-srcdir "make distcheck" failures (srcdir vs wildcard) * tests/xencapsdata/Makefile.am: Use $(wildcard in $(srcdir)-aware manner * tests/xmconfigdata/Makefile.am: Likewise. * tests/xml2sexprdata/Makefile.am: Likewise. --- tests/xencapsdata/Makefile.am | 5 +++-- tests/xmconfigdata/Makefile.am | 4 ++-- tests/xml2sexprdata/Makefile.am | 4 ++-- 3 files changed, 7 insertions(+), 6 deletions(-) diff --git a/tests/xencapsdata/Makefile.am b/tests/xencapsdata/Makefile.am index 7d77575..ed08bc4 100644 --- a/tests/xencapsdata/Makefile.am +++ b/tests/xencapsdata/Makefile.am @@ -1,2 +1,3 @@ - -EXTRA_DIST = $(wildcard *.xml) $(wildcard *.cpuinfo) $(wildcard *.caps) +EXTRA_DIST = \ + $(patsubst $(srcdir)/%,%,$(wildcard \ + $(srcdir)/*.xml $(srcdir)/*.cpuinfo $(srcdir)/*.caps)) diff --git a/tests/xmconfigdata/Makefile.am b/tests/xmconfigdata/Makefile.am index 05201a0..af0cb09 100644 --- a/tests/xmconfigdata/Makefile.am +++ b/tests/xmconfigdata/Makefile.am @@ -1,2 +1,2 @@ - -EXTRA_DIST = $(wildcard *.xml) $(wildcard *.cfg) +EXTRA_DIST = \ + $(patsubst $(srcdir)/%,%,$(wildcard $(srcdir)/*.xml $(srcdir)/*.cfg)) diff --git a/tests/xml2sexprdata/Makefile.am b/tests/xml2sexprdata/Makefile.am index 43117d5..20028bb 100644 --- a/tests/xml2sexprdata/Makefile.am +++ b/tests/xml2sexprdata/Makefile.am @@ -1,2 +1,2 @@ - -EXTRA_DIST = $(wildcard *.xml) $(wildcard *.sexpr) +EXTRA_DIST = \ + $(patsubst $(srcdir)/%,%,$(wildcard $(srcdir)/*.xml $(srcdir)/*.sexpr)) -- 1.7.0.367.g566c3

1 0

[libvirt] [PATCH] build: avoid non-srcdir "make distcheck" failure (test_conf.sh)
by Jim Meyering 24 Feb '10

24 Feb '10

"make distcheck" from a non-srcdir build dir was failing the "test_conf.sh" test TEST: test_conf.sh Failed to process /t/libvirt/.j/libvirt-0.7.6/tests/confdata/*.conf diff: /t/libvirt/.j/libvirt-0.7.6/tests/confdata/*.out: No such file or directory! 1 FAILED due to the fact that tests/confdata/Makefile.am was specifying its files via this: EXTRA_DIST = $(wildcard *.conf) $(wildcard *.out) That led to a distribution tarball that lacked those files, which are required by the test_conf.sh test. Automake normally warns us not to use $(wildcard ...), but we've suppressed the warning. This is one case in which using $(wildcard...) really should be avoided. In a non-srcdir build, each of those expands to the empty string, since the actual files are not in that directory, but in $(srcdir). My first reflex was to just hard-code the 4 file names: -EXTRA_DIST = $(wildcard *.conf) $(wildcard *.out) +EXTRA_DIST = \ + fc4.conf \ + fc4.out \ + libvirtd.conf \ + libvirtd.out But that'd make for more maintenance overhead if/when we add more files. Here it doesn't really matter, but in the next patch you'll see that it really does, in general. So here's a better way: Account for the fact that the files are available in $(srcdir): EXTRA_DIST = \ $(patsubst $(srcdir)/%,%,$(wildcard $(srcdir)/*.out $(srcdir)/*.conf)) >From ecce58c9432e83386f2a9ee275c873775577152b Mon Sep 17 00:00:00 2001 From: Jim Meyering <meyering(a)redhat.com> Date: Wed, 24 Feb 2010 15:01:11 +0100 Subject: [PATCH] build: avoid non-srcdir "make distcheck" failure (test_conf.sh) * tests/confdata/Makefile.am (EXTRA_DIST): Apply $(wildcard... to $(srcdir)/..., and then remove the prefix. --- tests/confdata/Makefile.am | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/tests/confdata/Makefile.am b/tests/confdata/Makefile.am index 5e97605..eaaadbc 100644 --- a/tests/confdata/Makefile.am +++ b/tests/confdata/Makefile.am @@ -1,2 +1,2 @@ - -EXTRA_DIST = $(wildcard *.conf) $(wildcard *.out) +EXTRA_DIST = \ + $(patsubst $(srcdir)/%,%,$(wildcard $(srcdir)/*.out $(srcdir)/*.conf)) -- 1.7.0.367.g566c3

1 0

[libvirt] [PATCH 0/4] maint: improve bootstrap
by Eric Blake 24 Feb '10

24 Feb '10

My biggest motivation in writing this patch series is the fact that I already have the complete gnulib.git on my hard drive, and repeatedly doing shallow clones of gnulib into multiple projects gets expensive in both network traffic and disk space. With this series, it is now possible to do: GNULIB_SRCDIR=/path/to/reference/gnulib.git ./autogen.sh so that the .gnulib subdirectory will exploit git's --reference capabilities rather than re-download all the files from scratch; it also results in less disk usage. The only caveat is that you should make sure that your reference gnulib.git is never rewound beyond contents referred to by a submodule, so that you never risk creating delta objects in the client repositories that would break if the reference module eventually prunes objects rendered unused by the rewind (in practice, this is only a problem if you are prone to pointing the .gnulib submodule to a non-published commit, in order to test out pending changes to gnulib.git, and can be avoided by doing your gnulib development in a different directory than in the reference gnulib.git that only tracks upstream). .gitignore | 20 +- autogen.sh | 21 +- bootstrap | 852 +++++++++++++++++++++++++++++++++++++++++++++----- bootstrap.conf | 145 +++++++++ build-aux/.gitignore | 12 +- po/.gitignore | 26 +- po/Makevars | 41 --- 7 files changed, 967 insertions(+), 150 deletions(-) Eric Blake (4): maint: fix quoting in autogen.sh maint: start factoring bootstrap maint: import modern bootstrap maint: sort .gitignore -- Eric Blake eblake(a)redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org

4 19

[libvirt] RFC: Libvirt FAQ
by Cole Robinson 24 Feb '10

24 Feb '10

Hi all, If you spend enough time on #virt and various virt mailing lists, there are quite a few libvirt questions that come up regularly. So, largely in an effort to save myself and everyone from repeating ourselves, I've put together a libvirt FAQ, found here: http://wiki.libvirt.org/page/FAQ Some of the really common questions that I tried to answer (paraphrased): Q) Where does libvirt store the VM XML? A) You shouldn't really care, use virsh edit/dumpxml/define/undefine Q) How do I access the qemu monitor with libvirt? A) You don't, monitor commands should be provided by libvirt APIs, take a look at this complete list... Q) Why is libvirt messing with iptables? A) Providing NAT based network access for your VMs. If you don't want it, here's how to get rid of it. I've also tried to answer some questions that I don't feel have good straightforward answers in a highly visible place, like: - What is libvirt? - What is some of the major functionality provided by libvirt? - What does it mean when someone says 'I use libvirt'? - Difference between qemu:///system and qemu:///session Feel free to make any additions or mention any feedback. At the very least, please take a glance, so when someone inevitably asks one of these questions, you know to point them to the FAQ, rather than type out an answer. If people think this is useful, we can link to it from the main libvirt.org page, and merge the current static FAQ content linked from the sidebar into the wiki page. Thanks, Cole

2 1

[libvirt] [PATCH 00/10] Various documentation updates
by Cole Robinson 24 Feb '10

24 Feb '10

Over the months I've noticed a few XML pieces that aren't documented, so I finally sat down to hammer these out. Patch #1 is actually a bug I noticed in the process of trying to document the affected attribute. Thanks, Cole Cole Robinson (10): storage: conf: Correctly calculate exabyte unit docs: storage: Document capacity/alloc 'unit' docs: storage: <volume><key> is always generated. docs: storage: Fix backingStore <format> docs docs: storage: Document <auth> element docs: storage: Document SCSI pools docs: storage: Document multipath pools docs: domain: Document <description> element docs: network: Document STP and delay attributes docs: network: Document <domain> element docs/formatdomain.html.in | 7 ++++ docs/formatnetwork.html.in | 12 ++++++- docs/formatstorage.html.in | 34 ++++++++++++++++--- docs/storage.html.in | 76 ++++++++++++++++++++++++++++++++++++++++++++ src/conf/storage_conf.c | 4 +- 5 files changed, 124 insertions(+), 9 deletions(-)

4 18

[libvirt] PATCH [0/1] Filesystem pool formatting
by David Allan 24 Feb '10

24 Feb '10

Here's an updated patch based on the feedback from DV and danpb. I haven't added support for any additional filesystems beyond what mke2fs supports. The addition of additional filesystems is easily done and better as a separate patch. Dave

4 7

[libvirt] [PATCH] virsh.c: avoid leak on OOM error path
by Jim Meyering 23 Feb '10

23 Feb '10

No one really cares if we leak memory while dying, but who knows... freeing that buffer may let us go down more gracefully. FYI, the leak is triggered when virFileReadAll succeeds (it allocates "buffer"), yet xmlNewDoc fails: if (virFileReadAll(from, VIRSH_MAX_XML_FILE, &buffer) < 0) return FALSE; doc = xmlNewDoc(NULL); if (doc == NULL) goto no_memory; >From 03c7a44e3d5b2e7c992bebc98fc8c6a7bf63881e Mon Sep 17 00:00:00 2001 From: Jim Meyering <meyering(a)redhat.com> Date: Fri, 19 Feb 2010 18:03:41 +0100 Subject: [PATCH] virsh.c: avoid leak on OOM error path * tools/virsh.c (cmdCPUBaseline): Also free "buffer" upon OOM. --- tools/virsh.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/tools/virsh.c b/tools/virsh.c index dd916f3..8756a7a 100644 --- a/tools/virsh.c +++ b/tools/virsh.c @@ -7139,6 +7139,7 @@ cleanup: return ret; no_memory: + VIR_FREE(buffer); vshError(ctl, "%s", _("Out of memory")); ret = FALSE; return ret; -- 1.7.0.233.g05e1a

3 6

[libvirt] [PATCH] Create raw storage files with O_DSYNC (again)
by Jiri Denemark 22 Feb '10

22 Feb '10

Recently we introduced O_DYSNC flag when creating raw storage files to avoid filling all disk cache with dirty pages. However, the patch got lost when virStorageBackendCreateRaw was reworked using virFileOperation. Let's use O_DYSNC again. Signed-off-by: Jiri Denemark <jdenemar(a)redhat.com> --- src/storage/storage_backend.c | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/src/storage/storage_backend.c b/src/storage/storage_backend.c index 8b9ed5d..3742493 100644 --- a/src/storage/storage_backend.c +++ b/src/storage/storage_backend.c @@ -356,7 +356,8 @@ virStorageBackendCreateRaw(virConnectPtr conn ATTRIBUTE_UNUSED, goto cleanup; } - if ((createstat = virFileOperation(vol->target.path, O_RDWR | O_CREAT | O_EXCL, + if ((createstat = virFileOperation(vol->target.path, + O_RDWR | O_CREAT | O_EXCL | O_DSYNC, vol->target.perms.mode, vol->target.perms.uid, vol->target.perms.gid, createRawFileOpHook, &hdata, -- 1.7.0

3 3

[libvirt] domain restore race condition
by Laine Stump 22 Feb '10

22 Feb '10

As noted in another message, the problem I was seeing is a race condition in qemudDomainRestore(), not with my modifications to qemudDmainSave(). Here's some discussion about that problem from IRC, with a question at the bottom: > <laine> Does anyone else see a failure of domain restore (immediately > after domain save? I'm very definitely seeing it on my machine with > F12+updates testing and libvirt built from unpatched sources. > <laine> It's very reproduceable - with virsh I do "save domain > filename", then "restore filename" and it pretty much always gives me > a black screen. Then I force shutdown the guest (with virt-manager) > and do "restore filename" again. Tada! It's restored and running! > [...] > <danpb> laine: possible race condition > <danpb> laine: try putting a sleep(10) before the qemuMonitorStartCPUs > in qemuDomainRestore() Dan's suggestion *did* eliminate the failures. > [...] > <danpb> laine: this sounds like the issue with libvirt prematurely > starting execution of the CPUs before QEMU has even started restoring > (or soemthing like that) > <danpb> laine: search the archives for a mail from Charles Duffy on > this subject some time ago > Here's the BZ filed by Charles Duffy https://bugzilla.redhat.com/show_bug.cgi?id=537938 It looks like he's dealing with a race condition earlier in the restore, since his solution was to wait for the migration process to terminate somewhere inside qemudStartVMDaemon(), rather than waiting until qemudStartVMDaemon() was finished (which is what it does now). Since this wait has already been done anyway by the time of Dan's sleep(10) in my test, I don't think Charles' patch would help this situation. So is there something that libvirt can wait on here to ensure proper start? Or is there a problem in qemu? (I'm still running 0.11. I'll also try upgrading to 0.12 and see if there are changes in behavior.)

1 0