On Tue, Jul 08, 2008 at 05:40:17PM +0100, Daniel P. Berrange wrote:
> This is a refactoring of the XM driver. Previously we would store
> the virConfPtr objects as our master 'in memory' representation
> of inactive domains. This switch it over to using virDomainDefPtr
> objects instead. The code for reading/writing the config files is
> unchanged at this time.
[...]
> @@ -1291,9 +1217,10 @@ int xenXMDomainPinVcpu(virDomainPtr doma
> xenXMConfCachePtr entry;
> virBuffer mapbuf = VIR_BUFFER_INITIALIZER;
> char *mapstr = NULL;
> - char *ranges = NULL;
> int i, j, n, comma = 0;
> int ret = -1;
> + char *cpuset = NULL;
> + int maxcpu = 4096;
hum, we use MAX_VIRT_CPUS at places
> +++ b/tests/xmconfigdata/test-fullvirt-new-cdrom.xml Mon Jul 07 10:11:30 2008 -0400
> @@ -1,23 +1,23 @@
> <domain type='xen'>
> <name>XenGuest2</name>
> <uuid>c7a5fdb2-cdaf-9455-926a-d65c16db1809</uuid>
> + <memory>592896</memory>
> + <currentMemory>403456</currentMemory>
> + <vcpu>1</vcpu>
> <os>
> - <type>hvm</type>
> + <type arch='i686' machine='xenfv'>hvm</type>
I'm just a bit surprized by that addition, is that derived from
the features set ? I don't see why the arch can't be x86-64 for example
just based on the tests/xmconfigdata/test-fullvirt-new-cdrom.cfg config
data.
> +++ b/tests/xmconfigdata/test-paravirt-old-pvfb.xml Mon Jul 07 10:11:30 2008 -0400
[..]
> <devices>
> + <emulator>/usr/lib/xen/bin/qemu-dm</emulator>
So we are adding the emulator here, I guess nobody is gonna change that
A couple of surprises in the tests, but the replacement looks safe
+1
Daniel
--
Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard | virtualization library http://libvirt.org/
veillard@xxxxxxxxxx | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
--
Libvir-list mailing list
Libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list