From: Anthony Liguori <anthony@codemonkey.ws>
To: jdsw2002@yahoo.com
Cc: KVM List <kvm@vger.kernel.org>
Subject: Re: KVM Management : Migration
Date: Sat, 09 Aug 2008 10:48:48 -0500 [thread overview]
Message-ID: <489DBC60.40405@codemonkey.ws> (raw)
In-Reply-To: <218687.89390.qm@web35807.mail.mud.yahoo.com>
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
>
next prev parent reply other threads:[~2008-08-09 15:49 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 [this message]
2008-08-09 21:33 ` jd
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=489DBC60.40405@codemonkey.ws \
--to=anthony@codemonkey.ws \
--cc=jdsw2002@yahoo.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox