[libvirt] [PATCH v3] qemu: don't use deprecated -no-kvm-pit-reinjection
by Ján Tomko
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
10 years, 6 months
[libvirt] pvpanic plans?
by Paolo Bonzini
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
10 years, 6 months
[libvirt] [PATCH 0/6] API documentation improvements
by Claudio Bley
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
10 years, 6 months
[libvirt] [PATCH v3 0/2] expose baselabel for each sec model/virt type
by Giuseppe Scrivano
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
10 years, 7 months
[libvirt] [PATCH v3]LXC: Helper function for checking permission of dir when userns enabled
by Chen Hanxiao
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
10 years, 7 months
[libvirt] [RESEND][PATCHv5 0/4] write separate module for hostdev passthrough
by Chunyan Liu
[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
10 years, 7 months
[libvirt] [PATCH]virsh: support readonly in attach-disk command
by Chen Hanxiao
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
10 years, 7 months
[libvirt] [BUG] libvirtd on destination crash frequently while migrating vms concurrently
by Wangyufei (A)
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
10 years, 7 months
[libvirt] [PATCH 0/2] btrfs subvolume management
by Oskari Saarenmaa
Moved btrfs subvolume management to storage_backend_fs.c instead of
implementing it as a separate pool as suggested by Daniel P. Berrange in
https://www.redhat.com/archives/libvir-list/2013-September/msg00316.html
Oskari Saarenmaa (2):
virFileFsType: get filesystem type of a given path
storage: btrfs subvolumes for directory pools
configure.ac | 25 ++-
docs/schemas/storagevol.rng | 1 +
docs/storage.html.in | 30 ++-
libvirt.spec.in | 4 +
src/conf/storage_conf.c | 3 +
src/conf/storage_conf.h | 1 +
src/libvirt_private.syms | 1 +
src/storage/storage_backend.c | 15 +-
src/storage/storage_backend_fs.c | 222 ++++++++++++++++++++--
src/util/virfile.c | 47 +++++
src/util/virfile.h | 1 +
src/util/virstoragefile.c | 4 +-
src/util/virstoragefile.h | 1 +
tests/storagevolxml2xmlin/vol-btrfs-snapshot.xml | 13 ++
tests/storagevolxml2xmlin/vol-btrfs.xml | 9 +
tests/storagevolxml2xmlout/vol-btrfs-snapshot.xml | 26 +++
tests/storagevolxml2xmlout/vol-btrfs.xml | 17 ++
tests/storagevolxml2xmltest.c | 2 +
18 files changed, 392 insertions(+), 30 deletions(-)
10 years, 7 months
[libvirt] [PATCH] Ignore thin pool LVM devices
by Dusty Mabe
For BZ 924672 the problem stems from the fact that thin pool logical
volume devices show up in /sbin/lvs output just like normal logical
volumes do. Since the thin pool devices show up libvirt assumes they are
just normal logical volumes and assumes there will be a corresponding
/dev/vgname/lvname device that has been created. This is not the case and
you will receive the following error when starting the storage pool:
error: cannot stat file '/dev/vgvirt/thinpool': No such file or directory
This patch modifies virStorageBackendLogicalMakeVol() to ignore thin pool
backing devices.
---
src/storage/storage_backend_logical.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/storage/storage_backend_logical.c b/src/storage/storage_backend_logical.c
index a1a37a1..74d26bd 100644
--- a/src/storage/storage_backend_logical.c
+++ b/src/storage/storage_backend_logical.c
@@ -85,6 +85,10 @@ virStorageBackendLogicalMakeVol(virStoragePoolObjPtr pool,
if (attrs[4] != 'a')
return 0;
+ /* BZ 924672 - Skip thin pools(t) and thin pool data(T) */
+ if (attrs[0] == 't' || attrs[0] == 'T')
+ return 0;
+
/* See if we're only looking for a specific volume */
if (data != NULL) {
vol = data;
--
1.8.3.1
10 years, 7 months