[Libvirt-cim] [PATCH 4 of 4] [TEST][RFC] Added new tc to verify remote live migration

[Kaitlin Rupert]

>> 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 ?

No, this won't work.

> If it does not then passing the Port through command line becomes 
> meaningless.

There's no need to specify a CIMOM port because 
MigrateVirtualSystemToHost() uses libvirt to migrate the guest - it 
doesn't use the CIMOM for this communication.

It is possible to specify other libvirt transport types - this can be 
done using the MigrationSettingData instance.  It's some what involved 
to use some of these transport types (more information at: 
http://libvirt.org/remote.html).

I would recommend using the default transport type for these tests. 
Testing additional transport methods is something that can be added 
later (once all the basic migration scenarios are covered).

>>> + 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 ?

This is pretty tricky.  The problem is that the /etc/hosts file can be 
formatted in numerous ways, and there isn't really a standard across 
distros / systems. So the gethostbyaddr(), getfqdn(), etc can return 
different values.

Like you've pointed out, it's tough to get a full list of possible 
aliases for the system.

I would say, for now, if the source and the target differ, assume it's a 
remote migration.

>>> + 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 ??

I'm not sure what you mean here.. for each of the migration types, you 
can still call local_remote_migrate().  The only difference here is that 
the function will set up the VirtualSystemMigrationService object each 
time.  But I don't think that's a problem - it doesn't take too much 
execution time.

-- 
Kaitlin Rupert
IBM Linux Technology Center
kaitlin at linux.vnet.ibm.com