From Fedora Project Wiki

< FWN‎ | Beats

No edit summary
 
(108 intermediate revisions by 2 users not shown)
Line 2: Line 2:


{{Anchor|Virtualization}}
{{Anchor|Virtualization}}


== Virtualization ==
== Virtualization ==
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.
In this section, we cover discussion of Fedora virtualization technologies on the
@fedora-virt list.


Contributing Writer: [[User:Dale | Dale Bewley]]
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]
==== More Device Support in virt-manager 'Add Hardware' Wizard ====
[[ColeRobinson|Cole Robinson]]
patched<ref>http://www.redhat.com/archives/et-mgmt-tools/2009-July/msg00013.html</ref>
{{package|virt-manager}} to implement adding of virtual video devices in the
'Add Hardware' wizard.  Cole also implemented<ref>http://www.redhat.com/archives/et-mgmt-tools/2009-July/msg00012.html</ref> attaching serial and parallel devices.
Both these features were added to
{{package|python-virtinst|virt-install}}<ref>http://www.redhat.com/archives/et-mgmt-tools/2009-July/msg00010.html</ref>. Serial ports can be directed to sockets listening on remote hosts. For example: <code>--serial udp,host=192.168.10.20:4444</code>. That may come in handy for the F12 Hostinfo feature<ref>http://fedoraproject.org/wiki/Features/Hostinfo</ref>.
<references />
==== Xen, Windows, and ACPI ====
[[GuidoGünther|Guido Günther]]
noted<ref>http://www.redhat.com/archives/et-mgmt-tools/2009-July/msg00000.html</ref>
that <code>virt-install</code> disables ACPI and APIC for Windows XP guests.
Adding, that it seems "that Windows XP is working fine with acpi/apic enabled which has
the immediate advantage that poweroff via ACPI works as expected.
So does it make sense to handle winxp the same win2k3?". Windows 2003 guests have ACPI enabled.
[[PasiKärkkäinen|Pasi Kärkkäinen]]
went to the xen-devel list and confirmed<ref>http://www.redhat.com/archives/et-mgmt-tools/2009-July/msg00007.html</ref>
and relayed "Keir Fraser replied that ACPI with Windows has been working properly at least since Xen 3.1.0 days".
Pasi then updated the Xen wiki page<ref>http://wiki.xensource.com/xenwiki/XenWindowsACPI</ref>.
<references />


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


==== New Mailing List and New Releases of libguestfs ====
==== Virt Status Report ====
[[RichardJones|Richard Jones]]
[[JustinForbes|Justin Forbes]]
announced<ref>http://www.redhat.com/archives/fedora-virt/2009-July/msg00107.html</ref>
posted<ref>http://www.redhat.com/archives/fedora-virt/2009-December/msg00056.html</ref> a Fedora virtualization status report.  
the creation of a new list<ref>http://www.redhat.com/mailman/listinfo/libguestfs</ref> dedicated to
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.
"{{package|libguestfs}}/<code>guestfish</code>/<code>virt-inspector</code> discussion/development".
 
The current release is now 1.0.57<ref>http://www.redhat.com/archives/libguestfs/2009-July/msg00011.html</ref>, but Richard is so fast that may change by the time you read this.
 
'''Recent new features:'''
* <code>virt-df</code> - like 'df' for virtual machines
* New Perl library called Sys::Guestfs::Lib
* Now available for EPEL
* Tab completion in guestfish now completes files and devices
* Big change to the code generator
* Lots more regression tests
* guestfish commands: time, glob, more, less
* new commands: readdir, mknod*, umask, du, df*, head*, tail*, wc*, mkdtemp, scrub, sh, sh-lines.
* Debian native<ref>http://www.redhat.com/archives/fedora-virt/2009-July/msg00088.html</ref> (debootstrap, debirf) support
 
