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(a)redhat.com | libxml GNOME XML XSLT toolkit
http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine
http://rpmfind.net/