Hi,
On Mon, 2006-07-03 at 13:02 +0100, Harry Butterworth wrote:
> > Could be useful in places, but it introduces a number of new
> > dependencies. The destination host now relies on the source host for
> > data, so if the source crashes, you crash the destination too; and if
> > you power-cycle, how do you track where in your cluster the latest copy
> > of the block device is?
>
> It's easy. You run code to coordinate the mapping inside a
> fault-tolerant virtual machine which persists across node failures and
> cluster power cycles.
Right, you just made the point I was making --- you've introduced
dependency on a new hypothetical fault-tolerant, cluster-aware device
layer. :-)
In principle, with the right software, and configuring your entire
infrastructure from scratch, this sort of device-based mechanism may
work very well.
But today, with my existing storage already set up, the only way I can
easily add Xen migration capabilities to my network, taking advantage of
the existing storage server I have, is to use NFS from that server. I
just don't have any block-level SAN configured. *That* is why NFS is
important --- not because it's necessarily the better choice, but that
it's one of the configurations we can expect users to have already.
Conversely, for users with SANs already, whether running over iSCSI or
FC or whatever, block-level migration will be needed. It's a matter of
being able to use existing solutions rather than mandating a new storage
configuration.
--Stephen
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home