See previous release announcement for 1.0.14 in FWN#179<ref>http://fedoraproject.org/wiki/FWN/Issue179#New_Release_libguestfs_1.0.41</ref>
and be sure to see the project homepage<ref>http://libguestfs.org/</ref> for
extensive usage examples.
 
<references />
 
==== Fedora Virt Status Update ====
[[MarkMcLoughlin|Mark McLoughlin]]
posted<ref>http://www.redhat.com/archives/fedora-virt/2009-July/msg00083.html</ref>
another Fedora Virt Status Update reminding that [[releases/12|Fedora 12]] is
quickly approaching with the Feature Freeze on 2009-07-28.
 
Also mentioned were:
* Details of a fix for "a dramatic slowdown in virtio-blk performance in F-11 guests"<ref>https://bugzilla.redhat.com/509383</ref>
* Note on Xen Dom0 support.
* New wiki pages created.
* Detailed run-down of current virt bugs.


<references />
<references />


==== USB Passthrough to Virtual Machines ====
==== RHEL and Fedora Virtualization Feature Parity ====
[[MarkMcLoughlin|Mark McLoughlin]]
Robert Day wondered how the virtualization features<ref>http://www.redhat.com/virtualization/rhev/</ref> of Red Hat Enterprise Linux 5.4
posted instructions<ref>http://www.redhat.com/archives/fedora-virt/2009-June/msg00182.html</ref> for attaching a USB device to a guest using {{package|virt-manager}} in Fedora 11. This could previously (FWN#165<ref>http://fedoraproject.org/wiki/FWN/Issue165#Hot_Add_USB_Device_to_Guest</ref>) be accomplished only on the command line.
compared to Fedora 12.


Unfortunately, those wishing to manage their iPhone or newer iPods in a guest (yours truly included), KVM does not yet support the required USB 2.
[[DanielBerrange|Daniel Berrange]]
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."


<references />
<references />


