September 2016 - Devel - libvirt List Archives

[libvirt] Cpu Modeling
by Jason J. Herne 13 Oct '16

13 Oct '16

Hi Jiri & Eduardo, You might remember a discussion with David Hildenbrand of IBM on the Qemu mailing list regarding a new Qemu<->Libvirt interface for cpu modeling. I am picking up this work from David and I wanted to confirm that we are still on the same page as to the direction of that interface. For your reference: https://www.redhat.com/archives/libvir-list/2016-June/thread.html#01413 https://lists.gnu.org/archive/html/qemu-devel/2016-09/threads.html#00489 The first link is to the discussion you were directly involved in. The second link is to the final patch set posted to qemu-devel. The cover letter gives a good overview of the interface added to Qemu and the proposed use-case for Libvirt to use this new cpu modeling support. I'll paste in the most relevant section for your convenience: --------------------------------Libvirt usecase---------------------------- Testing for runability: - Simply try to start QEMU with KVM, compat machine, CPU model - Could be done using query-cpu-model-comparison in the future. Identifying host model, e.g. "virsh capabilities" - query-cpu-model-expansion on "host" with "-M none --enable-kvm" <cpu mode='host-model'>: - simply copy the identified host model <cpu mode='host-passthrough'>: - "-cpu host" "virsh cpu-baseline": - query-cpu-model-baseline on two models with "-M none" "virsh cpu-compare": - query-cpu-model-comparison on two models with "-M none" There might be some cenarios where libvirt wants to convert another CPU model to a static variant, this can be done using query-cpu-model-expansion --------------------------------------------------------------------------- Now that I've hopefully refreshed your memory :) I just want to make sure that you are still on-board with this plan. I realize that this new approach does things differently than Libvirt does today for other platforms. Especially x86_64. The big differences are as follows: 1. We will invoke qemu to gather the host cpu data used for virsh capabilities. Today this data seems to be collected directly from the host hardware for most (all?) architectures. 2. virsh cpu-models {arch} will also use a Qemu invocation to gather cpu model data. 3. Most architectures seem to use a "map" (xml file containing cpu model data that ships with Libvirt) to satisfy #1 and #2 above. Our new method does not use this map as it gets all of the data directly from Qemu. 4. virsh cpu-baseline and cpu-compare will now invoke qemu directly as well. Note: I'm not sure exactly how much all of this will apply just to s390 with other architectures moving over to the new interface if/when they want to. Or if we will want to change all architectures to this new interface at the same time. Any guidance? Thanks for your time and consideration. -- -- Jason J. Herne (jjherne(a)linux.vnet.ibm.com)

4 13

[libvirt] [PATCH] allow snapshots of network sheepdog disks
by Vasiliy Tolstov 12 Oct '16

12 Oct '16

Sometimes ago in f7c1410b0ee5b878e81f2eddf86c609947a9b27c ability to snapshot sheepdog disk removed. But sheepdog have ability to store vm state inside special object type. Vasiliy Tolstov (1): sheepdog: allow snapshot src/qemu/qemu_driver.c | 6 ++++++ 1 file changed, 6 insertions(+) -- 2.7.4

2 4

[libvirt] [PATCH v3] qemu-migration: Disallow migration of read only disk
by Corey S. McQuay 12 Oct '16

12 Oct '16

