[libvirt] ANNOUNCE: libvirt 1.2.13.2 maintenance release
by Cole Robinson
libvirt 1.2.13.2 is now available. This is a maintenance release of
libvirt 1.2.13 with additional bugfixes that have accumulated
upstream since the initial release.
This release can be downloaded at:
http://libvirt.org/sources/stable_updates/libvirt-1.2.13.2.tar.gz
Changes in this version:
* spec: Delete .git after applying patches
* qemu: block-commit: Mark disk in block jobs only on successful command
* qemu: Disallow concurrent block jobs on a single disk
* qemu: event: Don't fiddle with disk backing trees without a job
* qemu: process: Export qemuProcessFindDomainDiskByAlias
* spec: Fix polkit dep on F23
* domain: Fix migratable XML with graphics/@listen
* qemu: hotplug: Properly clean up drive backend if frontend hotplug
fails
* tpm: adapt sysfs cancel path for new TPM driver
* libvirt-guests: Disable shutdown timeout
* systemd: Escape only needed characters for machined
* systemd: Escape machine name for machined
* cgroup: Drop resource partition from virSystemdMakeScopeName
* CVE-2015-5313: storage: don't allow '/' in filesystem volume names
* remoteClientCloseFunc: Don't mangle connection object refcount
* Revert "LXC: show used memory as 0 when domain is not active"
* lxc: Don't pass a local variable address randomly
* lxc: set nosuid+nodev+noexec flags on /proc/sys mount
* virnetdev: fix moving of 802.11 phys
* interface: don't error out if a bond has no interfaces
* lxc: don't up the veth interfaces unless explicitly asked to
* tests: Add virnetdevtestdata to EXTRA_DIST
* lxc: move wireless PHYs to a network namespace
* Cleanup "/sys/class/net" usage
* Introduce virnetdevtest
* build: provide virNetDevSysfsFile on non-Linux
For info about past maintenance releases, see:
http://wiki.libvirt.org/page/Maintenance_Releases
Thanks,
Cole
8 years, 11 months
[libvirt] [PATCH 0/3] 'Append' mode for serial ports output to file
by Dmitry Mishin
By default, QEMU truncates serial file on open. Sometimes, it could be weird -
for example, when we are trying to investigate some event, which occured several
restarts ago. This patch setadds an ability to preserve previous content.
Dmitry Mishin (3):
tests: add qemu 2.6 caps test
conf: Add mode 'append' for chardevs with file source
qemu: Process new mode='append' for char dev with output to a file
src/conf/domain_conf.c | 18 +-
src/conf/domain_conf.h | 1 +
src/qemu/qemu_capabilities.c | 2 +
src/qemu/qemu_capabilities.h | 1 +
src/qemu/qemu_command.c | 10 +
tests/qemucapabilitiesdata/caps_2.6.0-1.caps | 173 +
tests/qemucapabilitiesdata/caps_2.6.0-1.replies | 4043 +++++++++++++++++++++++
tests/qemucapabilitiestest.c | 1 +
8 files changed, 4245 insertions(+), 4 deletions(-)
create mode 100644 tests/qemucapabilitiesdata/caps_2.6.0-1.caps
create mode 100644 tests/qemucapabilitiesdata/caps_2.6.0-1.replies
--
1.8.3.1
8 years, 11 months
[libvirt] [PATCHv2 0/3] 'autodeflate' attribute for mememory balloon
by Dmitry Andreev
This patch-set adds support for the new feature 'deflate-on-oom'
that has been added to the QEMU virtio memory balloon a month ago.
This feature lets a guest OS deflate balloon on OOM.
With 'deflate-on-oom' enabled virtio balloon will release
it's memory if possible right before an OOM termination of
processes.
QEMU commit with the complete feature description:
http://git.qemu.org/?p=qemu.git;a=commit;h=e3816255bf4b6377bb405331e2ee0d...
v2:
* attribute renamed to 'autodeflate' [1/3][3/3]
* capability check added [2/3][2/3]
* ability to change 'autodeflate' for running domain wasn't added
because QEMU doesn't allow to on/off 'deflate-on-oom' in runtime
* more tests added [3/3]
*** BLURB HERE ***
Dmitry Andreev (3):
conf: introduce 'autodeflate' attribute for memballoon device
qemu: add capability check for memballoon 'autodeflate' feature
qemu: add support of optional 'autodeflate' attribute
docs/formatdomain.html.in | 10 ++
docs/schemas/domaincommon.rng | 5 +
src/conf/domain_conf.c | 23 +++
src/conf/domain_conf.h | 1 +
src/qemu/qemu_capabilities.c | 11 ++
src/qemu/qemu_capabilities.h | 2 +
src/qemu/qemu_command.c | 11 ++
tests/qemucapabilitiesdata/caps_1.2.2-1.replies | 68 ++++++++-
tests/qemucapabilitiesdata/caps_1.3.1-1.replies | 68 ++++++++-
tests/qemucapabilitiesdata/caps_1.4.2-1.replies | 68 ++++++++-
tests/qemucapabilitiesdata/caps_1.5.3-1.replies | 66 ++++++++-
tests/qemucapabilitiesdata/caps_1.6.0-1.replies | 66 ++++++++-
tests/qemucapabilitiesdata/caps_1.6.50-1.replies | 66 ++++++++-
tests/qemucapabilitiesdata/caps_2.1.1-1.replies | 78 +++++++++-
tests/qemucapabilitiesdata/caps_2.4.0-1.caps | 1 +
tests/qemucapabilitiesdata/caps_2.4.0-1.replies | 146 ++++++++++++++++++-
tests/qemucapabilitiesdata/caps_2.5.0-1.caps | 1 +
tests/qemucapabilitiesdata/caps_2.5.0-1.replies | 161 ++++++++++++++++++++-
.../qemuxml2argv-balloon-ccw-deflate.args | 20 +++
.../qemuxml2argv-balloon-ccw-deflate.xml | 21 +++
.../qemuxml2argv-balloon-device-deflate-off.args | 23 +++
.../qemuxml2argv-balloon-device-deflate-off.xml | 25 ++++
.../qemuxml2argv-balloon-device-deflate.args | 23 +++
.../qemuxml2argv-balloon-device-deflate.xml | 25 ++++
.../qemuxml2argv-balloon-mmio-deflate.args | 25 ++++
.../qemuxml2argv-balloon-mmio-deflate.xml | 30 ++++
tests/qemuxml2argvtest.c | 9 ++
27 files changed, 990 insertions(+), 63 deletions(-)
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-balloon-ccw-deflate.args
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-balloon-ccw-deflate.xml
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-balloon-device-deflate-off.args
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-balloon-device-deflate-off.xml
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-balloon-device-deflate.args
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-balloon-device-deflate.xml
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-balloon-mmio-deflate.args
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-balloon-mmio-deflate.xml
--
1.8.3.1
8 years, 11 months
[libvirt] [PATCH] qemu: Connect to guest agent iff needed
by Michal Privoznik
https://bugzilla.redhat.com/show_bug.cgi?id=1293351
I've came across a bit of a silly scenario, but long story short:
after domain was resumed, the virDomainSetTime() API hung for 5
seconds after which it failed with an error. Problem was, that
there is no guest agent installed in the domain. But this got me
thinking and digging into the code. So even though we do listen
to VSERPORT_CHANGE events and connect and disconnect ourselves to
guest agent, we still do connect to the guest agent at both
domain startup and resume. This is a bit silly as it produces the
delay - basically, because we connect to the guest agent,
priv->agent is not NULL. Therefore qemuDomainAgentAvailable()
will return true. And the place where we hang? Well,
historically, when there was no VSERPORT_CHANGE event, we used a
dummy ping command to the guest which has 5 seconds timeout. And
it's still there and effective. So there's where the delay comes
from.
What's the resolution? Well, I'm introducing new capability
QEMU_CAPS_VSERPORT_CHANGE that is enabled iff qemu is capable of
the event. And, during domain startup, reconnect after resume and
attach we do connect to the agent socket iff the capability is
NOT set.
Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com>
---
src/qemu/qemu_capabilities.c | 2 +
src/qemu/qemu_capabilities.h | 1 +
src/qemu/qemu_process.c | 66 ++++++++++++++++++----------
tests/qemucapabilitiesdata/caps_2.1.1-1.caps | 1 +
tests/qemucapabilitiesdata/caps_2.4.0-1.caps | 1 +
tests/qemucapabilitiesdata/caps_2.5.0-1.caps | 1 +
6 files changed, 48 insertions(+), 24 deletions(-)
diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c
index 6e5d203..9e11af9 100644
--- a/src/qemu/qemu_capabilities.c
+++ b/src/qemu/qemu_capabilities.c
@@ -308,6 +308,7 @@ VIR_ENUM_IMPL(virQEMUCaps, QEMU_CAPS_LAST,
"virtio-tablet", /* 205 */
"virtio-input-host",
+ "vserport-change-event",
);
@@ -1479,6 +1480,7 @@ struct virQEMUCapsStringFlags virQEMUCapsEvents[] = {
{ "SPICE_MIGRATE_COMPLETED", QEMU_CAPS_SEAMLESS_MIGRATION },
{ "DEVICE_DELETED", QEMU_CAPS_DEVICE_DEL_EVENT },
{ "MIGRATION", QEMU_CAPS_MIGRATION_EVENT },
+ { "VSERPORT_CHANGE", QEMU_CAPS_VSERPORT_CHANGE },
};
struct virQEMUCapsStringFlags virQEMUCapsObjectTypes[] = {
diff --git a/src/qemu/qemu_capabilities.h b/src/qemu/qemu_capabilities.h
index 61d6379..983faf6 100644
--- a/src/qemu/qemu_capabilities.h
+++ b/src/qemu/qemu_capabilities.h
@@ -335,6 +335,7 @@ typedef enum {
/* 205 */
QEMU_CAPS_VIRTIO_TABLET, /* -device virtio-tablet-{device,pci} */
QEMU_CAPS_VIRTIO_INPUT_HOST, /* -device virtio-input-host-{device,pci} */
+ QEMU_CAPS_VSERPORT_CHANGE, /* VSERPORT_CHANGE event */
QEMU_CAPS_LAST /* this must always be the last item */
} virQEMUCapsFlags;
diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c
index f274068..95a795c 100644
--- a/src/qemu/qemu_process.c
+++ b/src/qemu/qemu_process.c
@@ -3524,15 +3524,21 @@ qemuProcessReconnect(void *opaque)
if (qemuConnectMonitor(driver, obj, QEMU_ASYNC_JOB_NONE, NULL) < 0)
goto error;
- /* Failure to connect to agent shouldn't be fatal */
- if ((ret = qemuConnectAgent(driver, obj)) < 0) {
- if (ret == -2)
- goto error;
+ /* With newer qemus capable of VSERPORT_CHANGE event, we are connecting and
+ * disconnecting to the guest agent as it connects or disconnects to the
+ * channel within the guest. So, it's important to connect here iff we are
+ * running qemu not capable of the event. */
+ if (!virQEMUCapsGet(priv->qemuCaps, QEMU_CAPS_VSERPORT_CHANGE)) {
+ /* Failure to connect to agent shouldn't be fatal */
+ if ((ret = qemuConnectAgent(driver, obj)) < 0) {
+ if (ret == -2)
+ goto error;
- VIR_WARN("Cannot connect to QEMU guest agent for %s",
- obj->def->name);
- virResetLastError();
- priv->agentError = true;
+ VIR_WARN("Cannot connect to QEMU guest agent for %s",
+ obj->def->name);
+ virResetLastError();
+ priv->agentError = true;
+ }
}
if (qemuHostdevUpdateActiveDomainDevices(driver, obj->def) < 0)
@@ -4949,15 +4955,21 @@ qemuProcessLaunch(virConnectPtr conn,
if (qemuProcessWaitForMonitor(driver, vm, asyncJob, priv->qemuCaps, logCtxt) < 0)
goto cleanup;
- /* Failure to connect to agent shouldn't be fatal */
- if ((rv = qemuConnectAgent(driver, vm)) < 0) {
- if (rv == -2)
- goto cleanup;
+ /* With newer qemus capable of VSERPORT_CHANGE event, we are connecting and
+ * disconnecting to the guest agent as it connects or disconnects to the
+ * channel within the guest. So, it's important to connect here iff we are
+ * running qemu not capable of the event. */
+ if (!virQEMUCapsGet(priv->qemuCaps, QEMU_CAPS_VSERPORT_CHANGE)) {
+ /* Failure to connect to agent shouldn't be fatal */
+ if ((rv = qemuConnectAgent(driver, vm)) < 0) {
+ if (rv == -2)
+ goto cleanup;
- VIR_WARN("Cannot connect to QEMU guest agent for %s",
- vm->def->name);
- virResetLastError();
- priv->agentError = true;
+ VIR_WARN("Cannot connect to QEMU guest agent for %s",
+ vm->def->name);
+ virResetLastError();
+ priv->agentError = true;
+ }
}
VIR_DEBUG("Detecting if required emulator features are present");
@@ -5664,15 +5676,21 @@ int qemuProcessAttach(virConnectPtr conn ATTRIBUTE_UNUSED,
if (qemuProcessWaitForMonitor(driver, vm, QEMU_ASYNC_JOB_NONE, priv->qemuCaps, NULL) < 0)
goto error;
- /* Failure to connect to agent shouldn't be fatal */
- if ((ret = qemuConnectAgent(driver, vm)) < 0) {
- if (ret == -2)
- goto error;
+ /* With newer qemus capable of VSERPORT_CHANGE event, we are connecting and
+ * disconnecting to the guest agent as it connects or disconnects to the
+ * channel within the guest. So, it's important to connect here iff we are
+ * running qemu not capable of the event. */
+ if (!virQEMUCapsGet(priv->qemuCaps, QEMU_CAPS_VSERPORT_CHANGE)) {
+ /* Failure to connect to agent shouldn't be fatal */
+ if ((ret = qemuConnectAgent(driver, vm)) < 0) {
+ if (ret == -2)
+ goto error;
- VIR_WARN("Cannot connect to QEMU guest agent for %s",
- vm->def->name);
- virResetLastError();
- priv->agentError = true;
+ VIR_WARN("Cannot connect to QEMU guest agent for %s",
+ vm->def->name);
+ virResetLastError();
+ priv->agentError = true;
+ }
}
VIR_DEBUG("Detecting VCPU PIDs");
diff --git a/tests/qemucapabilitiesdata/caps_2.1.1-1.caps b/tests/qemucapabilitiesdata/caps_2.1.1-1.caps
index 1098dcf..332b85a 100644
--- a/tests/qemucapabilitiesdata/caps_2.1.1-1.caps
+++ b/tests/qemucapabilitiesdata/caps_2.1.1-1.caps
@@ -159,4 +159,5 @@
<flag name='rtl8139'/>
<flag name='e1000'/>
<flag name='virtio-net'/>
+ <flag name='vserport-change-event'/>
</qemuCaps>
diff --git a/tests/qemucapabilitiesdata/caps_2.4.0-1.caps b/tests/qemucapabilitiesdata/caps_2.4.0-1.caps
index d67a48d..1a5fe81 100644
--- a/tests/qemucapabilitiesdata/caps_2.4.0-1.caps
+++ b/tests/qemucapabilitiesdata/caps_2.4.0-1.caps
@@ -167,4 +167,5 @@
<flag name='virtio-mouse'/>
<flag name='virtio-tablet'/>
<flag name='virtio-input-host'/>
+ <flag name='vserport-change-event'/>
</qemuCaps>
diff --git a/tests/qemucapabilitiesdata/caps_2.5.0-1.caps b/tests/qemucapabilitiesdata/caps_2.5.0-1.caps
index f4f3673..8b3586a 100644
--- a/tests/qemucapabilitiesdata/caps_2.5.0-1.caps
+++ b/tests/qemucapabilitiesdata/caps_2.5.0-1.caps
@@ -168,4 +168,5 @@
<flag name='virtio-mouse'/>
<flag name='virtio-tablet'/>
<flag name='virtio-input-host'/>
+ <flag name='vserport-change-event'/>
</qemuCaps>
--
2.4.10
8 years, 11 months
[libvirt] [PATCH 0/3] Fix mingw build
by Michal Privoznik
We have a build failure on mingw platform:4
https://ci.centos.org/job/libvirt-mingw/899/console
Michal Privoznik (3):
sysconf: Include unistd.h
tools: Include PIE_LDFLAGS at the correct place
tools: Disable virt-login-shell on mingw
m4/virt-login-shell.m4 | 18 +++++++++++++++---
src/nodeinfo.c | 1 +
src/qemu/qemu_conf.h | 2 ++
src/util/vircgroup.c | 1 +
src/util/vircommand.c | 1 +
tools/Makefile.am | 4 ++--
tools/virt-login-shell.c | 1 +
7 files changed, 23 insertions(+), 5 deletions(-)
--
2.4.10
8 years, 11 months
[libvirt] Global domain cpu.cfs_quota_us setup
by Alexander Burluka
Hello all!
I would greatly appreciate your help with some cgroup question. Libvirt
xml has cpu tuning section and quota element in it. That parameter sets
up cpu.cfs_cgroup_us for every domain's vcpu. I set it to 55555 and has
such hierarchy of cgroups:
cpu.cfs_quota_us (-1)
|
|-emulator/cpu.cfs_quota_us (-1)
|-vcpu0/cpu.cfs_quota_us (55555)
|-vcpu1/cpu.cfs_quota_us (55555)
|-vcpu2/cpu.cfs_quota_us (55555)
....
\-vcpuN/cpu.cfs_quota_us (55555)
Is there any way to set up upper level quota limit via libvirt without
setting every vcpu? So I'd like to get next hierarchy:
cpu.cfs_quota_us (55555)
|
|-emulator/cpu.cfs_quota_us (-1)
|-vcpu0/cpu.cfs_quota_us (-1)
|-vcpu1/cpu.cfs_quota_us (-1)
|-vcpu2/cpu.cfs_quota_us (-1)
....
\-vcpuN/cpu.cfs_quota_us (-1)
Thank you!
--
Regards,
Alexander Burluka
8 years, 11 months
[libvirt] [PATCH] virStorageVolWipe: Document that wiping journaled FS is useless
by Michal Privoznik
So you have a libvirt volume that you want to wipe out. But lets
say that the volume is actually a file stored on a journaled
filesystem. Overwriting it with zeroes or a pattern does not mean
that corresponding physical location on the disk is overwritten
too, due to journaling. It's the same story with network based
volumes, copy-on-write filesystems, and so on. Since there is no
way that an userland application can write onto specific areas on
disk, all that we can do is document the fact.
Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com>
---
src/libvirt-storage.c | 16 +++++++++++++---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/src/libvirt-storage.c b/src/libvirt-storage.c
index 66dd9f0..513c72f 100644
--- a/src/libvirt-storage.c
+++ b/src/libvirt-storage.c
@@ -1725,7 +1725,12 @@ virStorageVolDelete(virStorageVolPtr vol,
* @vol: pointer to storage volume
* @flags: extra flags; not used yet, so callers should always pass 0
*
- * Ensure data previously on a volume is not accessible to future reads
+ * Ensure data previously on a volume is not accessible to future
+ * reads. Also note, that depending on the actual volume
+ * representation, this call may not really overwrite the
+ * physical location of the volume. For instance, files stored
+ * journaled, log structured, copy-on-write, versioned, and
+ * network file systems are known to be problematic.
*
* Returns 0 on success, or -1 on error
*/
@@ -1765,8 +1770,13 @@ virStorageVolWipe(virStorageVolPtr vol,
* @algorithm: one of virStorageVolWipeAlgorithm
* @flags: future flags, use 0 for now
*
- * Similar to virStorageVolWipe, but one can choose
- * between different wiping algorithms.
+ * Similar to virStorageVolWipe, but one can choose between
+ * different wiping algorithms. Also note, that depending on the
+ * actual volume representation, this call may not really
+ * overwrite the physical location of the volume. For instance,
+ * files stored journaled, log structured, copy-on-write,
+ * versioned, and network file systems are known to be
+ * problematic.
*
* Returns 0 on success, or -1 on error.
*/
--
2.4.10
8 years, 11 months
[libvirt] [PATCH 0/6] Small PCI hostdev improvements and fixes
by Andrea Bolognani
While working on v2 of my series[1] intended to fix
https://bugzilla.redhat.com/show_bug.cgi?id=1272300
I'm running into some smaller stuff that isn't necessarily strictly
related to the issue at hand. The idea is to have this smaller patches
merged before the bigger, more invasive changes that series will bring,
and hopefully make it easier to review by laying down the groundwork
in advance.
The series is organized as follows:
1-2: remove function parameters that are either not inspected by the
function or never have an interesting value
3: change a string field that can only assume one of three values
to a proper enumeration
4: improve bookkeeping when detaching PCI devices from the host,
by making sure they always transition through the 'inactive'
state (when they're attached to the stub driver)
5: make sure we never try to reattach an unmanaged device to the
host, not even when recovering from a previous error
6: add some useful debug messages
I expect patches 1, 2 and 6 to be fairly uncontroversial and easy to
review; patch 3 is kinda big, but it's IMHO a nice improvement over
the current situation; patches 4 and 5 are small but definitely need
a long hard stare from a different pair of eyes to ensure they're not
breaking anything.
Cheers.
[1] https://www.redhat.com/archives/libvir-list/2015-December/msg00070.html
Andrea Bolognani (6):
pci: Remove redundant parameter from virPCIDeviceBindToStub()
pci: Remove 'reprobe' parameter from virPCIDeviceUnbind()
pci: Introduce virPCIStubDriver enumeration
hostdev: Mark PCI devices as inactive as they're detached
hostdev: Only rollback detach of managed devices on error
hostdev: Emit debug messages while handling PCI hostdevs
src/libvirt_private.syms | 2 +
src/libxl/libxl_driver.c | 3 +-
src/qemu/qemu_driver.c | 6 +--
src/util/virhostdev.c | 107 ++++++++++++++++++++++++++++++-----------------
src/util/virpci.c | 102 ++++++++++++++++++++++----------------------
src/util/virpci.h | 18 +++++---
src/xen/xen_driver.c | 3 +-
tests/virhostdevtest.c | 5 ++-
tests/virpcitest.c | 35 ++++++++++------
9 files changed, 163 insertions(+), 118 deletions(-)
--
2.5.0
8 years, 11 months
[libvirt] [PATCH] qemu: Add debug message to spice migration
by Jiri Denemark
Signed-off-by: Jiri Denemark <jdenemar(a)redhat.com>
---
src/qemu/qemu_migration.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/qemu/qemu_migration.c b/src/qemu/qemu_migration.c
index 4519aef..2187241 100644
--- a/src/qemu/qemu_migration.c
+++ b/src/qemu/qemu_migration.c
@@ -2505,6 +2505,7 @@ qemuMigrationWaitForSpice(virDomainObjPtr vm)
if (!wait_for_spice)
return 0;
+ VIR_DEBUG("Waiting for SPICE to finish migration");
while (!priv->job.spiceMigrated && !priv->job.abortJob) {
if (virDomainObjWait(vm) < 0)
return -1;
--
2.6.4
8 years, 11 months
