Xen devel - Dec 2007 - sharing file between running domU (windowxp) and dom0

hi all,

As far as i know, both domU and dom0 runs in isolation. I want to modify a
particular file of running domU(xp) from dom0.

i have tried to pause the domu, then using lomount, mount its image and then
modifying the file and umounting the image. But when i unpause domu, it does not
reflect the changes.

Is it possible to do so. If yes, then what are possibles codes location should i
try for.

regards
rajneesh

       
---------------------------------
Looking for last minute shopping deals?  Find them fast with Yahoo! Search.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Fri, 7 Dec 2007 04:49:11 -0800 (PST)
rajneesh rana <rajneeshrana009@yahoo.com> wrote:
> hi all,
> 
> As far as i know, both domU and dom0 runs in isolation. I want to
> modify a particular file of running domU(xp) from dom0. 
> 
> i have tried to pause the domu, then using lomount, mount its image
> and then modifying the file and umounting the image. But when i
> unpause domu, it does not reflect the changes.
Is domU reachable from dom0 in your case?
If yes, the problem boils down to how do you change a config on machine
X which from machine Y, both connected to each other.

Isn''t this approach fair enough?
Or maybe i misunderstood your problem.

Thanks
		Pradeep
-- 
heh...people do try to read my signature.

http://eagain.wordpress.com
http://emptydomain.googlepages.com

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

> As far as i know, both domU and dom0 runs in isolation. I want to modify a
> particular file of running domU(xp) from dom0.
>
> i have tried to pause the domu, then using lomount, mount its image and
> then modifying the file and umounting the image. But when i unpause domu,
> it does not reflect the changes.
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.

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

-- 
Dave: Just a question. What use is a unicyle with no seat?  And no pedals!
Mark: To answer a question with a question: What use is a skateboard?
Dave: Skateboards have wheels.
Mark: My wheel has a wheel!

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

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

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Hi there,
> > 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.
I left that bit out because you mentioned just modifying a WinXP filesystem 
disk.  Cluster filesystems should be OK, provided all the domains accessing 
them are taking part in the locking protocol (i.e. as long as domanis are set 
up like you would do for separate hosts then it''s fine).

It''s also fine for multiple domains to mount a shared network
filesystem such
as NFS or CIFS because those are designed to handle multiple access.

Most other filesystems have no concept of writes happening "behind their
back"
so they can''t be used in this way.  In additon to what I said earlier,
please
note that it''s not just having multiple writers to an FS
that''s dangerous.
Even if you have the disk mounted read-only in one domain when you write to 
it in another, you''re liable to cause that domain to read corrupted
data and
possibly crash.

I think you can get away with not shutting down a domU if you are able to 
properly unmount the filesystem before you modify it in dom0, then mount it 
again in the domU.  But that does mean that you can never modify the / 
filesystem in this way, since it can''t be unmounted.
> Does virtual environment outs some extra constraints on the filesystems?
Shouldn''t add constraints beyond those of a normal host.  It''s
just that in
usual operation you''re not in a position to accidentally mount a
filesystem
on multiple hosts so many people haven''t come across this before.
> FWIW how is XenFS different from OCFS2 and GFS?
XenFS is more like a network filesystem than a disk filesystem.  The data is 
stored by a "normal" filesystem and XenFS exports that filesystem. 
The
difference from a network filesystem is that it uses shared memory instead of 
IP.
> 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?
Should be equivalent to the multiple host case, so long as you''re
running a
true cluster filesystem and both domains are configured correctly to access 
it.

Cheers,
Mark
> 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


