4:36 p.m.
----- Original Message -----
From: "Dale Bewley" <dale(a)fedoraproject.org>
To: virt(a)lists.fedoraproject.org
Sent: Friday, April 29, 2011 5:08:35 PM
Subject: [fedora-virt] fedora virt versus RHEV - libvirt tools availability
I hope this doesn't seem too far off topic.
In my current position we are a vmware shop. With a few dozen machines
in a handful of clusters, multipath fibrechannel storage, lots of live
migrations, etc.
In my past position, I did everything on Fedora with the help of
virsh,
guestfish and all their friends, and life was very good. I could
provision machines with virt-install and koan. I could tweak the
machine
definitions in XML. I could login and get a vm console very easy.
That environment was much smaller and all storage was essentially
direct
attached and there was no live migration. Moving to vmware has a few
niceties, but feels encumbered.
I now want to evaluate RHEV against vmware, but I'm immediately taken
aback to see the need for a windows mgt console, and troubled by an
apparent burying of the libvirt API with a user push towards a REST
API.
Maybe my perception is off. I'm going to RH Summit and will get some
more education next week.
You're certainly not alone Dale. While the features of RHEV are good (
http://bit.ly/RHEVINFO ) the requirement for a Windows management server is an issue to a
number of people, not least myself.
There's a number of sessions at summit that will address this - probably the best is
the "Red Hat Enterprise Virtualization Architecture: Past, Present, &
Future" session on Thursday.
The short answer is that Qumranet, the company behind KVM and Spice had a proprietary,
C#/Windows based management system for KVM called SolidICE that was the foundation of
RHEV.
We've spent the last 18 months porting and reworking RHEV. At summit we'll be
covering the 3.0 version (beta in August) that is Java running on RHEL. This session (and
the roadmap) will talk about the road from Windows/C# to Linux and talk about the open
sourcing process.
re: APIs the way RHEV is architected is that you have a central management server talking
to it's hypervisors. Under the covers the interface between RHEV and the hypervisors
is called VDSM, which then uses libvirt to do the actual VM lifecycle management.
The REST API is a centralized API that has a larger scope that libvirt - it's cluster
wide, understands everything from VM lifecycle and storage management all the way to
managing permissions and clustering.
Let's say you want to migrate a virtual machine and you decided to talk directly to
the hypervisor using libvirt, then you lose all the information about the other nodes, for
example RHEV could have decided that based on current utilization rates we were about to
take the node that you were migrating to offline for powersaving, or perhaps someone in
the management UI just decided to reboot that host.
In the upstream rhevm-api project there's a virsh equivalent called rhevsh
Tools like guestfish and virsh are some of the drivers causing me to
explore vmware alternatives. If RHEV occludes those tools I'm left
wondering what do I get that I can't get from Fedora with an
apparently
more open toolset. Other than the long term support.
What are others doing out there? How large have you scaled up a Fedora
solution (libvirt, virt-manager, virsh, kvm)? Are you performing live
migrations reliably? How do you feel about RHEV?
Anyone coming to RH Summit?
_______________________________________________
virt mailing list
virt(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/virt