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

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