| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] Excellent work; some questions, observations
> Ian Pratt wrote:
> > xenctl physical grant -psda2 -w
> >
> >
> Is it safe to assume that granting write access to the same root
> partition that domain0 started from would be potentially dangerous, if
> not disasterous?
Mounting the same partition read-write in two domains is
guaranteed disastrous!!! (strictly speaking, granting write
access to two domains isn't disasterous; actually using write
access in two domains is.)
I guess we should could have a check in Xen to try and prevent
this from happening, but some cluster file systems are actually
designed such that they can do this safely.
Sorry, I assumed sda2 in your example was a new partition that
you'd copied your root file system on to.
Granting the new domain read-only access to daomin0's root file
system should be safe, but the new domain is likely to get
somewhat upset with having a read-only root. Furthermore if you
happen to make any changes to the file system from domain0, the
new domain is likely to come to the conclusion that the file
system is corrupt, as it will see inconsistencies between its
buffer cache and what its reading off disk.
If you don't want to create a new partition for your new domain,
the best way is to run an NFS server in domain0 and export a copy
of the root directory to domain1.
There's a rather terse example of how to do this in README.CD,
drawing on the example /etc/exports file in /etc/xen-exports
> In which case, a read-only root partition would be
> more appropriate instead. I have separate partitions for /home /var
> /usr /tmp /boot and /. I'd like to instantiate a unique but identical
> domain without replicating the entire system. /usr would easily mount
> read-only. The rest would probably need to be copied to a virtual
> device on a single / mount. Any guidance on this?
Read-only direct mount of /usr should work fine.
For things like /homes, having shared read-write access via NFS
should work just fine. If you use knfsd as opposed to unfsd
you'll need to export each partition individually as exports
don't cross mount points (they do on unfsd with the -r option).
Having per-domain copies of /var seems sensible. I guess /tmp
could be shared, but you might have filename collisions, so I'd
probably make them per-domain.
I'd be inclined to start by copying your entire root, /var and
/tmp partitions to some NFS exportable location
e.g. /exports/roots/root1
Edit the etc/fstab file to reflect the NFS / mount and read-only
disk partition /usr mount.
It should boot and work just fine with the appropriate kernel
command line arguments. (remember to restart your nfsd after
editing /etc/exports ;-)
If you're feeling a bit more adventurous you can reduce the
amount of disk space you need for the root1 by arranging that the
/bin, /sbin and /lib directories are actually symlinks to
read-only copies in /usr/root/. README.CD gives some advice on
how to do this.
In the mid-term, we hope to release a user-space NFS server that
implements a proper stackable copy-on-write file system, but its
still undergoing development.
Best,
Ian
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel
|
|
|
| |
|
Home