This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] /etc/xc/defaults question..

To: I RATTAN <rattan@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] /etc/xc/defaults question..
From: Mark Williamson <Mark.Williamson@xxxxxxxxxxxx>
Date: Thu, 08 Apr 2004 12:31:44 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxxxx
Delivery-date: Thu, 08 Apr 2004 12:36:56 +0100
Envelope-to: steven.hand@xxxxxxxxxxxx
In-reply-to: Message from I RATTAN <rattan@xxxxxxxxxxxxx> of "Tue, 06 Apr 2004 16:27:49 EDT." <Pine.GSO.4.58.0404061623170.988@xxxxxxxxxxxxxxxxxxxx>
List-archive: <http://sourceforge.net/mailarchive/forum.php?forum=xen-devel>
List-help: <mailto:xen-devel-request@lists.sourceforge.net?subject=help>
List-id: List for Xen developers <xen-devel.lists.sourceforge.net>
List-post: <mailto:xen-devel@lists.sourceforge.net>
List-subscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=subscribe>
List-unsubscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=unsubscribe>
Sender: xen-devel-admin@xxxxxxxxxxxxxxxxxxxxx
The vbd_list contains a list of mappings of the form:

('real device name [as seen by dom0]',
'target device name [what the new domain sees the device as]',

The 'w' (writeable) permission implicitly also allows read access.  The real 
device name is specified as 'phy:devname' for a physical disk or partition, or 
as 'vd:identifier' for a Xen 'virtual disk'.

As you know, you can use this list of mappings to selectively grant a new 
domain access to certain disk resources.  You should never allow two domains 
to simultaneously have write access to any disk area - normal disk filesystems 
aren't designed to cope with multiple-writer access, so it will cause severe 
corruption.  Linux also gets confused if a filesystem that's read-only by one 
domain is written to by another, so single writer, multiple reader should also 
be avoided (although it won't cause corruption).

It is perfectly safe to have two domains have read-only access to a 
filesystem, however - this can be useful to avoid duplicating data).

Here's a concrete example of VBDs, where I'm configuring my system so I can 
start a second domain:

Suppose my machine has the following real partitions (as viewed from dom0, or 
booting with a normal Linux kernel):

/dev/hda1 : DOM0's / filesystem (the one you boot off)
/dev/hda2 : DOM0's /usr filesystem
/dev/hda3 : DOM0's swap partition
/dev/hda5 : a secondary / filesystem for use by a second domain
/dev/hda6 : a swap partition for the second domain to use

The new domain I'm going to start must have a separate / partition since it 
will have different information in it.  It will want write access to this 
partition.  It will also need a different swap partition to DOM0 because the 
two domains will be swapping out different data.

I might, however, want to share the contents of /usr, since they'll be the 
same for both domains.  This would have to be read-only for both DOM0 and my 
second domain, otherwise Linux will get confused.

* DOM0's fstab should specify /usr as read only.

For this example, I want the second domain to think its / filesystem is on 
/dev/sda1, its swap is on /dev/sda2 and its /usr is on /dev/sda3.

* vbd_list = [('phy:hda5','sda1','w'), ('phy:hda6','sda2','w'),

This setups up the appropriate disk translations so that the second domain 
will get this view of the disks.

* the other domain's fstab should match these details, i.e. / on /dev/sda1, 
swap on /dev/sda2, /usr read only on /dev/sda3

The standard xc_dom_create.py does some sanity checking to try to avoid 
dangerous sharing.  If you get a VBD sharing error, then you should check 
that, for instance, none of the second domain's filesystems are mounted in 
DOM0 and that the VBD mappings do not allow incorrect sharing.

This should get you going.  There's a more detailed discussion of this (and 
some more advanced stuff about Virtual Disks) in the VBD-HOWTO.txt document, 
which you should take a look at).  You could alternatively use NFS-root to 
boot the second domain.



This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
Xen-devel mailing list