Ryan Harper wrote:
* Uri Lublin <[EMAIL PROTECTED]> [2008-07-16 18:15]:
I think most kvm-tests will be client tests.
Agreed, the above examples will be client tests. Autotest client can do
parallel execution, or even step-wise. Between those, we should be able
to ensure we get proper coverage for the envisioned scenarios.
More complex tests, which involve multiple hosts, such as migration
between two hosts, should be server tests.
Managing all those tests, can be done by autoserv.
Agreed.
We all agree that most kvm tests are client-side tests. The server manages
multiple hosts and complex tests (such as multi-host migration). The server also
may run autotest tests on linux guests. We consider kvm-install, kvm-boot,
kvm-guest-install as client tests.
Following your comments our plan is to move the control to the server size:
The server executes a .srv file (or a server side control). It calls
client-tests (including simple building blocks such as kvm-installation,
boot/destroy a KVM-VM, etc), providing guest id and some specific tests
parameters. Guests are always created on the client (similar to current
kvm-autotest behaviour) and a client-side class that knows how to map guest-id
with a running guest (including guest-ip) will be used by all kvm client tests.
Accessing a linux guest (e.g. running autotest tests) can be done from the
server simply by using hosts.SSHHost just like any other linux host.
This will only work for global dhcp (no local host-only bridge) or if server and
host are the same.
Client tests can also be started from the client side using client-side control
files.
We do not know yet what we'll do with non-linux guests, but we sure want to test
them too.
Thanks,
Uri
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
