- Devel - libvirt List Archives

[libvirt] [PATCH 0/3] add pci-bridge device and address type
by liguang 08 Jan '13

08 Jan '13

Now, it's unnecessary to arrange devices into multi-pci-bus, for example: <sound model='ac97'> <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> </sound> <video> <model type='cirrus' vram='9216' heads='1'/> <address type='pci' domain='0x0000' bus='0x1' slot='0x02' function='0x0'/> </video> libvirt will complain about "bus != 0", fortunately, qemu supports pci-to-pci bridge, if we want to use multi-pci-bus, we can define 2 pci bridge devices then attach 1 to the other as a subordinate pci-bus, so, 2 pci-buses appear. for example: <pci-bridge type='root'/> <pci-bridge type='subordinate'> <address type='pci-bridge' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> </pci-bridge> <sound model='ac97'> <address type='pci-bridge' domain='0x0000' bus='0x01' slot='0x02' function='0x0'/> </sound> <video> <model type='cirrus' vram='9216' heads='1'/> <address type='pci-bridge' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> </video> src/conf/domain_conf.c | 88 +++++++++++++++++++++++++++++++++++++++++++++--- src/conf/domain_conf.h | 22 ++++++++++++ src/qemu/qemu_command.c | 52 +++++++++++++++++++++++++++++++++++++++++++--- docs/formatdomain.html.in | 23 +++++++++++++++++++++++ 4 files changed, 176 insertions(+), 9 deletions(-)

6 21

[libvirt] [PATCH 0/6] Resolve FORWARD_NULL errors found by Coverity
by John Ferlan 08 Jan '13

08 Jan '13

Bug: https://bugzilla.redhat.com/show_bug.cgi?id=880388 This set of patches resolves "Error: FORWARD_NULL (CWE-476)" errors found by Coverity. John Ferlan (6): xen: Avoid possible NULL dereference vmware: Avoid NULL dereference for 'caps' remote: Avoid calling virAuthConfigLookup() if 'credname' is NULL. lxc: Check for non NULL usb prior to calling usbFreeDevice() lxc: Avoid possible NULL dereference on *root prior to opendir(). cpu: Avoid NULL dereference src/cpu/cpu_powerpc.c | 3 ++- src/lxc/lxc_container.c | 6 ++++++ src/lxc/lxc_driver.c | 6 ++++-- src/remote/remote_driver.c | 3 ++- src/vmware/vmware_conf.c | 3 ++- src/xen/xen_driver.c | 6 +++--- 6 files changed, 19 insertions(+), 8 deletions(-) -- 1.7.11.7

3 13

[libvirt] It's said 'when the guest has PCI passthrough devices in use, operations like migration/save/restore are not possible.' where are the corresponding codes in xen? '
by bobooscar 08 Jan '13

08 Jan '13

It's said 'when the guest has PCI passthrough devices in use, operations like migration/save/restore are not possible.' where are the corresponding codes in xen? I'm wondering how xend/xenlight tells whether a guest has a pci passthu device in use or not. thank you in advance! 已从三星手机发送

2 1

[libvirt] libvirt-1.0.1 make check failure
by Marc Evans 07 Jan '13

07 Jan '13

Hello, I just attempted compilation and testing of libvirt-1.0.1 on an RHEL-6.3 x86_64 system and received one failure noted here: ... TEST: qemumonitorjsontest !!!!! 5 FAIL FAIL: qemumonitorjsontest ... ======================================= 1 of 68 tests failed (1 test was not run) Please report to libvir-list(a)redhat.com ======================================= The whole reason that I am even attempting this is because I have not be able to successfully craft a chroot LXC container using the older 0.9.10-21.el6_3.6 versions that I can get through yum. When attempting to start that container I get: # virsh start base error: Failed to start domain base error: internal error guest failed to start: 2013-01-07 18:48:31.382+0000: 2397: info : libvirt version: 0.9.10, package: 21.el6_3.6 (Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla>, 2012-11-12-11:08:41, x86-008.build.bos.redhat.com) 2013-01-07 18:48:31.382+0000: 2397: error : lxcControllerRun:1484 : Failed to query file context on /lxc/base_rhel-6.3-i686: No data available The /lxc/base_rhel-6.3-i686 directory contains a basic installation of an i686 choot environment which I can interact fine with using chroot. I have not been able to figure out what "error : lxcControllerRun:1484 : Failed to query file context on /lxc/base_rhel-6.3-i686: No data available" is trying to tell me and was hoping that maybe a newer version of libvirt may be more friendly (though this is more likely coming from lxc code). Does anyone have suggestions? Thanks in advance. - Marc

