Re: [sami] First SAMI email in the new year, can we go further? Look forward to your opinions.

> Like Thomas, I see that there is something to be done here. But I also agree that we need
> to figure out the use-cases first, driven by real operational requirements. It might help
> if we started talking about use-cases for VM migration - yes it's possible, but why do
> people use it? - so that we can figure out if any of them inform the discussion of state migration.

Here are four use cases to start with (all are non-disruptive with VM migration):

(1) Server load balancing - migrate VMs for balanced server loading.
(2) Power savings - Consolidate VMs onto fewer servers when overall data center load
	is light (perhaps at night) so that unused servers can be powered down.
(3) Non-disruptive server maintenance - vacate a server that needs to be powered
	down so that it can be worked on.
(4) Non-disruptive server hardware refresh - add new servers and remove old servers.

Thanks,
--David

> -----Original Message-----
> From: sami-bounces@ietf.org [mailto:sami-bounces@ietf.org] On Behalf Of Benson Schliesser
> Sent: Thursday, March 01, 2012 9:31 PM
> To: sami@ietf.org
> Subject: Re: [sami] First SAMI email in the new year, can we go further? Look forward to your
> opinions.
> 
> 
> On Mar 1, 2012, at 9:02 AM, <david.black@emc.com> <david.black@emc.com> wrote:
> 
> >> I think so, and there's no doubt it would be helpful to be clearer about
> >> that going forward.  However, my understanding that while the VM image
> >> would be moved (craploads of kernel state - file tables, page tables,
> >> all that crap), network activity would have to be quiesced first.
> >
> > That understanding is incorrect - network activity is not quiesced.  A
> > gratuitous ARP or RARP is issued after the migration, and some inbound
> > packets may get dropped because they are delivered only to the source
> > location of the migration.
> 
> Right. Minor packet loss is possible, but the VM migration is designed so that e.g. established TCP
> connections don't fail.
> 
> Like Thomas, I see that there is something to be done here. But I also agree that we need to figure
> out the use-cases first, driven by real operational requirements. It might help if we started talking
> about use-cases for VM migration - yes it's possible, but why do people use it? - so that we can
> figure out if any of them inform the discussion of state migration.
> 
> Further, are there any non-VM mobility use-cases for state migration? I can imagine a few, but again I
> want to make sure they're being driven by operational needs rather than mere possibility.
> 
> Cheers,
> -Benson
> 
> 
> _______________________________________________
> sami mailing list
> sami@ietf.org
> https://www.ietf.org/mailman/listinfo/sami