Now and Xen:Complexities of Fedora,Grub,LVM and Xen

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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>


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux