From: Pradeep Singh <rautelap@gmail.com>
To: Mark Williamson <mark.williamson@cl.cam.ac.uk>
Cc: rajneesh rana <rajneeshrana009@yahoo.com>, xen-devel@lists.xensource.com
Subject: Re: sharing file between running domU (windowxp) and dom0
Date: Fri, 7 Dec 2007 22:49:45 +0530 [thread overview]
Message-ID: <20071207224945.15e9c1f4@darkstar> (raw)
In-Reply-To: <200712071648.26147.mark.williamson@cl.cam.ac.uk>
On Fri, 7 Dec 2007 16:48:24 +0000
Mark Williamson <mark.williamson@cl.cam.ac.uk> wrote:
[snip]
>
> You should never, ever do that. You *must always* shut down a domain
> before modifying its filesystem from the outside. Otherwise you can
> create corruption that will destroy the domain's disk data. Just
> pausing the domain or saving it is not enough to protect you, and
> neither will using the guest's "hibernate" feature. The domain
> *really* has to be properly shut down.
Mark,I guess i understood your point here.
My question is what about cluster filesystems like GFS or OCFS2.
Does virtual environment outs some extra constraints on the filesystems?
FWIW how is XenFS different from OCFS2 and GFS?
What i mean is how is a HVM domain(e.g linux) and domain0 different
from two machines on a network from the perspective of cluster
filesystems?
PS - I am a rookie as far as distributed/cluster fs are
concerned.Please spare my ignorance and kindly enlighten me on this.
Thanks
Pradeep
> I'm sorry to emphasize that so harshly but it really is very very
> important.
>
> This is because filesystems are written with the assumption that they
> "own" the disk and that nothing will ever change "underneath" them.
> If you modify the filesystem from the outside then you're doing stuff
> without the guest OS knowing about it. It won't be looking for this
> and will get confused. This could seriously damage your filesystem.
>
> If you do it by accident, you could try xm destroy-ing the domain
> immediately in order to prevent it getting confused by the changes to
> the underlying disk - before it has time to corrupt anything. xm
> destroying a domain which is modifying the filesystem has corruption
> risks of its own though (and will lose any in-memory data), so it's
> better just to avoid this situation.
>
> I hope that helps. Again, sorry to be so harsh, but this is one
> thing about virtual machines that is *really* important to watch out
> for, or you will have major problems at some stage.
>
> Cheers,
> Mark
>
--
heh...people do try to read my signature.
http://eagain.wordpress.com
http://emptydomain.googlepages.com
next prev parent reply other threads:[~2007-12-07 17:19 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-12-07 12:49 sharing file between running domU (windowxp) and dom0 rajneesh rana
2007-12-07 16:21 ` Pradeep Singh
2007-12-07 16:48 ` Mark Williamson
2007-12-07 17:19 ` Pradeep Singh [this message]
2007-12-07 17:41 ` Mark Williamson
2007-12-07 21:09 ` Pradeep Singh
2007-12-08 14:41 ` Mark Williamson
2007-12-08 14:55 ` Pradeep Singh
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=20071207224945.15e9c1f4@darkstar \
--to=rautelap@gmail.com \
--cc=mark.williamson@cl.cam.ac.uk \
--cc=rajneeshrana009@yahoo.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.