- 1 Virtualization
- 1.1 Enterprise Management Tools List
- 1.2 Fedora Virtualization List
- 1.3 Libvirt List
- 1.4 Fedora-Xen List
In this section, we cover discussion of Fedora virtualization technologies on the @et-mgmnt-tools-list, @fedora-xen-list, @libvirt-list and @ovirt-devel-list lists.
Contributing Writer: Dale Bewley
Enterprise Management Tools List
This section contains the discussion happening on the et-mgmt-tools list
Fedora Virtualization List
This section contains the discussion happening on the fedora-virt list.
New list for libguestfs
Fedora Virt Status Update
Also mentioned were:
- Details of a fix for "a dramatic slowdown in virtio-blk performance in F-11 guests"
- Note on Xen Dom0 support.
- New wiki pages created.
- Detailed run-down of current virt bugs.
USB Passthrough to Virtual Machines
This has been covered in FWN, find ref
best Fedora virtualization
I am planning on running several virtual machines on a single host. I will have two or three Linux baeed virtual machines and one or two Windoze. I plan on using a F11 host system. I need most of these to run automatically on boot-up of the host system. It would be really nice if I could use something like the Ctl-Alt-FN to be able to access and switch between virtual machines. This needs to be stable. The machines that these virtual machines are intended to replace are often running hundreds of days between reboots. My gut feel is that the virt-manager suite might be the way to go, editting the apropriate xml files as required. I also see there is a qemu launcher and it seems to work okay. I suspect there are others as well. What tends to be the consensus here on the various virtual machine managers? Are there white papers somewhere that could give some insight?
For stability and long-term maintainability, I wonder if you've considered using RHEL or CentOS? That means you have to use Xen as the hypervisor, but if you use libvirt / virsh / virt-manager, the future upgrade path to KVM is reasonable. All tools stay the same, and you just need to run our forthcoming v2v tool on the guests (or reinstall the guests) when you upgrade.
The only one we're supporting here on Fedora<ref>http://fedoraproject.org/wiki/Virtualization</ref> is libvirt / virsh / virt-manager. Use 'virsh edit <domain>' to edit the XML for a domain. The same commands will work on RHEL / CentOS too.
I suspect this is the result of trying to use SELinux to protect everything and the mandatory access control idea that everything is disallowed except that which is explicitly permitted. But, I just do not understand what and why CD/DVD images and devices are being protected. Furthermore, when virtualization changes a file's context (including /dev/sr0), could this effect other valid usage of these files/devices? If there is no effect for other applications, then just what is protected?
This section contains the discussion happening on the libvir-list.
This section contains the discussion happening on the fedora-xen list.
Xen dom0 Forward Ported to Latest Kernel
Previously, Xen dom0 support in Fedora was provided by forward porting the Xensource patches from kernel 2.6.18 to the version found in the Fedora release at the time. This consumed developer resources and led to separate
packages for a time. As of
Fedora 9 this practice was deamed untenable, and support for hosting Xen guests was dropped from Fedora.
Work has since focused on creating a paravirt operations dom0 kernel based on the most recent upstream vanilla kernel. This work is incomplete and not expected to be done before F12 or even F13. However, experimental dom0 kernels have been created for the adventurous.
Pasi Kärkkäinen tells us the Xen 2.6.18 patches have now been forward-ported to the current 2.6.29 and 2.6.30 kernel. "Forward-porting has been done by Novell for OpenSUSE. Novell also has a forward-port to 2.6.27 for SLES11."
Pasi added "These patches are still more stable and mature than the pv_ops dom0 code.. Also, these patches have the full Xen feature set (pv_ops still lacks some features)."
More history is avilable.