----- Original Message ----- > From: "Dale Bewley" <[email protected]> > To: [email protected] > 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 > [email protected] > https://admin.fedoraproject.org/mailman/listinfo/virt _______________________________________________ virt mailing list [email protected] https://admin.fedoraproject.org/mailman/listinfo/virt
