From owner-freebsd-xen@FreeBSD.ORG Wed Jul 20 23:21:16 2011 Return-Path: Delivered-To: freebsd-xen@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0396D106564A for ; Wed, 20 Jul 2011 23:21:16 +0000 (UTC) (envelope-from scott@bqinternet.com) Received: from mail.bqinternet.com (mail.bqinternet.com [69.9.32.203]) by mx1.freebsd.org (Postfix) with ESMTP id CCBA98FC08 for ; Wed, 20 Jul 2011 23:21:15 +0000 (UTC) Received: from localhost (mail [69.9.32.203]) by mail.bqinternet.com (Postfix) with ESMTP id 0DDD7840062 for ; Wed, 20 Jul 2011 22:50:48 +0000 (GMT) Received: from mail.bqinternet.com ([69.9.32.203]) by localhost (mail.bqinternet.com [69.9.32.203]) (amavisd-new, port 10024) with ESMTP id FPDkDPEl6bxm for ; Wed, 20 Jul 2011 22:50:47 +0000 (GMT) Received: from [192.168.23.125] (mail [69.9.32.203]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.bqinternet.com (Postfix) with ESMTP id 48A85840060 for ; Wed, 20 Jul 2011 22:50:47 +0000 (GMT) Message-ID: <4E275BC1.9040508@bqinternet.com> Date: Wed, 20 Jul 2011 18:50:41 -0400 From: Scott Burns User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: freebsd-xen@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Xen save/resume with XENHVM kernel X-BeenThere: freebsd-xen@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion of the freebsd port to xen - implementation and usage List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 23:21:16 -0000 Hi guys, I have been using FreeBSD 8.2 with the XENHVM kernel for several months. The performance is great, and the reliability is rock solid. However, while preparing to upgrade the hardware in our Xen servers, I was unpleasantly surprised to find that Xen's save/restore functionality does not work, and thus I can't use live migration. I see in sys/dev/xen/blkfront/blkfront.c that the blkfront_resume() function is not implemented, and there are also some notes about it in blkif_recover(). Is anyone currently working on this? Is there a hack I could use to get live migration working, even if it's not under ideal conditions? -- Scott Burns System Administrator BQ Internet Corporation