| |
|
 |
|
 |
|
|
|
| |
|
|
xen-users
RE: [Xen-users] live migration on SAN
> -----Original Message-----
> From: xen-users-bounces@xxxxxxxxxxxxxxxxxxx
> [mailto:xen-users-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Fast Jack
> Sent: 12 June 2007 17:08
> To: xen-users@xxxxxxxxxxxxxxxxxxx
> Subject: [Xen-users] live migration on SAN
>
> Hi,
>
> Currently I'm trying to set up a number of servers with Xen 3.0. To
> ensure high availability, this setup should support live migration of
> the domUs between the hardware-nodes.
>
> On the hardware side we have a number of servers connected to a SAN
> via fibre channel. The problem now is that I can't find any definitive
> requirements for the virtual block devices and filesystems presented
> to the domUs. The documentations doesn't say much on that subject.
> I have read a number of example setups ranging from ext3 in LVM
> (non-cluster) volumes on the SAN-disk to cluster-aware solutions based
> on e.g. OCFS2.
>
> As far as I can tell no concurrent access to each dumUs storage from
> multiple hosts takes place during live migration or otherwise. So I'm
> wondering whether cluster-save technology like OCFS2, GFS or CLVM are
> really necessary to ensure that the domUs filesystem is not corrupted
> during migration. If possible I would like to avoid using
> cluster-software as it brings with it new points of failure.
>
> So my questions are:
> What are the actual requirements on the domUs storage?
The obvious requirement is that the storage is available to both physical
machines - so some sort of networked storage is absolutely necessary.
I don't believe that it needs to be "cluster" or "multi-access" capable,
although I'm not 100% sure. The reason I believe this to be superfluous is that
the domain on the "new" machine isn't actually started until AFTER the domain
on the "old" machine has been stopped. What makes me unsure is that there is a
chance that some disk read/write operation from "old" machine is still "in
flight" somewhere [actually, only writes are a problem here], and thus will
arrive after some read request by "new" machine.
The bad thing about getting this wrong is of course that the problems caused by
such "in flight" operations will most likely just be harmless, and the result
of any "cross" access is unnoticable, but on the rare occasion where it goes
wrong, according to Murphy's law, it will be something important that gets
messed up.
I don't really know how to figure out if there is a possible race-condition
between data written by old guest and new guest reading the same data.
--
Mats
> Could you give me a few examples of thoroughly tried and
> tested setups?
>
> Thanks in advance
>
> Björn
>
> _______________________________________________
> Xen-users mailing list
> Xen-users@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-users
>
>
>
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|
|
|
| |
|
Home