* Uri Lublin <[EMAIL PROTECTED]> [2008-07-16 18:15]: > >Client side, for installation, we already have a solution that works for > >all types of guests: > > > >http://kvm.qumranet.com/kvmwiki/KVMTest > > > > >which is already integrated as a client test in autotest. Once you > >record your installation via kvmtest, then it is just matter for > >keeping the iso and an empty disk image around and replaying the > >installation with -snapshot. > > > > So guest installation is a client test. KVMtest has its own way of > managing/booting/communicating-with guests, and naturally does not use > KVM/KVMGuest classes of autotest server.
It does not use the KVM/KVMGuest classes in autotest server precisely because it is a client test, there is no need to do anything server-side w.r.t KVMTest. We ensure that we've built and installed whatever version of kvm on the target machine and that the target machine has access to require inputs (iso,disk image) and invoke KVMTest. > > How about the test, suggested by Marcelo/Chris, of changing physical cpu of > a VM > using taskset. Would that be a client test or a server test ? > What about stop/cont, save/restore ? > > 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. > > > > > > >Now, I'm actually more interested in doing the following: > > > >use kvmtest to replay an installation of a guest and instead of throwing > >the guest away once (running with -snapshot) it has passes the install, > >it is now ready to be used to execute autotest client tests or something > >else. > > autotest client tests can be consider as "guest load" which usually does is > orthogonal to the "real" kvm-test that is running (e.g. migration-test Definitely. I just want to utilize autotest to drive both guest creation and test orchestration which includes installation as well as testing known working guests in various scenarios and yes autotest simplifies generating "guest load". > while watching a movie, or migration-test while building the kernel). Also > what would you do for non-linux guest ? I'm not quite sure what to do here since non-linux guests isn't really in my scope beyond simple tests (installation, shutdown, reboot, configuration variance). > > > > >>We'll try this little exercise of writing a kvm-test on the server side > >>and on the client side and compare complexity. > > > >That's a bit vague, what sort of test are you talking about? If you > >mean installation, i'm not interested since that's been handled by > >KVMTest. > Are you actually running autotest tests with KVMTest installed guests? Do Yes, but the transition between using KVMtest to install aguest and running autotest inside isn't completely automated -- yet. > you have to manually exchange ssh-keys. Yeah, we'll need a solution, but it should be pretty simple to automate, Mostly likely pregenerate a key and serve it up to the guest via cdrom image and then install that into the guest. > >As to complexity, I urge you to look at the existing kvm u > >examples[2] in the autotest server dir, those look pretty darn simple to me > >and already include all of the infrastructure for capturing console > >logs, results and errors. > > It does look simple. It was written for a different purpose though, which > is to run autotest tests on guests, not to run kvm tests. Sure, but that doesn't mean it isn't a good infrastructure on top of which we can build kvm testing. > > > > > > >Oh, I forgot my pointer to the server setup last time: > > > >1. http://test.kernel.org/autotest/AutotestServerInstall > >2. autotest/server/samples/kvm.srv > > > > > > > So what do you propose ? > We've were thinking today how we can move things to the server and want to > get your (or anyone's) opinion. Does the server always starts (boots) > guests ? Do most tests run on the server-side (similar to [2]) or may Yeah, let me explain a bit more about how the server and clients work: You'll have one master server which runs the job monitor, it will look for autotest server files (.srv) and that file will run on the server, but you will write your srv file to execute on a set of machines that your master server manages. Autotest server maintains a db of machines. Looking at autotest/server/samples/sleeptest.srv: def run(machine): host = hosts.SSHHost(machine) at = autotest.Autotest(host) at.run_test('sleeptest') job.parallel_simple(run, machines) We're defining a run function, and then running that across all the machines in the grid. The other interesting one to look at is netperf-guest-to-host-far.srv. That file demonstrates installing kvm to differnt host machines (not the server where the .srv file is running); on each host machine, create a KVM guest, and then on each host, creating a KVM guest, in each guest, running a netperf test between each guest. > client tests start guests (similar to KVMTest and migration)? If both how > would you synchronize between them. If some tests run on the client side Synchronization is done via barriers, see autotest/client/tests/netperf2/netperf2.py and autotest/client/common_lib/barrier.py for more details. > and only the server starts guests, how do those tests access the guest. Do > you assume the guest images always exist before running the tests or do you > create them automatically if needed/requested. For multi-machine setup, either we'd need to create the image as needed, or you'll want some sort of shared storage mounted on each host that you want to run kvm tests upon. And obviously, shared storage is need as soon as we put migration into the mix. -- Ryan Harper Software Engineer; Linux Technology Center IBM Corp., Austin, Tx (512) 838-9253 T/L: 678-9253 [EMAIL PROTECTED] -- 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
