Xen devel - Oct 2003 - Excellent work; some questions, observations

Congratulations on your release!  Between Slashdot and the bittorrent, I 
imagine this will get a lot of attention.

I booted from the CD and toyed around creating various domains... this 
worked just fine.  I also copied the images to my boot partition and 
successfully booted my development machine using Xen.  Some minor tweaks 
to XF86Config and X was running, too.

What I wasn''t able to do was replicate the environment of the CD 
sufficiently to get a domain running.  xenctl works, and I can create a 
domain, but when running the newdomain script, it would fail when 
mapping the cdrom_link.  Apparently a control file in /var/lib/xen 
dealing with virtual devices is missing.  I''m away from that machine at
the moment, so I don''t have the exact name but it was something like 
vdstat.xml if memory serves.  Perhaps that''s enough to go on.  The 
documentation on the CD is good, but perhaps I missed the full details 
on setting this up in a bootable fashion without fdisk''ing my machine 
first.  I''m running RH8.0 on that machine with the following GRUB
entry:

title Xen - XenoLinux (2.4.22)
     kernel /xenimage.gz dom0_mem=131072 ser_baud=115200 noht
     module /xenolinux.gz root=/dev/sda2 ro console=tty0

I renamed image.gz as I already have one.  Everything worked that I 
expected. Lots of warnings, but not a big deal.  Any plans for IPv6?

Finally, the CD has a lot of... questionable items on it.  I suppose 
this comes from the original bootable linux project.  You might consider 
omitting the exploits directory in the future.  It feels wrong.  And it 
doesn''t correlate with your stated objective.

Otherwise, outstanding work.  I''ve been working on a lightweight 
operating system that requires resource isolation, and Xen solves many 
of my problems, particularly in testing.

Anybody considering work on a single-step debugger/monitor for a domain? 
  That would make ring 0/1 OS debugging _very_ interesting.

John Joganic



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

> Congratulations on your release!  Between Slashdot and the bittorrent, I 
> imagine this will get a lot of attention.
> 
> I booted from the CD and toyed around creating various domains... this 
> worked just fine.  I also copied the images to my boot partition and 
> successfully booted my development machine using Xen.  Some minor tweaks 
> to XF86Config and X was running, too.
Excellent, it''s always good to hear success stories.
> What I wasn''t able to do was replicate the environment of the CD 
> sufficiently to get a domain running.  xenctl works, and I can create a 
> domain, but when running the newdomain script, it would fail when 
> mapping the cdrom_link.  Apparently a control file in /var/lib/xen 
> dealing with virtual devices is missing.  
Ignore the error about the missing file in
/var/lib/xen/vdstat.xml -- you only have this file if you''ve
created virtual disks (rather than physical partitions), which
I''m guessing you haven''t. 

What the /etc/xen-mynewdom script is trying to do is grant the
new domain access to the physical partition it needs to be able
to read and write. The default is ''no access''.

For the CD, domains need to be able to mount the CD read-only as
their /usr partition.  The link called /dev/cdrom_link is created
on boot and points to whatever device is the CDROM (/dev/hdc,
/dev/sda etc).

Once you''ve installed on your hard disk, you''ll need to update
/etc/xen-mynewdom to grant physical access as appropriate
for your root partition (plus swap and anything else you want it
to be able to access).

e.g. to grant read/write access to /dev/sda2. (In xenctl scripts,
the domain number being operated on is implicit. If you''re
running the commands on the command line use the -n option to
specify the domain)

  xenctl physical grant -psda2 -w

> I renamed image.gz as I already have one.  Everything worked that I 
> expected. 
image.gz was a terrible choice of name on our part. Sorry.
> Lots of warnings, but not a big deal.
Although some will be due to attempts to access hardware that the
new domain is not allowed to get at, most will probably be due to
missing modules in the xeno-linux kernel. Most will "just work"
if you enable the relevant options in the .config file, build
them, and put them in /lib/modules as per normal.

We just like building lean, mean kernels round here as we''re
impatient. I guess the default .config could be a bit more
> Any plans for IPv6?
We''re working on a new version of the Virtual Firewall Router,
but I''m afraid IPv6 isn''t very high up the feature list.
Sorry.
 
> Finally, the CD has a lot of... questionable items on it.  I suppose 
> this comes from the original bootable linux project.  You might consider 
> omitting the exploits directory in the future.  It feels wrong.  And it 
> doesn''t correlate with your stated objective.
Ha, I didn''t even realise there was an exploits directory on the CD!

We wanted a bootable ''live iso'' version of RH9, and took the
file
systems from the Plan-B CD, with the initrd and build setup from
hpa''s SupeRescue. 

Round here, we use Plan-B as a general system rescue disk, and
I''m afraid I just didn''t realise there was any questionable
stuff
on the CD. How embarrassing.
> Otherwise, outstanding work.  I''ve been working on a lightweight 
> operating system that requires resource isolation, and Xen solves many 
> of my problems, particularly in testing.
We''re very keen to build up a user community.
 
> Anybody considering work on a single-step debugger/monitor for a domain? 
>   That would make ring 0/1 OS debugging _very_ interesting.
There''s certainly a plan to use Xen for debugging of distributed
applications by running multiple simulated nodes on the same
machine under close control. Single-step is certainly a
possibility.

Cheers,
Ian


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

On Fri, Oct 03 03 at  3:01:41PM +0100, Ian Pratt wrote:
> > What I wasn''t able to do was replicate the environment of the
CD
> > sufficiently to get a domain running.  xenctl works, and I can create
a
> > domain, but when running the newdomain script, it would fail when 
> > mapping the cdrom_link.  Apparently a control file in /var/lib/xen 
> > dealing with virtual devices is missing.  
> 
> Ignore the error about the missing file in
> /var/lib/xen/vdstat.xml -- you only have this file if you''ve
> created virtual disks (rather than physical partitions), which
> I''m guessing you haven''t. 
I should''ve made it more clear that this was a warning, not an error,
when I rewrote the command line interface. You should be able to touch
vdstat.xml to make the warning go away, as xenctl''s parser
won''t actually
care if the file is empty.
> > Anybody considering work on a single-step debugger/monitor for a
domain?
> >   That would make ring 0/1 OS debugging _very_ interesting.
> 
> There''s certainly a plan to use Xen for debugging of distributed
> applications by running multiple simulated nodes on the same
> machine under close control. Single-step is certainly a
> possibility.
This is one feature that I might be interested in looking into, if I''m
not going to do XenoXP stuff.. it would probbaly help the XenoXP port
too since the windows kernel debugger doesn''t work properly under Xen..

Once I get a moment I might look into how to approach this.

-- 
Torne
torne@wolfpuppy.org.uk



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

Ian Pratt wrote:
>Once you''ve installed on your hard disk, you''ll need to
update
>/etc/xen-mynewdom to grant physical access as appropriate
>for your root partition (plus swap and anything else you want it
>to be able to access).
>
>e.g. to grant read/write access to /dev/sda2. (In xenctl scripts,
>the domain number being operated on is implicit. If you''re
>running the commands on the command line use the -n option to
>specify the domain)
>
>  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?  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?

Thanks!

John Joganic



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

> 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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel