[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] 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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |