(re-upload from offline editing - much cleanup still going on...) |
(→Xen Users Shafted on Fedora?: this thread done) |
||
Line 45: | Line 45: | ||
[http://www.redhat.com/mailman/listinfo/fedora-xen fedora-xen list]. | [http://www.redhat.com/mailman/listinfo/fedora-xen fedora-xen list]. | ||
==== Xen Users | ==== Xen Users Future on Fedora ==== | ||
{{ | [[EvanLavelle|Evan Lavelle]] wondered[1] if those who have invested years in {{package|xen}} on Fedora have been "shafted". "<code>Xen</code> isn't flavour of the month around here, but I assumed there were good reasons for that. Now, rather belatedly, I've found" that Red Hat acquired Qumranet and {{package|KVM}}. (FWN #143[2]) | ||
[[ | [[NeilThompson|Neil Thompson]] thought[3] not. "Shafted?...I don't think so. We're just in a blip at the moment." Neil pointed out that "RHEL5, which has a number of years left, includes xen - I don't think | ||
Red Hat are going to mess their corporate clients around by removing it. The problem with F8 is that the {{package|kernel}} people could no longer drag an obsolete (2.6.21) <code>kernel</code> around just for xen, and decided to concentrate on helping get it into the mainstream <code>kernel</code>. This[4] has taken longer than expected." | |||
[ | Jan ONDREJ was also concerned[5] that, "<code>KVM</code> is still not a replacement for paravirtualized machines and I think fully virtualized <code>KVM</code> will be slower like a paravirtualized XEN." | ||
[[RichardJones|Richard W.M. Jones]] countered[6] | |||
"<code>KVM</code> is a great replacement for <code>Xen</code>. It's much easier to use for a start -- no more rebooting into a completely separate <code>kernel</code> hypervisor. As long as you have the <code>virtio</code> drivers in the guest, which is the default for all new Linux distros, performance is roughly the same." | |||
[[RichardJones|Richard W.M. Jones]] countered[ | |||
"KVM is a great replacement for Xen. It's much easier to use for a start -- no more rebooting into a completely separate kernel hypervisor. As long as you have the <code>virtio</code> | |||
Apropros to the topic, but on another list, [[MarkMcLoughlin|Mark McLoughlin]] explained[7] | Apropros to the topic, but on another list, [[MarkMcLoughlin|Mark McLoughlin]] explained[7] | ||
"Para-virtualization isn't always better. | "Para-virtualization isn't always better. <code>KVM</code> uses full virtualization, meaning that it uses the processor's support for virtualization. This means you can run an unmodified guest OS on <code>KVM</code>. | ||
If you can modify the guest OS, then <code>KVM</code> does allow you to use paravirtualization for some performance sensitive operations - so e.g. we've got <code>pvclock</code>, pv MMU and <code>virtio</code> devices. | |||
KVM uses full virtualization, meaning that it uses the processor's support for virtualization. This means you can run an unmodified guest OS on KVM. | |||
If you can modify the guest OS, then KVM does allow you to use paravirtualization for some performance sensitive operations - so e.g. we've got <code>pvclock</code>, pv MMU and <code>virtio</code> devices. | |||
Don't get tied up in marketing terminology - try both and decide for yourself which works best for you." | Don't get tied up in marketing terminology - try both and decide for yourself which works best for you." | ||
Support for dom0 is targeted[8] for <code>kernel</code> 2.6.29, but the | |||
changelogs[9] for the release candidates don't seem to indicate completion yet. | |||
for | |||
[1] http://www.redhat.com/archives/fedora-xen/2009-January/msg00031.html | [1] http://www.redhat.com/archives/fedora-xen/2009-January/msg00031.html | ||
[ | [2] http://fedoraproject.org/wiki/FWN/Issue143#Red_Hat_Acquires_Makers_of_KVM.2C_Qumranet_Inc. | ||
[ | [3] http://www.redhat.com/archives/fedora-xen/2009-January/msg00033.html | ||
[ | [4] http://fedoraproject.org/wiki/Features/XenPvopsDom0 | ||
[ | [5] http://www.redhat.com/archives/fedora-xen/2009-January/msg00032.html | ||
[ | [6] http://www.redhat.com/archives/fedora-xen/2009-January/msg00041.html | ||
[ | [7] http://www.redhat.com/archives/et-mgmt-tools/2009-January/msg00063.html | ||
[ | [8] http://wiki.xensource.com/xenwiki/XenParavirtOps | ||
[9] http://www.kernel.org/pub/linux/kernel/v2.6/testing/ChangeLog-2.6.29-rc2 http://www.kernel.org/pub/linux/kernel/v2.6/testing/ChangeLog-2.6.29-rc1 | |||
==== Migrating Xen DomU to KVM Guest ==== | ==== Migrating Xen DomU to KVM Guest ==== |
Revision as of 23:38, 31 January 2009
Virtualization
In this section, we cover discussion on the @et-mgmnt-tools-list, @fedora-xen-list, @libvirt-list and @ovirt-devel-list of Fedora virtualization technologies.
Contributing Writer: Dale Bewley
Enterprise Management Tools List
This section contains the discussion happening on the et-mgmt-tools list
New Release virt-manager 0.6.1
Cole Robinson announced[1] a new virt-manager
release, version 0.6.1.
This release includes:
- VM disk and network stats reporting (Guido Gunther)
- VM Migration support (Shigeki Sakamoto)
- Support for adding sound devices to an existing VM
- Enumerate host devices attached to an existing VM
- Allow specifying a device model when adding a network device to an existing VM
- Combine the serial console view with the VM Details window
- Allow connection to multiple VM serial consoles
- Bug fixes and many minor improvements.
[1] http://www.redhat.com/archives/et-mgmt-tools/2009-January/msg00067.html
New Release virtinst 0.4.1
Cole Robinson announced[1] a new virtinst
release, version 0.4.1.
This release includes:
- Add virt-image -> vmx support to virt-convert, replacing virt-pack (Joey Boggs)
- Add disk checksum support to virt-image (Joey Boggs)
- Enhanced URL install support: Debian Xen paravirt, Ubuntu kernel and boot.iso, Mandriva kernel, and Solaris Xen Paravirt (Guido Gunther, John Levon, Cole Robinson)
- Expanded test suite
- Numerous bug fixes, cleanups, and minor improvements
[1] http://www.redhat.com/archives/et-mgmt-tools/2009-January/msg00068.html
Fedora Virtualization List
This section contains the discussion happening on the fedora-virt list.
Fedora Xen List
This section contains the discussion happening on the fedora-xen list.
Xen Users Future on Fedora
Evan Lavelle wondered[1] if those who have invested years in xen
on Fedora have been "shafted". "Xen
isn't flavour of the month around here, but I assumed there were good reasons for that. Now, rather belatedly, I've found" that Red Hat acquired Qumranet and KVM
. (FWN #143[2])
Neil Thompson thought[3] not. "Shafted?...I don't think so. We're just in a blip at the moment." Neil pointed out that "RHEL5, which has a number of years left, includes xen - I don't think
Red Hat are going to mess their corporate clients around by removing it. The problem with F8 is that the kernel
people could no longer drag an obsolete (2.6.21) kernel
around just for xen, and decided to concentrate on helping get it into the mainstream kernel
. This[4] has taken longer than expected."
Jan ONDREJ was also concerned[5] that, "KVM
is still not a replacement for paravirtualized machines and I think fully virtualized KVM
will be slower like a paravirtualized XEN."
Richard W.M. Jones countered[6]
"KVM
is a great replacement for Xen
. It's much easier to use for a start -- no more rebooting into a completely separate kernel
hypervisor. As long as you have the virtio
drivers in the guest, which is the default for all new Linux distros, performance is roughly the same."
Apropros to the topic, but on another list, Mark McLoughlin explained[7]
"Para-virtualization isn't always better. KVM
uses full virtualization, meaning that it uses the processor's support for virtualization. This means you can run an unmodified guest OS on KVM
.
If you can modify the guest OS, then KVM
does allow you to use paravirtualization for some performance sensitive operations - so e.g. we've got pvclock
, pv MMU and virtio
devices.
Don't get tied up in marketing terminology - try both and decide for yourself which works best for you."
Support for dom0 is targeted[8] for kernel
2.6.29, but the
changelogs[9] for the release candidates don't seem to indicate completion yet.
[1] http://www.redhat.com/archives/fedora-xen/2009-January/msg00031.html
[2] http://fedoraproject.org/wiki/FWN/Issue143#Red_Hat_Acquires_Makers_of_KVM.2C_Qumranet_Inc.
[3] http://www.redhat.com/archives/fedora-xen/2009-January/msg00033.html
[4] http://fedoraproject.org/wiki/Features/XenPvopsDom0
[5] http://www.redhat.com/archives/fedora-xen/2009-January/msg00032.html
[6] http://www.redhat.com/archives/fedora-xen/2009-January/msg00041.html
[7] http://www.redhat.com/archives/et-mgmt-tools/2009-January/msg00063.html
[8] http://wiki.xensource.com/xenwiki/XenParavirtOps
[9] http://www.kernel.org/pub/linux/kernel/v2.6/testing/ChangeLog-2.6.29-rc2 http://www.kernel.org/pub/linux/kernel/v2.6/testing/ChangeLog-2.6.29-rc1
Migrating Xen DomU to KVM Guest
Migrating a virtual machine from Xen to KVM is straight forward. Well, more or less.
Richard W.M. Jones explained[3] how to migrate from Xen to KVM
- Ensure recent kernel in guest with
"Install a recent Linux kernel in the guest, adjust the configuration
file[1], and reboot. You only need xenner
if you want to run the Xen
PV guest unchanged (ie. without installing a new guest kernel).
[1] 'virsh edit domname', and edit the domain type, <os> and <emulator> fields, as detailed here: http://libvirt.org/drvqemu.html"
And[5] detailed how to take advantage of speedy virtio
drivers in the guest.
"You have to tell the host to give the guest a virtio
network card -
change the NIC <model type='virtio'/>
as described here: http://libvirt.org/formatdomain.html#elementsNICS
The guest needs to have a relatively up to date kernel which has drivers for the virtio network card - that's included in all recent Linux kernels (virtio_net.ko)."
Richard finally noted[6]
"Upgrading to using virtio_blk
is very complicated. You have to
rebuild initrd, and there's a difficult circular dependency to be
resolved when doing this because you need to be using virtio_blk
in
order for mkinitrd to believe that you need it, although possibly
mkinitrd supports some command line argument to override this. I
actually gave up at this point.
For newly installed guests, recent anaconda just works everything out for you and puts the correct drivers into initrd."
Mark McLoughlin distilled this into the mkinitrd
command in the guest:
mkinitrd --with virtio_pci --with virtio_blk -f /boot/initrd-$(kernelversion) $(kernelversion)
"You only need to do this once. After that, if a new kernel is installed while you're booted off a virtio disk, then mkinitrd will include the modules automatically. "
Emre Erenoglu elaborated[8]
"You will also need to specify /dev/vdX
on the kernel root=
line and make sure your init script inside your initrd
triggers the virtio drivers at boot so that the /dev/vdX
are created."
Template:Admin/Warning Mark McLoughlin added[9] a caveat. "Could this have been an x86_64 Fedora 9 xen guest? If so, you probably hit a nasty special case - the F9 x86_64 xen kernel didn't have support for running 32 bit binaries like grub, so the bootloader would never have been installed into the MBR. That works fine for pygrub, but not with KVM's real BIOS."
[3] http://www.redhat.com/archives/fedora-xen/2009-January/msg00041.html
[4] http://wiki.libvirt.org/page/Virtio
[5] http://www.redhat.com/archives/fedora-xen/2009-January/msg00048.html
[6] http://www.redhat.com/archives/fedora-xen/2009-January/msg00053.html
[7] http://www.redhat.com/archives/fedora-xen/2009-January/msg00054.html
[8] http://www.redhat.com/archives/fedora-xen/2009-January/msg00058.html
[9] http://www.redhat.com/archives/fedora-xen/2009-January/msg00078.html
Libvirt List
This section contains the discussion happening on the libvir-list.
oVirt Devel List
This section contains the discussion happening on the ovirt-devel list.