- Devel - libvirt List Archives

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

14 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 14 Sep '09

14 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 14 Sep '09

14 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 14 Sep '09

14 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

[libvirt] [PATCH] Save vcpuinfo in status file
by Daniel P. Berrange 11 Sep '09

11 Sep '09

* 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

2 1

[libvirt] Postponing 0.7.1 release by a couple of days
by Daniel Veillard 11 Sep '09

11 Sep '09

We still commited quite a bit in the last few days and I think taking a couple of extra days for testing is a bit safer, so I suggest to make the release only on Tuesday. So we have today and this week end for testing, push fixes if needed on Monday and I would make the release early on tuesday, Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel(a)veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/

1 0

[libvirt] [PATCH] Restart libvirtd upon RPM upgrade
by Daniel P. Berrange 11 Sep '09

11 Sep '09

* libvirt.spec.in: Restart libvirtd in %post --- libvirt.spec.in | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/libvirt.spec.in b/libvirt.spec.in index 0157eee..8d4c8cc 100644 --- a/libvirt.spec.in +++ b/libvirt.spec.in @@ -471,6 +471,9 @@ fi %endif /sbin/chkconfig --add libvirtd +if [ "$1" -ge "1" ]; then + /sbin/service libvirtd condrestart > /dev/null 2>&1 +fi %endif %preun -- 1.6.2.5

2 1