=== Libvirt List ===
This section contains the discussion happening on the
[http://www.redhat.com/mailman/listinfo/libvir-list libvir-list].
==== New Release libvirt 0.6.5 ====
[[DanielVeillard|Daniel Veillard]]
announced<ref>http://www.redhat.com/archives/libvir-list/2009-July/msg00060.html</ref>
a new {{package|libvirt}} release, version 0.6.5.
'''New features:'''
'''Improvements:'''
<code>libvirt</code> 0.6.4 was
released<ref>http://fedoraproject.org/wiki/FWN/Issue179#New_Release_libvirt_0.6.4</ref>
on May 29.


====  ====
<references />
<references />


==== F11 and KVM Migrations ====
====  ====
[[ScottBaker|Scott Baker]]
tried<ref>http://www.redhat.com/archives/libvir-list/2009-July/msg00187.html</ref>
"to do a 'migration' from one host to another and I'm getting an error."
"Where can I look next to figure out why it didn't work?"
virsh # migrate --live Narwhal qemu+ssh://10.1.1.1/system
error: operation failed: failed to start listening VM
 
[[DanielVeillard|Daniel Veillard]]
suggested checking {{filename|/var/log/libvirt/qemu/Narwhal.log}} on the target server. It came out that one server was running x86_64 while the other was i586.
 
[[ChrisLalancette|Chris Lalancette]]
said<ref>http://www.redhat.com/archives/libvir-list/2009-July/msg00202.html</ref>
"that's just not going to work.  In theory it might work, but it's never
been tested, so I'm not surprised it doesn't.  In general migration is extremely
finicky when it comes to CPU versions, and versions of the software." And
suggested trying again after starting libvirtd by hand with debugging turned
up.
<code>LIBVIRT_DEBUG=1 /usr/sbin/libvirtd --verbose --listen</code>
 
<references />
 
==== The Role of libvirtd ====
[[HughBrock|Hugh Brock]]
described<ref>http://www.redhat.com/archives/libvir-list/2009-July/msg00179.html</ref>
client desires to make
"libvirtd be a one-stop shop for everything they need
to do on a virtualization host, including things we have traditionally
held out-of-scope for libvirt. A partial list of those things would
include:"
 
* In-depth multipath config management
* Hardware lifecycle management (power-off, reboot, etc.)
* HA configuration
 
Hugh then asked "why *not* expand the scope of libvirtd
to be a one-stop shop for managing a node? Is there a really good
reason it shouldn't have the remaining capabilities libvirt users
want?"
 
[[DanielBerrange|Daniel Berrange]]
replied<ref>http://www.redhat.com/archives/libvir-list/2009-July/msg00182.html</ref>
"This is essentially suggesting that libvirtd become a general purpose
RPC layer for all remote management tasks. At which point you have
just re-invented QPid/AMQP or CIM or any number of other general
purpose message buses."
 
<pre>
libvirtd has a core well defined goal:
 
- Provide a remote proxy for libvirt API calls
 
if you want todo anything more than that you should be considering an
alternative remote management system. We already have 2 good ones to
choose from supported with libvirt
 
- QPid/AMQP, with libvirt-qpid  agent + your own custom agents
- CIM, with libvirt-CIM + your own custom CIM providers
 
Both of these offer other benefits besides just pluggable support
for other functionality. In particular
 
- Non-blocking asynchronous RPC calls
  - Assured delivery for RPC calls
- Scalable network architecture / topology
- Inter-operability with plugins written by other projects/vendors
 
Furthermore, adding more plugins to libvirtd means we will never
be able to reduce its privileges to an acceptable level, because we'll
never know what capabilities the plugins may want.
</pre>
 
Hugh countered <ref>http://www.redhat.com/archives/libvir-list/2009-July/msg00183.html</ref>
<pre>
I understand your point -- certainly we want to use existing RPC
mechanisms for libvirt and node management, not maintain our own.
 
However, given a libvirt-qpid daemon on the node that handles RPC over
QMF (for example), is there not some value in having libvirt expose a
consistent API for the operations people want to do on a host regardless
of whether they have directly to do with managing a virtual machine or
not?
 
I will note that when I presented the large client with the option of
QMF talking to multiple agents on the node but exposing (effectively) a
single API and a single connection, they seemed much happier. So perhaps
the right way to attack this is with the ovirt-qpid daemon we are
currently working on.
 
Daniel V., any further thoughts on this?
</pre>
 
[[DanielBerrange|Daniel Berrange]]
<ref>http://www.redhat.com/archives/libvir-list/2009-July/msg00184.html</ref>
<pre>
> consistent API for the operations people want to do on a host regardless
> of whether they have directly to do with managing a virtual machine or
> not?
 
I don't really see any value in that - you're just putting in another
abstraction layer where none need exist. Just have whatever QMF agent
you write talk directly to the thing you need to manage. If someone
wants to write a QMF agent to managing cluster software, they don't
need to introduce an artificial dependancy on libvirtd, when their
agent could talk directly to the cluster software being managed, and
thus be useful without libvirt deployed.
 
> I will note that when I presented the large client with the option of
> QMF talking to multiple agents on the node but exposing (effectively) a
> single API and a single connection, they seemed much happier. So perhaps
> the right way to attack this is with the ovirt-qpid daemon we are
> currently working on.
 
A client application cannot tell whether a remote service is implemented
by a single agent, or multiple agents, nor do they see the concept of
a connection. All they see is a set of objects, representing everything
on the message bus. So again for clients, there is no need for everything
to be in one agent.
</pre>
 
[[DanielVeillard|Daniel Veillard]]
was<ref>http://www.redhat.com/archives/libvir-list/2009-July/msg00186.html</ref>
"a bit synpathetic to the suggestion though."
<pre>
I think libvirt API
should help run those virtualization nodes, I would not open the gate
like completely, but if we could provide all APIs needed to manage the
node on a day by day basis  then I think this is not really beyond our
scope. I think that netcf is an example of such API where we start to
add admin services for the purpose of running virtualization. Things
like rebooting or shutting down the node would fit in this, maybe
editing a drive partition too.
  HA configuration starts to be a bit stretched, I would expect this to
be set once at creation and not part of the routine maintainance, so
probably out of scope, multipath is a bit more in scope we discussed
this already.
  Basically if we take the idea of a stripped down Node used only for
virtualization, then except for operations which are first time setup
options or maintainance, I think we should try to cover the requirements
of normal operations of that node. To some extend that means we would
step on the toes of CIM, but we would stick to a subset that's sure.
</pre>
 
<references />
 
==== Upcoming 0.6.5 release and switching to git ====
[[DanielVeillard|Daniel Veillard]]
<ref>http://www.redhat.com/archives/libvir-list/2009-July/msg00007.html</ref>
 
<references />
 
==== libvirt Repositories Mirrored on Gitorious ====
[[DanielBerrange|Daniel Berrange]]
announced<ref>http://www.redhat.com/archives/libvir-list/2009-July/msg00252.html</ref>
"I have created a {{package|libvirt}} project<ref>http://gitorious.org/libvirt</ref> on gitorious which has a mirror of
the master branch of the libvirt.git repository. This mirror is *readonly*
and updated automatically every 15 minutes. The purpose of this mirror is
to allow people to easily publish their personal <code>libvirt</code> working repos
to the world. The master upstream repository for <code>libvirt</code> does not change<ref>http://libvirt.org/git</ref>".
 
<references />
 
==== virsh Dump for QEMU Guests ====
[[PaoloBonzini|Paolo Bonzini]]
submitted<ref>http://www.redhat.com/archives/libvir-list/2009-July/msg00255.html</ref>
a patch that "uses a stop/migrate/cont combination to implement
"virsh dump" for QEMU guests
{{bz|507551}}. The code is mostly based on qemudDomainSave
, except that the XML
prolog is not included as it is not needed to examine the dump
with e.g. crash."
 
<references />
 
=== Fedora-Xen List ===
This section contains the discussion happening on the
[http://www.redhat.com/mailman/listinfo/fedora-xen 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 {{package|kernel}} and {{package|kernel-xen}} packages for a time. As of
[[Releases/9|Fedora 9]]<ref>http://docs.fedoraproject.org/release-notes/f9/en_US/sn-Virtualization.html</ref> this practice was deamed<ref>https://www.redhat.com/archives/fedora-xen/2007-November/msg00106.html</ref> untenable, and support for hosting Xen guests was dropped from Fedora.
 
Work has since focused on creating a paravirt operations dom0<ref>http://fedoraproject.org/wiki/Features/XenPvopsDom0</ref> 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<ref>http://fedoraproject.org/wiki/FWN/Issue170#Experimental_Dom0_Kernel_Update</ref> have been created for the adventurous.
 
[[PasiKärkkäinen|Pasi Kärkkäinen]]
tells<ref>http://www.redhat.com/archives/fedora-xen/2009-July/msg00000.html</ref> 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."
 
The patches can be found
here<ref>http://www.nabble.com/2.6.30-dom0-Xen-patches-td24293721.html</ref>
here <ref>http://code.google.com/p/gentoo-xen-kernel/downloads/list</ref>
and here<ref>http://x17.eu/xen/</ref>.
 
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<ref>http://fedoraproject.org/wiki/Virtualization/History</ref>.
 
<references />
<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.

  1. ↑ http://www.redhat.com/archives/fedora-virt/2009-December/msg00056.html
  2. ↑ http://fedoraproject.org/wiki/Virtualization_bugs

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 libvirt 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."

  1. ↑ http://www.redhat.com/virtualization/rhev/
  2. ↑ http://www.redhat.com/archives/fedora-virt/2009-December/msg00040.html



Retrieved from "https://fedoraproject.org/w/index.php?title=FWN/Beats/Virtualization&oldid=142485"