From Fedora Project Wiki

< FWN‎ | Beats

(re-re-upload from offline editing - much cleanup still going on...)
 
(281 intermediate revisions by 3 users not shown)
Line 1: Line 1:
[[Category:Virtualization]] <!-- do not copy into FWN issue -->
{{Anchor|Virtualization}}
{{Anchor|Virtualization}}


== Virtualization ==
== Virtualization ==
In this section, we cover discussion on the @et-mgmnt-tools-list, @fedora-virt, @fedora-xen-list, and @libvirt-list of Fedora virtualization technologies.
In this section, we cover discussion of Fedora virtualization technologies on the
 
@fedora-virt list.
Contributing Writer: [[User:Dale|Dale Bewley]]
 
=== Enterprise Management Tools List ===
This section contains the discussion happening on the
[http://www.redhat.com/mailman/listinfo/et-mgmt-tools et-mgmt-tools list]
 
==== New Release virt-manager 0.6.1 ====
[[ColeRobinson|Cole Robinson]] announced[1] a new {{package|virt-manager}} release, version 0.6.1.
 
Virtual Machine Manager provides a graphical tool for administering virtual
machines for <code>KVM</code>, <code>Xen</code>, and <code>QEmu</code>. Start, stop, add or remove virtual devices,
connect to a graphical or serial console, and see resource usage statistics
for existing VMs on local or remote machines. Uses <code>libvirt</code> as the backend
management API.
 
'''New features:'''
* 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 ====
[[ColeRobinson|Cole Robinson]] announced[1] a new <code>virtinst</code> release, version 0.4.1.
 
{{package|python-virtinst}} is a module that helps build and install <code>libvirt</code> based virtual
machines. Currently supports <code>KVM</code>, <code>QEmu</code> and <code>Xen</code> virtual machines. Package
includes several command line utilities, including <code>virt-install</code> (build
and install new VMs) and <code>virt-clone</code> (clone an existing virtual machine).
 
'''New features:'''
* 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
Contributing Writer: [[User:Dale | Dale Bewley]]


=== Fedora Virtualization List ===
=== Fedora Virtualization List ===
Line 52: Line 14:
[http://www.redhat.com/mailman/listinfo/fedora-virt fedora-virt list].
[http://www.redhat.com/mailman/listinfo/fedora-virt fedora-virt list].


==== Fedora Virt Status Update ====
==== Virt Status Report ====
True to his word, [[MarkMcLoughlin|Mark McLoughlin]] posted[1] another weekly update on the status of virtualization development in Fedora. Some highlights included:
[[JustinForbes|Justin Forbes]]
 
posted<ref>http://www.redhat.com/archives/fedora-virt/2009-December/msg00056.html</ref> a Fedora virtualization status report.  
* F11 Alpha Blockers - Workaround found for "unsynchronized TSC" issue[2] which caused guests on certain hosts to hang or crash.
Justin pointed out F13 bugs<ref>http://fedoraproject.org/wiki/Virtualization_bugs</ref> now include Important and Pony classifications in addition to Blocker and Target.
* New release of {{package|libvirt}} coming very soon. It's out now.
* The KVM PCI Device Assignment[3] feature for F11 "received a very positive reception from FESCo", and "basic device assignment seems to be working."
* "Related to PCI device assignment are Intel VT-d issues that have been reported recently. Basically, on some machines ... VT-d support is causing serious and, in one case, data loss."
* New F11 feature page created for <code>sVirt</code>.[4] "sVirt integrates SELinux with the Fedora virtualization stack".
* New patches[5] from Jeremy Fitzhardinge reduce the overhead of enabling
paravirt_ops on bare-metal by 75% in testing.
* Bug count climbed from 186 to 191.
 
{{Admon/warning|FWN Note to Self| Research when I'm online. Plans have changed, F10 is going to get 2.6.29: https://www.redhat.com/archives/fedora-kernel-list/2009-January/msg00098.html Initial builds are available in Koji for testing.  }}
 
[1] http://www.redhat.com/archives/fedora-virt/2009-January/msg00063.html
 
[2] https://bugzilla.redhat.com/475598
 
[3] http://fedoraproject.org/wiki/Features/KVM_PCI_Device_Assignment
 
{{Admon/warning|FWN Note to Self|Check Link. Added "Features" is URL correct?}}
 
[4] http://fedoraproject.org/wiki/Features/SVirt_Mandatory_Access_Control
 
[5] http://lkml.org/lkml/2009/1/28/438
 
=== Fedora Xen List ===
This section contains the discussion happening on the
[http://www.redhat.com/mailman/listinfo/fedora-xen fedora-xen list].
 
==== Xen Users Future on Fedora ====
[[EvanLavelle|Evan Lavelle]] might have struck a nerve when wondering[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."
 
Apropros to the topic, but on another list, [[MarkMcLoughlin|Mark McLoughlin]] explained[7]
"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.
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.
[[GerdHoffmann|Gerd Hoffmann]] confirmed[10] that "...most of the dom0 stuff missed the boat. Some prelimary stuff might be in though..." adding that "The pv_ops/dom0 kernel has some not-yet debugged storage issues (disk controller either fails after a while or doesn't work at all), which is the major stumbling block right now."
 
[[DanielBerrange|Daniel P. Berrange]], of Red Hat Engineering, detailed the history of <code>Xen</code> on Fedora and explained "while it is definitely unfortunate that we don't have a <code>Xen</code> Dom0 kernel in Fedora 9/10, we are *not* trying to shaft anyone & will re-introduce <code>Xen</code> Dom0 kernels to Fedora when they become available." ... "It [is] still hard to say just when these will be accepted upstream, but there is a semi-reasonable [chance] we'll be able to turn <code>Xen</code> Dom0 back on in Fedora 11 kernels."[11]
 
[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
 
[10] http://www.redhat.com/archives/fedora-xen/2009-January/msg00056.html
 
[11] http://www.redhat.com/archives/fedora-xen/2009-January/msg00036.html
 
==== Migrating Xen DomU to KVM Guest ====
{{Admon/warning|FWN Note to Self|Not ready to publish. This needs some digestion. Perhaps a migration page is on the wiki already? Is it here: http://wiki.libvirt.org/page/Virtio ?}}
 
Migrating a virtual machine from Xen to KVM is straight forward. Well, more or less.
 
[[RichardJones|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 {{package|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 <code>virtio</code> drivers in the guest.
"You have to tell the host to give the guest a <code>virtio</code> network card -
change the NIC <code><model type='virtio'/></code> 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 <code>virtio_blk</code> 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 <code>virtio_blk</code> 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."
 
[[MarkMcLoughlin|Mark McLoughlin]] distilled this into the <code>mkinitrd</code> command in the guest:
 
<pre>mkinitrd --with virtio_pci --with virtio_blk -f /boot/initrd-$(kernelversion) $(kernelversion)</pre>
 
"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.
"
 
[[EmreErenoglu|Emre Erenoglu]] elaborated[8]
"You will also need to specify <code>/dev/vdX</code> on the <code>kernel root=</code> line and make sure your init script inside your <code>initrd</code> triggers the virtio drivers at boot so that the <code>/dev/vdX</code> are created."
 
{{Admon/note|FWN Note to Self| Richard said Yup, I got as far as working out that you would have to edit fstab and possibly /boot/grub/device.map and /boot/grub/menu.lst, before giving up.}}
 
{{Admon/warning|FWN Note to Self |F9 x86_64 Bug. No 32 bit grub. Re-word this.}}
 
[[MarkMcLoughlin|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 ===
<references />
This section contains the discussion happening on the
[http://www.redhat.com/mailman/listinfo/libvir-list libvir-list].


==== New Release libvirt 0.6.0 ====
==== RHEL and Fedora Virtualization Feature Parity ====
[[DanielVeillard|Daniel Veillard]] announced[1] a new {{package|libvirt}} release, version 0.6.0.  
Robert Day wondered how the virtualization features<ref>http://www.redhat.com/virtualization/rhev/</ref> of Red Hat Enterprise Linux 5.4
compared to Fedora 12.


<code>Libvirt</code> is a <code>C</code> toolkit to interact with the virtualization capabilities
[[DanielBerrange|Daniel Berrange]]
of recent versions of Linux (and other OSes).
explained<ref>http://www.redhat.com/archives/fedora-virt/2009-December/msg00040.html</ref>
"The KVM based virtualization in RHEL-5.4 is not nearly so far behind
Fedora as you might think. The {{package|libvirt}} mgmt stack in RHEL-5.4 was
rebased to be near parity with [[Releases/11|Fedora 11]], and KVM in RHEL-5.4 is
also pretty close to that using what's best described as a hybrid of
kvm-83 and kvm-84."


'''New features:'''
<references />
* thread safety of the API and event handling (Daniel Berrange)
* allow QEmu domains to survive daemon restart (Guido Gunther)
* extended logging capabilities
* support copy-on-write storage volumes (Daniel Berrange)
* support of storage cache control options for QEmu/KVM (Daniel Berrange)


'''Improvements:'''
* driver infrastructure and locking (Daniel Berrange)
* Test driver infrastructure (Daniel Berrange)
* parallelism in the daemon and associated config (Daniel Berrange)
* virsh help cleanups (Jim Meyering)
* logrotate daemon logs (Guido Gunther)
* more regression tests (Jim Meyering)
* QEmu SDL graphics (Itamar Heim)
* add --version flag to daemon (Dave Allan)
* memory consumption cleanup (Dave Allan)
* QEmu pid file and XML states for daemon restart (Guido Gunther)
* gnulib updates (Jim Meyering and Dan Berrange)
* PCI passthrough for KVM (Jason Krieg)
* generic internal thread API (Daniel Berrange)
* RHEL-5 specific Xen configure option and code (Markus Armbruster)
* save domain state as string in status file (Guido Gunther)
* add locking to all API entry points (Daniel Berrange)
* new ref counting APIs (Daniel Berrange)
* IP address for Xen bridges (John Levon)
* driver format for disk file types (Daniel Berrange)
* improve QEmu/KVM tun/tap performances (Mark McLoughlin)
* enable floppies for Xen fully virt (John Levon)
* support VNC password settings for QEmu/KVM (Daniel Berrange)
* qemu driver version reporting (Daniel Berrange)


There were also dozens of cleanups, documentation enhancements, portability and bug fixes.
====  ====
<references />


[1] http://www.redhat.com/archives/libvir-list/2009-January/msg00863.html
====  ====
<references />

Latest revision as of 18:09, 18 December 2009



Virtualization

In this section, we cover discussion of Fedora virtualization technologies on the @fedora-virt list.

Contributing Writer: Dale Bewley

Fedora Virtualization List

This section contains the discussion happening on the fedora-virt list.

Virt Status Report

Justin Forbes posted[1] a Fedora virtualization status report. Justin pointed out F13 bugs[2] now include Important and Pony classifications in addition to Blocker and Target.

RHEL and Fedora Virtualization Feature Parity

Robert Day wondered how the virtualization features[1] of Red Hat Enterprise Linux 5.4 compared to Fedora 12.

Daniel Berrange explained[2] "The KVM based virtualization in RHEL-5.4 is not nearly so far behind Fedora as you might think. The Package-x-generic-16.pnglibvirt mgmt stack in RHEL-5.4 was rebased to be near parity with Fedora 11, and KVM in RHEL-5.4 is also pretty close to that using what's best described as a hybrid of kvm-83 and kvm-84."