From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jacob Gorm Hansen Subject: Re: XEN migration architecture question Date: Thu, 20 Jan 2005 13:56:45 -0800 Message-ID: <41F0291D.8080307@diku.dk> References: <20050120204440.26397.qmail@web41413.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Sender: xen-devel-admin@lists.sourceforge.net Errors-To: xen-devel-admin@lists.sourceforge.net List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , List-Archive: To: andrew.warfield@cl.cam.ac.uk Cc: Eric Tessler , xen-devel@lists.sourceforge.net List-Id: xen-devel@lists.xenproject.org One thing I found fairly easy to setup for self-migration, was to use software RAID-1 (mirroring) to iSCSI targets on the original and destination hosts. When its time to migrate, I add the remote iSCSI disk to the RAID-1 array, and when that has synced up 100%, I self-migrate there. You can either run your iSCSI (or GNBD haven't tried that) targets in dom0, or you can run them in separate domUs (in my implementation, you will first fire off a bootstrap of a small iSCSI-server domain to the remote host, as my dom0 is not allowed to include dangerous stuff such as a TPC/IP stack and an iSCSI server). That gives me live disk-migration using a simple shell-script. Jacob ------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl