September 2009 - Devel - libvirt List Archives

[libvirt] ESX [10/12]: Replace esxUtil_EqualSuffix() with virFileHasSuffix()
by Matthias Bolte 13 Sep '09

13 Sep '09

* src/esx/esx_util.[ch]: remove esxUtil_EqualSuffix() * src/esx/esx_driver.c, src/esx/esx_vmx.c: replace esxUtil_EqualSuffix() with virFileHasSuffix()

1 0

[libvirt] ESX [09/12]: Add esxDomainDefineXML()
by Matthias Bolte 13 Sep '09

13 Sep '09

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

1 0

[libvirt] ESX [08/12]: Add esxVI_Occurence enum to describe expected occurence of items
by Matthias Bolte 13 Sep '09

13 Sep '09

* 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()

1 0

[libvirt] ESX [06/12]: Add x86_64 detection based on the CPUID
by Matthias Bolte 13 Sep '09

13 Sep '09

* src/esx/esx_driver.c: add esxSupportsLongMode() and update esxCapsInit() * src/esx/esx_vi.[ch]: Add AnyType handling for lists * src/esx/esx_vi_types.c: bind VI type HostCpuIdInfo

1 0

[libvirt] ESX [04/12]: Add tests for the VMX to/from domain XML mapping
by Matthias Bolte 13 Sep '09

13 Sep '09

* 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

1 0

[libvirt] ESX [03/12]: Add esxDomainXMLToNative()
by Matthias Bolte 13 Sep '09

13 Sep '09

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

1 0

[libvirt] ESX [02/12]: Set challenge for auth callback to hostname
by Matthias Bolte 13 Sep '09

13 Sep '09

This enables the auth callback to automatically distinguish between requests for ESX host and vCenter credentials. * src/esx/esx_util.[ch]: set challenge for auth callback to hostname

1 0

[libvirt] Interface driver and ESX support
by Shahar Klein 13 Sep '09

13 Sep '09

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

4 14

[libvirt] Re: [PATCH 0/2] port over extboot from kvm
by Jan Kiszka 12 Sep '09

12 Sep '09

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

4 6

[libvirt] vnet<X>'s & interfaceStats().. KVM device numbering confusion?
by r-c＠rocketmail.com 12 Sep '09

12 Sep '09

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

2 2