-- 
Dave: Just a question. What use is a unicyle with no seat?  And no pedals!
Mark: To answer a question with a question: What use is a skateboard?
Dave: Skateboards have wheels.
Mark: My wheel has a wheel!

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Fri, 7 Dec 2007 17:41:32 +0000
Mark Williamson <mark.williamson@cl.cam.ac.uk> wrote:
> Hi there,
Hello Mark,
> 
[snip]
> > Mark,I guess i understood your point here.
> > My question is what about cluster filesystems like GFS or OCFS2.
> 
[...]
> 
> Most other filesystems have no concept of writes happening "behind
> their back" so they can''t be used in this way.  In additon to
what I
> said earlier, please note that it''s not just having multiple
writers
> to an FS that''s dangerous. Even if you have the disk mounted
> read-only in one domain when you write to it in another, you''re
> liable to cause that domain to read corrupted data and possibly crash.
[...]
> > FWIW how is XenFS different from OCFS2 and GFS?
> 
> XenFS is more like a network filesystem than a disk filesystem.  The
> data is stored by a "normal" filesystem and XenFS exports that
> filesystem.  The difference from a network filesystem is that it uses
> shared memory instead of IP.
XenFS looks like an interesting prospect.Shared memory instead of
network perhaps will mean better speed.Any repository where i can have
a look at its source?Can i employ it on my Xen machine or is it still
under development?

Thanks for explaining things lucidly and for your patience.

Cheers,
	Pradeep
[...]

-- 
heh...people do try to read my signature.

http://eagain.wordpress.com
http://emptydomain.googlepages.com

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

> > > FWIW how is XenFS different from OCFS2 and GFS?
> >
> > XenFS is more like a network filesystem than a disk filesystem.  The
> > data is stored by a "normal" filesystem and XenFS exports
that
> > filesystem.  The difference from a network filesystem is that it uses
> > shared memory instead of IP.
>
> XenFS looks like an interesting prospect.Shared memory instead of
> network perhaps will mean better speed.
That''s the idea, both because you''re cutting out the overhead
of simulating a
network (and all the protocol processing) and because it exposes more 
knowledge about the underlying system - which could enable more optimisations 
(such as sharing the same cached filesystem data between multiple domains).
> Any repository where i can have 
> a look at its source?
http://xenbits.xensource.com/maw/xenfs.hg

But the code in there is very buggy and nasty ;-)  It might hurt your brain!  
There are loads of flaws in it.
> Can i employ it on my Xen machine or is it still 
> under development?
It''s definitely not ready for deployment.  It''s incomplete and
buggy, although
it''s still under development so maybe one day it''ll be usable!
> Thanks for explaining things lucidly and for your patience.
No problem!

Cheers,
Mark

-- 
Dave: Just a question. What use is a unicyle with no seat?  And no pedals!
Mark: To answer a question with a question: What use is a skateboard?
Dave: Skateboards have wheels.
Mark: My wheel has a wheel!

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Sat, 8 Dec 2007 14:41:59 +0000
Mark Williamson <mark.williamson@cl.cam.ac.uk> wrote:

[snip]
> > XenFS looks like an interesting prospect.Shared memory instead of
> > network perhaps will mean better speed.
> 
> That''s the idea, both because you''re cutting out the
overhead of
> simulating a network (and all the protocol processing) and because it
> exposes more knowledge about the underlying system - which could
> enable more optimisations (such as sharing the same cached filesystem
> data between multiple domains).
Sounds good.
Good luck and thanks for your time.
Will try to get to XenFS source sooner or later :).

Cheers,
	Pradeep
> 
> > Any repository where i can have 
> > a look at its source?
> 
> http://xenbits.xensource.com/maw/xenfs.hg
> 
> But the code in there is very buggy and nasty ;-)  It might hurt your
> brain! There are loads of flaws in it.
> 
> > Can i employ it on my Xen machine or is it still 
> > under development?
> 
> It''s definitely not ready for deployment.  It''s
incomplete and buggy,
> although it''s still under development so maybe one day
it''ll be
> usable!
> 
> > Thanks for explaining things lucidly and for your patience.
> 
> No problem!
> 
> Cheers,
> Mark
> 

-- 
heh...people do try to read my signature.

http://eagain.wordpress.com
http://emptydomain.googlepages.com

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel