Thanks very much.
Some conceptual problems: libvirt is other virt software, so, kvm is
one virt software? how are these conceptions linked: virt, libvirt and
kvm? 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. 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 ?
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?
How to use them and what are the conventions of wring my own steps?
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? Why writing new profilers are like
writing new client tests, one profiler for each client test?
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?
我英文烂，不知所云，再用汉语写一遍吧：
一些概念问题：
libvirt是另一种virt software，那么kvm也是virt software的其中一种么？ virt, libvirt,
kvm之间关系如何?
在"autotest/client/virt/kvm_vm.py"中我看到VM类的__make_qemu_command方法。这个方法返回带参数的qemu命令:qemu_cmd。autotest里似乎使用qemu命令来启动kvm虚拟机。如果autotest里也可以用其他命名启动非内核虚拟机，我并没有找到非内核虚拟机类。在“autotest/client/virt/virt_vm.py”
里，我看到BaseVM类。根据你们对这个类的描述，BaseVM是所有“特定hypervisor虚拟机”的基类。按照你们的习惯，是否说kvm和libvirt是两种不同的“hypervisor”，
还是说是两种不同的"virt"? 我很好奇virt这个词是怎么起名的，它代表什么意义或缩写？
class BaseVM(object):
"""
Base class for all hypervisor specific VM subclasses.
This class should not be used directly, that is, do not attempt to
instantiate and use this class. Instead, one should implement a subclass
that implements, at the very least, all methods defined right after the
the comment blocks that are marked with:
"Public API - *must* be reimplemented with virt specific code"
and
"Protected API - *must* be reimplemented with virt specific classes"
The current proposal regarding methods naming convention is:
- Public API methods: named in the usual way, consumed by tests
- Protected API methods: name begins with a single underline, to be
consumed only by BaseVM and subclasses
- Private API methods: name begins with double underline, to be consumed
only by the VM subclass itself (usually implements virt specific
functionality: example: __make_qemu_command())
So called "protected" methods are intended to be used only by VM classes,
and not be consumed by tests. Theses should respect a naming convention
and always be preceeded by a single underline.
Currently most (if not all) methods are public and appears to be consumed
by tests. It is a ongoing task to determine whether methods should be
"public" or "protected".
"""
一些功能问题：
autotest/client/tests/kvm/steps下的那些steps文件是做什么的？
它们每个对应一种操作系统版本，对无人安装操作系统的步骤文件么？ 如何使用？编辑规范如何？我看了好久看不明白。
再，profilers
(autotest/client/profilers)的作用很难理解。profilers是用来收集autotest运行前，运行过程中，运行后的各种信息的模块吧？
从github上的autotest文档里(https://github.com/autotest/autotest/wiki/AddingProfiler)看到:
添加一个profiler的步骤跟添加一个client test的步骤相似，怎么会是这样？ 莫非每个client
test对应各自的profiler ?
到现在为止，我还不知道为什么需要一个kvm-autotest(它是autotest最主要的一个client
test)。请问，你们主要在什么测试场景下使用kvm-autotest或autotest？
--
huai.sinaapp.com
_______________________________________________
Autotest mailing list
[email protected]
http://test.kernel.org/cgi-bin/mailman/listinfo/autotest
