Anytime we're dealing with multiple machines, it's good to consider involving the autotest server. If not, at a minimum I think we need an autotest client running on the other machine. The problem is, for reliable and repeatable testing, there needs to be some more control over both machines (i.e. configuration, installed verions, running services, etc.).
There are many other benefits here also, such as being able to run multi-machine testing from test-time compiled code (libvirt, kernel, and/or other dependencies). However, since not everyone wants to run the autotest server, we also need to support standalone client testing. One thought is perhaps to introduce a new "libvirt_host" module to support the functionality you're interested in (i.e. tests against libvirt that don't involve any guest VMs). Perhaps make a libvirt_host class as a "list" subclass where the items are VM instances? With or without a new libvirt_host module/class, I think you could consider split your test into two halves, using a client/server model. We already have a barrier module you can use to synchronize the two. I think you'll find this approach easier to write/maintain/enhance for the long run. Just some ideas for thought :) On 07/05/2012 06:58 AM, tangchen wrote: > Hi~ > > Thanks for the comments. > > But I still don't think migrating vm1 to remote is a convenient way, because > in attach-device tests, > we need to transfer a xml file to remote host, and clean up all the > environments. > > I will send a patch set to test attach-interface command. > I first ssh to remote host, and run "virsh -c src_uri xxx" to test "-c" > option. > This patch set is just for comments. So please review it and give some more > comments. > > Thanks. :) > > On 07/05/2012 05:52 PM, Alex Jia wrote: >> On 07/05/2012 09:17 AM, tangchen wrote: >>> Hi~ >>> >>> On 07/04/2012 07:03 PM, Alex Jia wrote: >>>> On 07/04/2012 06:50 PM, tangchen wrote: >>>>> Hi~ >>>>> >>>>> If I want to test "virsh -c" commands, any good idea to do it? >>>>> I think class VM in libvirt_vm.py cannot meet my requirtment. >>>> I have ever suggested to support remote URI, I think it should be what you >>>> want: >>>> >>>> http://test.kernel.org/pipermail/autotest/2011-November/009440.html >>> This patch is just what virsh_cmd() like now, isn't it? >>> It is not what I am talking about. Correct me if I made a mistake, please. >>> >>> I assume vm1 is on local host. If I run "virsh -c rempte_uri xxx", there is >>> no vm1 on remote host. >> >> It's your idea 1, you also test virsh -c during the migrating, although you >> think it's not good idea, >> IMHO, if you want to write some cases to test 'virsh -c', remote URI make >> more sense, you know >> libvirt supports many kinds of remote transports such as tls, unix, ssh, ext >> and tcp: >> >> http://libvirt.org/remote.html >> >>> If I only have one case need to test -c option, and all the other cases are >>> local tests, what should I do ? >>> >>> How about the following idea 2 ? >> URI alias may be helpful for you, for details, please see >> /etc/libvirt/libvirt.conf. >>>>> For example: >>>>> >>>>> I have 2 Hosts: Host1 with IP1 and Host2 with IP2. >>>>> My autotest is running on Host1, and of course vm1 is also on Host1. >>>>> Now I want to test "virsh -c" option. >>>>> >>>>> 1. If I run "virsh -c qemu://IP2/system xxx", I don't have a vm1 on Host2. >>>>> Migrating vm1 to Host2 is not a good idea, I think. Because it >>>>> depends on migration >>>>> test configurations, which makes my test more complicated. >>>>> OR >>>>> 2. If I ssh to Host2 and run "virsh -c qemu://IP1/system xxx", class VM >>>>> cannot do this. >>>>> >>>>> Now, I'm using method 2, and I don't use class VM. And all the "non -c" >>>>> tests are using >>>>> class VM, but "-c" tests are not. This is strange. >> BTW, if you run 'virsh -c qemu://IP/system xxx', you will need to configure >> TLS certification, >> 'tls' is a default transport. >> >>>>> >>>>> IMO, if virsh_cmd() can do this, class VM will support this kind of tests. >>>>> So maybe I will modify virsh_cmd() one more time, using method 2. >> I tend to extend virsh_cmd() to support this. >>>>> Any good idea to do this ? >>>>> >>>>> Thanks. :) >>>>> >>>> >> >> > -- Chris Evich, RHCA, RHCE, RHCDS, RHCSS Quality Assurance Engineer e-mail: cevich + `@' + redhat.com o: 1-888-RED-HAT1 x44214 _______________________________________________ Autotest mailing list Autotest@test.kernel.org http://test.kernel.org/cgi-bin/mailman/listinfo/autotest
