1:10 p.m.
> 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(a)linux.vnet.ibm.com