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@xxxxxxxxxx>
> Signed-off-by: Amos Kong <akong@xxxxxxxxxx>
> ---
> 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@xxxxxxxxxxxxxxx
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
