September 2013 - Devel - libvirt List Archives

[libvirt] JNA Error Callback could cause core dump.
by Benjamin Wang (gendwang) 20 Dec '13

20 Dec '13

Hi, When I changed code as following: public class Connect { // Load the native part static { Libvirt.INSTANCE.virInitialize(); try { ErrorHandler.processError(Libvirt.INSTANCE); } catch (Exception e) { e.printStackTrace(); } + Libvirt.INSTANCE.virSetErrorFunc(null, new ErrorCallback()); } The server will generate the following core dump: Program terminated with signal 6, Aborted. #0 0x0000003f9b030265 in raise () from /lib64/libc.so.6 (gdb) where #0 0x0000003f9b030265 in raise () from /lib64/libc.so.6 #1 0x0000003f9b031d10 in abort () from /lib64/libc.so.6 #2 0x0000003f9b06a84b in __libc_message () from /lib64/libc.so.6 #3 0x0000003f9b07230f in _int_free () from /lib64/libc.so.6 #4 0x0000003f9b07276b in free () from /lib64/libc.so.6 #5 0x00002aaaacf46868 in ?? () #6 0x0000000000000000 in ?? () The problem was caused that when JNA call setErrorFunc, it will create ErrorCallback object. But when GC is executed, the object is GCed. But even I change code as following. When GC is excuted, the callback object will be moved. Then C can't find this object. Both of scenarios will cause core dump. It seems that JNA mustn't provide ErrorCallback Class, Because nobody can use this. Please correct me. public class Connect { + private static final ErrorCallback callback = new ErrorCallback(); // Load the native part static { Libvirt.INSTANCE.virInitialize(); try { ErrorHandler.processError(Libvirt.INSTANCE); } catch (Exception e) { e.printStackTrace(); } + Libvirt.INSTANCE.virSetErrorFunc(null, callback); } B.R. Benjamin Wang

2 4

[libvirt] [PATCH 0/4] Support for integrating cgroups with systemd
by Daniel P. Berrange 16 Dec '13

16 Dec '13

From: "Daniel P. Berrange" <berrange(a)redhat.com> This is a much changed / expanded version of my previous work to create cgroups via systemd. The difference is that this time it actually works :-) I'm not proposing this for merge until after the 1.1.1 release. Daniel P. Berrange (4): Add APIs for formatting systemd slice/scope names Add support for systemd cgroup mount Cope with races while killing processes Enable support for systemd-machined in cgroups creation src/libvirt_private.syms | 2 + src/lxc/lxc_process.c | 10 +- src/qemu/qemu_cgroup.c | 1 + src/util/vircgroup.c | 270 +++++++++++++++++++++++++++++++++++++++++------ src/util/vircgroup.h | 2 + src/util/virsystemd.c | 96 ++++++++++++++++- src/util/virsystemd.h | 5 + tests/vircgrouptest.c | 9 ++ tests/virsystemdtest.c | 48 +++++++++ 9 files changed, 403 insertions(+), 40 deletions(-) -- 1.8.1.4

4 16

[libvirt] [PATCH v3] qemu: don't use deprecated -no-kvm-pit-reinjection
by Ján Tomko 05 Nov '13

05 Nov '13

