Hi Chris,
Sorry for such a long delay, and thank you for your patient.
I having been doing some other libvirt work recently.
I read your comments and I think we need a further discuss.
See below.
On 07/27/2012 05:00 AM, Chris Evich wrote:
+ pre_vm_state = running
+ libvirtd_state = on
I lost track of who the patch was for, but...I remember suggesting
that we add both of these as global options to control
virt_env_process preprocess_vm() and postprocess_vm(). I've seen at
least two (maybe more) tests that want to control/check/change initial
state of VM and libvirt. Instead of writing these new for each test,
it makes sense to centralize.
Thoughts? Concerns? Can I help?
P.S. Off-hand, I _THINK_ test module code can actually call
postprocess_vm() if it needs to respond to resulting conditions. i.e.
I don't think there will be harm if autotest then calls this function
again (after test) - but I could be wrong.
I completely agree with you.
But unfortunately, I cannot find a good enough way to settle this
problem, for now.
Since sometimes, our test needs to do some configuration before actual
test starts, for example, get the id or rename the vm and restart it.
In this case, we need libvirtd running, and we need to know what status
we should turn vm into before test.
So these 2 parameters are needed.
+ status_error = no
+ no_attach = no
It was my mistake. The testcases using this parameter have been dropped.
+ test_times = 1
This is a confusing name, does it mean how many times to run the test?
Looking at code, this looks like numeric substitution for "nics"
parameter. New networking code doesn't require enumerating all
"nics", so I think this parameter can just be removed. Variants can
then use:
nics = nic1 nic2 nic3 nic4
or
nics = nic1
If you need to set some specific details for some or all nics, you
just put it before the name. For example:
mac_nic1 = 01:02:03:04:05:06
See my comments in base.cfg.sample for how this works. Good news is,
code is already written
Thanks for telling me about this.
But what if I need to test the attach-interface command? I need to
configure the attach options.
And I don't need a vm which has had these configuration.
Also see below.
+ # Nic information.
+ device = interface
+ device_type = bridge
+ device_source = virbr0
+ device_targets = vnet1
+ auto_target = no
+ auto_nic_mac = yes
+ bus_type = virtio
Again, all these nic parameters are supported in new network code.
It's all optional, where if you don't specify then you get defaults.
It also supports heterogeneous environments, e.g. vm1_nic1 can be
different from vm2_nic2 even in the same test! Check out my comments
in base.cfg.sample and
https://github.com/autotest/autotest/wiki/KVMAutotest-Networking
Also, if we need to extend the new networking model to support testing
better, let's do it!
But in this test, I want to test attach-interface command, and these
parameters may be used
to configure attach-interface options. I don't need the vm started with
these configurations.
The configurations in base.cfg are used to configure vm before tests,
right?
I didn't read network code deeply, so I could be wrong. If so or you
have any better idea, please tell me.
+ - invalid_mac:
+ invalid_nic_mac = xyz
Interesting, this one will be tricky. The new networking code goes to
great lengths to make sure you CAN'T define a nic with an invalid mac
address. This will be difficult test variant to accommodate but I
must admit, it's actually a problem with the networking code, not your
test.
How do you feel if we drop this invalid_mac test for now? We can add
it as an enhancement later, after I have chance to review how to make
it possible. I have sent myself a note to investigate more.
N/B: It's complex problem because networking code involves multiple
cache databases and pickling the test context into env file. If a mac
is invalid, it's hard for low-level code to know it's intended to be
wrong instead of cache or env corruption problem.
Sure.
Since this is a huge test, I think I can separate it into smaller parts.
I will send a set of new patches soon including the simple
"vm_reference_method" tests.
And all the others will be added later.
All the other comments are followed.
Thanks.
_______________________________________________
Autotest-kernel mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/autotest-kernel