1 0

[libvirt] [PATCH] build: Add libxenctrl to LIBXL_LIBS
by Jim Fehlig 07 Jan '13

07 Jan '13

Commit dfa1e1dd removed libxenctrl from LIBXL_LIBS, but the libxl driver uses a symbol from this library. Explicitly link with libxenctrl instead of relying on the build system to support implicit DSO linking. --- configure.ac | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index ab08f17..20108c2 100644 --- a/configure.ac +++ b/configure.ac @@ -733,7 +733,7 @@ if test "$with_libxl" != "no" ; then LIBS="$LIBS $LIBXL_LIBS" AC_CHECK_LIB([xenlight], [libxl_ctx_alloc], [ with_libxl=yes - LIBXL_LIBS="$LIBXL_LIBS -lxenlight" + LIBXL_LIBS="$LIBXL_LIBS -lxenlight -lxenctrl" ],[ if test "$with_libxl" = "yes"; then fail=1 -- 1.8.0.1

2 3

[libvirt] [PATCH] Fix virLXCPrepareHostDevices method
by Daniel P. Berrange 07 Jan '13

07 Jan '13

From: "Daniel P. Berrange" <berrange(a)redhat.com> The virLXCPrepareHostDevices method was returning success even when it reported an error, and failed to handle several host device types --- src/lxc/lxc_hostdev.c | 16 +++++++++++++++- 1 file changed, 15 insertions(+), 1 deletion(-) diff --git a/src/lxc/lxc_hostdev.c b/src/lxc/lxc_hostdev.c index 21f3096..4fa0508 100644 --- a/src/lxc/lxc_hostdev.c +++ b/src/lxc/lxc_hostdev.c @@ -299,15 +299,29 @@ int virLXCPrepareHostDevices(virLXCDriverPtr driver, virReportError(VIR_ERR_CONFIG_UNSUPPORTED, _("Unsupported hostdev type %s"), virDomainHostdevSubsysTypeToString(dev->source.subsys.type)); + return -1; + } + break; + + case VIR_DOMAIN_HOSTDEV_MODE_CAPABILITIES: + switch (dev->source.subsys.type) { + case VIR_DOMAIN_HOSTDEV_CAPS_TYPE_STORAGE: + case VIR_DOMAIN_HOSTDEV_CAPS_TYPE_MISC: break; + default: + virReportError(VIR_ERR_CONFIG_UNSUPPORTED, + _("Unsupported hostdev type %s"), + virDomainHostdevSubsysTypeToString(dev->source.subsys.type)); + return -1; } break; + default: virReportError(VIR_ERR_CONFIG_UNSUPPORTED, _("Unsupported hostdev mode %s"), virDomainHostdevModeTypeToString(dev->mode)); - break; + return -1; } } -- 1.8.0.1

2 1

[libvirt] [PATCH] Ensure we always setup a private mount namespace for LXC controller
by Daniel P. Berrange 07 Jan '13

07 Jan '13

