[Kimchi-devel] [v3 1/1] Virtual machine migration

[Crístian Viana]

On 14-11-2014 07:04, simonjin wrote:
>> The code above is running "self.conn.get().getInfo()" more than once. 
>> You can store that value in a variable so you don't have to talk to 
>> libvirt multiple times.
>> Actually, "self.conn" is used in more places later in the code, so 
>> that value can also be stored in a separate value. Try not to contact 
>> libvirt several times for the same information, it has a performance 
>> cost.
>>
> self.conn it self doesn't cost anything.

But there's no need to declare a function parameter if the function 
doesn't use it.

>> Usually we keep the model objects as instance variables. That means 
>> that "vmhostdevs" should be declared in VMModel's constructor - along 
>> with many other model variables - as "self.vmhostdevs".
> Due to the reason in code that VMHostDevsModel can't be imported at 
> the top of the class, the workaround is import and get the instance here.

Err, you're right, we have a huge dependency problem in the code right 
now... So you should keep that.

>> As I commented in the previous e-mail thread, the function "add_task" 
>> will add the task to the object store. You don't need to do that.
>>
> Will need this to verify whether the vm is already in migration, right ?

You definitely need that task later to track the migration process but 
the function "add_task" already stores the task in the object store. I 
mean you shouldn't store it yourself because it's already done.

In order to check the migration task, you can lookup a task with the code:

task = taskmodel.lookup(taskid);

(where "taskmodel" is an instance of "TaskModel" and "taskid" is the 
Task ID)

if you have the Task ID, or:

alltasks = taskmodel.get_list()

if you don't have the ID and you want to inspect all tasks (probably 
filtering by its 'target_uri' to find out which of them is related to 
migration).