Since qemu-kvm 1.1 [1] (since 1.3. in upstream QEMU [2]) '-no-kvm-pit-reinjection' has been deprecated. Use -global kvm-pit.lost_tick_policy=discard instead. https://bugzilla.redhat.com/show_bug.cgi?id=978719 [1] http://git.kernel.org/cgit/virt/kvm/qemu-kvm.git/commit/?id=4e4fa39 [2] http://git.qemu.org/?p=qemu.git;a=commitdiff;h=c21fb4f --- v3: use -global instead of trying to add another -device re: https://www.redhat.com/archives/libvir-list/2013-July/msg00833.html Unsetting the QEMU_CAPS_NO_KVM_PIT capability for QEMU >1.2 seems to work okay with libvirtd upgrades. v2: https://www.redhat.com/archives/libvir-list/2013-July/msg00821.html v1: https://www.redhat.com/archives/libvir-list/2013-July/msg00045.html src/qemu/qemu_capabilities.c | 5 ++-- src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_command.c | 8 ++++-- .../qemuxml2argv-kvm-pit-delay.args | 5 ++++ .../qemuxml2argv-kvm-pit-delay.xml | 29 ++++++++++++++++++++++ .../qemuxml2argv-kvm-pit-device.args | 5 ++++ .../qemuxml2argv-kvm-pit-device.xml | 29 ++++++++++++++++++++++ tests/qemuxml2argvtest.c | 4 +++ 8 files changed, 82 insertions(+), 4 deletions(-) create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-kvm-pit-delay.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-kvm-pit-delay.xml create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-kvm-pit-device.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-kvm-pit-device.xml diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c index dc8f0be..06b71b5 100644 --- a/src/qemu/qemu_capabilities.c +++ b/src/qemu/qemu_capabilities.c @@ -242,6 +242,7 @@ VIR_ENUM_IMPL(virQEMUCaps, QEMU_CAPS_LAST, "usb-storage.removable", "virtio-mmio", "ich9-intel-hda", + "kvm-pit", ); struct _virQEMUCaps { @@ -1393,6 +1394,7 @@ struct virQEMUCapsStringFlags virQEMUCapsObjectTypes[] = { { "usb-storage", QEMU_CAPS_DEVICE_USB_STORAGE }, { "virtio-mmio", QEMU_CAPS_DEVICE_VIRTIO_MMIO }, { "ich9-intel-hda", QEMU_CAPS_DEVICE_ICH9_INTEL_HDA }, + { "kvm-pit", QEMU_CAPS_DEVICE_KVM_PIT }, }; static struct virQEMUCapsStringFlags virQEMUCapsObjectPropsVirtioBlk[] = { @@ -2477,13 +2479,12 @@ virQEMUCapsInitArchQMPBasic(virQEMUCapsPtr qemuCaps, /* * Currently only x86_64 and i686 support PCI-multibus, - * -no-acpi and -no-kvm-pit-reinjection. + * -no-acpi */ if (qemuCaps->arch == VIR_ARCH_X86_64 || qemuCaps->arch == VIR_ARCH_I686) { virQEMUCapsSet(qemuCaps, QEMU_CAPS_PCI_MULTIBUS); virQEMUCapsSet(qemuCaps, QEMU_CAPS_NO_ACPI); - virQEMUCapsSet(qemuCaps, QEMU_CAPS_NO_KVM_PIT); } ret = 0; diff --git a/src/qemu/qemu_capabilities.h b/src/qemu/qemu_capabilities.h index f8dc728..770744e 100644 --- a/src/qemu/qemu_capabilities.h +++ b/src/qemu/qemu_capabilities.h @@ -197,6 +197,7 @@ enum virQEMUCapsFlags { QEMU_CAPS_USB_STORAGE_REMOVABLE = 156, /* usb-storage.removable */ QEMU_CAPS_DEVICE_VIRTIO_MMIO = 157, /* -device virtio-mmio */ QEMU_CAPS_DEVICE_ICH9_INTEL_HDA = 158, /* -device ich9-intel-hda */ + QEMU_CAPS_DEVICE_KVM_PIT = 159, /* -device kvm-pit */ QEMU_CAPS_LAST, /* this must always be the last item */ }; diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c index ba102f4..c988646 100644 --- a/src/qemu/qemu_command.c +++ b/src/qemu/qemu_command.c @@ -7966,11 +7966,15 @@ qemuBuildCommandLine(virConnectPtr conn, case VIR_DOMAIN_TIMER_TICKPOLICY_DELAY: /* delay is the default if we don't have kernel (-no-kvm-pit), otherwise, the default is catchup. */ - if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_NO_KVM_PIT)) + if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_DEVICE_KVM_PIT)) + virCommandAddArgList(cmd, "-global", + "kvm-pit.lost_tick_policy=discard", NULL); + else if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_NO_KVM_PIT)) virCommandAddArg(cmd, "-no-kvm-pit-reinjection"); break; case VIR_DOMAIN_TIMER_TICKPOLICY_CATCHUP: - if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_NO_KVM_PIT)) { + if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_NO_KVM_PIT) || + virQEMUCapsGet(qemuCaps, QEMU_CAPS_DEVICE_KVM_PIT)) { /* do nothing - this is default for kvm-pit */ } else if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_TDF)) { /* -tdf switches to 'catchup' with userspace pit. */ diff --git a/tests/qemuxml2argvdata/qemuxml2argv-kvm-pit-delay.args b/tests/qemuxml2argvdata/qemuxml2argv-kvm-pit-delay.args new file mode 100644 index 0000000..ca5823f --- /dev/null +++ b/tests/qemuxml2argvdata/qemuxml2argv-kvm-pit-delay.args @@ -0,0 +1,5 @@ +LC_ALL=C PATH=/bin HOME=/home/test USER=test LOGNAME=test QEMU_AUDIO_DRV=none \ +/usr/bin/qemu -S -M pc -m 214 -smp 2 -nographic \ +-monitor unix:/tmp/test-monitor,server,nowait \ +-no-kvm-pit-reinjection -no-acpi -boot c -usb -hda /dev/HostVG/QEMUGuest1 \ +-net none -serial none -parallel none diff --git a/tests/qemuxml2argvdata/qemuxml2argv-kvm-pit-delay.xml b/tests/qemuxml2argvdata/qemuxml2argv-kvm-pit-delay.xml new file mode 100644 index 0000000..7835a1b --- /dev/null +++ b/tests/qemuxml2argvdata/qemuxml2argv-kvm-pit-delay.xml @@ -0,0 +1,29 @@ +<domain type='qemu'> + <name>QEMUGuest1</name> + <uuid>c7a5fdbd-edaf-9455-926a-d65c16db1809</uuid> + <memory unit='KiB'>219136</memory> + <currentMemory unit='KiB'>219136</currentMemory> + <vcpu placement='static'>2</vcpu> + <os> + <type arch='i686' machine='pc'>hvm</type> + <boot dev='hd'/> + </os> + <clock offset='utc'> + <timer name='pit' tickpolicy='delay'/> + </clock> + <on_poweroff>destroy</on_poweroff> + <on_reboot>restart</on_reboot> + <on_crash>destroy</on_crash> + <devices> + <emulator>/usr/bin/qemu</emulator> + <disk type='block' device='disk'> + <source dev='/dev/HostVG/QEMUGuest1'/> + <target dev='hda' bus='ide'/> + <address type='drive' controller='0' bus='0' target='0' unit='0'/> + </disk> + <controller type='usb' index='0'/> + <controller type='ide' index='0'/> + <controller type='pci' index='0' model='pci-root'/> + <memballoon model='virtio'/> + </devices> +</domain> diff --git a/tests/qemuxml2argvdata/qemuxml2argv-kvm-pit-device.args b/tests/qemuxml2argvdata/qemuxml2argv-kvm-pit-device.args new file mode 100644 index 0000000..f03840f --- /dev/null +++ b/tests/qemuxml2argvdata/qemuxml2argv-kvm-pit-device.args @@ -0,0 +1,5 @@ +LC_ALL=C PATH=/bin HOME=/home/test USER=test LOGNAME=test QEMU_AUDIO_DRV=none \ +/usr/bin/qemu -S -M pc -m 214 -smp 2 -nographic \ +-monitor unix:/tmp/test-monitor,server,nowait \ +-global kvm-pit.lost_tick_policy=discard -no-acpi -boot c -usb \ +-hda /dev/HostVG/QEMUGuest1 -net none -serial none -parallel none diff --git a/tests/qemuxml2argvdata/qemuxml2argv-kvm-pit-device.xml b/tests/qemuxml2argvdata/qemuxml2argv-kvm-pit-device.xml new file mode 100644 index 0000000..7835a1b --- /dev/null +++ b/tests/qemuxml2argvdata/qemuxml2argv-kvm-pit-device.xml @@ -0,0 +1,29 @@ +<domain type='qemu'> + <name>QEMUGuest1</name> + <uuid>c7a5fdbd-edaf-9455-926a-d65c16db1809</uuid> + <memory unit='KiB'>219136</memory> + <currentMemory unit='KiB'>219136</currentMemory> + <vcpu placement='static'>2</vcpu> + <os> + <type arch='i686' machine='pc'>hvm</type> + <boot dev='hd'/> + </os> + <clock offset='utc'> + <timer name='pit' tickpolicy='delay'/> + </clock> + <on_poweroff>destroy</on_poweroff> + <on_reboot>restart</on_reboot> + <on_crash>destroy</on_crash> + <devices> + <emulator>/usr/bin/qemu</emulator> + <disk type='block' device='disk'> + <source dev='/dev/HostVG/QEMUGuest1'/> + <target dev='hda' bus='ide'/> + <address type='drive' controller='0' bus='0' target='0' unit='0'/> + </disk> + <controller type='usb' index='0'/> + <controller type='ide' index='0'/> + <controller type='pci' index='0' model='pci-root'/> + <memballoon model='virtio'/> + </devices> +</domain> diff --git a/tests/qemuxml2argvtest.c b/tests/qemuxml2argvtest.c index 0b808a4..58eb3e9 100644 --- a/tests/qemuxml2argvtest.c +++ b/tests/qemuxml2argvtest.c @@ -1080,6 +1080,10 @@ mymain(void) QEMU_CAPS_DRIVE, QEMU_CAPS_DEVICE_VIRTIO_MMIO, QEMU_CAPS_DEVICE_VIRTIO_RNG, QEMU_CAPS_OBJECT_RNG_RANDOM); + DO_TEST("kvm-pit-device", QEMU_CAPS_DEVICE_KVM_PIT); + DO_TEST("kvm-pit-delay", QEMU_CAPS_NO_KVM_PIT); + DO_TEST("kvm-pit-device", QEMU_CAPS_NO_KVM_PIT, QEMU_CAPS_DEVICE_KVM_PIT); + virObjectUnref(driver.config); virObjectUnref(driver.caps); virObjectUnref(driver.xmlopt); -- 1.8.1.5

