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