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

[Deepti B Kalakeri]

Kaitlin Rupert wrote:
>>> 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.
Oops! I mixed two different things. Yes I had included the 
VirtualSystemMigrationService object creation to be able to use it for 
different migration types.
Also, I was en quiring with you that if it is a good idea to include 
scenarios for all the migration types in one tc.
Sorry for not being clear.
> But I don't think that's a problem - it doesn't take too much 
> execution time.
>

-- 
Thanks and Regards,
Deepti B. Kalakeri
IBM Linux Technology Center
deeptik at linux.vnet.ibm.com