Thanks... inline..

--- On Sat, 8/9/08, Anthony Liguori <[EMAIL PROTECTED]> wrote:

> From: Anthony Liguori <[EMAIL PROTECTED]>
> Subject: Re: KVM Management : Migration
> To: [EMAIL PROTECTED]
> Cc: "KVM List" <[email protected]>
> 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 [EMAIL PROTECTED]
> > More majordomo info at 
> http://vger.kernel.org/majordomo-info.html
> >


      
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to