From Fedora Project Wiki

< FWN‎ | Beats

(→‎Libvirt vs XenAPI: add 2 threads)
Line 42: Line 42:
out. Does libvirtd need to always be running? [[RichardJones|Richard W.M. Jones]] answered[2] "yes and no". The local Xen hypervisor can be managed by direct hypervisor calls and/or a connection to xend. Warnings that libvirtd isn't running may be ignored.
out. Does libvirtd need to always be running? [[RichardJones|Richard W.M. Jones]] answered[2] "yes and no". The local Xen hypervisor can be managed by direct hypervisor calls and/or a connection to xend. Warnings that libvirtd isn't running may be ignored.


Libvirtd must be running to support the following, howerver.
Libvirtd must be running to support the following, however.
* remote access
* remote access
* non-root access
* non-root access

Revision as of 02:33, 8 September 2008

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

Fedora Xen List

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

Libvirt List

This section contains the discussion happening on the libvir-list.

Libvirt vs XenAPI

Atif Bajwa asked[1] about the advantages of using libvirt over XenAPI and what platforms libvirt supports. Atsushi Sakai pointed to a list[2] of which libvirt calls work on which drivers / hypervisors. Daniel P. Berrange replied[3] that libvirt is available for every major Linux distro, and listed several benefits such as:

  • avoids locking applications to a particular hypervisor
  • provides a guaranteed stable API that can be used both locally and remotely
  • remote security options include SSL + x509 certificates, SSH tunnel, Kerberos GSSAPI single sign on, and username + password
  • works with every version of Xen 3.0.x or later while XenAPI is only usable in Xen 3.1.0 and later

Richard W.M. Jones mentioned[4] that although there are no binaries yet, libvirt client code can be compiled on windows.

[1] https://www.redhat.com/archives/libvir-list/2008-September/msg00002.html

[2] http://libvirt.org/hvsupport.html

[3] https://www.redhat.com/archives/libvir-list/2008-September/msg00008.html

[4] https://www.redhat.com/archives/libvir-list/2008-September/msg00016.html

Latest MinGW Patches

Daniel P. Berrange posted[1] patches to allow building on F10 of libvirt-0.dll and virsh.exe which run successfully under Wine, provided only 'test' and 'remote' drivers are turned on.

[1] https://www.redhat.com/archives/libvir-list/2008-September/msg00065.html

Does Libvirtd Needs to Always be Running

Yushu Yao asked[1] a basic question which may be helpful to point out. Does libvirtd need to always be running? Richard W.M. Jones answered[2] "yes and no". The local Xen hypervisor can be managed by direct hypervisor calls and/or a connection to xend. Warnings that libvirtd isn't running may be ignored.

Libvirtd must be running to support the following, however.

  • remote access
  • non-root access
  • if you use the network or storage features
  • managing QEMU and KVM instances

[1] https://www.redhat.com/archives/libvir-list/2008-September/msg00085.html

[2] https://www.redhat.com/archives/libvir-list/2008-September/msg00103.html

oVirt Devel List

This section contains the discussion happening on the ovirt-devel list.

Renaming oVirt RPMs

Alan Pevec proposed[1] renaming the oVirt packages which turned into a discussion with Daniel P. Berrange about how to organize the git repos and how to continue support build-all after such a change.

[1] https://www.redhat.com/archives/ovirt-devel/2008-September/msg00029.html

WUI Management of Underlying Hardware

Chris Lalancette posted[1] a series of patches to allow the Web User Interface to manage the underlying hardware it is running on.

[1] https://www.redhat.com/archives/ovirt-devel/2008-September/msg00081.html

Network Interface Bonding and Failover

Darryl L. Pierce began[1] a discussion on implementing support for ethernet bonding multiple interfaces for load balancing and failover. Special consideration for different hardware scenarios such as blade servers lead Konrad Rzeszutek to ask how these extra parameters would be passed in to the bonding setup. Darryl explained[2] that on boot the node identifies itself to the oVirt server, and downloads a configuration file to be processed by augtool[3]. The managed node then restarts the network service to apply the network configuration that it just retrieved.


[1] https://www.redhat.com/archives/ovirt-devel/2008-September/msg00064.html

[2] https://www.redhat.com/archives/ovirt-devel/2008-September/msg00075.html

[3] http://augeas.net/