Mailing-List: contact cloudstack-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cloudstack-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of Chiradeep.Vittal@citrix.com
 designates 66.165.176.63 as permitted sender)
From: Chiradeep Vittal <Chiradeep.Vittal@citrix.com>
To: "cloudstack-dev@incubator.apache.org"
	<cloudstack-dev@incubator.apache.org>
CC: "hugo@apache.org" <hugo@apache.org>
Date: Tue, 26 Feb 2013 00:10:39 -0800
Subject: Re: [discuss] NetworkManager in migration
Thread-Topic: [discuss] NetworkManager in migration
Thread-Index: Ac4T+MX+GO5w+hitQIeH2+ndykzNWg==
Message-ID: <CD51AC72.9885%chiradeep.vittal@citrix.com>
In-Reply-To: <512C2438.3020901@stratosphere.co.jp>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/14.3.1.130117
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0


On 2/25/13 6:55 PM, "KAWAI Hiroaki" <kawai@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.=20
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?
>