KVM Management : Migration

KVM Management : Migration

[jd]

Hi 
  For migration to work, it is recommended to start the VM with exact same params as the original VM. Can some one clarify the minimum set that should be the same.. while if others like VNC port Or default bridge can be different. (as the target machine may have vnc port already used.)

 Also, if there are any compatibility checks for migration that needed to be done for predicting successful migration
   -- KVM version  ? Same... similar.. any other way to find if they are 'compatible' ? (As KVM is released frequently)
   -- Processor  same / similar ? Do we have a good compatibility matrix somewhere ? I am assuming that there is nothing specific to KVM but would like to confirm.
   -- Memory availability : How to compute availability of "enough" memory ? Free physical memory ? Or some weight on available virtual memory/swap ? weave in some knowledge of ballooning details.
   
   Any other checks ? 

Thanks
/Jd


      

Re: KVM Management : Migration

[Anthony Liguori]

jd wrote:
> Hi 
>   For migration to work, it is recommended to start the VM with exact same params as the original VM. Can some one clarify the minimum set that should be the same.. while if others like VNC port Or default bridge can be different. (as the target machine may have vnc port already used.)
>   

Anything that affects the hardware exposed to the guest must be the 
same.  -vnc, -net tap, -monitor, etc. have no effect on the hardware 
exposed to the guest so they can be modified.

>  Also, if there are any compatibility checks for migration that needed to be done for predicting successful migration
>   

Note that a primary design goal of migration is that failure will never 
result in a lost VM so it is generally safe to try a migration even if 
there's a chance it may fail.

>    -- KVM version  ? Same... similar.. any other way to find if they are 'compatible' ? (As KVM is released frequently)
>   

The format should be backwards compatible so version checking isn't 
necessary.

>    -- Processor  same / similar ? Do we have a good compatibility matrix somewhere ? I am assuming that there is nothing specific to KVM but would like to confirm.
>   

We do our best to expose only a common subset of features for guests.  
Practically speaking, it's a trade-off.  It is only "safe" to migrate to 
absolutely identical CPUs otherwise you risk the guest miscalibrating 
the TSC.

In general, modern Linux guests can detect the TSC screwing up and as 
long as your going from a slower to faster system, it should be okay (or 
perhaps vice versa).

>    -- Memory availability : How to compute availability of "enough" memory ? Free physical memory ? Or some weight on available virtual memory/swap ? weave in some knowledge of ballooning details.
>   

KVM supports memory overcommit so it simplifies and complicates things.  
A migration should always succeed regardless of memory on the system but 
performance may suffer because of swapping.  So choosing the best 
migration target will have to take into account available free memory, 
how many VMs are on the system already (the potential memory use for the 
future), etc.

Regards,

Anthony Liguori

>    Any other checks ? 
>
> Thanks
> /Jd
>
>
>       
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>   

Re: KVM Management : Migration

[jd]

Thanks... inline..


--- On Sat, 8/9/08, Anthony Liguori <anthony@codemonkey.ws> wrote:

> From: Anthony Liguori <anthony@codemonkey.ws>
> Subject: Re: KVM Management : Migration
> To: jdsw2002@yahoo.com
> Cc: "KVM List" <kvm@vger.kernel.org>
> Date: Saturday, August 9, 2008, 8:48 AM
> jd wrote:
> > Hi 
> >   For migration to work, it is recommended to start
> the VM with exact same params as the original VM. Can some
> one clarify the minimum set that should be the same.. while
> if others like VNC port Or default bridge can be different.
> (as the target machine may have vnc port already used.)
> >   
> 
> Anything that affects the hardware exposed to the guest
> must be the 
> same.  -vnc, -net tap, -monitor, etc. have no effect on the
> hardware 
> exposed to the guest so they can be modified.
> 
> >  Also, if there are any compatibility checks for
> migration that needed to be done for predicting successful
> migration
> >   
> 
> Note that a primary design goal of migration is that
> failure will never 
> result in a lost VM so it is generally safe to try a
> migration even if 
> there's a chance it may fail.
> 
> >    -- KVM version  ? Same... similar.. any other way
> to find if they are 'compatible' ? (As KVM is
> released frequently)
> >   
> 
> The format should be backwards compatible so version
> checking isn't 
> necessary.
> 
> >    -- Processor  same / similar ? Do we have a good
> compatibility matrix somewhere ? I am assuming that there is
> nothing specific to KVM but would like to confirm.
> >   
> 
> We do our best to expose only a common subset of features
> for guests.  
> Practically speaking, it's a trade-off.  It is only
> "safe" to migrate to 
> absolutely identical CPUs otherwise you risk the guest
> miscalibrating 
> the TSC.
> 
> In general, modern Linux guests can detect the TSC screwing
> up and as 
> long as your going from a slower to faster system, it
> should be okay (or 
> perhaps vice versa).

Any ides about how this affects Windows guests ?

> 
> >    -- Memory availability : How to compute
> availability of "enough" memory ? Free physical
> memory ? Or some weight on available virtual memory/swap ?
> weave in some knowledge of ballooning details.
> >   
> 
> KVM supports memory overcommit so it simplifies and
> complicates things.  
> A migration should always succeed regardless of memory on
> the system but 
> performance may suffer because of swapping.  So choosing
> the best 
> migration target will have to take into account available
> free memory, 
> how many VMs are on the system already (the potential
> memory use for the 
> future), etc.
> 

Interesting...so the migration would succeed even if the available memory is < required by VM. It will end up using swap space and performance would suffer.

Thanks
/Jd


> Regards,
> 
> Anthony Liguori
> 
> >    Any other checks ? 
> >
> > Thanks
> > /Jd
> >
> >
> >       
> > --
> > To unsubscribe from this list: send the line
> "unsubscribe kvm" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at 
> http://vger.kernel.org/majordomo-info.html
> >