From: "Daniel P. Berrange" <berrange(a)redhat.com> The code for setting up a private /dev/pts for the containers is also responsible for making the LXC controller have a private mount namespace. Unfortunately the /dev/pts code is not run if launching a container without a custom root. This causes the LXC FUSE mount to leak into the host FS. --- src/lxc/lxc_controller.c | 38 ++++++++++++++++++++++++++------------ 1 file changed, 26 insertions(+), 12 deletions(-) diff --git a/src/lxc/lxc_controller.c b/src/lxc/lxc_controller.c index c9d96b3..a1c264c 100644 --- a/src/lxc/lxc_controller.c +++ b/src/lxc/lxc_controller.c @@ -1143,6 +1143,29 @@ cleanup: static int +virLXCControllerSetupPrivateNS(void) +{ + int ret = -1; + + if (unshare(CLONE_NEWNS) < 0) { + virReportSystemError(errno, "%s", + _("Cannot unshare mount namespace")); + goto cleanup; + } + + if (mount("", "/", NULL, MS_SLAVE|MS_REC, NULL) < 0) { + virReportSystemError(errno, "%s", + _("Failed to switch root mount into slave mode")); + goto cleanup; + } + + ret = 0; +cleanup: + return ret; +} + + +static int virLXCControllerSetupDevPTS(virLXCControllerPtr ctrl) { virDomainFSDefPtr root = virDomainGetRootFilesystem(ctrl->def); @@ -1193,18 +1216,6 @@ virLXCControllerSetupDevPTS(virLXCControllerPtr ctrl) goto cleanup; } - if (unshare(CLONE_NEWNS) < 0) { - virReportSystemError(errno, "%s", - _("Cannot unshare mount namespace")); - goto cleanup; - } - - if (mount("", "/", NULL, MS_SLAVE|MS_REC, NULL) < 0) { - virReportSystemError(errno, "%s", - _("Failed to switch root mount into slave mode")); - goto cleanup; - } - if (virAsprintf(&devpts, "%s/dev/pts", root->src) < 0 || virAsprintf(&ctrl->devptmx, "%s/dev/pts/ptmx", root->src) < 0) { virReportOOMError(); @@ -1408,6 +1419,9 @@ virLXCControllerRun(virLXCControllerPtr ctrl) goto cleanup; } + if (virLXCControllerSetupPrivateNS() < 0) + goto cleanup; + if (virLXCControllerSetupLoopDevices(ctrl) < 0) goto cleanup; -- 1.8.0.1

2 1

[libvirt] [PATCH qom-cpu 00/11] disable-kvm_mmu + -cpu check/enforce fixes (v2)
by Eduardo Habkost 07 Jan '13

07 Jan '13

Changes on v2: - Now both the kvm_mmu-disable and -cpu "enforce" changes are on the same series - Coding style fixes Git tree for reference: git://github.com/ehabkost/qemu-hacks.git cpu-enforce-all.v2 https://github.com/ehabkost/qemu-hacks/tree/cpu-enforce-all.v2 Patches 1-2 disable the "kvm_mmu" feature by default on pc-1.4. Host-side support for the kvm_mmu feature was removed from the kernel since v3.3 (released in March 2012), it was marked for removal since January 2011 and it's slower than shadow or hardware assisted paging (see kernel commit fb92045843). It doesn't make sense to keep it enabled by default. Also, keeping it enabled by default would cause unnecessary hassle when libvirt start using the "enforce" option. Patches 3-11 change the -cpu check/enforce code to work as it should: it will check every single CPUID bit to make sure it is supported by the host. The changes are a bit intrusive, but: - The longer we take to make "enforce" strict as it should (and make libvirt finally use it), more users will have VMs with migration-unsafe unpredictable guest ABIs. For this reason, I would like to get this into QEMU 1.4. - The changes in this series should affect only users that are already using the "enforce" flag, and I believe whoever is using the "enforce" flag really want the strict behavior introduced by this series. Eduardo Habkost (11): target-i386: Don't set any KVM flag by default if KVM is disabled target-i386: Disable kvm_mmu_op by default on pc-1.4 target-i386: kvm: -cpu host: Use GET_SUPPORTED_CPUID for SVM features target-i386: kvm: Enable all supported KVM features for -cpu host target-i386: check/enforce: Fix CPUID leaf numbers on error messages target-i386: check/enforce: Do not ignore "hypervisor" flag target-i386: check/enforce: Check all CPUID.80000001H.EDX bits target-i386: check/enforce: Check SVM flag support as well target-i386: check/enforce: Eliminate check_feat field target-i386: Call kvm_check_features_against_host() only if CONFIG_KVM is set target-i386: check/enforce: Check all feature words hw/pc_piix.c | 9 +++++- target-i386/cpu.c | 93 +++++++++++++++++++++++++++++++++++++++++-------------- target-i386/cpu.h | 4 +++ 3 files changed, 81 insertions(+), 25 deletions(-) -- 1.7.11.7

