[libvirt] ESX [09/12]: Add esxDomainDefineXML()
by Matthias Bolte
A given domain XML gets converted to a VMX config, uploaded to the host
and registered as new virtual machine.
* src/esx/esx_driver.c: refactor datastore related path parsing into
esxUtil_ParseDatastoreRelatedPath()
* src/esx/esx_util.[ch]: add esxUtil_ParseDatastoreRelatedPath()
* src/esx/esx_vi.[ch]: add esxVI_Context_UploadFile(), add datastores to
the traversal in esxVI_BuildFullTraversalSpecList(), add
esxVI_LookupDatastoreByName()
* src/esx/esx_vi_methods.[ch]: add esxVI_RegisterVM_Task()
* src/esx/esx_vi_types.c: make some error message more verbose
* src/esx/esx_vmx.[ch]: add esxVMX_AbsolutePathToDatastoreRelatedPath() to
convert a path into a datastore related path, add esxVMX_ParseFileName() to
convert from VMX path format to domain XML path format, extend the other
parsing function to be datastore aware, add esxVMX_FormatFileName() to
convert from domain XML path format to VMX path format, fix VMX ethernet
entry formating
* tests/esxutilstest.c: add test for esxUtil_ParseDatastoreRelatedPath()
* tests/vmx2xmldata/*: update domain XML files to use datastore related paths
* tests/xml2vmxdata/*: update domain XML files to use datastore related paths,
update VMX files to use absolute paths
15 years, 2 months
[libvirt] ESX [08/12]: Add esxVI_Occurence enum to describe expected occurence of items
by Matthias Bolte
* src/esx/esx_driver.c: update the use of esxVI_LookupVirtualMachineByUuid()
* src/esx/esx_vi.c: add an esxVI_Occurence parameter to
esxVI_LookupVirtualMachineByUuid() and take care if esxVI_FindByUuid() can't
find anything for a given uuid
* src/esx/esx_vi.h: add esxVI_Occurence enum
* src/esx/esx_vi_methods.c: expect null or more items to be returned from
esxVI_FindByUuid()
15 years, 2 months
[libvirt] ESX [04/12]: Add tests for the VMX to/from domain XML mapping
by Matthias Bolte
* tests/.gitignore: ignore new test binaries
* tests/Makefile.am: add new tests
* tests/esxutilstest.c: test esxVMX_IndexToDiskName()
* tests/vmx2xmldata/*: config files for the VMX to domain XML test
* tests/vmx2xmltest.c: test the VMX to domain XML mapping
* tests/xml2vmxdata/*: config files for the domain XML to VMX test
* tests/xml2vmxtest.c: test the domain XML to VMX mapping
15 years, 2 months
[libvirt] ESX [03/12]: Add esxDomainXMLToNative()
by Matthias Bolte
Extend and cleanup the VMX to domain XML mapping. Add the domain XML to VMX
mapping functions.
* src/esx/esx_driver.c: add esxDomainXMLToNative()
* src/esx/esx_vmx.[ch]: add esxVMX_SCSIDiskNameToControllerAndID(),
esxVMX_IDEDiskNameToControllerAndID(), esxVMX_FloppyDiskNameToController(),
esxVMX_GatherSCSIControllers(), add basic handling for the VMX guestOS entry
to distinguish between i686 and x86_64, make SCSI virtualDev VMX entry
optional as it should be, map the VMX networkName entry to the domain XML
interface bridge name, add basic mapping for serial devices in pipe mode,
add several esxVMX_Format*() functions
15 years, 2 months
[libvirt] Interface driver and ESX support
by Shahar Klein
I'm trying to get a feel of the python binding and the esx driver
Trying to get the number of interfaces hit(as anticipated) a non-support wall:
Traceback (most recent call last):
File "test.py", line 362, in ?
vmm.refresh()
File "test.py", line 189, in refresh
print self.conn.numOfDefinedInterfaces()
File "/usr/lib/python2.4/site-packages/libvirt.py", line 1347, in numOfDefinedInterfaces
if ret == -1: raise libvirtError ('virConnectNumOfDefinedInterfaces() failed', conn=self)
libvirt.libvirtError: this function is not supported by the hypervisor: virConnectNumOfDefinedInterfaces
I'm wondering how to fix it
can I register the esx driver as the interface driver?
so I can use the ESX web-services to handle all the interface issues that normally(?) netcf would handle?
if yes - how is it done?
I thought that configure --without-netcf would do the trick(it didn't-I think)
Thanks
Shahar
15 years, 2 months
[libvirt] Re: [PATCH 0/2] port over extboot from kvm
by Jan Kiszka
Gerd Hoffmann wrote:
> On 09/08/09 15:47, Jan Kiszka wrote:
>
>> Before setting this definitely useful feature in stone, I have two
>> questions though:
>>
>> - -drive ...,boot=on is logically in conflict with -boot. Yes, -boot
>> for x86 currently cannot differentiate between multiple disks, only
>> between boot media types. Still, this two-stage configuration is
>> rather unintuitive and looks like a patchwork. Given that we have
>> full control over all components, is it really the preferred
>> approach? I already thought about, e.g., -boot c2 to select the
>> second disk. Not that nice, but I would rather vote for a consistent
>> configuration than a scattered one.
>
> Disk numbers are bad. Define "second hard disk". Especially for a
> system with different kinds of disks (say one scsi and one virtio).
One could use the specification order, but I agree it's not very handy.
>
> Drives have names though which can be used to reference the disks, so we
> could use that instead. -boot cmd line syntax becomes a bit tricky then
> though, we somehow have to figure whenever the user gave us names or
> old-style letters. Something like this ...
>
> -drive if=virtio,id=sys,file=/path/to/disk.img
> -cdrom /path/to/install.iso
> -boot order=[sys],once=d,menu=off
Yes, this looks powerful and clean. One could even still define probe
orders like "-boot order=[sys][backup]d".
>
> ... might work out nicely. I suspect the libvirt folks will hate us for
> that though.
Does anyone from libvirt want to comment on this?
>
>> - This is just an implementation detail: Do we really need to implement
>> booting from virtio and scsi via an extension rom? Isn't it possible
>> to merge the corresponding support into the main bios?
>
> Well. There are quite a few. bochs pcbios, seabios, coreboot ...
Ok, but that's only an argument to have extboot as a workaround for
bioses not yet supporting scsi and virtio natively, isn't it? I'm
thinking long-term here, not arguing against a extboot-based short-term
solution.
Jan
--
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux
15 years, 2 months
[libvirt] vnet<X>'s & interfaceStats().. KVM device numbering confusion?
by r-c＠rocketmail.com
Hi libirt-list,
I am attempting to migrate from Xen->KVM and am having a little trouble understanding the new vnet<X> interface numbering scheme and how to use it to collect statistics of the interface using the interfaceStats() function.
In Xen, the ID for a given domain was know, and a corresponding vif<ID>.0 interface was brought up so it was easy to grab the stats (amongst other things).
Under my new KVM config I've realised that vnet<X> is brought up in a 'first free' fashion as opposed to a counter in the Xen case. This leaves me scratching my head a little bit, say I have a domain which has ended up with ID = 8, but may for instance have network 'vnet1' associated with it. I'm not sure how I can determine any association between the domain & which interface belongs to it! (e.g. a call to domain.interfaceStats() requires the correct network interface as a parameter).
Surely I must be missing something here? Anyone have any advice/workaround for this situation? Ideally I would like to either be able to hardcode vnet-labels in the XML description (tried but it's ignored), or otherwise keep vnet numbering in sync with domain ID.
Thanks in advance,
Ravi
15 years, 2 months
[libvirt] [PATCH] Save vcpuinfo in status file
by Daniel P. Berrange
* src/qemu_driver.c: Don't trust monitor for vcpu PID info on
restart
* src/domain_conf.c: Save and load vCPU PID info from domain
status file
---
src/domain_conf.c | 35 +++++++++++++++++++++++++++++++++++
src/qemu_driver.c | 5 +----
2 files changed, 36 insertions(+), 4 deletions(-)
diff --git a/src/domain_conf.c b/src/domain_conf.c
index 050cf50..5ae0775 100644
--- a/src/domain_conf.c
+++ b/src/domain_conf.c
@@ -3061,6 +3061,8 @@ static virDomainObjPtr virDomainObjParseXML(virConnectPtr conn,
xmlNodePtr oldnode;
virDomainObjPtr obj;
char *monitorpath;
+ xmlNodePtr *nodes = NULL;
+ int n, i;
if (!(obj = virDomainObjNew(conn)))
return NULL;
@@ -3133,9 +3135,32 @@ static virDomainObjPtr virDomainObjParseXML(virConnectPtr conn,
break;
}
+ n = virXPathNodeSet(conn, "./vcpus/vcpu", ctxt, &nodes);
+ if (n < 0)
+ goto error;
+ if (n) {
+ obj->nvcpupids = n;
+ if (VIR_REALLOC_N(obj->vcpupids, obj->nvcpupids) < 0)
+ goto error;
+
+ for (i = 0 ; i < n ; i++) {
+ char *pidstr = virXMLPropString(nodes[i], "pid");
+ if (!pidstr)
+ goto error;
+
+ if (virStrToLong_i(pidstr, NULL, 10, &(obj->vcpupids[i])) < 0) {
+ VIR_FREE(pidstr);
+ goto error;
+ }
+ VIR_FREE(pidstr);
+ }
+ VIR_FREE(nodes);
+ }
+
return obj;
error:
+ VIR_FREE(nodes);
virDomainChrDefFree(obj->monitor_chr);
virDomainObjFree(obj);
return NULL;
@@ -4422,6 +4447,16 @@ char *virDomainObjFormat(virConnectPtr conn,
virBufferVSprintf(&buf, " type='%s'/>\n",
virDomainChrTypeToString(obj->monitor_chr->type));
+
+ if (obj->nvcpupids) {
+ int i;
+ virBufferAddLit(&buf, " <vcpus>\n");
+ for (i = 0 ; i < obj->nvcpupids ; i++) {
+ virBufferVSprintf(&buf, " <vcpu pid='%d'/>\n", obj->vcpupids[i]);
+ }
+ virBufferAddLit(&buf, " </vcpus>\n");
+ }
+
if (!(config_xml = virDomainDefFormat(conn,
obj->def,
flags)))
diff --git a/src/qemu_driver.c b/src/qemu_driver.c
index 0e7d8d4..a65334f 100644
--- a/src/qemu_driver.c
+++ b/src/qemu_driver.c
@@ -336,10 +336,6 @@ qemuReconnectDomain(struct qemud_driver *driver,
goto error;
}
- if (qemudDetectVcpuPIDs(NULL, obj) < 0) {
- goto error;
- }
-
if (qemuUpdateActivePciHostdevs(driver, obj->def) < 0) {
goto error;
}
@@ -2519,6 +2515,7 @@ qemudMonitorCommandWithHandler(const virDomainObjPtr vm,
qemuMonitorDiscardPendingData(vm);
+ VIR_DEBUG("Send '%s'", cmd);
if (qemudMonitorSend(vm, cmd, scm_fd) < 0)
return -1;
--
1.6.2.5
15 years, 2 months
