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? >