4 42

[libvirt] [PATCH] Only initialize capabilities after setting dir permissions
by Daniel P. Berrange 07 Jan '13

07 Jan '13

From: "Daniel P. Berrange" <berrange(a)redhat.com> The current code is initializing capabilities before setting directory permissions. Thus the QEMU binaries being run may not have the ability to create the UNIX monitor socket on the first run of libvirtd. --- src/qemu/qemu_driver.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index ac4c094..cea76af 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -831,9 +831,6 @@ qemuStartup(bool privileged, if (!qemu_driver->capsCache) goto error; - if ((qemu_driver->caps = qemuCreateCapabilities(qemu_driver)) == NULL) - goto error; - if ((qemu_driver->activePciHostdevs = pciDeviceListNew()) == NULL) goto error; @@ -870,6 +867,9 @@ qemuStartup(bool privileged, } } + if ((qemu_driver->caps = qemuCreateCapabilities(qemu_driver)) == NULL) + goto error; + /* If hugetlbfs is present, then we need to create a sub-directory within * it, since we can't assume the root mount point has permissions that * will let our spawned QEMU instances use it. -- 1.8.0.1

2 1

[libvirt] [PATCH] Speed up fallback to legacy non-QMP probing
by Daniel P. Berrange 07 Jan '13

07 Jan '13

From: "Daniel P. Berrange" <berrange(a)redhat.com> Since we daemonized QEMU for capabilities probing there is a long time if QEMU fals to launch. This is because we're not passing in any virDomainObjPtr instance and thus the monitor code can not check to see if the PID is still alive. Signed-off-by: Daniel P. Berrange <berrange(a)redhat.com> --- src/qemu/qemu_capabilities.c | 34 ++++++++++++++++++++-------------- 1 file changed, 20 insertions(+), 14 deletions(-) diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c index e16bc70..bcecc6d 100644 --- a/src/qemu/qemu_capabilities.c +++ b/src/qemu/qemu_capabilities.c @@ -2307,6 +2307,8 @@ qemuCapsInitQMP(qemuCapsPtr caps, char *pidfile = NULL; qemuCapsHookData hookData; char *archstr; + pid_t pid = 0; + virDomainObj vm; /* the ".sock" sufix is important to avoid a possible clash with a qemu * domain called "capabilities" @@ -2360,7 +2362,16 @@ qemuCapsInitQMP(qemuCapsPtr caps, goto cleanup; } - if (!(mon = qemuMonitorOpen(NULL, &config, true, &callbacks))) { + if (virPidFileReadPath(pidfile, &pid) < 0) { + VIR_DEBUG("Failed to read pidfile %s", pidfile); + ret = 0; + goto cleanup; + } + + memset(&vm, 0, sizeof(vm)); + vm.pid = pid; + + if (!(mon = qemuMonitorOpen(&vm, &config, true, &callbacks))) { ret = 0; goto cleanup; } @@ -2446,21 +2457,16 @@ cleanup: VIR_FREE(monpath); VIR_FREE(package); - if (pidfile) { + if (pid != 0) { char ebuf[1024]; - pid_t pid; - int rc; - if ((rc = virPidFileReadPath(pidfile, &pid)) < 0) { - VIR_DEBUG("Failed to read pidfile %s: %s", - pidfile, virStrerror(-rc, ebuf, sizeof(ebuf))); - } else { - VIR_DEBUG("Killing QMP caps process %lld", (long long) pid); - if (virProcessKill(pid, SIGKILL) < 0 && errno != ESRCH) - VIR_ERROR(_("Failed to kill process %lld: %s"), - (long long) pid, - virStrerror(errno, ebuf, sizeof(ebuf))); - } + VIR_DEBUG("Killing QMP caps process %lld", (long long) pid); + if (virProcessKill(pid, SIGKILL) < 0 && errno != ESRCH) + VIR_ERROR(_("Failed to kill process %lld: %s"), + (long long) pid, + virStrerror(errno, ebuf, sizeof(ebuf))); + } + if (pidfile) { unlink(pidfile); VIR_FREE(pidfile); } -- 1.8.0.1

2 1