cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From KAWAI Hiroaki <>
Subject Re: [discuss] NetworkManager in migration
Date Tue, 26 Feb 2013 08:38:27 GMT
Thanks for reply :

(2013/02/26 17:10), Chiradeep Vittal wrote:
> On 2/25/13 6:55 PM, "KAWAI Hiroaki" <> wrote:
>> Hi, I'm writing a network plugin that tracks the location
>> of the virtual machine (and then reacts).
>> There're interface methods in NetworkGuru and NetworkElement
>> that can be used for this purpose.
>> The location of the virtual machine is provided by
>> DeployDestination, which will be passed in NetworkGuru#reserve
>> and NetworkElement#prepare.
>> The two methods are called at the time VM starts up. The
>> problem is that, in migration those methods are not called.
>> There is NetworkManager#prepareNicForMigration, and it is
>> called before the VM migration. But NetworkManagerImpl
>> does not call NetworkGuru#reserve and NetworkElement#prepare.
>> This makes tracking the vm location impossible.
> Perhaps a little more information would help us understand this better?
> This doesn't seem to be a problem with current out-of-the-box vanilla VLAN
> based networks.
> Anybody else (Hugo? Dave Cahill?) want to chime in?

Out-of-the-box vlan setup does not track the DeployDestination at all,
so it does not affect. The problem happens when we write a plugin
that tracks DeployDestination.

>> We need to add calls in NetworkManagerImpl.
> I can see the value of this, but a bit more explanation is required.

In the NetworkManagerImpl#prepareNicForMigration, we only see
NetworkGuru#updateNicProfile is called(*1). The DeployDestination dest
argument is not passed to NetworkGuru nor NetworkElement.

I think prepareNicForMigration is a variant of prepareNic.
And we should add guru.reserve and preapreElement in
prepareNicForMigration and pass the DeployDestination in
that method arguments.
# Because migration is really going to change the DeployDestination
# and need to reserve a resource in the destination environment.

>> And then, after the migration, NetworkGuru#release and
>> NetworkElement#release should be called, otherwise the
>> network resources that plugin reserved will be kept
>> even when the vm leaves off.
> This should be on the previous nic profile?

If the migration was successful, the nic profiles on source
deployment should be released. If the migration was in failure,
the new prepared nic profiles should be released.


View raw message