- Devel - libvirt List Archives

[libvirt] [PATCH] Don't log qemu monitor output from blockStats
by Cole Robinson 02 Mar '09

02 Mar '09

The attached patch changes the qemu driver blockStats command to not log qemu monitor output. virt-manager offers an option to continually poll VM disk stats, and if the app is left running for a while with many VMs, this can make the logs huge, for little benefit (a user reported 100 MB with virt-manager left running overnight). The output from the command is still printed with a DEBUG call, so the info isn't completely lost. Thanks, Cole

2 3

[libvirt] PATCH: Add two missing symbol exports
by Daniel P. Berrange 02 Mar '09

02 Mar '09

If building with --with-driver-modules, the Xen and OpenVZ drivers fail to dlopen() because of a couple of missing symbol exports. THis patch adds them Daniel Index: src/libvirt_private.syms =================================================================== RCS file: /data/cvs/libvirt/src/libvirt_private.syms,v retrieving revision 1.23 diff -u -p -u -p -r1.23 libvirt_private.syms --- src/libvirt_private.syms 2 Mar 2009 17:39:43 -0000 1.23 +++ src/libvirt_private.syms 2 Mar 2009 18:23:07 -0000 @@ -26,6 +26,7 @@ virCapabilitiesFormatXML; virCapabilitiesFree; virCapabilitiesNew; virCapabilitiesSetMacPrefix; +virCapabilitiesGenerateMac; # conf.h @@ -47,6 +48,7 @@ virGetStoragePool; virGetStorageVol; virGetNodeDevice; virUnrefDomain; +virUnrefConnect; # domain_conf.h -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

2 1

[libvirt] PATCH: Always reset PCI devices
by Daniel P. Berrange 02 Mar '09

02 Mar '09