Currently Libvirt allows attempts to migrate read only disks. Qemu cannot handle this as read only disks cannot be written to on the destination system. The end result is a cryptic error message and a failed migration. This patch causes migration to fail earlier and provides a meaningful error message stating that migrating read only disks is not supported. Signed-off-by: Corey S. McQuay <csmcquay(a)linux.vnet.ibm.com> Reviewed-by: Jason J. Herne <jjherne(a)linux.vnet.ibm.com> Reviewed-by: Boris Fiuczynski <fiuczy(a)linux.vnet.ibm.com> --- src/qemu/qemu_migration.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/src/qemu/qemu_migration.c b/src/qemu/qemu_migration.c index e451ef6..c8fb7ec 100644 --- a/src/qemu/qemu_migration.c +++ b/src/qemu/qemu_migration.c @@ -1764,6 +1764,12 @@ qemuMigrationStartNBDServer(virQEMUDriverPtr driver, /* check whether disk should be migrated */ if (!qemuMigrateDisk(disk, nmigrate_disks, migrate_disks)) continue; + + if (disk->src->readonly) { + virReportError(VIR_ERR_OPERATION_UNSUPPORTED, + _("Cannot migrate read-only disk %s"), disk->dst); + goto cleanup; + } VIR_FREE(diskAlias); if (!(diskAlias = qemuAliasFromDisk(disk))) -- 2.7.4

4 4

[libvirt] [PATCH 0/4] systemd-related fixes and improvements
by Andrea Bolognani 11 Oct '16

11 Oct '16

Make libvirt on systemd nicer for the user, by getting rid of some confusing behavior, and overall more solid. More details in each specific patch. Andrea Bolognani (4): virtlogd.socket: Tie lifecycle to libvirtd.service libvirt-guests.service: Improve description libvirt-guests.service: Split After= relationship libvirt-guests.service: Add Requires=libvirtd.service daemon/libvirtd.service.in | 1 + src/logging/virtlogd.service.in | 2 ++ src/logging/virtlogd.socket.in | 2 ++ tools/libvirt-guests.service.in | 7 +++++-- 4 files changed, 10 insertions(+), 2 deletions(-) -- 2.7.4

3 14

[libvirt] [PATCH] libvirt-storage.c:Lines too long, use 80 character columns.
by Nitesh Konkar 11 Oct '16

11 Oct '16

Signed-off-by: Nitesh Konkar <nitkon12(a)linux.vnet.ibm.com> --- src/libvirt-storage.c | 24 ++++++++++++++++-------- 1 file changed, 16 insertions(+), 8 deletions(-) diff --git a/src/libvirt-storage.c b/src/libvirt-storage.c index 48996ba..c4f2a03 100644 --- a/src/libvirt-storage.c +++ b/src/libvirt-storage.c @@ -233,7 +233,8 @@ virConnectNumOfDefinedStoragePools(virConnectPtr conn) virCheckConnectReturn(conn, -1); - if (conn->storageDriver && conn->storageDriver->connectNumOfDefinedStoragePools) { + if (conn->storageDriver && + conn->storageDriver->connectNumOfDefinedStoragePools) { int ret; ret = conn->storageDriver->connectNumOfDefinedStoragePools(conn); if (ret < 0) @@ -280,7 +281,8 @@ virConnectListDefinedStoragePools(virConnectPtr conn, virCheckNonNullArgGoto(names, error); virCheckNonNegativeArgGoto(maxnames, error); - if (conn->storageDriver && conn->storageDriver->connectListDefinedStoragePools) { + if (conn->storageDriver && + conn->storageDriver->connectListDefinedStoragePools) { int ret; ret = conn->storageDriver->connectListDefinedStoragePools(conn, names, maxnames); if (ret < 0) @@ -332,7 +334,8 @@ virConnectFindStoragePoolSources(virConnectPtr conn, virCheckNonNullArgGoto(type, error); virCheckReadOnlyGoto(conn->flags, error); - if (conn->storageDriver && conn->storageDriver->connectFindStoragePoolSources) { + if (conn->storageDriver && + conn->storageDriver->connectFindStoragePoolSources) { char *ret; ret = conn->storageDriver->connectFindStoragePoolSources(conn, type, srcSpec, flags); if (!ret) @@ -485,7 +488,8 @@ virStoragePoolLookupByVolume(virStorageVolPtr vol) virCheckStorageVolReturn(vol, NULL); - if (vol->conn->storageDriver && vol->conn->storageDriver->storagePoolLookupByVolume) { + if (vol->conn->storageDriver && + vol->conn->storageDriver->storagePoolLookupByVolume) { virStoragePoolPtr ret; ret = vol->conn->storageDriver->storagePoolLookupByVolume(vol); if (!ret) @@ -1188,7 +1192,8 @@ virStoragePoolNumOfVolumes(virStoragePoolPtr pool) virCheckStoragePoolReturn(pool, -1); - if (pool->conn->storageDriver && pool->conn->storageDriver->storagePoolNumOfVolumes) { + if (pool->conn->storageDriver && + pool->conn->storageDriver->storagePoolNumOfVolumes) { int ret; ret = pool->conn->storageDriver->storagePoolNumOfVolumes(pool); if (ret < 0) @@ -1230,7 +1235,8 @@ virStoragePoolListVolumes(virStoragePoolPtr pool, virCheckNonNullArgGoto(names, error); virCheckNonNegativeArgGoto(maxnames, error); - if (pool->conn->storageDriver && pool->conn->storageDriver->storagePoolListVolumes) { + if (pool->conn->storageDriver && + pool->conn->storageDriver->storagePoolListVolumes) { int ret; ret = pool->conn->storageDriver->storagePoolListVolumes(pool, names, maxnames); if (ret < 0) @@ -1297,7 +1303,8 @@ virStorageVolLookupByName(virStoragePoolPtr pool, virCheckStoragePoolReturn(pool, NULL); virCheckNonNullArgGoto(name, error); - if (pool->conn->storageDriver && pool->conn->storageDriver->storageVolLookupByName) { + if (pool->conn->storageDriver && + pool->conn->storageDriver->storageVolLookupByName) { virStorageVolPtr ret; ret = pool->conn->storageDriver->storageVolLookupByName(pool, name); if (!ret) @@ -1471,7 +1478,8 @@ virStorageVolCreateXML(virStoragePoolPtr pool, virCheckNonNullArgGoto(xmlDesc, error); virCheckReadOnlyGoto(pool->conn->flags, error); - if (pool->conn->storageDriver && pool->conn->storageDriver->storageVolCreateXML) { + if (pool->conn->storageDriver && + pool->conn->storageDriver->storageVolCreateXML) { virStorageVolPtr ret; ret = pool->conn->storageDriver->storageVolCreateXML(pool, xmlDesc, flags); if (!ret) -- 2.1.0

3 3

[libvirt] dnsmasq option "dhcp-authoritative" in libvirt virtual networks?
by Martin Wilck 10 Oct '16

10 Oct '16

Hello, I am seeing a slightly annoying behavior of libvirt-created networks on my system. Whenever a VM fails to renew its DHCP lease in time (for example because my laptop is suspended), the IP address changes, causing various annoyances. If this happens, the log message "DHCPNAK(virbrX): ... lease not found" appears in the libvirtd logs. Looking at the dnsmasq code, it seems that this would be fixed by running dnsmasq with the "dhcp-authoritative" option, which, according to the dnsmasq man page, "should be set when dnsmasq is definitely the only DHCP server on a network" - IMO that's the case for libvirtd- managed virtual networks. So the question comes to my mind: is there a good reason why libvirtd doesn't set "dhcp-authoritative" on the dnsmasq instances it starts? Regards Martin -- Dr. Martin Wilck <mwilck(a)suse.com>, Tel. +49 (0)911 74053 2107 SUSELinux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg)

4 6

[libvirt] [PATCH 00/11] cleanups and improvements for video device code
by Pavel Hrdina 10 Oct '16

10 Oct '16

Pavel Hrdina (11): tests: fix some QXL capability combinations that doesn't make sense qemu_capabilities: join capabilities for qxl and qxl-vga devices qemu_capabilities: mark QEMU_CAPS_VGA_QXL capability as deprecated qemu_domain: move video validation out of qemu_command qemu_process: move video validation out of qemu_command qemu_capabilities: rename QEMU_CAPS_VIRTIO_GPU_VIRGL qemu_command: separate code for video device via -vga attribute qemu_command: cleanup qemuBuildVideoCommandLine qemu_capabilities: check for existence of virtio-vga qemu_command: properly detect which model to use for video device qemu_command: add support to use virtio as secondary video device docs/formatdomain.html.in | 3 +- src/qemu/qemu_capabilities.c | 23 +- src/qemu/qemu_capabilities.h | 15 +- src/qemu/qemu_command.c | 335 +++++++++------------ src/qemu/qemu_domain.c | 70 +++++ src/qemu/qemu_domain.h | 3 + src/qemu/qemu_domain_address.c | 6 - src/qemu/qemu_process.c | 54 +++- .../qemu_2.6.0-gicv2-virt.aarch64.xml | 1 - .../qemu_2.6.0-gicv3-virt.aarch64.xml | 1 - tests/domaincapsschemadata/qemu_2.6.0.aarch64.xml | 1 - tests/domaincapsschemadata/qemu_2.6.0.ppc64le.xml | 1 - .../qemucapabilitiesdata/caps_1.2.2.x86_64.replies | 70 +---- tests/qemucapabilitiesdata/caps_1.2.2.x86_64.xml | 4 - .../qemucapabilitiesdata/caps_1.3.1.x86_64.replies | 76 +---- tests/qemucapabilitiesdata/caps_1.3.1.x86_64.xml | 4 - .../qemucapabilitiesdata/caps_1.4.2.x86_64.replies | 74 +---- tests/qemucapabilitiesdata/caps_1.4.2.x86_64.xml | 4 - .../qemucapabilitiesdata/caps_1.5.3.x86_64.replies | 74 +---- tests/qemucapabilitiesdata/caps_1.5.3.x86_64.xml | 4 - .../qemucapabilitiesdata/caps_1.6.0.x86_64.replies | 74 +---- tests/qemucapabilitiesdata/caps_1.6.0.x86_64.xml | 4 - .../qemucapabilitiesdata/caps_1.7.0.x86_64.replies | 74 +---- tests/qemucapabilitiesdata/caps_1.7.0.x86_64.xml | 4 - .../qemucapabilitiesdata/caps_2.1.1.x86_64.replies | 74 +---- tests/qemucapabilitiesdata/caps_2.1.1.x86_64.xml | 4 - .../qemucapabilitiesdata/caps_2.4.0.x86_64.replies | 107 ++----- tests/qemucapabilitiesdata/caps_2.4.0.x86_64.xml | 6 +- .../qemucapabilitiesdata/caps_2.5.0.x86_64.replies | 117 +++---- tests/qemucapabilitiesdata/caps_2.5.0.x86_64.xml | 6 +- .../caps_2.6.0-gicv2.aarch64.replies | 43 ++- .../caps_2.6.0-gicv2.aarch64.xml | 1 - .../caps_2.6.0-gicv3.aarch64.replies | 43 ++- .../caps_2.6.0-gicv3.aarch64.xml | 1 - .../caps_2.6.0.ppc64le.replies | 43 ++- tests/qemucapabilitiesdata/caps_2.6.0.ppc64le.xml | 2 +- .../qemucapabilitiesdata/caps_2.6.0.x86_64.replies | 117 +++---- tests/qemucapabilitiesdata/caps_2.6.0.x86_64.xml | 6 +- .../qemucapabilitiesdata/caps_2.7.0.x86_64.replies | 122 +++----- tests/qemucapabilitiesdata/caps_2.7.0.x86_64.xml | 6 +- tests/qemuhelptest.c | 4 - .../qemuxml2argv-pcie-root-port.args | 5 +- .../qemuxml2argv-pcie-switch-downstream-port.args | 5 +- .../qemuxml2argv-pcie-switch-upstream-port.args | 5 +- .../qemuxml2argv-pcihole64-q35.args | 5 +- .../qemuxml2argv-q35-usb2-multi.args | 5 +- .../qemuxml2argv-q35-usb2-reorder.args | 5 +- tests/qemuxml2argvdata/qemuxml2argv-q35-usb2.args | 5 +- tests/qemuxml2argvdata/qemuxml2argv-q35.args | 5 +- .../qemuxml2argv-video-virtio-gpu-device.args | 2 +- .../qemuxml2argv-video-virtio-gpu-sec.args | 25 ++ .../qemuxml2argv-video-virtio-gpu-sec.xml | 36 +++ .../qemuxml2argv-video-virtio-gpu-spice-gl.args | 2 +- .../qemuxml2argv-video-virtio-gpu-virgl.args | 2 +- .../qemuxml2argv-video-virtio-vga.args | 24 ++ ...evice.xml => qemuxml2argv-video-virtio-vga.xml} | 11 +- tests/qemuxml2argvtest.c | 152 +++++----- tests/qemuxml2xmltest.c | 18 +- 58 files changed, 778 insertions(+), 1215 deletions(-) create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-video-virtio-gpu-sec.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-video-virtio-gpu-sec.xml create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-video-virtio-vga.args rename tests/qemuxml2argvdata/{qemuxml2argv-video-qxl-sec-nodevice.xml => qemuxml2argv-video-virtio-vga.xml} (77%) -- 2.10.0

2 31

[libvirt] [PATCH v2 00/20] Split parsing and defining logic of daemon's logging
by Erik Skultety 10 Oct '16

10 Oct '16

v2 of the original series https://www.redhat.com/archives/libvir-list/2016-May/msg00229.html since v1: - as Cole pointed out in 20/38 of the original series, the patches were not designed in an elegant way and they were hard to review, so this series reworked the whole series: -> first the existing methods that do combine parsing and defining logic and which should be dropped are renamed to a more accurate name -> all the necessary methods to achieve the "split" are introduced gradually, interconnected with each other -> finally, all the callers switch to the new logic introduced in the early patches in a transparent way -> all the original poorly named methods are completely dropped - also, the original series introduced a new set of API locks because there was an issue with 2 concurrent setters that while setter1 was preparing its local set of outputs to replace the existing global one, setter2 might just replace the global set with its copy, invalidating all fds of the setter1's set because the original series used a concept of *copying* (not duplicating) of fds, so the copied fd would be invalidated by issuing reset by setter2. This series however, duplicates the file-based outputs' (that should remain opened) fds. So even if setter2 replaces the original set with its copy and calls reset, effectively closing all fds, it does not matter for setter1, since unlink only decrements the number of references to a specific opened fd. Erik Skultety (20): virlog: Rename virLogParse* to virLogParseAndDefine* virlog: Introduce virLogOutputNew virlog: Introduce virLogFilterNew virlog: Introduce virLogFindOutput virlog: Introduce virLogDefineOutputs virlog: Introduce virLogDefineFilters virlog: Introduce virLogNewOutputTo* as a replacement for virLogAddOutputTo* virlog: Take a special care of syslog when setting new set of log outputs virlog: Introduce virLogParseOutput virlog: Introduce virLogParseFilter virlog: Introduce virLogParseOutputs virlog: Introduce virLogParseFilters virlog: Introduce virLogSetOutputs virlog: Introduce virLogSetFilters daemon: Split output parsing and output defining daemon: Split filter parsing and filter defining virlog: Remove functions that aren't used anywhere anymore virlog: Make some of the methods static virlog: Store the journald fd within the output object virlog: Split parsing and setting priority daemon/libvirtd.c | 8 +- src/libvirt_private.syms | 10 +- src/locking/lock_daemon.c | 8 +- src/logging/log_daemon.c | 8 +- src/util/virlog.c | 1079 ++++++++++++++++++++++++++------------------- src/util/virlog.h | 61 +-- tests/eventtest.c | 3 +- tests/testutils.c | 11 +- tests/virlogtest.c | 10 +- 9 files changed, 702 insertions(+), 496 deletions(-) -- 2.5.5

3 52

[libvirt] [RFC v2] libvirt vGPU QEMU integration
by Kirti Wankhede 07 Oct '16

07 Oct '16

Hi libvirt experts, Thanks for valuable input on v1 version of RFC. Quick brief, VFIO based mediated device framework provides a way to virtualize their devices without SR-IOV, like NVIDIA vGPU, Intel KVMGT and IBM's channel IO. This framework reuses VFIO APIs for all the functionalities for mediated devices which are currently being used for pass through devices. This framework introduces a set of new sysfs files for device creation and its life cycle management. Here is the summary of discussion on v1: 1. Discover mediated device: As part of physical device initialization process, vendor driver will register their physical devices, which will be used to create virtual device (mediated device, aka mdev) to the mediated framework. Vendor driver should specify mdev_supported_types in directory format. This format is class based, for example, display class directory format should be as below. We need to define such set for each class of devices which would be supported by mediated device framework. --- mdev_destroy --- mdev_supported_types |-- 11 | |-- create | |-- name | |-- fb_length | |-- resolution | |-- heads | |-- max_instances | |-- params | |-- requires_group |-- 12 | |-- create | |-- name | |-- fb_length | |-- resolution | |-- heads | |-- max_instances | |-- params | |-- requires_group |-- 13 |-- create |-- name |-- fb_length |-- resolution |-- heads |-- max_instances |-- params |-- requires_group In the above example directory '11' represents a type id of mdev device. 'name', 'fb_length', 'resolution', 'heads', 'max_instance' and 'requires_group' would be Read-Only files that vendor would provide to describe about that type. 'create': Write-only file. Mandatory. Accepts string to create mediated device. 'name': Read-Only file. Mandatory. Returns string, the name of that type id. 'fb_length': Read-only file. Mandatory. Returns <number>{K,M,G}, size of framebuffer. 'resolution': Read-Only file. Mandatory. Returns 'hres x vres' format. Maximum supported resolution. 'heads': Read-Only file. Mandatory. Returns integer. Number of maximum heads supported. 'max_instance': Read-Only file. Mandatory. Returns integer. Returns maximum mdev device could be created at the moment when this file is read. This count would be updated by vendor driver. Before creating mdev device of this type, check if max_instance is > 0. 'params' Write-Only file. Optional. String input. Libvirt would pass the string given in XML file to this file and then create mdev device. Set empty string to clear params. For example, set parameter 'frame_rate_limiter=0' to disable frame rate limiter for performance benchmarking, then create device of type 11. The device created would have that parameter set by vendor driver. 'requires_group' Read-Only file. Optional. This should be provided by vendor driver if vendor driver need to group mdev devices in one domain so that vendor driver can use 'first open' to commit resources of all mdev devices associated to that domain and 'last close' to free those. The parent device would look like: <device> <name>pci_0000_86_00_0</name> <capability type='pci'> <domain>0</domain> <bus>134</bus> <slot>0</slot> <function>0</function> <capability type='mdev'>  <type id='11'>  <name>GRID M60-0B</name> <attribute name='fb_length'>512M</attribute> <attribute name='resolution'>2560x1600</attribute> <attribute name='heads'>2</attribute> <attribute name='max_instances'>16</attribute> <attribute name='requires_group'>1</attribute> </type> </capability> <product id='...'>GRID M60</product> <vendor id='0x10de'>NVIDIA</vendor> </capability> </device> 2. Create/destroy mediated device With above example, vGPU device XML would look like: <device> <name>my-vgpu</name> <parent>pci_0000_86_00_0</parent> <capability type='mdev'> <type id='11'/> <group>1</group> <params>'frame_rate_limiter=0'</params> </capability> </device> 'type id' is mandatory. 'group' is optional. It should be a unique number in the system among all the groups created for mdev devices. Its usage is: - not needed if single vGPU device is being assigned to a domain. - only need to be set if multiple vGPUs need to be assigned to a domain and vendor driver have 'requires_group' file in type id directory. - if type id directory include 'requires_group' and user tries to assign multiple vGPUs to a domain without having <group> field in XML, it will create single vGPU. 'params' is optional field. User should set this field if extra parameters need to be set for a particular vGPU device. Libvirt don't need to parse these params. These are meant for vendor driver. Libvirt need to follow the sequence to create device: * Read /sys/../0000\:86\:00.0/11/max_instances. If it is greater than 0, then only proceed else fail. * Set extra params if 'params' field exist in device XML and 'params' file exist in type id directory echo "frame_rate_limiter=0" > /sys/../0000\:86\:00.0/11/params * Autogenerate UUID * Create device: echo "$UUID:<group>" > /sys/../0000\:86\:00.0/11/create where <group> is optional. Group should be unique number among all the groups created for mdev devices. * Clear params, if set earlier: echo "" > /sys/../0000\:86\:00.0/11/params * To destroy device: echo $UUID > /sys/../0000\:86\:00.0/mdev_destroy 3. Start/stop mediated device No change or requirement for libvirt as this will be handled by open() and close() callbacks to vendor driver. In case of multiple devices and 'requires_group' set, this will be handled in 'first open()' and 'last close()' on device in that group. 4. Launch QEMU/VM Pass the mdev sysfs path to QEMU as vfio-pci device. For above vGPU device example: -device vfio-pci,sysfsdev=/sys/bus/mdev/devices/$UUID 5. QEMU/VM Shutdown sequence No change or requirement for libvirt. 6. VM Reset No change or requirement for libvirt as this will be handled via VFIO reset API and QEMU process will keep running as before. 7. Hot-plug It is same syntax to create a virtual device for hot-plug. Thanks, Kirti

8 60

[libvirt] [PATCH] qemu_process: add pid of vm in domain log
by Chen Hanxiao 06 Oct '16

06 Oct '16

From: Chen Hanxiao <chenhanxiao(a)gmail.com> Add pid of VM in domain log. We used to show this info in debug log. For example: If a process send SIGKILL to a qemu process, we could find something in audit logs. Then the pid of VM in domain log will be helpful. Signed-off-by: Chen Hanxiao <chenhanxiao(a)gmail.com> --- src/qemu/qemu_process.c | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c index 27d04a4..8510a89 100644 --- a/src/qemu/qemu_process.c +++ b/src/qemu/qemu_process.c @@ -5392,11 +5392,14 @@ qemuProcessLaunch(virConnectPtr conn, _("Domain %s didn't show up"), vm->def->name); rv = -1; } - VIR_DEBUG("QEMU vm=%p name=%s running with pid=%llu", - vm, vm->def->name, (unsigned long long)vm->pid); + qemuDomainLogContextWrite(logCtxt, + "QEMU vm=%p name=%s running with pid=%llu\n", + vm, + vm->def->name, + (unsigned long long)vm->pid); } else { - VIR_DEBUG("QEMU vm=%p name=%s failed to spawn", - vm, vm->def->name); + qemuDomainLogContextWrite(logCtxt, "QEMU vm=%p name=%s failed to spawn", + vm, vm->def->name); } VIR_DEBUG("Writing early domain status to disk"); -- 1.8.3.1

3 2