Re: [PATCH] kvm-autotest: add object addressing in sample cfg

[Michael Goldish <mgoldish@redhat.com>]

----- "Ryan Harper" <ryanh@us.ibm.com> wrote:

> The wiki documents[1] object addressing quite well, but we should
> include it in the example config file as well.
> 
> 1. 
> http://www.linux-kvm.org/page/KVM-Autotest/Parameters#Addressing_objects_.28VMs.2C_images.2C_NICs_etc.29
> 
> 
> -- 
> Ryan Harper
> Software Engineer; Linux Technology Center
> IBM Corp., Austin, Tx
> ryanh@us.ibm.com
> 
> 
> diffstat output:
>  kvm_tests.cfg.sample |    4 ++++
>  1 files changed, 4 insertions(+)
> 
> Signed-off-by: Ryan Harper <ryanh@us.ibm.com>
> ---
> diff --git a/client/tests/kvm_runtest_2/kvm_tests.cfg.sample
> b/client/tests/kvm_runtest_2/kvm_tests.cfg.sample
> index 5619fa8..64f8e4b 100644
> --- a/client/tests/kvm_runtest_2/kvm_tests.cfg.sample
> +++ b/client/tests/kvm_runtest_2/kvm_tests.cfg.sample
> @@ -19,6 +19,10 @@ image_size = 10G
>  ssh_port = 22
>  display = vnc
>  
> +# specify specific values for vm1 and nic1
> +mem_vm1 = 256
> +nic_model_nic1 = rtl8139
> +
>  # Port redirections
>  redirs = ssh
>  guest_port_ssh = 22

This may not be a good idea, because we'll end up using only rtl8139.
Further down in the file we define virtio and e1000 variants. The e1000 one, for example,
specifies 'nic_model = e1000'. So you'll get a dict that contains:

nic_model_vm1 = rtl8139
nic_model = e1000

and the second statement will have no effect on vm1, because object specific statements
take precedence over general ones, regardless of order (as mentioned in the wiki).

Also, we'll end up always using mem = 256 (isn't that too little for some guests?).

Soon we'll try to implement parsing of statements like 'nic_model.* ?= e1000', which will
apply to any key that matches the regex 'nic_model.*'. This will make things
a little easier.

On the other hand, nic_model represents the default value for all VMs that don't have
their own values. It makes sense to work mainly with this parameter, and give specific
values only to VMs whose values we don't want to change. For example, when we implement
a load test that brings up numerous VMs in the background, we may choose to always give
them their own specific nic_model or mem or anything, as well as their own specific
guest OS which excels at producing load, and leave our main_vm with the main OS we're
testing (which depends on the current variant).

Thanks,
Michael