All of lore.kernel.org
 help / color / mirror / Atom feed
From: jd <jdsw2002@yahoo.com>
To: Anthony Liguori <anthony@codemonkey.ws>
Cc: KVM List <kvm@vger.kernel.org>
Subject: Re: KVM Management : Migration
Date: Sat, 9 Aug 2008 14:33:37 -0700 (PDT)	[thread overview]
Message-ID: <993772.68422.qm@web35803.mail.mud.yahoo.com> (raw)
In-Reply-To: <489DBC60.40405@codemonkey.ws>

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


      

      reply	other threads:[~2008-08-09 21:33 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-08-09  2:22 KVM Management : Migration jd
2008-08-09 15:48 ` Anthony Liguori
2008-08-09 21:33   ` jd [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=993772.68422.qm@web35803.mail.mud.yahoo.com \
    --to=jdsw2002@yahoo.com \
    --cc=anthony@codemonkey.ws \
    --cc=kvm@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.