I'm preparing to do an install of FC4t2 and rawhide. I need to port, test and support code to multiple vendors and releases of Linux on the one luggable PC. It's going to be fun trying to get copies of FC3/4,Rawhide, Ubuntu and Debian etc to coexist as differing boot option, let along getting them to run together under Xen. Looking over the Xen documentation ( http://www.fedoraproject.org/wiki/FedoraXenQuickstart ) and skimming though the Xen mailing lists, I have a couple of questions and ideas. First, major questions: a) Whats the chances of a stable ( enough ) Xen making it into the final release of FC4? b) Is it going to be safe/stable/secure for the domain U kernels use LVM mounts? Or are loopback file systems, mounted by the domain 0 kernel, the only effective choice? c) Is it worth allocating swap partitions for domain U systems? Is it safe/possible to use LVM for this? d) Is the combination of X-server/AGP/sound going to available and stable on domain 0 kernels? e) Will the actual performance of the non-test final release kernels approach the performance of the recent Xen demos? f) Will Redhat be back porting Xen domain 0 and U kernels for RHEL 3/4? ( slightly off topic for this list ) Second, minor thoughts: In the past, for multi OS booting I have used multiple primary bootable /boot partitions, one for each distribution, with the MBR grub install selecting and chaining off one of the four partitions. This still effectively limits you to four distros/OSs. Any further OSs require manual merging of the root/initrd/boot info into one of the existing primary partition boot sequences. This works fine but it has a tendency to upsets any SELinux auditing. Is there a better way of doing this? For example have each root FS store the /boot directory on root and hack grub to read off multiple non- primary/LVM partitions. Due to grub/BIOS limitations is it possible? A similar problems occurs when remounting any shared SELinux protected file systems, including /home. "/sbin/restorecon -v -R /home" or "/sbin/fixfiles relabel" solves the problem but defeats the protection. Is it possible to verify the partition based on the previous labeling? Is it possible for different instances of SELinux system to share common labeling for shared partitions? Thirdly, so-so ideas: Have the Fedora Core core developer given any consideration to a single "xen" init.d script which would : 1) Setup the virtual networking for the domain 0 and domain U hosted systems. Virtual bridging + remote DHCP/static addressing OR internal DHCPd + NAT + plus forwarding 2) Allocate file system mount rights on a first come first served basis, with fall over of NFS mounting if the first serves the requested partition. There should be an easier way to configuring the combinations of Fedora,Grub,LVM and Xen than manually editing configure files and CLI launching instances. Multiple root file systems with multiple kernels, each in turn with multiple options for multiple run levels, mount point and services. However, with a little scripted configuration, one OS install and one mounted file system tree, should be able to perform all of the following, one at a time, depending on boot flags and kernel selection. Native without Xen Workstation : Run level 5 Graphical mode. Runs most user applications locally. Can host remote services ( httpd etc ). X-Terminal : Run level 4? LTSP like thin graphical client. Runs most user applications remotely. Server : Run level 3 Text mode. Runs most user applications locally. hosts remote services. Repair : Run level 2 Text mode Root login only. Does not host remote services. Xen domain 0 Xen + Domain 0 Workstation : Run level 5 Graphical mode ( assuming that AGP is compatible ) Should operate same as native workstation Xen + Domain 0 X-Terminal : Run level 4? Graphical mode ( assuming that AGP is compatible ) Can also log into local domain U servers. Xen + Domain 0 Server : Run level 3 Text mode, Xen + Domain 0 Monitor : Run level 2? Text mode. Minimal Xen host setup, plus network support. Runs user application and services on domain U servers NOTE : whatever runlevel the Xen domain 0 is running it would still host/run the "xen" init.d Xen0 services. Xen domain U Note only two. Domain U Server : Run level 3 Domain U Repair : Run level 2 It would require a lot of modifications to the existing init.d scripts which would each have to take into account the virtual mode NATIVE | Xen0 | XenU But the overall result would be well worth it. Lastly. Any word on getting a version of Anaconda to work under Domain U Server level? Ie VNCserver mode with the domain 0 host granting lvm partition/group access. -- David Mohring <heretic@xxxxxxxxxx>
