WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-users

Re: [Xen-users] Live Migration... shortest path

To: "Kraska, Joe A (US SSA)" <joe.kraska@xxxxxxxxxxxxxx>
Subject: Re: [Xen-users] Live Migration... shortest path
From: Tim Post <tim.post@xxxxxxxxxxxxxxx>
Date: Thu, 15 Feb 2007 12:40:35 +0800
Cc: xen-users@xxxxxxxxxxxxxxxxxxx
Delivery-date: Wed, 14 Feb 2007 20:40:08 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <09D59AEF0405D740BDCA2FAC0E0EA97601B3D208@xxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-users-request@lists.xensource.com?subject=help>
List-id: Xen user discussion <xen-users.lists.xensource.com>
List-post: <mailto:xen-users@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=unsubscribe>
Organization: Net Kinetics
References: <09D59AEF0405D740BDCA2FAC0E0EA97601B3D208@xxxxxxxxxxxxxxxxxxx>
Reply-to: tim.post@xxxxxxxxxxxxxxx
Sender: xen-users-bounces@xxxxxxxxxxxxxxxxxxx
On Tue, 2007-02-13 at 14:43 -0800, Kraska, Joe A (US SSA) wrote:
> In a prior message I documented my woes in getting an NFS_ROOT xen
> 
> going. I haven’t resolved those yet, want to try a different tack at
> this:
> 
>  
> 
> If the group were to recommend a path of least resistance
> 
> to showing migration/live migration, which configuration would it be?

I like AoE personally because its easy, route-less and stable. All of my
servers however have a secondary gig-e nic and switch just for AoE and
migration / interconnect stuff. 

I put guest FS's on a NAS and their swap locally on the node supporting
them (stupid to swap to network storage). Half of your battle is just
keeping your naming convention correlated to AoE block devices available
so you can tell them apart at a glance.

i.e. /dev/etherd/e1.0 would be something dom-0 on node1 is using, e3.4
would be something vm #4 on node 3 is using.

Then name your dom-u's and vifnames appropriately so bandwidth
accounting can follow it as it migrates around. 

Most of my guests have names using this nomenclature :

x-y-z

Where :

x = location ID
y = node ID
z = VM id

So migrating 6-8-32 over to 7-9-21 means I migrated vm #32 on node 8 at
location 6 over to node 9 at location 7 (locations being geographical)
with iscsi bridging in between to move from location to location.

I have "helpers" setup to auto increment and rename ID's so they inherit
their bandwidth accounting from the previous location or node, which
ever. So , vm named 1-2-3 would have 'vifname=1-2-3.0' , meaning , eth0
on vif 1-2-3.

Since AoE remains a local phenomenon for me at each location, the
major / minor always point to the right place. This *really* makes
automation simpler especially when working with distributed
applications.

It takes a little hammering and scripting to do, but a worth while
effort.

Otherwise you'll soon have a bowl of block and ethernet device spaghetti
to sort out, if your network is of any substantial size. I migrate
locally, and geographically based on this nomenclature and its worked
out pretty well.

Planning is as important as what you use to accomplish it.

Hope I didn't just confuse you even more.

Best,
--Tim



_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users

<Prev in Thread] Current Thread [Next in Thread>