3 4

[libvirt] pvpanic plans?
by Paolo Bonzini 04 Nov '13

04 Nov '13

The thread from yesterday has died off (perhaps also because of my inappropriate answer to Michael, for which I apologize to him and everyone). I took some time to discuss the libvirt requirements further with Daniel Berrange and Eric Blake on IRC. If anyone is interested, I can give logs. This is a suggestion for how to proceed in both QEMU and libvirt. == Builtin pvpanic == QEMU will remove pvpanic from pc-1.5 in 1.6.1 and 1.5.4. This does not break migration. == Support in libvirt for current functionality == libvirt will add a <panic-notifier/> element, and possibly a capability for it accessible via "virsh capabilities". There are two possibilities: 1) On QEMU 1.5.4/1.6.1 and newer (and on QEMU 1.6.0 with a machine type other than pc-1.5), <on_crash> will only work if the element is there. On QEMU 1.5.0->1.5.3, and on QEMU 1.6.0 with the pc-1.5 machine type, <on_crash> will be obeyed always, and may override e.g. reboot-on-panic if a guest driver exist. 2) On all versions, <on_crash> will only work if the element is there. In turn, there are two ways to implement (2): 2a) libvirt will always add -global pvpanic.iobase=0 to neutralize the builtin pvpanic device if present. <panic-notifier/> will create the device with -device pvpanic,iobase=0x505 Advantage: no changes to QEMU Disadvantage 1: writes to port 0 with QEMU 1.{5.0,5.1,5.2,5.3,6.0} and pc-1.5 machine type will write to a pvpanic device instead of the DMA controller. Probably harmless, and limited to some QEMU versions. Disadvantage 2: libvirt has knowledge of the pvpanic port number 2b) QEMU will provide a way for libvirt to detect that no machine type has the builtin pvpanic. If some machine type may have the builtin pvpanic, and <panic-notifier/> is absent, libvirt will add "-global pvpanic.iobase=0" to neutralize it. Otherwise, libvirt will create the device normally. A possible way for libvirt to detect "good" machine types is a dummy property. This is a bit ugly in that the property would not affect the behavior of the device. The property would remain in the long term. Another possibility is for QEMU to rename the device, e.g. to isa-pvpanic. This is also somewhat gross, but not visible in the long term when the "pvpanic" name will be lost in history. Advantage 1: libvirt has no knowledge of the pvpanic port number Disadvantage 1: same as above Disadvantage 2: need a somewhat gross change in QEMU This method also provides an (also somewhat gross on the QEMU side) way to detect other changes in the pvpanic semantics. One example mentioned below, is making the panicked state temporary. == Possible improvements to pvpanic == The current implementation of pvpanic supports three modes: reset system on panic, destroy domain on panic, preserve domain with no possibility to resume it. (Optionally a domain can be dumped too). Long term, the choice to include pvpanic should not be on the guest admin's shoulders, but rather in libosinfo. Thus, it would be nice to have a fourth mode where the panic is logged but the guest otherwise keeps running. This mode would let libosinfo add pvpanic by default without affecting the guest's behavior on panic. With this change, <on_crash>ignore</on_crash> will behave as follows for the three possibilities above: (1) With QEMU 1.5.0 to 1.6.1, <on_crash> will _not_ obey the setting, never (even if no <panic-notifier/> is specified). libvirt will have to pick a fallback action. advantage of destroy as fallback: it is the default (but note that restart is the default for virt-install) advantage of preserve as fallback: lets the admin examine the panic advantage of restart as fallback: maximum availability of the VM, it is the default for virt-install (2a) With QEMU 1.5.0 to 1.6.1, <on_crash> will _not_ obey the setting if <panic-notifier/> is specified. libvirt has _no way_ to learn about this, so the capability would always be present with these QEMU versions and libosinfo would always add <panic-notifier/> with these versions. Given the libosinfo scenario being considered here, this is not very different from (1). (2b) With QEMU 1.5.0 to 1.6.1, the <panic-notifier/> element will not be available and not exposed in libvirt capabilities. Thus with this version libosinfo would omit <panic-notifier/> from the XML. Guest policy will always be followed correctly. The problem in both (1) and (2a) can be summarized as follows. First, libvirt will have to implement and document a fallback action for buggy QEMU. Second, even though the problems would be limited to some version of QEMU, they would be relatively hard to debug for a casual user, could start happening randomly by updating any one of QEMU, libvirt, libosinfo or the guest kernel, and there is no fallback action for libvirt that is always correct. Thus, considering future libosinfo support for pvpanic, (2b) is preferrable in my opinion. Now, making pvpanic reversible requires a change in QEMU (patch already posted). Andreas proposed using a pvpanic property to determine whether the panicked state is temporary or definitive. libvirt could piggyback on such a property to detect the "goodness" of machine types (as mentioned regarding solution 2b above). However: First, this would require a more intrusive patch, less appealing for 1.5 and 1.6 stable branches. Second, there is no reason why libvirt would want to make the panicked state definitive. To achieve the same effect, libvirt can just not issue the "continue" monitor command when the guest is panicked. Thus the new property would be useless except to communicate pvpanic behavior---and renaming the device still seems preferrable to me. Thanks for reading up to here! Paolo

