>
> some of the problems i remember encountering:
> in dom0: creating a new domain, destroying it, and creating a new domain
> reboots my machine. same happens if dom1 is unable to boot, and the
> domains gets destroyed this way.
This isn't good. I haven't seen Xen crash due to another domain
failing in a very long time. It's possible that this bug has been
introduced recently -- I'll try and reproduce.
> the default .config works fine, but as soon as i enable
> CONFIG_EXPERIMENTAL and CONFIG_FS_DEVFS(sp?), dom0 isn't able to boot
> anymore (immediate reboot). i'll try examining this one in a ring 1 domain,
> as soon as i have my first virtual harddrive install boot.
Odd. I've never used devfs, but I'd have thought it would have
worked. Its configuration will probably need teaching about
virtual block devices.
> things that don't work:
> mouse (logitech ps/2 optical wheelmouse) neither in X nor gpm
PS2 mice seem to work for us. Can you say a bit more about the setup.
> questions:
> how do i assign a partition as root partition to the new domain?
> i suspect vbds are what i want. are they documented anywhere?
You can either give the new domain a real, physical partition as
its root, or give it a virtual disk.
If the former, you'll need to grant the domain access e.g. to
give domain 1 r/w access to /dev/hda4 :
xenctl physical grant -phda4 -w -n1
You'll need to set "root=/dev/hda4" on the command line for the
new domain.
Alternatively, create and populate a virtual disk, and then use
'xenctl vbd create' to attach it to another domain. [see the
other thread on xen-devel for more info]
> any discussions about a 2.6 port yet? are you aiming for
> inclusion in 2.7?
We'll probably do a 2.6 port once its stable. Inclusion it 2.7
would be great, but we'll need to demonstrate a vibrant user
community. That's where you come in ;-)
> i know that the multiboot approach is more flexible, but would it be
> possible to implement xen's functionality into a linux kernel? could
> this possibly increase dom0*'s performance and range of available
> drivers?
Trying to implement Xen within Linux is actually likely to slow
things down. In the long term, we see Xen's future more as a
'next generation BIOS'. We want to create a standard
OS-independent environment for running device drivers in a
protected ring-1 environment.
In the shorter term, we may add support to allow drivers for 'low
performance' devices like USB, PCMCIA etc to run in domain0, and
be virtualized via domain0. This should give us the same hardware
support as Linux, until we convince the world that Xen should be
shipped on every machine ;-)
Cheers,
Ian
-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel
|
Home