June 2014 - Devel - libvirt List Archives

[libvirt] [PATCH 1/1] libvirtd crash when defining scsi storage pool
by Pradipta Kr. Banerjee 05 Sep '14

05 Sep '14

libvirtd crashes when there is an existing SCSI pool with adapter type as 'scsi_host' and defining a new SCSI pool with adapter type as 'fc_host' and parent attribute missing. For eg when defining a storage-pool with the following XML will crash libvirtd if there already exists a SCSI pool with adapter type 'scsi_host' <pool type='scsi'> <name>TEST_SCSI_FC_POOL</name> <source> <adapter type='fc_host' wwnn='1234567890abcdef' wwpn='abcdef1234567890'/> </source> <target> <path>/dev/disk/by-path</path> </target> </pool> This happens because for fc_host, adapter 'name' is not relevant whereas for scsi_host its mandatory attribute. However the check in libvirt for finding duplicate storage pools doesn't take that into account while comparing, resulting into crash This patch fixes the issue Signed-off-by: Pradipta Kr. Banerjee <bpradip(a)in.ibm.com> --- src/conf/storage_conf.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/src/conf/storage_conf.c b/src/conf/storage_conf.c index 8b6fd79..54a4589 100644 --- a/src/conf/storage_conf.c +++ b/src/conf/storage_conf.c @@ -2126,8 +2126,10 @@ virStoragePoolSourceFindDuplicate(virStoragePoolObjListPtr pools, STREQ(pool->def->source.adapter.data.fchost.wwpn, def->source.adapter.data.fchost.wwpn)) matchpool = pool; - } else if (pool->def->source.adapter.type == - VIR_STORAGE_POOL_SOURCE_ADAPTER_TYPE_SCSI_HOST){ + } else if ((pool->def->source.adapter.type == + VIR_STORAGE_POOL_SOURCE_ADAPTER_TYPE_SCSI_HOST)\ + && (def->source.adapter.type == + VIR_STORAGE_POOL_SOURCE_ADAPTER_TYPE_SCSI_HOST)) { if (STREQ(pool->def->source.adapter.data.name, def->source.adapter.data.name)) matchpool = pool; -- 1.9.3

3 2

[libvirt] [PATCH] selinux: Avoid label reservations for type = none during restart
by Shivaprasad G Bhat 04 Sep '14

04 Sep '14

