Paul Schulze
2008-Aug-30 06:44 UTC
[Xen-devel] Feature Requests (maybe some even for Xen 3.4)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi everyone, While using Xen for a little project of mine in the last 2 months, I discovered some limitations in its usefulness for a virtualized desktop environment and compiled a list of features, that would help me out and might benefit Xen in general. 1) I would like to see support for Optical drives like CD/DVD-ROM and RW devices in a paravirtualized DomU included in Xen. From my point of view, exclusive use would be sufficient for the moment, since I imagine it to be quiet troublesome if two guests would try to burn data on the same disk at the same time. This might already be possible with Xen 3.3 and the PvSCSI support, but I haven''t tried it yet. There seems to be a shortage of documentation on that particular subject, so it is hard to tell, if it could work. 2) A way to pass through PS/2 hardware (keyboard and mouse) or maybe even character devices in general to paravirtualized guests would be nice. I know, there is a way to work around this, but it involves passing a whole USB controller to the DomU and requires the user to have a usb keyboard and mouse. 3) There is already a way to pass the primary VGA graphics card through to a HVM guest, so I would really like to be able to do the same with a paravirtualized guest. The VGA hardware would need to be visible to the kernel very early, for it to grab it for kernel output and might need a way to disable the virtual ttys, to enable use as a text-mode terminal (not too important though). More important would be full graphics support (X11/DirectFB), with both VESA and specialized chipset device drivers. 4) PCIFront support in PV_OPS kernels would be very, since it is one of the key features, I am currently missing and it does seem like many of the distributors have given up on forward porting their set of XenLinux patches. As I know, the most recent kernel version with support for this feature is 2.6.24. This feature seems widely used in home server setups and I would really prefer to use it with a recent kernel. Also, depending on a distributor always means that a custom kernel build is very difficult, because distributors only seem to fix what is related to their specialized kernel build. For example, it is near impossible to compile a linux kernel with only DomU support from the Ubuntu sources, even compiling a (more or less) Vanilla 2.6.24 kernel with Ubuntu patches took about 3h and some knowledge in C programming. Justification (or why someone would want to use a virtualized desktop system): Personally, I am a big fan of virtualization and I have watched several solutions for years now. But one thing, I did never like, is having direct access to the running virtual machine from my desktop, be it via changing the harddsik images, or any form of direct management access. Desktops are the main targets for a wide range of area attacks like worms and viruses (not too threatening on linux at the moment, but still there) and having a desktop system running as a Dom0 automatically endangers all the DomU systems. There are ways to prevent this, for example by putting the whole desktop into a chroot environment, but that might prove quiet a bit more difficult. I realize, that with the current methods of passing PCI devices through to a DomU, security might not be much higher, but it might still be harder to figure out and to exploit then a chroot environment. Besides that, being able to update and reboot the Desktop system while the servers are left untouched would improve the convenience as well as the security of the Desktop further and therefor make the whole system more secure. All this combined would enable f.e. small companies to have a cluster/ grid-like network set up, where users are able to work on their workstations, while a second DomU on each system could for example be connected to a cluster/grid master, to handle larger tasks like rendering or calculations, whenever necessary and without the administrators having to fear the "stupidity" of their favorite user too much (who probably doesn''t even use more then 5% of his computers capabilities per day). Looking at the virtualization features, already included in the current hardware (mainly CPUs for now), I think cases like this will become very common in the future, along with (hardware-bundled) virtual appliances (firewalls/gateways, different kinds of servers and so on) for desktop computers and I would really like to see my favorite solution, Xen, take the lead on that field. All the best, Paul. - -- Paul Schulze Mail: avlex gmx net ($1@$2.$3) Public Key: http://solaris-net.dyndns.org/keys/key_avlex.asc "Making mistakes is human, but to really screw things up, you need Computers" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iD8DBQFIuOxFYDWOGtiChoARApdEAJ9+D2oj1Y+7ra323wwAh14BgFhJygCfSS5t uHNe7GY2ZoJ9NeLbfmudC5k=P2df -----END PGP SIGNATURE----- _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel