From: Jerone Young <jyoung5@us.ibm.com>
To: Dan Smith <danms@us.ibm.com>
Cc: Ian Pratt <m+Ian.Pratt@cl.cam.ac.uk>,
"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
Julian Chesterfield <julian.chesterfield@cl.cam.ac.uk>,
NAHieu <nahieu@gmail.com>,
Andrew Warfield <andrew.warfield@cl.cam.ac.uk>
Subject: Re: [PATCH] Blktap: Userspace file-based image support.(RFC)
Date: Fri, 30 Jun 2006 17:15:21 -0500 [thread overview]
Message-ID: <1151705722.2570.5.camel@localhost.localdomain> (raw)
In-Reply-To: <m3sllmpfvj.fsf@guaranine.beaverton.ibm.com>
On Fri, 2006-06-30 at 13:06 -0700, Dan Smith wrote:
> ST> Could be useful in places, but it introduces a number of new
> ST> dependencies.
>
> I was mostly commenting about making migrating block devices as easy
> as (or easier) than file-backed domains, especially from a migration
> point of view. Being able to use local LVMs but still migrate easily
> without a NAS would be cool, I think, where appropriate.
I would ask how exactly do you propose to do this ? Today at least
file-backed domains seems to be the only real world way of doing
migrations. Migrating block devices seems a little hairy (what if the
other machine is already using sda for example), and may not be all the
practical to do.
>
> ST> The destination host now relies on the source host for data, so if
> ST> the source crashes, you crash the destination too;
>
> Sure, which a NAS solves, assuming the NAS is stable.
>
> ST> and if you power-cycle, how do you track where in your cluster the
> ST> latest copy of the block device is?
>
> I think that keeping metadata on that and invalidating blocks when you
> pull them off the source host could be done without too much trouble.
> Plus, I'm not talking about multiple-writers, so I think you could
> ignore a lot of the normal locking issues.
>
> ST> A true NAS solution isolates the Xen hosts from these problems.
>
> Absolutely. So what's the benefit of having image files on NFS (as
> you mentioned) if you can use nbd or iSCSI?
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
next prev parent reply other threads:[~2006-06-30 22:15 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-06-20 11:07 [PATCH] Blktap: Userspace file-based image support.(RFC) Ian Pratt
2006-06-20 21:10 ` Dan Smith
2006-06-21 14:45 ` Anthony Liguori
2006-06-30 13:41 ` Stephen C. Tweedie
2006-06-30 14:17 ` Dan Smith
2006-06-30 19:37 ` Stephen C. Tweedie
2006-06-30 20:06 ` Dan Smith
2006-06-30 22:15 ` Jerone Young [this message]
2006-07-01 0:36 ` Mark Williamson
2006-07-01 14:22 ` Dan Smith
2006-07-03 11:00 ` Mark Williamson
2006-07-03 14:52 ` Stephen C. Tweedie
2006-07-03 12:02 ` Harry Butterworth
2006-07-03 14:56 ` Stephen C. Tweedie
2006-07-03 15:40 ` Harry Butterworth
2006-07-04 19:39 ` Andrew Warfield
2006-07-05 0:25 ` Dan Smith
2006-07-05 0:48 ` Andrew Warfield
2006-07-05 1:40 ` Harry Butterworth
[not found] <C0BDB8FE.5C5D%julian@xensource.com>
2006-06-20 13:57 ` [PATCH] Blktap: Userspace file-based image support. (RFC) Julian Chesterfield
[not found] <C0BD844E.5C4D%julian@xensource.com>
2006-06-20 13:44 ` Julian Chesterfield
[not found] <C0BCD26E.5C31%julian@xensource.com>
2006-06-19 21:42 ` Julian Chesterfield
2006-06-19 21:56 ` Anthony Liguori
-- strict thread matches above, loose matches on Subject: below --
2006-06-19 16:19 Andrew Warfield
2006-06-19 16:51 ` NAHieu
2006-06-19 17:22 ` Andrew Warfield
2006-06-19 18:41 ` NAHieu
2006-06-19 21:07 ` Andrew Warfield
2006-06-19 21:16 ` Dan Smith
2006-06-19 18:55 ` Anthony Liguori
2006-06-19 19:22 ` Andrew Warfield
2006-06-19 19:26 ` Andrew Warfield
2006-06-19 19:51 ` Anthony Liguori
2006-06-19 19:15 ` Anthony Liguori
2006-06-19 19:31 ` Andrew Warfield
2006-06-29 3:35 ` Rusty Russell
2006-06-29 5:24 ` Andrew Warfield
2006-06-29 6:31 ` Rusty Russell
2006-06-29 14:34 ` Andrew Warfield
2006-06-30 13:35 ` Stephen C. Tweedie
2006-06-30 14:17 ` Julian Chesterfield
2006-06-30 18:41 ` Jeff Moyer
2006-06-29 11:49 ` Anthony Liguori
2006-06-29 12:26 ` Laurent Vivier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1151705722.2570.5.camel@localhost.localdomain \
--to=jyoung5@us.ibm.com \
--cc=andrew.warfield@cl.cam.ac.uk \
--cc=danms@us.ibm.com \
--cc=julian.chesterfield@cl.cam.ac.uk \
--cc=m+Ian.Pratt@cl.cam.ac.uk \
--cc=nahieu@gmail.com \
--cc=xen-devel@lists.xensource.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.