Libvirt vs vSphere Management Agent: A Quick Comparison
Libvirt is an open source project for managing almost all hypervisors and containers. It’s implemented in C and can be exposed through different language bindings.
There are both server (a.k.a daemon or agent) and client. If you are familiar with VMware vSphere (I assume you are if you read my blog), the server is very much like the hostd running on the ESXi side. The client is like the VI Java API that can be used for remote management.
Time to learn how to "Google" and manage your VMware and clouds in a fast and secureHTML5 App
Before comparing the libvirt and VMware, it’s important to understand the terminology differences between two worlds as shown in the following table. Coming from VMware world, I was wondering why a virtual machine is called a domain. But really, a term is a term. Once you know what it stands for or refers to, move on. At the end of the day, there is no “right” but familiar name and any debate can go days leading to no result.
Table: Comparison between Libvirt and VMware vSphere
|Hypervisors||KVM/QEMU, XEN, LXC, OpenVZ, User Mode Linux, VirtualBox, VMware(ESX/GSX/
Player/Workstation), Microsoft Hyper-V, IBM PowerVM, Parallels
|Components||libvirtd, libvirt||hostd agent on ESXi|
|Protocol||RPC||Web Services (SOAP)|
|Security||SSH, TLS, SASL||Https, SSH|
|Ports||16514 (TLS), 22(SSH), 16509 (TCP)||443 for https, 80 for http|
|Language bindings||C#, Java, OCaml, Perl, PHP, Python, Ruby||All languages that supports SOAP|
|Features||Limited and open (you can migrate Domain to another hypervisor)||Comprehensive and restrictive (i.e., vMotion API is not publicly available on ESXi)|
|Object model||No, but can be easily built||Yes in doc, but missing in WSDL and needs to be recovered in language binding like vijava API|
|CLIs||Virsh||RCLI, PowerCLI, Perl CLI, etc.|
|Client platforms||Linux, Windows (limited)||All OSes (Linux, Windows, MacOS, etc.)|