12 54

[libvirt] [PATCH 0/6] API documentation improvements
by Claudio Bley 30 Oct '13

30 Oct '13

Hi. It's been a while since I tackled this, but here it goes... This is version 4 of https://www.redhat.com/archives/libvir-list/2013-January/msg02094.html exclusive of the already applied patches, of course. Changes since v3: * skipped the ECMAScript code highlighting patch[1] in this series (postponed for now) * added link generation patch (#6) which I had proposed seperately back in Jan 2013, too. * added a reference to an affected API in patch #1 and #4 as per Eric's comments * changed the code block XSL processing to avoid cutting off characters at the beginning of a line [1] https://www.redhat.com/archives/libvir-list/2013-January/msg02104.html [2] https://www.redhat.com/archives/libvir-list/2013-January/msg00884.html Claudio Bley (6): docs: process code blocks similar to Markdown docs: add class "description" to div's containing descriptions docs: define style of code blocks inside descriptions libvirt.c: add 2 spaces of indentation to example code of virStreamSend libvirt.c: indent code of virDomainGetMemoryParameters's documentation docs: generate links from plain text documentation docs/libvirt.css | 7 +++ docs/newapi.xsl | 121 +++++++++++++++++++++++++++++++++++++++----------- src/libvirt.c | 130 +++++++++++++++++++++++++++--------------------------- 3 files changed, 167 insertions(+), 91 deletions(-) -- 1.7.9.5

