On Thu, Jul 24, 2008 at 10:44:18AM -0400, Daniel Veillard wrote: > 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
Yeah, we need todo better here. The problem is Xen's idea of max CPU's is different from Linux's :-) > > +++ 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. What's happening is that in the Xen test suite we now define a static set of XML capabilities, which are independant of the host machine running the test. In the Xen case I defined the test suite to be a 32-bit machine, so the test XML files have to use 'i686'. Outside of the tst suite, the real capabilities data is fetched from the hypervisor so supports whatever is appropriate - i686, x86_64, ia64, ppc, etc. > > +++ 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 This is also driven off the capabilities data - so its just matching the the path defined in the test suite capabilities XML. In real Xen driver usage, it varies according to usr/lib vs /usr/lib64 on 32 vs 64 bit hosts Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
