From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: KVM Management : Migration Date: Sat, 09 Aug 2008 10:48:48 -0500 Message-ID: <489DBC60.40405@codemonkey.ws> References: <218687.89390.qm@web35807.mail.mud.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: KVM List To: jdsw2002@yahoo.com Return-path: Received: from mail-gx0-f29.google.com ([209.85.217.29]:51415 "EHLO mail-gx0-f29.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753415AbYHIPt0 (ORCPT ); Sat, 9 Aug 2008 11:49:26 -0400 Received: by gxk10 with SMTP id 10so7086718gxk.13 for ; Sat, 09 Aug 2008 08:49:25 -0700 (PDT) In-Reply-To: <218687.89390.qm@web35807.mail.mud.yahoo.com> Sender: kvm-owner@vger.kernel.org List-ID: 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 >