7:19 a.m.
Kaitlin Rupert wrote:
Deepti B. Kalakeri wrote:
> # HG changeset patch
> # User Deepti B. Kalakeri <deeptik(a)linux.vnet.ibm.com>
> # Date 1236853868 25200
> # Node ID 89db4ac2378c90fd89845dd09836bfb39cc6e6ed
> # Parent caae383c83ec70e6cb6de9b6e5ccf6d2fcbecb45
> [TEST][RFC] Added new tc to verify remote live migration.
>
> Verified with KVM.
> The test case will not pass for KVM since the guest information needs
> to have emulator
> information without which the remote migration fails.
> The support to pass the emulator information via
> VirtualSystemMigrationSettingData is
> not yet available.
I haven't verified this on Xen yet.
I have not verified it either.
> +def main():
> + options = main.options
> + virt = options.virt
> + s_sysname = os.environ['SRC_IP']
You already know the source IP from options.ip - do you need to set an
environment variable for it?
> + t_sysname = os.environ['TARGET_IP']
Shouldn't you be able to the target ip from main.options the same way
we get the source IP?
I knew that the test cases were using the const.py options but was not
able to track how they inherited the command line args given.
Hmmm... I traced it now and its a bit tricky. I will make the changes in
the subsequent patch I submit.
I have one query, MigrateVirtualSystemToHost() just takes the
DestinationHost ip / hostname, but what if the user wanted to connect
using a specific port.
Will passing the port information as part of the DestinationHost work ?
If it does not then passing the Port through command line becomes
meaningless.
> + if options.virt == 'KVM' and t_sysname == s_sysname:
I was wondering how to make the check for verifying if the user wanted
to do local migration, which means I need to validate the src ip and
dest ip to be different.
The user might give the src and destination information in any form like
localhost, ip address, hostname, FQDN.
The live.full_hostname() does not come handy.
Also, the following function gave me a similar results which could be
used for comparison. [ Only some o/p given]
>> print "Hostname is ",
socket.gethostbyaddr('localhost')
Hostname is ('elm3b41',
['localhost.localdomain', 'localhost',
'localhost'], ['127.0.0.1'])
>> print "Hostname is ",
socket.gethostbyaddr('elm3b41.beaverton.ibm.com')
Hostname is
('elm3b41.beaverton.ibm.com', [], ['9.47.67.41'])
>> print "Hostname is ",
socket.gethostbyaddr('9.47.67.41')
Hostname is
('elm3b41.beaverton.ibm.com', [], ['9.47.67.41'])
>> print "fqdn is %s",
socket.getfqdn('elm3b41')
fqdn is %s localhost.localdomain
>> print "fqdn is %s", socket.getfqdn('')
fqdn is %s localhost.localdomain
>> print "fqdn is %s",
socket.getfqdn('9.47.67.41')
fqdn is %s elm3b41.beaverton.ibm.com
>> print "fqdn is %s",
socket.getfqdn('elm3b41.beaverton.ibm.com')
fqdn is %s
elm3b41.beaverton.ibm.com
>> print "fqdn is %s",
socket.getfqdn('localhost.localdomain')
fqdn is %s localhost.localdomain
>> print "FQDN is ",
socket.gethostbyaddr(socket.gethostname())[0]
FQDN is elm3b41
>>socket.getfqdn('127.0.0.1')
'localhost.localdomain'
Can you suggest something here ?
> + logger.info("Libvirt does not support local migratoin for
KVM")
> + return SKIP
> +
> + status = FAIL
> + test_dom = 'VM_frm_' + socket.gethostname()
> +
> + try:
> + status, cxml = setup_guest(test_dom, s_sysname, virt)
> + if status != PASS:
> + logger.error("Error setting up the guest")
> + return status
> +
> + # Migrate the test_dom to t_sysname.
> + # local_remote_migrate executes live migration by default
> + # Enable remote migration by setting remote_migrate=1
> + vsms_cn = get_vs_mig_setting_class(virt) + vsmservice =
> vsms_cn(s_sysname, virt)
> + status = local_remote_migrate(vsmservice, s_sysname, t_sysname, virt,
> + remote_migrate=1, guest_name=test_dom)
Why not have local_remote_migrate() get its own
VirtualSystemMigrationService object? There's no need to pass it in
here because it's not used later on..
Or are you planning to have future tests use it for something?
Oh! yeah we do not use it for anything else in the current test case
changes.
I had created the VirtualSystemMigrationService object thinking that I
shall execute one by one migration types.
I will shift this to vsmigrations.py.
But I guess writing separate scenarios for each of them makes it more
cleaner or else it will become lengthier , wat say ??
> + except Exception,details:
> + logger.error("Exception details :%s", details)
> + cxml.cim_destroy(s_sysname)
> + cxml.undefine(s_sysname)
> + return FAIL
> +
> + if status == PASS:
> + # Remote Migration Successful, clean the domain on target machine
> + cxml.cim_destroy(t_sysname)
> + cxml.undefine(t_sysname)
> + else:
> + # Remote Migration not Successful, clean the domain on src machine
> + cxml.cim_destroy(s_sysname)
> + cxml.undefine(s_sysname)
> +
Technically, if the migration fails partway through migrating a guest,
it's possible for the guest to end up on both systems. So it'd be good
to check both the source and the target to see if the guest exists
(and remove it if it does).
Ok I shall take care of this as well.
--
Thanks and Regards,
Deepti B. Kalakeri
IBM Linux Technology Center
deeptik(a)linux.vnet.ibm.com