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@linux.vnet.ibm.com