Re: [Qemu-devel] [RFC PATCH 11/14] KVM-test: Add a subtest of changing mac address

[Lucas Meneghel Rodrigues <lmr@redhat.com>]

On Tue, 2010-07-20 at 09:36 +0800, Amos Kong wrote:
> Mainly test steps:
> 1. get a new mac from pool, and the old mac addr of guest.
> 2. execute the mac_change.sh in guest.
> 3. relogin to guest and query the interfaces info by `ifconfig`
> 
> Signed-off-by: Cao, Chen <kcao@redhat.com>
> Signed-off-by: Amos Kong <akong@redhat.com>
> ---
>  0 files changed, 0 insertions(+), 0 deletions(-)
> 
> diff --git a/client/tests/kvm/tests/mac_change.py b/client/tests/kvm/tests/mac_change.py
> new file mode 100644
> index 0000000..dc93377
> --- /dev/null
> +++ b/client/tests/kvm/tests/mac_change.py
> @@ -0,0 +1,66 @@
> +import logging
> +from autotest_lib.client.common_lib import error
> +import kvm_utils, kvm_test_utils, kvm_net_utils
> +
> +
> +def run_mac_change(test, params, env):
> +    """
> +    Change MAC Address of Guest.
> +
> +    1. get a new mac from pool, and the old mac addr of guest.
> +    2. set new mac in guest and regain new IP.
> +    3. re-log into guest with new mac
> +
> +    @param test: kvm test object
> +    @param params: Dictionary with the test parameters
> +    @param env: Dictionary with test environment.
> +    """
> +    timeout = int(params.get("login_timeout", 360))
> +    vm = kvm_test_utils.get_living_vm(env, params.get("main_vm"))
> +    logging.info("Trying to log into guest '%s' by serial", vm.name)
> +    session = kvm_utils.wait_for(lambda: vm.serial_login(),
> +                                  timeout, 0, step=2)

^ One thing that I forgot to comment on previous patches: For more
clarity, it'd be good to name the session variable in a way that lets
people refer easily that is a serial session

session_serial = ...

> +    if not session:
> +        raise error.TestFail("Could not log into guest '%s'" % vm.name)
> +
> +    old_mac = vm.get_macaddr(0)
> +    kvm_utils.put_mac_to_pool(vm.root_dir, old_mac, vm.instance)
> +    new_mac = kvm_utils.get_mac_from_pool(vm.root_dir,
> +                                          vm=vm.instance,
> +                                          nic_index=0,
> +                                          prefix=vm.mac_prefix)
> +    logging.info("The initial MAC address is %s" % old_mac)
> +    interface = kvm_net_utils.get_linux_ifname(session, old_mac)
> +
> +    # Start change mac address
> +    logging.info("Changing mac address to %s" % new_mac)
> +    change_cmd = "ifconfig %s down && ifconfig %s hw ether %s && ifconfig %s up"\
> +                 % (interface, interface, new_mac, interface)
> +    if session.get_command_status(change_cmd) != 0:
> +        raise error.TestFail("Fail to send mac_change command")
> +
> +    # Verify whether mac address is changed to new one
> +    logging.info("Verifying the new mac address")
> +    if session.get_command_status("ifconfig | grep -i %s" % new_mac) != 0:
> +        raise error.TestFail("Fail to change mac address")
> +
> +    # Restart `dhclient' to regain IP for new mac address
> +    logging.info("Re-start the network to gain new ip")
> +    dhclient_cmd = "dhclient -r && dhclient %s" % interface
> +    session.sendline(dhclient_cmd)
> +
> +    # Re-log into the guest after changing mac address
> +    if kvm_utils.wait_for(session.is_responsive, 120, 20, 3):
> +        # Just warning when failed to see the session become dead,
> +        # because there is a little chance the ip does not change.
> +        logging.warn("The session is still responsive, settings may fail.")

^ Isn't this a serial session? Then why the IP of guest changing would
make this session un-responsive? I think the best idea here is to:

1) Release the IP through dhclient -r [interface]
2) Make sure we can't stablish a ssh based session to the guest by
making a try/except block with kvm_test_utils.wait_for_login() with the
appropriate timeouts and other parameters, if succeeds, fail the test,
if it doesn't, proceed with the test.
3) Get a new IP with dhclient [interface]
4) Try to stablish a new, ssh based session to the guest and see if that
works.

> +    session.close()
> +
> +    # Re-log into guest and check if session is responsive
> +    logging.info("Re-log into the guest")
> +    session = kvm_test_utils.wait_for_login(vm,
> +              timeout=int(params.get("login_timeout", 360)))
> +    if not session.is_responsive():
> +        raise error.TestFail("The new session is not responsive.")

^ Is it possible that right after you stablish the session it becomes
non-responsive? It seems like a redundant verification step to me.

> +    session.close()
> diff --git a/client/tests/kvm/tests_base.cfg.sample b/client/tests/kvm/tests_base.cfg.sample
> index 5515601..7716d48 100644
> --- a/client/tests/kvm/tests_base.cfg.sample
> +++ b/client/tests/kvm/tests_base.cfg.sample
> @@ -394,6 +394,10 @@ variants:
>          restart_vm = yes
>          pxe_timeout = 60
>  
> +    - mac_change: install setup unattended_install.cdrom
> +        type = mac_change
> +        kill_vm = yes
> +
>      - physical_resources_check: install setup unattended_install.cdrom
>          type = physical_resources_check
>          catch_uuid_cmd = dmidecode | awk -F: '/UUID/ {print $2}'
> @@ -1070,7 +1074,7 @@ variants:
>  
>      # Windows section
>      - @Windows:
> -        no autotest linux_s3 vlan_tag ioquit unattended_install.(url|nfs|remote_ks) jumbo file_transfer nicdriver_unload nic_promisc multicast
> +        no autotest linux_s3 vlan_tag ioquit unattended_install.(url|nfs|remote_ks) jumbo file_transfer nicdriver_unload nic_promisc multicast mac_change
>          shutdown_command = shutdown /s /f /t 0
>          reboot_command = shutdown /r /f /t 0
>          status_test_command = echo %errorlevel%
> 
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>