On 02/08/2012 07:45 AM, nie xining wrote: > Now I am trying some kvm-autotest tests. The very first file I am > concerned about as a new user is the main configuration file : > tests.cfg, under "autotest/client/tests/kvm/". And for help page, I > referred to "How to run KVM autotest tests on an existing guest > image?" on github > (https://github.com/autotest/autotest/wiki/KVMAutotest-RunTestsExistingGuest). > > I see that the tests sets variants in tests.cfg is defined in other > config files which all be included by tests.cfg at the top lines: > > include base.cfg > include subtests.cfg > include guest-os.cfg > include cdkeys.cfg > include virtio-win.cfg > > Yet I couldn't think up which one defines them, i.e. rtl8319, > smallpages, Fedora.15.64, and kvm subtest cases (should these be > called that way, or should python files under kvm/virt tests directory > like: boot.py, unattended_install.py, shutdown.py be?) like: > unattended_install.cdrom, boot, shutdown. > > The github help page(which may be outdated) said these definitions > should be in tests_base.cfg, which does not exit in my autotest > version (autotest-autotest-0.13.1-0-g86127dd.tar.gz).
It is outdated, will fix it up. You can look for the files: client/virt/*.cfg There you can find all you're looking for. I guess it > either be subtests.cfg or guest-os.cfg. Have you any docs or tools > for helping me get a clearer idea of which config files defines what > variants? Especially those kvm-subtests cases. For example, what > should I put after "only" in main config file tests.cfg if I want to > try cases in clock_getres.py under "autotest/client/virt/tests" ? I > found one configuration parser tool named cartesian_config.py under > "autotest/client/commlib" interesting. How if such tools becomes more > powerful as to tell "only xxx" if I meet a new .py under kvm tests > directories? the 'writing new tests' doc is useful to show how the tests are selected: https://github.com/autotest/autotest/wiki/KVMAutotest-WritingNewTests But bottom line: # Runs qemu-kvm, f16 64 bit guest OS, install, boot, shutdown - @qemu_kvm_f16_quick: # We want qemu-kvm for this run qemu_binary = /usr/bin/qemu-kvm qemu_img_binary = /usr/bin/qemu-img qemu_io_binary = /usr/bin/qemu-io only qcow2 only rtl8139 only ide only smp2 only no_9p_export only no_pci_assignable only smallpages only Fedora.16.64 only clock_getres <--- Change this line with the tests Of course, for the above to work you *must* have an image installed in a prior execution of autotest, that is, having # Runs qemu-kvm, f16 64 bit guest OS, install, boot, shutdown - @qemu_kvm_f16_quick: # We want qemu-kvm for this run qemu_binary = /usr/bin/qemu-kvm qemu_img_binary = /usr/bin/qemu-img qemu_io_binary = /usr/bin/qemu-io only qcow2 only rtl8139 only ide only smp2 only no_9p_export only no_pci_assignable only smallpages only Fedora.16.64 only unattended_install.cdrom As the contents of your test block, and executing the code *with the right Fedora DVD image in the right place*. get_started.py should help you to put the right image in the right place. > The intentions I ask for your own kvm-autotest test scenarios in last > letter is that I want to a quick idea about When and why kvm-autotest > better than manually operations. I see kvm-autotest give logs with > time stamps for the start and end of test, which provides some > convinience. But I believe there's more. Have you any written words > on this subject? It depends, I for one use kvm autotest whenever I need some fresh vm images of say, Fedora or Windows. Also, I bet KVM autotest tests KVM migration a lot better and faster than you could do manually, for example. We run daily over 9 hours of tests for each branch, so you might imagine that we use it for quite a bit of scenarios. _______________________________________________ Autotest mailing list [email protected] http://test.kernel.org/cgi-bin/mailman/listinfo/autotest
