On 02/06/2012 06:57 AM, nie xining wrote: > Thanks very much. > > Some conceptual problems: libvirt is other virt software, so, kvm is > one virt software?
KVM is a linux hypervisor. See http://www.linux-kvm.org/page/Main_Page. Libvirt is a library, built as an abstraction layer to other virt hypervisors, such as KVM, Xen and others. how are these conceptions linked: virt, libvirt and > kvm? libvirt and kvm both provide capabilities of virtual machines creation, kvm does it directly, through the kvm linux module and qemu as the userspace component. libvirt does it by wrapping an underlying virtualization hypervisor. We can have, for example, libvirt with kvm driver, libvirt with xen driver, so on an so forth. There is an method of class VM named __make_qemu_command in > "autotest/client/virt/kvm_vm.py" which returns qemu command line: > qemu_cmd. It seems that autotest is using qemu command to starting a > KVM virtual machine. If other non-kernel-based-virtual-machine could > be boot in autotest, I didn't find any class definition of the type > there. Because we don't have the manpower needed to write an upstream version of, say, Xen hypervisors. But all the pieces are there. Moreover, you'll see that there's a libvirt_vm.py file in there, that uses libvirt to create and manipulate the vms. Yet I found one base class BaseVM in > "autotest/client/virt/virt_vm.py", which, by your descriptions, are > "base class for all hypervisor specific VM subclasses". Should kvm > and libvirt be called two different "hypervisors" or "virts" by your > conventions? One more questions: what does "virt" stands for ? virt stands for virtualization. > And some functional problems: What are the steps under > "autotest/client/tests/kvm/steps" for ? Are these for steps of > automatic operation systems installation without human interactions? It contain files that are a description of an interaction with a vm. Example, 'type the letter 'r', then the letter 'o', then 'o', then 't', then press enter, and so on and so forth. It can be used to automate interaction with the vm. > How to use them and what are the conventions of wring my own steps? I've been promising another community member that I'd write docs on how to use step files, but have failed to find the time to take care of it. Will see what I can do during the next weeks. > For the profiles under "autotest/cient/profilers", Are they not > information modules for collecting information of a test before, after > and during one autotest running? Collecting data about system resources usage during an autotest test. For more information about profiling, see: http://en.wikipedia.org/wiki/Profiling_(computer_programming) > Why writing new profilers are like > writing new client tests, one profiler for each client test? Because they were designed that way. They are written very much like tests, and they are executed on a separate thread, measuring system resources usage during the test execution. The fact they are written like tests increases familiarity for developers, and after all, they are not *that* much different from tests in the sense they are all about executing commands and reporting results. > By now, I am not aware of why and when I need kvm-autotest, which is > one of the the most substantial client tests. What are your kvm-autotest > test scenarios, may I ask? Very simple. If you are interested to test kvm, both the kernel module or the qemu userspace component, then you will find kvm-autotest interesting. If not, you don't need it. Lucas _______________________________________________ Autotest mailing list [email protected] http://test.kernel.org/cgi-bin/mailman/listinfo/autotest