Mark's patches added a attribute managed='yes|no' for PCI <hostdev> configuration. This allows the caller app to indicate who is responsible for attaching/detaching the PCI device from the host drivers. When using managed=yes, libvirt does it, while using managed=no, the someone else should do it - typically blacklist the devices in /etc/modprobe.conf Before launching a guest though the devices need to be reset. Mark made the reset operation conditional on managed=yes, which was not what I had intended. libvirtd should always reset the devices so they are in a sane state before booting, regardless of who manages the host driver binding. The forthcoming PCI passthrough suppor in the Xen driver will work in this way - we'll only support managed=no, but XenD will still always do the reset of devices I also add a comment to remind us that we should add validation that the PCI device is not still in use in the non-managed case. Daniel Index: src/qemu_conf.c =================================================================== RCS file: /data/cvs/libvirt/src/qemu_conf.c,v retrieving revision 1.132 diff -u -p -u -p -r1.132 qemu_conf.c --- src/qemu_conf.c 2 Mar 2009 16:40:31 -0000 1.132 +++ src/qemu_conf.c 2 Mar 2009 18:23:07 -0000 @@ -1411,7 +1411,9 @@ int qemudBuildCommandLine(virConnectPtr } pciFreeDevice(conn, dev); - } + } /* else { + XXX validate that non-managed device isn't in use + } */ } } @@ -1421,8 +1423,7 @@ int qemudBuildCommandLine(virConnectPtr virDomainHostdevDefPtr hostdev = vm->def->hostdevs[i]; pciDevice *dev; - if (!hostdev->managed || - hostdev->mode != VIR_DOMAIN_HOSTDEV_MODE_SUBSYS || + if (hostdev->mode != VIR_DOMAIN_HOSTDEV_MODE_SUBSYS || hostdev->source.subsys.type != VIR_DOMAIN_HOSTDEV_SUBSYS_TYPE_PCI) continue; -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

2 1

[libvirt] [PATCH] tests: fix an error that made us skip the daemon-conf test
by Jim Meyering 02 Mar '09

02 Mar '09

FYI, I'm committing this as obvious. Otherwise, you'd get this: grep: /h/meyering/w/co/libvirt/lib/config.h: No such file or directory ./daemon-conf: skipping test: configured without QEMU support SKIP: daemon-conf >From e92b94d5b84d2f840ea3e0f88c17411167cfeac8 Mon Sep 17 00:00:00 2001 From: Jim Meyering <meyering(a)redhat.com> Date: Mon, 2 Mar 2009 20:01:50 +0100 Subject: [PATCH] tests: fix an error that made us skip the daemon-conf test * tests/Makefile.am (CONFIG_HEADER): Correct definition. --- tests/Makefile.am | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/tests/Makefile.am b/tests/Makefile.am index 7479e03..b40785f 100644 --- a/tests/Makefile.am +++ b/tests/Makefile.am @@ -125,7 +125,7 @@ TESTS_ENVIRONMENT = \ abs_top_srcdir=`cd '$(top_srcdir)'; pwd` \ abs_builddir=`cd '$(builddir)'; pwd` \ abs_srcdir=`cd '$(srcdir)'; pwd` \ - CONFIG_HEADER='$(abs_top_builddir)/lib/config.h' \ + CONFIG_HEADER='$(abs_top_builddir)/config.h' \ PATH="$(path_add)$(PATH_SEPARATOR)$$PATH" \ SHELL="$(SHELL)" \ LIBVIRT_DRIVER_DIR="$(abs_top_builddir)/src/.libs" \ -- 1.6.2.rc1.285.gc5f54

1 0

[libvirt] many more config variables required? or 1 "prefix" config
by Jim Meyering 02 Mar '09

02 Mar '09

I found network-related config from one test leaking into another and making the latter test fail, despite my use of what I thought was everything required to keep them separate (unix_sock_dir and log_outputs both set in config, and --pid-file specified on command line). Unfortunately, there are still hard-coded references to some files. /* Configuration paths are either ~/.libvirt/qemu/... (session) or * /etc/libvirt/qemu/... (system). That's from network_driver.c, to set these variables: struct network_driver ->networkConfigDir ->networkAutostartDir However, storage_driver is nearly identical in that respect. It also uses ~/.libvirt/ vs SYSCONF_DIR/libvirt. Same for uml_driver.c. So, rather than adding new variables for each of these six new parameters, how about just one new config parameter to allow specification of a directory prefix that would replace "~" and "/etc" in determining how to form config-related names? Being able to run multiple libvirtd processes in parallel without having one affect another is a hard requirement for any serious testing.

2 1

[libvirt] [PATCH] Account for defined networks when generating bridge names
by Cole Robinson 02 Mar '09

02 Mar '09

This is the second part of the fix for rhbz 479622. If we are generating a bridge name for a virtual network, don't collide with any bridge name in a defined network. This patch also generates a bridge name at network define time, if none was passed in the xml. The downside to all this is that it won't fix things for existing victims of the bug: if they have 2 networks with the same bridge device in the xml, we can't intelligently remedy the situation. This patch just helps prevent future users getting into that predicament. Thanks, Cole

3 6

[libvirt] [PATCH] Remove redundant monitorWatch
by Cole Robinson 02 Mar '09

02 Mar '09

For some reason there are two VMDef members being used to keep track of monitor event handles: monitor_watch and monitorWatch. Remove the latter. Thanks, Cole

3 5

[libvirt] [PATCH] Better error reporting in qemu AttachDevice
by Cole Robinson 02 Mar '09

02 Mar '09

The attached patch fixes qemu AttachDevice to show the invalid disk bus or type in it's error messages. This also adds an error message where previously we could fall through, leading virsh to print 'Unknown Error' if attempting to hotplug an IDE disk. Thanks, Cole

3 3

[libvirt] [PATCH] Recognize available media in nodedev hal driver
by Cole Robinson 02 Mar '09

02 Mar '09

The host device hal driver can't tell when a storage device has media available, the culprit being an incorrect return value check. The attached patch fixes this. Unfortunately the driver also doesn't properly detect media eject and media inserted hal events. I've been poking at this but it's a more involved fix. Thanks, Cole

3 3

[libvirt] [PATCH] Mark defined networks as persistent
by Cole Robinson 02 Mar '09

02 Mar '09

We aren't setting the persistent bit when a network is defined, so 'destroy' makes them disappear (though they will reappear later since their persistent config is never removed). Attached patch fixes this. Thanks, Cole

3 5