The problem is libvirt kills the guests during libvirt restart if more than guest has security type as none. This is because, libvirt as part of guest- reconnect tries to reserve the security labels. In case of type=none, the range of security context happen to be same for several guests. During reservation, the second attempt to reserve the same range fails and the Guests would be killed. The fix is to avoid reserving labels for type = none during libvirt restart. Signed-off-by: Shivaprasad G Bhat <sbhat(a)linux.vnet.ibm.com> --- src/security/security_selinux.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/security/security_selinux.c b/src/security/security_selinux.c index 008c58c..2f8a7f2 100644 --- a/src/security/security_selinux.c +++ b/src/security/security_selinux.c @@ -739,7 +739,8 @@ virSecuritySELinuxReserveSecurityLabel(virSecurityManagerPtr mgr, virSecurityLabelDefPtr seclabel; seclabel = virDomainDefGetSecurityLabelDef(def, SECURITY_SELINUX_NAME); - if (!seclabel || seclabel->type == VIR_DOMAIN_SECLABEL_STATIC) + if (!seclabel || seclabel->type == VIR_DOMAIN_SECLABEL_STATIC || + seclabel->type == VIR_DOMAIN_SECLABEL_NONE) return 0; if (getpidcon_raw(pid, &pctx) == -1) {

3 3

[libvirt] [RFC] powerpc : Add support for VM in compat mode
by Prerna Saxena 19 Aug '14

19 Aug '14

PowerISA allows processors to run VMs in binary compatibility ("compat") mode supporting an older version of ISA. Eg,in compatibility mode, a POWER8 host can run a "Power7" VM,conforming to PowerISA v2.06, while a POWER7 host can run a "POWER6" VM, conforming to PowerISA v2.05. QEMU has recently added support to explicitly denote a VM running in compatibility mode through commit 6d9412ea. Now, a "compat" mode VM can be run by invoking this qemu commandline on a POWER8 host: -cpu host,compat=power7 as against the older specification of "-cpu power7". However, running in compatibility mode is not identical to running natively on an older processor. Hence the virtualization stack needs to explicitly provide for a compat-mode VM. This patch allows libvirt to extend the "fallback" semantics of cpu model to describe this new mode for PowerKVM guests. Additionally with the new scheme of things, qemu doesn't provide a way to query for the supported compat models and models returned when querying with '-cpu ?' are no longer valid. Hence removing the check cpuModelIsAllowed() for now. When a user wants to request a power7 vm to run in compatibility mode on a Power8 host, this can be described in XML as follows : <cpu mode='custom' match='exact'> <model fallback='compat'>power7</model> </cpu> An alternative approach could be to leave the libvirt XML intact, and merely change the backend qemu command generation when the VM-requested cpu does not match the host processor. Looking forward to suggestions on how this can best be implemented.. Signed-off-by: Li Zhang <zhlcindy(a)linux.vnet.ibm.com> Signed-off-by: Pradipta Kr. Banerjee <bpradip(a)in.ibm.com> Signed-off-by: Prerna Saxena <prerna(a)linux.vnet.ibm.com> diff --git a/src/conf/cpu_conf.c b/src/conf/cpu_conf.c index ebdaa19..2f41bd7 100644 --- a/src/conf/cpu_conf.c +++ b/src/conf/cpu_conf.c @@ -47,7 +47,8 @@ VIR_ENUM_IMPL(virCPUMatch, VIR_CPU_MATCH_LAST, VIR_ENUM_IMPL(virCPUFallback, VIR_CPU_FALLBACK_LAST, "allow", - "forbid") + "forbid", + "compat") VIR_ENUM_IMPL(virCPUFeaturePolicy, VIR_CPU_FEATURE_LAST, "force", diff --git a/src/conf/cpu_conf.h b/src/conf/cpu_conf.h index 8c932ce..50354f2 100644 --- a/src/conf/cpu_conf.h +++ b/src/conf/cpu_conf.h @@ -65,6 +65,7 @@ VIR_ENUM_DECL(virCPUMatch) typedef enum { VIR_CPU_FALLBACK_ALLOW, VIR_CPU_FALLBACK_FORBID, + VIR_CPU_FALLBACK_COMPAT, VIR_CPU_FALLBACK_LAST } virCPUFallback; diff --git a/src/cpu/cpu_powerpc.c b/src/cpu/cpu_powerpc.c index b220448..218c013 100644 --- a/src/cpu/cpu_powerpc.c +++ b/src/cpu/cpu_powerpc.c @@ -457,8 +457,8 @@ ppcCompare(virCPUDefPtr host, static int ppcDecode(virCPUDefPtr cpu, const virCPUData *data, - const char **models, - unsigned int nmodels, + const char **models ATTRIBUTE_UNUSED, + unsigned int nmodels ATTRIBUTE_UNUSED, const char *preferred ATTRIBUTE_UNUSED, unsigned int flags) { @@ -478,13 +478,6 @@ ppcDecode(virCPUDefPtr cpu, goto cleanup; } - if (!cpuModelIsAllowed(model->name, models, nmodels)) { - virReportError(VIR_ERR_CONFIG_UNSUPPORTED, - _("CPU model %s is not supported by hypervisor"), - model->name); - goto cleanup; - } - if (VIR_STRDUP(cpu->model, model->name) < 0 || (model->vendor && VIR_STRDUP(cpu->vendor, model->vendor->name) < 0)) { goto cleanup; @@ -498,7 +491,6 @@ ppcDecode(virCPUDefPtr cpu, return ret; } - static void ppcDataFree(virCPUDataPtr data) { @@ -561,8 +553,8 @@ ppcUpdate(virCPUDefPtr guest, static virCPUDefPtr ppcBaseline(virCPUDefPtr *cpus, unsigned int ncpus, - const char **models, - unsigned int nmodels, + const char **models ATTRIBUTE_UNUSED, + unsigned int nmodels ATTRIBUTE_UNUSED, unsigned int flags) { struct ppc_map *map = NULL; @@ -582,13 +574,6 @@ ppcBaseline(virCPUDefPtr *cpus, goto error; } - if (!cpuModelIsAllowed(model->name, models, nmodels)) { - virReportError(VIR_ERR_CONFIG_UNSUPPORTED, - _("CPU model %s is not supported by hypervisor"), - model->name); - goto error; - } - for (i = 0; i < ncpus; i++) { const struct ppc_vendor *vnd; diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c index 1d5bce6..94e9b78 100644 --- a/src/qemu/qemu_command.c +++ b/src/qemu/qemu_command.c @@ -6176,7 +6176,9 @@ qemuBuildCpuArgStr(virQEMUDriverPtr driver, *hasHwVirt = hasSVM > 0 ? true : false; } - if (cpu->mode == VIR_CPU_MODE_HOST_PASSTHROUGH) { + if ((cpu->mode == VIR_CPU_MODE_HOST_PASSTHROUGH) || + ((cpu->mode == VIR_CPU_MODE_HOST_MODEL) && + (def->os.arch == VIR_ARCH_PPC64))) { const char *mode = virCPUModeTypeToString(cpu->mode); if (!virQEMUCapsGet(qemuCaps, QEMU_CAPS_CPU_HOST)) { virReportError(VIR_ERR_CONFIG_UNSUPPORTED, @@ -6208,7 +6210,13 @@ qemuBuildCpuArgStr(virQEMUDriverPtr driver, if (cpuDecode(guest, data, (const char **)cpus, ncpus, preferred) < 0) goto cleanup; - virBufferAdd(&buf, guest->model, -1); + if (def->os.arch == VIR_ARCH_PPC64 && + cpu->fallback == VIR_CPU_FALLBACK_COMPAT) { + virBufferAddLit(&buf, "host"); + virBufferAsprintf(&buf, ",compat=%s", guest->model); + } else + virBufferAdd(&buf, guest->model, -1); + if (guest->vendor_id) virBufferAsprintf(&buf, ",vendor=%s", guest->vendor_id); for (i = 0; i < guest->nfeatures; i++) { -- Prerna Saxena Linux Technology Centre, IBM Systems and Technology Lab, Bangalore, India

2 2

[libvirt] [RFC] require for suggestions on support for ivshmem device
by Wangrui (K) 28 Jul '14

28 Jul '14

Hi, Libvirt does not support ivshmem(Inter-VM Shared Memory) device recently, thus, I would like to know if there's any plan to support it in the future? If not, I would like to contribute a serial of patches to do so. On Jan 28, Wangyufei (James) asked about this question, and Daniel replied with 2 suggestions: 1. Libvirt should be capable of configuring the guest's xml on ivshmem. 2.An ivshmem daemon is needed to run on the host to support it, libvirt is recommended to provide such a daemon. Please refer to https://www.redhat.com/archives/libvir-list/2014-January/msg01335.html for details. What I'll do later is the 1st suggestion, the 2nd one is left to be accomplished by someone else. Here is the detailed work I'll do to support configuration of the guest in libvirt: virDomainDefParseXML: parse ivshmem device xml when defining dom.xml virDomainDeviceInfoIterateInternal: iterate ivshmem devices qemuAssignDevicePCISlots: assign ivshmem device pci slots virDomainDefFormatInternal: format ivshmem device xml (Eg. virsh edit dom) virDomainDefFree: free ivshmem device def qemuBuildCommandLine: build ivshmem device command line when vm starts qemuAssignDeviceAliases: assign ivshmem device aliases when vm starts virDomainDeviceDefParse: attach and parse ivshmem device xml qemuDomainAttachDeviceConfig: attach ivshmem device xml persistently qemuDomainAttachDeviceLive: attach ivshmem device online qemuDomainDetachDeviceConfig: detach ivshmem device xml persistently qemuDomainDetachDeviceLive: detach ivshmem device online There are two ways to use ivshmem with qemu (please refer to http://qemu.weilnetz.de/qemu-doc.html#pcsys_005fother_005fdevs ): 1.Guests map a POSIX shared memory region into the guest as a PCI device that enables zero-copy communication to the application level of the guests, The basic syntax is: qemu-system-i386-device ivshmem, size = <size in format accepted by -m> [, shm = <shm name>] 2.If desired, interrupts can be sent between guest VMs accessing the same shared memory region. Interrupt support requires using a shared memory server and using a chardev socket to connect to it. An example syntax when using the shared memory server is: qemu-system-i386-device ivshmem, size = <size in format accepted by -m> [, chardev = <id>] [, msi = on] [, ioeventfd = on] [, vectors = n] [, role = peer | master] qemu-system-i386-chardev socket, path = <path>, id = <id> The respective xml configuration for the above 2 qemu command lines are shown as below: Example1: automatically attach device with KVM <devices> <ivshmem role='master'> <memory name='dom-ivshmem' size='2'/> </ivshmem> </devices> NOTE: "size" means ivshmem size in unit MB, "name" means shm name "role" is optional, it may be set to "master" or "peer", the default one is "master" Example2: manually attach device with static PCI slot 4 requested <devices> <ivshmem role='master'> <memory name='dom-ivshmem' size='2'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> </ivshmem> </devices> Example3: automatically attach device with KVM <devices> <ivshmem role='master' type='unix'> <source mode='connect' path='/tmp/ivshmem'/> <memory name='dom-ivshmem' size='2'/> </ivshmem> </devices> NOTE: "path" means shared memory socket path which is set by the daemon. " source mode " and "type" is similar with vmchannel. I'm looking forward to your suggestions, thank you very much.

5 6

[libvirt] KVM Forum 2014 Call for Participation
by Paolo Bonzini 25 Jul '14

25 Jul '14

================================================================= KVM Forum 2014: Call For Participation October 14-16, 2014 - Congress Centre Düsseldorf - Düsseldorf, Germany (All submissions must be received before midnight July 27, 2014) ================================================================= KVM is an industry leading open source hypervisor that provides an ideal platform for datacenter virtualization, virtual desktop infrastructure, and cloud computing. Once again, it's time to bring together the community of developers and users that define the KVM ecosystem for our annual technical conference. We will discuss the current state of affairs and plan for the future of KVM, its surrounding infrastructure, and management tools. Mark your calendar and join us in advancing KVM. http://events.linuxfoundation.org/events/kvm-forum/ Once again we are colocated with the Linux Foundation's LinuxCon Europe, CloudOpen Europe, Embedded Linux Conference (ELC) Europe, and this year, the Linux Plumbers Conference. KVM Forum attendees will be able to attend LinuxCon + CloudOpen + ELC for a discounted rate. http://events.linuxfoundation.org/events/kvm-forum/attend/register We invite you to lead part of the discussion by submitting a speaking proposal for KVM Forum 2014. http://events.linuxfoundation.org/cfp Suggested topics: KVM/Kernel - Scaling and optimizations - Nested virtualization - Linux kernel performance improvements - Resource management (CPU, I/O, memory) - Hardening and security - VFIO: SR-IOV, GPU, platform device assignment - Architecture ports QEMU - Management interfaces: QOM and QMP - New devices, new boards, new architectures - Scaling and optimizations - Desktop virtualization and SPICE - Virtual GPU - virtio and vhost, including non-Linux or non-virtualized uses - Hardening and security - New storage features - Live migration and fault tolerance - High availability and continuous backup - Real-time guest support - Emulation and TCG - Firmware: ACPI, UEFI, coreboot, u-Boot, etc. - Testing Management and infrastructure - Managing KVM: Libvirt, OpenStack, oVirt, etc. - Storage: glusterfs, Ceph, etc. - Software defined networking: Open vSwitch, OpenDaylight, etc. - Network Function Virtualization - Security - Provisioning - Performance tuning =============== SUBMITTING YOUR PROPOSAL =============== Abstracts due: July 27, 2014 Please submit a short abstract (~150 words) describing your presentation proposal. Slots vary in length up to 45 minutes. Also include in your proposal the proposal type -- one of: - technical talk - end-user talk Submit your proposal here: http://events.linuxfoundation.org/cfp Please only use the categories "presentation" and "panel discussion" You will receive a notification whether or not your presentation proposal was accepted by Aug 20th. Speakers will receive a complimentary pass for the event. In the instance that your submission has multiple presenters, only the primary speaker for a proposal will receive a complementary event pass. For panel discussions, all panelists will receive a complimentary event pass. TECHNICAL TALKS A good technical talk should not just report on what has happened over the last year; it should present a concrete problem and how it impacts the user and/or developer community. Whenever applicable, it should focus on the work that needs to be done or the difficulties that haven't yet been solved. Summarizing recent developments is okay but it should not be more than a small portion of the overall talk. END-USER TALKS One of the big challenges as developers is to know what, where and how people actually use our software. We will reserve a few slots for end users talking about their deployment challenges and achievements. If you are using KVM in production you are encouraged submit a speaking proposal. Simply mark it as an end-user talk. As an end user, this is a unique opportunity to get your input to developers. HANDS-ON / BOF SESSIONS We will reserve some time for people to get together and discuss strategic decisions as well as other topics that are best solved within smaller groups. This time can also be used for hands-on hacking sessions if you have concrete code problems to solve. These sessions will be announced during the event. If you are interested in organizing such a session, please add it to the list at http://www.linux-kvm.org/page/KVM_Forum_2014_BOF Let people you think might be interested know about it, and encourage them to add their names to the wiki page as well. Please try to add your ideas to the list before KVM Forum starts. PANEL DISCUSSIONS If you are proposing a panel discussion, please make sure that you list all of your potential panelists in your abstract. We will request full biographies if a panel is accepted. =============== HOTEL / TRAVEL =============== The KVM Forum 2014 will be held in Düsseldorf, Germany at Congress Centre Düsseldorf http://events.linuxfoundation.org/events/kvm-forum/attend/hotel-and-travel =============== IMPORTANT DATES =============== Notification: August 20, 2014 Schedule announced: August 29, 2014 Event dates: October 14-16, 2014 Thank you for your interest in KVM. We're looking forward to your submissions and seeing you at the KVM Forum 2014 in October! -your KVM Forum 2014 Program Committee Please contact us with any questions or comments.

1 1

[libvirt] [PATCH 0/2] virtio serial address allocation
by Ján Tomko 24 Jul '14

24 Jul '14

Ján Tomko (2): Add test for virtio serial port assignment Implement virtio serial address allocation src/conf/domain_addr.c | 426 +++++++++++++++++++++ src/conf/domain_addr.h | 49 +++ src/conf/domain_conf.c | 30 -- src/libvirt_private.syms | 9 + src/qemu/qemu_command.c | 61 +++ src/qemu/qemu_domain.c | 1 + src/qemu/qemu_domain.h | 1 + src/qemu/qemu_hotplug.c | 31 +- tests/qemuhotplugtest.c | 2 +- .../qemuxml2argv-channel-virtio-auto.args | 8 +- .../qemuxml2argv-channel-virtio-autoassign.args | 20 + .../qemuxml2argv-channel-virtio-autoassign.xml | 50 +++ tests/qemuxml2argvtest.c | 2 + .../qemuxml2xmlout-channel-virtio-auto.xml | 10 +- 14 files changed, 658 insertions(+), 42 deletions(-) create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-channel-virtio-autoassign.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-channel-virtio-autoassign.xml -- 1.8.5.5

2 4

[libvirt] [PATCH libvirt-tck] docs: typo fixes
by Roman Bogorodskiy 23 Jul '14

23 Jul '14

Fix a few typos in docs/intro.pod. --- docs/intro.pod | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/docs/intro.pod b/docs/intro.pod index 3684d51..09227ae 100644 --- a/docs/intro.pod +++ b/docs/intro.pod @@ -47,7 +47,7 @@ hypervisor and libvirt release is configured correctly =back Thus the libvirt TCK will allow developers, administrators and users -to determine the level of compatability of their platform, and +to determine the level of compatibility of their platform, and evaluate whether it will meet their needs, and get awareness of any regressions that may have occurred since a previous test run @@ -249,7 +249,7 @@ running domain, replacing it with -1. =item * -QEMU refuseed to boot kernel+initrd unless at least one disk +QEMU refused to boot kernel+initrd unless at least one disk image is provided =back @@ -261,7 +261,7 @@ The libvirt-tck tool outputs results in a number of formats. The default format is a simple plain test summary listing each test case, and the pass/fail state, and details of each check failure -A more verbose text format otputs the full Perl TAP (Test Anything +A more verbose text format outputs the full Perl TAP (Test Anything Protocol) format results as described in 'man 3 TAP' or 'man 3 Test::Harness::TAP'. @@ -301,7 +301,7 @@ flag The code as it stands is the bare minimum to get a proof of concept working for testing of domain APIs for Xen and QEMU drivers. The test suite though -is intended to be independant of any driver, and also allow for coverage of +is intended to be independent of any driver, and also allow for coverage of all the libvirt APIs. Of the top of my head, some important things that need doing @@ -389,7 +389,7 @@ Fix up all the horribly broken areas of libvirt that this uncovers. This will entail deciding that the semantics for various edge cases are with each API. Deciding what errors codes need to be formally defined for each API. Figuring -out how to implement/fix the neccessary semantics in the +out how to implement/fix the necessary semantics in the drivers. =item Failure recording -- 1.9.0

2 3

[libvirt] [PATCH libvirt-tck] bhyve: reconnect to domains after libvirtd restart
by Roman Bogorodskiy 19 Jul '14

19 Jul '14

Try to reconnect to the running domains after libvirtd restart. To achieve that, do: * Save domain state - Modify virBhyveProcessStart() to save domain state to the state dir - Modify virBhyveProcessStop() to cleanup the pidfile and the state * Detect if the state information loaded from the driver's state dir matches the actual state. Consider domain active if: - PID it points to exist - Process title of this PID matches the expected one with the domain name Otherwise, mark the domain as shut off. Note: earlier development bhyve versions before FreeBSD 10.0-RELEASE didn't set proctitle we expect, so the current code will not detect it. I don't plan adding support for this unless somebody requests this. --- src/bhyve/bhyve_driver.c | 18 ++++++++++ src/bhyve/bhyve_process.c | 91 +++++++++++++++++++++++++++++++++++++++++++++++ src/bhyve/bhyve_process.h | 2 ++ 3 files changed, 111 insertions(+) diff --git a/src/bhyve/bhyve_driver.c b/src/bhyve/bhyve_driver.c index eb5fc95..4c7596e 100644 --- a/src/bhyve/bhyve_driver.c +++ b/src/bhyve/bhyve_driver.c @@ -1151,6 +1151,8 @@ bhyveStateInitialize(bool priveleged ATTRIBUTE_UNUSED, virStateInhibitCallback callback ATTRIBUTE_UNUSED, void *opaque ATTRIBUTE_UNUSED) { + virConnectPtr conn = NULL; + if (!priveleged) { VIR_INFO("Not running priveleged, disabling driver"); return 0; @@ -1199,6 +1201,15 @@ bhyveStateInitialize(bool priveleged ATTRIBUTE_UNUSED, } if (virDomainObjListLoadAllConfigs(bhyve_driver->domains, + BHYVE_STATE_DIR, + NULL, 1, + bhyve_driver->caps, + bhyve_driver->xmlopt, + 1 << VIR_DOMAIN_VIRT_BHYVE, + NULL, NULL) < 0) + goto cleanup; + + if (virDomainObjListLoadAllConfigs(bhyve_driver->domains, BHYVE_CONFIG_DIR, BHYVE_AUTOSTART_DIR, 0, bhyve_driver->caps, @@ -1207,9 +1218,16 @@ bhyveStateInitialize(bool priveleged ATTRIBUTE_UNUSED, NULL, NULL) < 0) goto cleanup; + conn = virConnectOpen("bhyve:///system"); + + virBhyveProcessReconnectAll(conn, bhyve_driver); + + virObjectUnref(conn); + return 0; cleanup: + virObjectUnref(conn); bhyveStateCleanup(); return -1; } diff --git a/src/bhyve/bhyve_process.c b/src/bhyve/bhyve_process.c index f3898f5..ea5ac9b 100644 --- a/src/bhyve/bhyve_process.c +++ b/src/bhyve/bhyve_process.c @@ -185,6 +185,11 @@ virBhyveProcessStart(virConnectPtr conn, vm->def->id = vm->pid; virDomainObjSetState(vm, VIR_DOMAIN_RUNNING, reason); + if (virDomainSaveStatus(driver->xmlopt, + BHYVE_STATE_DIR, + vm) < 0) + goto cleanup; + ret = 0; cleanup: @@ -257,6 +262,10 @@ virBhyveProcessStop(bhyveConnPtr driver, cleanup: virCommandFree(cmd); + + virPidFileDelete(BHYVE_STATE_DIR, vm->def->name); + virDomainDeleteConfig(BHYVE_STATE_DIR, NULL, vm); + return ret; } @@ -295,3 +304,85 @@ virBhyveGetDomainTotalCpuStats(virDomainObjPtr vm, return ret; } + +struct bhyveProcessReconnectData { + virConnectPtr conn; + bhyveConnPtr driver; + kvm_t *kd; +}; + +static int +virBhyveProcessReconnect(virDomainObjPtr vm, + void *opaque) +{ + struct bhyveProcessReconnectData *data = opaque; + struct kinfo_proc *kp; + int nprocs; + char **proc_argv; + char *expected_proctitle = NULL; + int ret = -1; + + if (!virDomainObjIsActive(vm)) + return 0; + + if (!vm->pid) + return 0; + + virObjectLock(vm); + + kp = kvm_getprocs(data->kd, KERN_PROC_PID, vm->pid, &nprocs); + if (kp == NULL || nprocs != 1) + goto cleanup; + + if (virAsprintf(&expected_proctitle, "bhyve: %s", vm->def->name) < 0) + goto cleanup; + + proc_argv = kvm_getargv(data->kd, kp, 0); + if (proc_argv && proc_argv[0]) + if (STREQ(expected_proctitle, proc_argv[0])) + ret = 0; + + cleanup: + if (ret < 0) { + /* If VM is reported to be in active state, but we cannot find + * its PID, then we clear information about the PID and + * set state to 'shutdown' */ + vm->pid = 0; + vm->def->id = -1; + virDomainObjSetState(vm, VIR_DOMAIN_SHUTOFF, + VIR_DOMAIN_SHUTOFF_UNKNOWN); + ignore_value(virDomainSaveStatus(data->driver->xmlopt, + BHYVE_STATE_DIR, + vm)); + } + + virObjectUnlock(vm); + VIR_FREE(expected_proctitle); + + return ret; +} + +void +virBhyveProcessReconnectAll(virConnectPtr conn, + bhyveConnPtr driver) +{ + kvm_t *kd; + struct bhyveProcessReconnectData data; + char errbuf[_POSIX2_LINE_MAX]; + + if ((kd = kvm_openfiles(NULL, NULL, NULL, O_RDONLY, errbuf)) == NULL) { + virReportError(VIR_ERR_SYSTEM_ERROR, + _("Unable to get kvm descriptor: %s"), + errbuf); + return; + + } + + data.conn = conn; + data.driver = driver; + data.kd = kd; + + virDomainObjListForEach(driver->domains, virBhyveProcessReconnect, &data); + + kvm_close(kd); +} diff --git a/src/bhyve/bhyve_process.h b/src/bhyve/bhyve_process.h index 3049ad0..006a5ae 100644 --- a/src/bhyve/bhyve_process.h +++ b/src/bhyve/bhyve_process.h @@ -37,6 +37,8 @@ int virBhyveProcessStop(bhyveConnPtr driver, int virBhyveGetDomainTotalCpuStats(virDomainObjPtr vm, unsigned long long *cpustats); +void virBhyveProcessReconnectAll(virConnectPtr conn, bhyveConnPtr driver); + typedef enum { VIR_BHYVE_PROCESS_START_AUTODESTROY = 1 << 0, } bhyveProcessStartFlags; -- 1.9.0

2 5

[libvirt] [libvirt-glib] gobject: Fix GEnum generation through glib-mkenums
by Christophe Fergeau 18 Jul '14

18 Jul '14

We were only passing libvirt-gobject-domain.h and libvirt-gobject-connection.h through glib-mkenums, which causes it to only generate GEnum information for enums found in these headers. We want to do that for all enums defined in installed headers, so passing all headers listed in libvirt_gobject_1_0_la_HEADERS is more appropriate. --- libvirt-gobject/Makefile.am | 4 ++-- libvirt-gobject/libvirt-gobject.sym | 5 +++++ 2 files changed, 7 insertions(+), 2 deletions(-) diff --git a/libvirt-gobject/Makefile.am b/libvirt-gobject/Makefile.am index 516c10f..7163c7d 100644 --- a/libvirt-gobject/Makefile.am +++ b/libvirt-gobject/Makefile.am @@ -93,7 +93,7 @@ libvirt_gobject_1_0_la_LDFLAGS = \ -Wl,--version-script=$(srcdir)/libvirt-gobject.sym \ -version-info $(LIBVIRT_GLIB_VERSION_INFO) -libvirt-gobject-enums.c: libvirt-gobject-domain.h libvirt-gobject-connection.h +libvirt-gobject-enums.c: $(libvirt_gobject_1_0_la_HEADERS) $(AM_V_GEN)glib-mkenums \ --fhead "#include \"libvirt-gobject/libvirt-gobject.h\"\n\n" \ --vhead "static const G@Type@Value _@enum_name@_values[] = {" \ @@ -106,7 +106,7 @@ libvirt-gobject-enums.c: libvirt-gobject-domain.h libvirt-gobject-connection.h --vtail " return type;\n}\n\n" \ $^ | sed -e 's/g_vir/gvir/g' > $@ -libvirt-gobject-enums.h: libvirt-gobject-domain.h libvirt-gobject-connection.h +libvirt-gobject-enums.h: $(libvirt_gobject_1_0_la_HEADERS) $(AM_V_GEN)glib-mkenums --fhead "#ifndef __LIBVIRT_GOBJECT_ENUMS_H__\n" \ --fhead "#define __LIBVIRT_GOBJECT_ENUMS_H__\n\n" \ --fhead "G_BEGIN_DECLS\n\n" \ diff --git a/libvirt-gobject/libvirt-gobject.sym b/libvirt-gobject/libvirt-gobject.sym index b781cc6..4e856e7 100644 --- a/libvirt-gobject/libvirt-gobject.sym +++ b/libvirt-gobject/libvirt-gobject.sym @@ -237,6 +237,11 @@ LIBVIRT_GOBJECT_0.1.5 { LIBVIRT_GOBJECT_0.1.9 { global: gvir_domain_snapshot_delete; + gvir_domain_snapshot_delete_flags_get_type; + gvir_storage_pool_state_get_type; + gvir_storage_vol_resize_flags_get_type; + gvir_storage_vol_type_get_type; + gvir_stream_io_condition_get_type; } LIBVIRT_GOBJECT_0.1.5; # .... define new API here using predicted next version number .... -- 1.9.3

2 2

[libvirt] libxl: Enable video device selection for Xen
by Stefan Bader 18 Jul '14

18 Jul '14

Sorry, this fell complete off my todos for a while. So I split off the fixup of VRAM into a separate patch which may or may not be used and only accept vga, xen and cirrus as supported types in the main patch. I believe I saw some discussions about how to fix some of the VRAM values as they are passed into qemu. At least for the Cirrus type I saw that the command line looked ok but the guest was getting a much larger VRAM size than it was told. -Stefan

3 9