Hi,

At this point... if you have something like SVM/UFS or ZFS that you're storing 
image files on.. not much you can do. The reason why is that if you want to 
move just one guest domain.. you would have to move all of them. The reason is 
that with SVM/UFS and ZFS.. or regular VxVM/VxFS.. you can't have more than one 
host reading/writting to that storage. You would need something like QFS or 
clustered VxVM/VxFS.

My recommendation is to setup SAN LUN's specifically for each guest domain. In 
that sense, you could have a ZFS pool for each guest domain. So, you would have 
to export the pool on the source and import it on the destination somewhere 
during the migration process. Unfortunately, LDM is lacking the hooks to handle 
this automatically. In which case, if you want the least amount of work.. then 
don't use image files and instead use SAN LUN's directly for each guest domain. 
That way, there's no mounting/unmounting involved.

 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
Octave J. Orgeron
Solaris Virtualization Architect and Consultant
Web: http://unixconsole.blogspot.com
E-Mail: unixconsole at yahoo.com
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*




________________________________
From: Tom Gendron <[email protected]>
To: ldoms-discuss at opensolaris.org
Sent: Friday, January 16, 2009 1:21:37 PM
Subject: Re: [ldoms-discuss] ldm 1.1 warm migration and shared storage



Liam Merwick wrote: 
On 16/01/2009 15:29, Tom Gendron wrote:

Hi,

I am playing with the warm migration feature of ldm 1.1 and notice that
there is no provision made to move the root disk from source to target
machine. I must do this by some external means correct?


Yes, the disk backend(s) must be visible to both machines. e.g. a SAN or
have the disk image files exported via NFS.


I see how NFS could do this but I am confused on how to do it with my
SAN.  I have direct attached fiber channel disks that are visible to
both hosts but I am not sure how to share the file system. ZFS is going
to label the pool and be tied to one of the hosts. I would have to
explicitly export it and then import it to the target machine.  Is
there a filesystem solution to this with native Solaris tools? I think
QFS would solve this but that is not native. Anything else?

How are we planning to solve this when we complete the migration
capability as in live migration?

My setup has two T5x20s with three to four ldoms each. Both machines are
setup identically and the ldoms boot off of local files that resides in
a zfs file system on one of the internal disks on each server. From the
control domain it looks like this.

VDS
NAME VOLUME OPTIONS DEVICE
primary-vds0 ldm1-vol1 /export/ldoms/ldm1/rootdisk
ldm2-vol1 /export/ldoms/ldm2/rootdisk


Using shared storage, what are options in getting this rootdisk from
ldom1 from the source to the target machine?

Note that I do have a Fiber channel JBOD array attached to both machines
but I am not sure how to use it to faciliate warm migration and moving
this file. With Vmotion the vmdk file (rookdisk) is not moved becuase of
vmfs being a clustered file system. Anyone care to offer an easy way to
approximate vmotion w.r.t to the ldom root disk file?

I am Looking for ideas.


You don't really "move" the file. If the disk images are on shared
storage and visible to both machines then you keep it at the same
location and bother the source and target machines access it at
that location.

e.g. both source and target machines would have a disk added like this.
ldm add-vdsdev /net/somemachine/disk.image disk1 at primary-vds0
or something similar for a SAN LUN

HTH

-- Liam
_______________________________________________
ldoms-discuss mailing list
ldoms-discuss at opensolaris.org 
http://mail.opensolaris.org/mailman/listinfo/ldoms-discuss 

-- 
Tom Gendron
SPARC Systems Technologist
U.S Systems Practice
Sun Microsystems 
781 442-2622



      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://mail.opensolaris.org/pipermail/ldoms-discuss/attachments/20090117/565cab5c/attachment.html>

Reply via email to