3 18

[libvirt] [PATCH v3 0/2] expose baselabel for each sec model/virt type
by Giuseppe Scrivano 17 Oct '13

17 Oct '13

Now each security model can define its own base label, that describes the default security context used by libvirt to run an hypervisor process. This information is exposed to users trough the host capabilities XML. *v3 major changes - support LXC - merge virSecurityDACSetUser and virSecurityDACSetGroup in virSecurityDACSetUserAndGroup - DAC sets the baselabel in virSecurityDACSetUserAndGroup - Use virDomainVirtTypeToString instead of hardcoding the name Giuseppe Scrivano (2): security: add new internal function "virSecurityManagerGetBaseLabel" capabilities: add baselabel per sec driver/virt type to secmodel docs/schemas/capability.rng | 8 ++++ src/conf/capabilities.c | 60 +++++++++++++++++++++++++++- src/conf/capabilities.h | 14 +++++++ src/libvirt_private.syms | 2 + src/lxc/lxc_conf.c | 10 ++++- src/qemu/qemu_conf.c | 21 ++++++++-- src/security/security_apparmor.c | 8 ++++ src/security/security_dac.c | 34 +++++++++++----- src/security/security_dac.h | 7 ++-- src/security/security_driver.h | 4 ++ src/security/security_manager.c | 22 +++++++++- src/security/security_manager.h | 2 + src/security/security_nop.c | 10 +++++ src/security/security_selinux.c | 12 ++++++ src/security/security_stack.c | 9 +++++ tests/capabilityschemadata/caps-qemu-kvm.xml | 2 + tests/capabilityschemadata/caps-test3.xml | 2 + 17 files changed, 204 insertions(+), 23 deletions(-) -- 1.8.3.1

2 9

[libvirt] [PATCH v3]LXC: Helper function for checking permission of dir when userns enabled
by Chen Hanxiao 15 Oct '13

15 Oct '13

