10:09 a.m.
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 -=|
10:24 a.m.
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(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
11:31 a.m.
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 -=|
6673
days inactive
6673
days old
2 comments
2 participants
participants (2)
-
Daniel P. Berrange -
Daniel Veillard