[libvirt] [PATCH 1/1] libvirtd crash when defining scsi storage pool
by Pradipta Kr. Banerjee
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
10 years, 7 months
[libvirt] [PATCH] selinux: Avoid label reservations for type = none during restart
by Shivaprasad G Bhat
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) {
10 years, 7 months
[libvirt] [RFC] powerpc : Add support for VM in compat mode
by Prerna Saxena
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
10 years, 7 months
[libvirt] [RFC] require for suggestions on support for ivshmem device
by Wangrui (K)
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.
10 years, 8 months
[libvirt] KVM Forum 2014 Call for Participation
by Paolo Bonzini
=================================================================
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.
10 years, 8 months
[libvirt] [PATCH 0/2] virtio serial address allocation
by Ján Tomko
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
10 years, 8 months
[libvirt] [PATCH libvirt-tck] docs: typo fixes
by Roman Bogorodskiy
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
10 years, 8 months
[libvirt] [PATCH libvirt-tck] bhyve: reconnect to domains after libvirtd restart
by Roman Bogorodskiy
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
10 years, 8 months
[libvirt] [libvirt-glib] gobject: Fix GEnum generation through glib-mkenums
by Christophe Fergeau
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
10 years, 8 months
[libvirt] libxl: Enable video device selection for Xen
by Stefan Bader
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
10 years, 8 months
