You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by KAWAI Hiroaki <ka...@stratosphere.co.jp> on 2013/02/26 03:55:52 UTC
[discuss] NetworkManager in migration
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.
We need to add calls in NetworkManagerImpl.
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.
So one more proposal is that we add one interface method
NetworkManager#releaseNicForMigrated to call those methods.
To let the plugin Guru or Elements know it is migration or normal
server startup/shutdown, ReservationContext will be useful.
Do this proposal make sense?
Re: [discuss] NetworkManager in migration
Posted by KAWAI Hiroaki <ka...@stratosphere.co.jp>.
Since I heared no big objections for now, I created
an issue CLOUDSTACK-1638 and created a patch in
https://reviews.apache.org/r/9871/
The patch is intended to be a minimum change, but I'm
thinking that we should stop the migration if plugin
failed to handle the operation...
# NetworkManager interface change is needed to do.
I want to get comments.
(2013/02/26 11:55), 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.
>
> We need to add calls in NetworkManagerImpl.
>
> 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.
>
> So one more proposal is that we add one interface method
> NetworkManager#releaseNicForMigrated to call those methods.
>
> To let the plugin Guru or Elements know it is migration or normal
> server startup/shutdown, ReservationContext will be useful.
>
> Do this proposal make sense?
>
Re: [discuss] NetworkManager in migration
Posted by KAWAI Hiroaki <ka...@stratosphere.co.jp>.
(2013/02/26 17:21), Dave Cahill wrote:
> Hi,
>
>
>> Anybody else (Hugo? Dave Cahill?) want to chime in?
>
>
> I have noticed some issues with the NetworkManager's treatment of non-Guest
> NICs / VMs - see for example thread [1].
>
> Kawai-san - could you provide more info on the type of traffic (Guest
> only?) and VMs (Guest only, or System VMs too) you're working with?
For now, I'm working on GuestNetwork only, because the other system
networks does not have parent physical networks and I could not
find an normal way to operate with system networks from
PhysicalNetworkServiceProviders.
# It will be good if those system networks have physical networks.
## But this is another topic...
> Thanks,
> Dave.
>
> [1] http://markmail.org/message/6qxdsek2dgu4cpxj
>
> On Tue, Feb 26, 2013 at 5:10 PM, Chiradeep Vittal <
> Chiradeep.Vittal@citrix.com> wrote:
>
>>
>>
>> On 2/25/13 6:55 PM, "KAWAI Hiroaki" <ka...@stratosphere.co.jp> 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?
>>
>>>
>>> We need to add calls in NetworkManagerImpl.
>>
>> I can see the value of this, but a bit more explanation is required.
>>
>>>
>>> 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?
>>
>>>
>>> So one more proposal is that we add one interface method
>>> NetworkManager#releaseNicForMigrated to call those methods.
>>>
>>> To let the plugin Guru or Elements know it is migration or normal
>>> server startup/shutdown, ReservationContext will be useful.
>>>
>>> Do this proposal make sense?
>>>
>>
>>
>
Re: [discuss] NetworkManager in migration
Posted by Dave Cahill <dc...@midokura.com>.
Hi,
> Anybody else (Hugo? Dave Cahill?) want to chime in?
I have noticed some issues with the NetworkManager's treatment of non-Guest
NICs / VMs - see for example thread [1].
Kawai-san - could you provide more info on the type of traffic (Guest
only?) and VMs (Guest only, or System VMs too) you're working with?
Thanks,
Dave.
[1] http://markmail.org/message/6qxdsek2dgu4cpxj
On Tue, Feb 26, 2013 at 5:10 PM, Chiradeep Vittal <
Chiradeep.Vittal@citrix.com> wrote:
>
>
> On 2/25/13 6:55 PM, "KAWAI Hiroaki" <ka...@stratosphere.co.jp> 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?
>
> >
> >We need to add calls in NetworkManagerImpl.
>
> I can see the value of this, but a bit more explanation is required.
>
> >
> >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?
>
> >
> >So one more proposal is that we add one interface method
> >NetworkManager#releaseNicForMigrated to call those methods.
> >
> >To let the plugin Guru or Elements know it is migration or normal
> >server startup/shutdown, ReservationContext will be useful.
> >
> >Do this proposal make sense?
> >
>
>
Re: [discuss] NetworkManager in migration
Posted by KAWAI Hiroaki <ka...@stratosphere.co.jp>.
Thanks for reply :
(2013/02/26 17:10), Chiradeep Vittal wrote:
> On 2/25/13 6:55 PM, "KAWAI Hiroaki" <ka...@stratosphere.co.jp> 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.
----------
1)
https://git-wip-us.apache.org/repos/asf?p=incubator-cloudstack.git;a=blob;f=server/src/com/cloud/network/NetworkManagerImpl.java;h=82893c4cafc808d54590d97d2e1fe0f440a62c89;hb=HEAD#l1654
Re: [discuss] NetworkManager in migration
Posted by Chiradeep Vittal <Ch...@citrix.com>.
On 2/25/13 6:55 PM, "KAWAI Hiroaki" <ka...@stratosphere.co.jp> 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?
>
>We need to add calls in NetworkManagerImpl.
I can see the value of this, but a bit more explanation is required.
>
>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?
>
>So one more proposal is that we add one interface method
>NetworkManager#releaseNicForMigrated to call those methods.
>
>To let the plugin Guru or Elements know it is migration or normal
>server startup/shutdown, ReservationContext will be useful.
>
>Do this proposal make sense?
>