From: Chen Hanxiao <chenhanxiao(a)cn.fujitsu.com> If we enable userns, the process with uid/gid in idmap should have enough permission to access dir we provided for containers. Currently, the debug log is very implicit or misleading sometimes. This patch will help clarify this for us when using debug log or virsh. v2: syntax-check clean v3: reliable method for checking permission of dir Signed-off-by: Chen Hanxiao <chenhanxiao(a)cn.fujitsu.com> --- src/lxc/lxc_container.c | 88 +++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 88 insertions(+) diff --git a/src/lxc/lxc_container.c b/src/lxc/lxc_container.c index 8abaea0..9a05e30 100644 --- a/src/lxc/lxc_container.c +++ b/src/lxc/lxc_container.c @@ -110,6 +110,13 @@ struct __lxc_child_argv { int handshakefd; }; +typedef struct __lxc_userns_DirPermCheck_argv lxc_userns_DirPermCheck_argv_t; +struct __lxc_userns_DirPermCheck_argv { + uid_t uid; + gid_t gid; + virDomainDefPtr vmDef; +}; + static int lxcContainerMountFSBlock(virDomainFSDefPtr fs, const char *srcprefix); @@ -1829,6 +1836,84 @@ lxcNeedNetworkNamespace(virDomainDefPtr def) return false; } +static +int lxcContainerCheckDirPermissionChild(void *argv) +{ + size_t i; + lxc_userns_DirPermCheck_argv_t *args = argv; + uid_t uid = args->uid; + uid_t gid = args->gid; + virDomainDefPtr vmDef = args->vmDef; + char *path; + + if (virSetUIDGID(uid, gid, NULL, 0) < 0) { + virReportSystemError(errno, "%s", + _("setuid or setgid failed")); + _exit(-1); + } + + for (i = 0; i < vmDef->nfss; i++) { + path = vmDef->fss[i]->src; + if (access(path, R_OK) || access(path, W_OK) || virFileIsExecutable(path)) { + VIR_DEBUG("Src dir '%s' does not belong to uid/gid: %d/%d", + vmDef->fss[i]->src, uid, gid); + _exit(-1); + } + } + + _exit(0); +} + +/* + * Helper function for helping check + * whether we have enough privilege + * to operate the source dir when userns enabled + * @vmDef: pointer to vm definition structure + * Returns 0 on success or -1 in case of error + */ +static int +lxcContainerCheckDirPermission(virDomainDefPtr vmDef) +{ + uid_t uid; + gid_t gid; + int cpid = 0; + int status; + char *childStack; + char *stack; + int flags = SIGCHLD; + + uid = vmDef->idmap.uidmap[0].target; + gid = vmDef->idmap.gidmap[0].target; + + lxc_userns_DirPermCheck_argv_t args = { + .uid = uid, + .gid = gid, + .vmDef = vmDef + }; + + if (VIR_ALLOC_N(stack, getpagesize() * 4) < 0) + return -1; + + childStack = stack + (getpagesize() * 4); + cpid = clone(lxcContainerCheckDirPermissionChild, childStack, flags, &args); + VIR_FREE(stack); + if (cpid < 0) { + virReportSystemError(errno, "%s", + _("Unable to clone to check permission of directory")); + return -1; + } else if (virProcessWait(cpid, &status) < 0) { + return -1; + } + + if (WEXITSTATUS(status) != 0) { + virReportSystemError(errno, "%s", + _("Check the permission of source dir provided for container")); + return -1; + } + + return 0; +} + /** * lxcContainerStart: * @def: pointer to virtual machine structure @@ -1880,6 +1965,9 @@ int lxcContainerStart(virDomainDefPtr def, if (userns_supported()) { VIR_DEBUG("Enable user namespace"); cflags |= CLONE_NEWUSER; + if (lxcContainerCheckDirPermission(def) < 0) { + return -1; + } } else { virReportSystemError(VIR_ERR_CONFIG_UNSUPPORTED, "%s", _("Kernel doesn't support user namespace")); -- 1.8.2.1

2 4

[libvirt] [RESEND][PATCHv5 0/4] write separate module for hostdev passthrough
by Chunyan Liu 14 Oct '13

14 Oct '13

[rebased to latest libvirt code for applying and reviewing the patches] These patches implements a separate module for hostdev passthrough so that it could be shared by different drivers and can maintain a global state of a host device. Plus, add passthrough to libxl driver, and change qemu driver and lxc driver to use hostdev common library instead of their own hostdev APIs. --- Changes to v4: * change the way checking hypervisor driver name to decide whether use pciback or pci-stub as stub driver, instead, using driver callback to handle that. * remove get active/inactive list APIs from hostdev common library since currently no code uses them. * add nodedev-detach/reattach/reset to libxl driver * other fixes to Daniel and Jim's comments v4 is here: https://www.redhat.com/archives/libvir-list/2013-August/msg00806.html Changes to v3: * fix Jim's comments v3 is here: https://www.redhat.com/archives/libvir-list/2013-August/msg00019.html Changes to v2: * add patches for qemu driver and lxc driver, use common library APIs instead of their own hostdev APIs. * add APIs for nodedev-detach and nodedev-reattach calling. * rename functions to use unified prefix 'virHostdev' * use VIR_ONCE_GLOBAL_INIT() as others instead of previous Init and Cleanup. * use VIR_STRDUP instead of strdup * rebase to latest code v2 is here: https://www.redhat.com/archives/libvir-list/2013-June/msg00263.html Chunyan Liu (4): add hostdev passthrough common library add pci passthrough to libxl driver change qemu driver to use hostdev common library change lxc driver to use hostdev common library docs/schemas/domaincommon.rng | 1 + po/POTFILES.in | 3 +- src/Makefile.am | 3 +- src/conf/domain_conf.c | 3 +- src/conf/domain_conf.h | 1 + src/libvirt_private.syms | 15 + src/libxl/libxl_conf.c | 63 ++ src/libxl/libxl_conf.h | 4 + src/libxl/libxl_domain.c | 9 + src/libxl/libxl_driver.c | 443 ++++++++++++++- src/lxc/lxc_conf.h | 4 - src/lxc/lxc_driver.c | 45 +- src/lxc/lxc_hostdev.c | 413 ------------- src/lxc/lxc_hostdev.h | 43 -- src/lxc/lxc_process.c | 21 +- src/qemu/qemu_command.c | 1 - src/qemu/qemu_conf.h | 9 +- src/qemu/qemu_domain.c | 9 + src/qemu/qemu_driver.c | 72 +-- src/qemu/qemu_hostdev.c | 1289 --------------------------------------- src/qemu/qemu_hostdev.h | 72 --- src/qemu/qemu_hotplug.c | 126 ++--- src/qemu/qemu_process.c | 34 +- src/util/virhostdev.c | 1335 +++++++++++++++++++++++++++++++++++++++++ src/util/virhostdev.h | 104 ++++ src/util/virpci.c | 28 +- src/util/virpci.h | 9 +- src/util/virscsi.c | 26 +- src/util/virscsi.h | 8 +- src/util/virusb.c | 27 +- src/util/virusb.h | 8 +- 31 files changed, 2195 insertions(+), 2033 deletions(-) delete mode 100644 src/lxc/lxc_hostdev.c delete mode 100644 src/lxc/lxc_hostdev.h delete mode 100644 src/qemu/qemu_hostdev.c delete mode 100644 src/qemu/qemu_hostdev.h create mode 100644 src/util/virhostdev.c create mode 100644 src/util/virhostdev.h

2 8

[libvirt] [PATCH]virsh: support readonly in attach-disk command
by Chen Hanxiao 14 Oct '13

14 Oct '13

From: Chen Hanxiao <chenhanxiao(a)cn.fujitsu.com> support readonly in attach-disk virsh command with option --readonly Signed-off-by: Chen Hanxiao <chenhanxiao(a)cn.fujitsu.com> --- tools/virsh-domain.c | 7 +++++++ tools/virsh.pod | 5 +++-- 2 files changed, 10 insertions(+), 2 deletions(-) diff --git a/tools/virsh-domain.c b/tools/virsh-domain.c index 3479a1c..d334ebe 100644 --- a/tools/virsh-domain.c +++ b/tools/virsh-domain.c @@ -315,6 +315,10 @@ static const vshCmdOptDef opts_attach_disk[] = { .type = VSH_OT_BOOL, .help = N_("shareable between domains") }, + {.name = "readonly", + .type = VSH_OT_BOOL, + .help = N_("allow guest read-only access to disk") + }, {.name = "rawio", .type = VSH_OT_BOOL, .help = N_("needs rawio capability") @@ -612,6 +616,9 @@ cmdAttachDisk(vshControl *ctl, const vshCmd *cmd) if (vshCommandOptBool(cmd, "shareable")) virBufferAddLit(&buf, " <shareable/>\n"); + if (vshCommandOptBool(cmd, "readonly")) + virBufferAddLit(&buf, " <readonly/>\n"); + if (straddr) { if (str2DiskAddress(straddr, &diskAddr) != 0) { vshError(ctl, _("Invalid address.")); diff --git a/tools/virsh.pod b/tools/virsh.pod index 0ae5178..91b4429 100644 --- a/tools/virsh.pod +++ b/tools/virsh.pod @@ -1908,8 +1908,8 @@ expected. [[[I<--live>] [I<--config>] | [I<--current>]] | [I<--persistent>]] [I<--driver driver>] [I<--subdriver subdriver>] [I<--cache cache>] [I<--type type>] [I<--mode mode>] [I<--config>] [I<--sourcetype soucetype>] -[I<--serial serial>] [I<--wwn wwn>] [I<--shareable>] [I<--rawio>] -[I<--address address>] [I<--multifunction>] [I<--print-xml>] +[I<--serial serial>] [I<--wwn wwn>] [I<--shareable>] [I<--readonly>] +[I<--rawio>] [I<--address address>] [I<--multifunction>] [I<--print-xml>] Attach a new disk device to the domain. I<source> is path for the files and devices. I<target> controls the bus or @@ -1931,6 +1931,7 @@ I<cache> can be one of "default", "none", "writethrough", "writeback", "directsync" or "unsafe". I<serial> is the serial of disk device. I<wwn> is the wwn of disk device. I<shareable> indicates the disk device is shareable between domains. +I<readonly> indicates the disk device is read-only. I<rawio> indicates the disk needs rawio capability. I<address> is the address of disk device in the form of pci:domain.bus.slot.function, scsi:controller.bus.unit or ide:controller.bus.unit. -- 1.8.2.1

3 5

[libvirt] [BUG] libvirtd on destination crash frequently while migrating vms concurrently
by Wangyufei (A) 11 Oct '13

11 Oct '13

Hello, I found a problem that libvirtd on destination crash frequently while migrating vms concurrently. For example, if I migrate 10 vms concurrently ceaselessly, then after about 30 minutes the libvirtd on destination will crash. So I analyzed and found two bugs during migration process. First, during migration prepare phase on destination, libvirtd assigns ports to qemu to be startd on destination. But the port increase operation is not aomic, so there's a chance that multi vms get the same port, and only the first one can start successfully, others will fail to start. I've applied a patch to solve this bug, and I test it, it works well. If only this bug exists, libvirtd will not crash. The second bug is fatal. Second, I found the libvirtd crash because of segment fault which is produced by accessing vm released. Apparently it's caused by multi-thread operation, thread A access vm data which has released by thread B. At last I proved my thought right. Step 1. Because of bug one, the port is already occupied, so qemu on destination failed to start and sent a HANGUP signal to libvirtd, then libvirtd received this VIR_EVENT_HANDLE_HANGUP event, thread A dealing with events called qemuProcessHandleMonitorEOF as following: #0 qemuProcessHandleMonitorEOF (mon=0x7f4dcd9c3130, vm=0x7f4dcd9c9780) at qemu/qemu_process.c:399 #1 0x00007f4dc18d9e87 in qemuMonitorIO (watch=68, fd=27, events=8, opaque=0x7f4dcd9c3130) at qemu/qemu_monitor.c:668 #2 0x00007f4dccae6604 in virEventPollDispatchHandles (nfds=18, fds=0x7f4db4017e70) at util/vireventpoll.c:500 #3 0x00007f4dccae7ff2 in virEventPollRunOnce () at util/vireventpoll.c:646 #4 0x00007f4dccae60e4 in virEventRunDefaultImpl () at util/virevent.c:273 #5 0x00007f4dccc40b25 in virNetServerRun (srv=0x7f4dcd8d26b0) at rpc/virnetserver.c:1106 #6 0x00007f4dcd6164c9 in main (argc=3, argv=0x7fff8d8f9f88) at libvirtd.c:1518 static int virEventPollDispatchHandles(int nfds, struct pollfd *fds) { ...... /* deleted flag is still false now, so we pass through to qemuProcessHandleMonitorEOF */ if (eventLoop.handles[i].deleted) { EVENT_DEBUG("Skip deleted n=%d w=%d f=%d", i, eventLoop.handles[i].watch, eventLoop.handles[i].fd); continue; } Step 2: Thread B dealing with migration on destination set deleted flag in virEventPollRemoveHandle as following: #0 virEventPollRemoveHandle (watch=74) at util/vireventpoll.c:176 #1 0x00007f4dccae5e6f in virEventRemoveHandle (watch=74) at util/virevent.c:97 #2 0x00007f4dc18d8ca8 in qemuMonitorClose (mon=0x7f4dbc030910) at qemu/qemu_monitor.c:831 #3 0x00007f4dc18bec63 in qemuProcessStop (driver=0x7f4dcd9bd400, vm=0x7f4dbc00ed20, reason=VIR_DOMAIN_SHUTOFF_FAILED, flags=0) at qemu/qemu_process.c:4302 #4 0x00007f4dc18c1a83 in qemuProcessStart (conn=0x7f4dbc031020, driver=0x7f4dcd9bd400, vm=0x7f4dbc00ed20, migrateFrom=0x7f4dbc01af90 "tcp:[::]:49152", stdin_fd=-1, stdin_path=0x0, snapshot=0x0, vmop=VIR_NETDEV_VPORT_PROFILE_OP_MIGRATE_IN_START, flags=6) at qemu/qemu_process.c:4145 #5 0x00007f4dc18cc688 in qemuMigrationPrepareAny (driver=0x7f4dcd9bd400, Step 3: Thread B cleanup vm in qemuMigrationPrepareAny after qemuProcessStart failed. #0 virDomainObjDispose (obj=0x7f4dcd9c9780) at conf/domain_conf.c:2009 #1 0x00007f4dccb0ccd9 in virObjectUnref (anyobj=0x7f4dcd9c9780) at util/virobject.c:266 #2 0x00007f4dccb42340 in virDomainObjListRemove (doms=0x7f4dcd9bd4f0, dom=0x7f4dcd9c9780) at conf/domain_conf.c:2342 #3 0x00007f4dc189ac33 in qemuDomainRemoveInactive (driver=0x7f4dcd9bd400, vm=0x7f4dcd9c9780) at qemu/qemu_domain.c:1993 #4 0x00007f4dc18ccad5 in qemuMigrationPrepareAny (driver=0x7f4dcd9bd400, Step 4: Thread A access priv which is released by thread B before, then libvirtd crash, bomb! static void qemuProcessHandleMonitorEOF(qemuMonitorPtr mon ATTRIBUTE_UNUSED, virDomainObjPtr vm) { virQEMUDriverPtr driver = qemu_driver; virDomainEventPtr event = NULL; qemuDomainObjPrivatePtr priv; int eventReason = VIR_DOMAIN_EVENT_STOPPED_SHUTDOWN; int stopReason = VIR_DOMAIN_SHUTOFF_SHUTDOWN; const char *auditReason = "shutdown"; VIR_DEBUG("Received EOF on %p '%s'", vm, vm->def->name); virObjectLock(vm); priv = vm->privateData; (gdb) p priv $1 = (qemuDomainObjPrivatePtr) 0x0 if (priv->beingDestroyed) { At last if anything bad happened to make qemuProcessStart failed during migration on destination, we'll be in the big trouble that accessing some memory freed. I didn't find any locks or flags exist could stop this happening. Please help me out, thanks a lot. Best Regards, -WangYufei

2 4