[Libvir] Major extensio of test backend driver functionality
Ok, here comes the huge patch for today - a major extension of the test driver backend... As well as the interal hardcoded 'test:///default' hypervisor config you can now provide a path to an arbitrary XML file defining your HV and its domains. An example file to define a moster 128x6GHz CPU box with 128 GB of RAM and two guest domains looks like: <node> <domain file="testdomfv0.xml"/> <domain file="testdomfc4.xml"/> <cpu> <mhz>6000</mhz> <model>i986</model> <active>50</active> <nodes>4</nodes> <sockets>4</sockets> <cores>4</cores> <threads>2</threads> </cpu> <memory>137438953472</memory> </node> 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' So for example: $ virsh --connect test:///home/berrange/src/xen/libvirt/docs/testnode.xml virsh > nodeinfo CPU model: i986 CPU(s): 50 CPU frequency: 6000 MHz CPU socket(s): 4 Core(s) per socket: 4 Thread(s) per core: 2 NUMA cell(s): 4 Memory size: 137438953472 kB virsh > list Id Name State ---------------------------------- 0 fv0 running 1 fc4 running virsh > dominfo fc4 Id: 1 Name: fc4 UUID: ef861801-45b9-11cb-88e3-afbfe5370493 OS Type: linux State: running CPU(s): 1 CPU time: 1155740835.5s Max memory: 131072 kB Used memory: 131072 kB virsh > 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 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). 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 -=|
On Wed, Aug 16, 2006 at 04:09:10PM +0100, Daniel P. Berrange wrote:
Ok, here comes the huge patch for today - a major extension of the test driver backend...
As well as the interal hardcoded 'test:///default' hypervisor config you can now provide a path to an arbitrary XML file defining your HV and its domains. An example file to define a moster 128x6GHz CPU box with 128 GB of RAM and two guest domains looks like:
<node> <domain file="testdomfv0.xml"/> <domain file="testdomfc4.xml"/>
<cpu> <mhz>6000</mhz> <model>i986</model> <active>50</active> <nodes>4</nodes> <sockets>4</sockets> <cores>4</cores> <threads>2</threads> </cpu> <memory>137438953472</memory> </node>
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 :-)
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. Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
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 -=|
participants (2)
-
Daniel P. Berrange -
Daniel Veillard