On Wed, Aug 16, 2006 at 11:24:38AM -0400, Daniel Veillard wrote: > On Wed, Aug 16, 2006 at 04:09:10PM +0100, Daniel P. Berrange wrote: > > > > The individual domains 'testdomfv0.xml' and 'testdomfc4.xml' are defined > > using the regular libvirt XML format. The only exception is that the 'type' > > attribute on the top level '<domain>' tag should be 'test' instead of 'xen' > > Sounds very cool :-) > > [...] > > Next up, I've written implementations of the set memory, set max memory, > > set vcpus, dump xml, create linux APIs for the test driver. THe only major > > Okay. Push that too, you're basically in control of the test driver :-) Ok, I've commited this now, along with example config files in the docs/ directory. > > areas of functionality lacking in the test driver now are handling of disk > > and network devices when creating domains, and the VCPU pinning methods. > > This test backend makes testing the virt-manager application much more > > reliable - although we still do need some level of testing against a real > > Xen backend (for example domain creation). > > The big problem of real regression tests is the amount of data needed, > it's like 1GB per Xen system image, I don't see how that could go into CVS, > though I would really like to be able to always run 'make tests' and know > I didn't broke something in my local changes ... I welcome ideas on the > subject, the test driver will allow to cover some part of the code, but > not all of it that's sure. Yeah, my intention for the test driver is that it lets us get unit test level coverage of all the APIs & virsh. For functional / integration testing though we'll need real Xen guests - given the complexity & reliance on state of the host system I think it would be unrealistic to expect this type of functionality to be run as part of 'make test'. My dev box runs many Xen guests of varying flavours - I wouldn't want to have to shut them all down load special libvirt test VMs, every time I did 'make test' :-) Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|