On 05/05/2011 05:51 AM, Daniel P. Berrange wrote:
Wire up logging of VM taintint to the QEMU driver
s/taintint/tainting/
- If running QEMU as root user/group or without capabilities
being cleared
- If passing custom QEMU command line args
- If issuing custom QEMU monitor commands
- If using a network interface config with an associated
shell script
- If using a disk config relying on format probing
The warnings, per-VM appear in the main libvirtd logs
11:56:17.571: 10832: warning : qemuDomainObjTaint:712 : Domain id=1 name='l2'
uuid=c7a3edbd-edaf-9455-926a-d65c16db1802 is tainted: high-privileges
11:56:17.571: 10832: warning : qemuDomainObjTaint:712 : Domain id=1 name='l2'
uuid=c7a3edbd-edaf-9455-926a-d65c16db1802 is tainted: disk-probing
The taint flags are reset when the VM is stopped.
* src/qemu/qemu_domain.c, src/qemu/qemu_domain.h: Helper APIs
for logging taint warnings
* src/qemu/qemu_driver.c: Log tainting with custom QEMU monitor
commands and disk/net hotplug with unsupported configs
* src/qemu/qemu_process.c: Log tainting at startup based on
unsupported configs
+++ b/src/qemu/qemu_driver.c
@@ -3877,6 +3877,7 @@ qemuDomainAttachDeviceLive(virDomainObjPtr vm,
switch (dev->type) {
case VIR_DOMAIN_DEVICE_DISK:
+ qemuDomainObjCheckDiskTaint(driver, vm, dev->data.disk);
ret = qemuDomainAttachDeviceDiskLive(driver, vm, dev);
Do we really want to issue the taint message before attempting the
attach? Or are we still safe if you perform the attach first, and issue
the taint message only on success?
if (!ret)
dev->data.disk = NULL;
@@ -3889,6 +3890,7 @@ qemuDomainAttachDeviceLive(virDomainObjPtr vm,
break;
case VIR_DOMAIN_DEVICE_NET:
+ qemuDomainObjCheckNetTaint(driver, vm,
dev->data.net);
ret = qemuDomainAttachNetDevice(dom->conn, driver, vm,
Likewise.
On second thought - we can't guarantee if failure happened before a disk
was probed, or after, so I guess doing unconditional taint is the
conservatively safe approach, and the whole point of this is
conservative safety even if it lets through some false positives.
So, ACK.
--
Eric Blake eblake(a)redhat.com +1-801-349-2682
Libvirt virtualization library
http://libvirt.org