
Libvirt – The Unsung Hero of Cloud Computing (2013) - vikrantrathore
https://vyomtech.com/2013/12/17/libvirt_the_unsung_hero_of_cloud_computing.html
======
guerby
We're currently migrating from VMware to libvirt, we discovered the cockpit
project and cockpit-machines to manage VMs:

[https://cockpit-project.org/](https://cockpit-project.org/)

cockpit-machines is available in a recent version in debian backports,
installing it is trivial, no configuration,
[https://hostname:9090/](https://hostname:9090/) and just works.

RedHat announced that cockpit will be the long term successor of virt-manager:

[https://www.redhat.com/en/blog/managing-virtual-machines-
rhe...](https://www.redhat.com/en/blog/managing-virtual-machines-rhel-8-web-
console)

[https://blog.wikichoon.com/2020/06/virt-manager-
deprecated-i...](https://blog.wikichoon.com/2020/06/virt-manager-deprecated-
in-rhel.html)

cockpit has frequent releases, latest:

[https://cockpit-project.org/blog/cockpit-227.html](https://cockpit-
project.org/blog/cockpit-227.html)

It hasn't all the features of virt-manager, far from it, but looks promising.

~~~
servilio
> RedHat announced that cockpit will be the long term successor of virt-
> manager

For RHEL, virt-manager will still be developed independently.

~~~
indolering
> For RHEL, virt-manager will still be developed independently.

By whom? The _vast_ majority of contributions are paid for by Red Hat [0].

[0]: [https://github.com/virt-manager/virt-
manager/graphs/contribu...](https://github.com/virt-manager/virt-
manager/graphs/contributors)

------
ohazi
If you haven't tried it, the "Virtual Machine Manager" GUI [1] is also
surprisingly usable on Desktop Linux. I use it with both Windows and Linux
images, and getting it to work with the usual guest extension niceties is
straightforward.

From what I remember, getting VirtualBox or VMware to launch and run properly
after a few months of automatic upgrades and not launching your images for a
while was always kind of a gamble. With libvirt, everything just seems to
work, and your images are just ready to go when you need them.

[1] [https://virt-manager.org/](https://virt-manager.org/)

~~~
throwaway8941
>With libvirt, everything just seems to work

Strictly speaking, you have qemu to thank for that. libvirt is just a frontend
for several hypervisors, including qemu (which is what typically used).

~~~
bonzini
Libvirt is also responsible for keeping the guest exactly the same after
upgrades; a basic QEMU command line does not guarantee that the guest hardware
remains the same when you upgrade to a newer version, while Libvirt uses the
more complicated and less human-friendly options to ensure that.

Libvirt does a lot more for QEMU than for other hypervisors, so much that
libvirtd's initial name was qemud.

------
amscanne
While I respect the job that libvirt does (it works — high praise for
software), it’s unfortunate that it is also the answer to the question “how
can I represent all these virtualized things using XML?”, which was in fashion
when libvirt was created.

It’s also a bit misleading to characterize cloud providers as building on
libvirt. Libvirt is useful as an mostly hypervisor-agnostic wrapper, which is
super useful for enterprise on-prem software, but kinda of the opposite of
what big providers need and build for themselves.

I wonder what we will look back on as the XML of today. Everything is
schemaless JSON and YAML; surely we’ll look back and wonder WTF everyone was
thinking? But alas, it’s probably not a data format at all. Only time will
tell.

~~~
foepys
JSON is a bad configuration format simply for the fact that it doesn't support
comments. Some parsers do but most don't. XML for all its verbosity and
complexity at least has comments where I can quickly try out configuration
changes without needing to save the old configuration somewhere else.

Hell, even INI files had support for comments and were just as expressional as
JSON. I wonder why we regressed in that regard. Was it just because of the
success of JavaScript and readily available JSON parsers? Because I'd argue
that an INI parser is just as easy to write.

~~~
japanuspus
This is exactly why TOML [0] is gaining traction as a simple configuration
file format. Rust's cargo has been TOML from day one (`Cargo.toml`) and Python
is moving this way with (`pyproject.toml`).

For more general data structures, remember that JSON is a true subset of YAML
[1]: Switch to a YAML parser and you can start optionally adding comments to
your files while still being compatible with legacy input.

[0] [https://toml.io/en/](https://toml.io/en/) [1]
[https://yaml.org/](https://yaml.org/)

~~~
eska
Yaml is generally derided as too complex and transforming data in unintended
ways.

I see a lot of Rust programmers preferring RON over TOML because it is much
less complex and doesn't have multiple ways to express the same thing
[https://crates.io/crates/ron](https://crates.io/crates/ron)

------
xfennec
We've build our own automated hosting infrastructure* a few years ago on top
of libvirt. Using the libvirt API was a breeze and libvirt is rock solid since
day one for us, I can only recommend this project.

* Shameless plug: [https://github.com/OnitiFR/mulch](https://github.com/OnitiFR/mulch)

We're using libvirt-go binding (Daniel Berrangé and his team is doing a
excellent job maintaining it!), and KVM/QEMU hypervisior. For a small team
like us, it's incredibly valuable to have access to such powerful tools in a
such easy way.

~~~
appleflaxen
Mulch looks super cool; you have some great ideas!

------
CSDude
Libvirt is really nice. For linux, I also recommend reading the man page of
Qemu directly to learn more about internals, it helped me understand a lot. Of
course you have to take care networking, disk management on your own but it
can be really simple. [https://linux.die.net/man/1/qemu-
kvm](https://linux.die.net/man/1/qemu-kvm)

~~~
guerby
There's a nice tool to get qemu command lines from libvirt xml:

    
    
      virsh domxml-to-native qemu-argv myvm.xml

~~~
tarruda
Nice, thanks for sharing!

------
catern
I really doubt that AWS is using libvirt. They almost certainly have their own
abstraction.

But still, I agree that libvirt is great; I wrote about it here:
[http://catern.com/posts/libvirt.html](http://catern.com/posts/libvirt.html)

~~~
vikrantrathore
Might be true, but don’t see any open source work from Amazon in public domain
which shows they built their own libraries from scratch to manage Xen and
cloud management in early years from 2008.

Indeed it’s 2020 and yet to see any major open source work from Amazon (which
has benefited a lot from open source itself using Perl, CPAN, C, Java, Linux
etc.). In this respect IBM, google, Microsoft, Facebook and Apple are far
better. Here even Oracle fare better due to acuisition of MySQL and sun
microsystems.

I believe the major contribution from amazon might be hiring some of the open
source developers to build proprietary systems. Those developers in spare time
or weekends continue their open source project, but I do not have any study or
articles on it.

Based on my information in 2013, amazon built their cloud using Xen hypervisor
and related tools and libraries. Libvirt is one of the key libraries providing
beautiful abstractions and language bindings to manage xen on Linux node at
that time.

It will be nice if you can point to code from Amazon on low level library like
Libvirt for cloud computing.

~~~
lmz
What makes you think it was libvirt instead of the Xen native xm / xl tools?

------
willscott
for the last month (v6.6.0 and v6.7.0) libvirt has been released with a new
key 453B65310595562855471199CA68BE8010084C9C (first seen:2020-07-20). It
hasn't been signed or verified by any other source in libvirt / redhat yet.
[https://www.redhat.com/archives/libvirt-
announce/2020-July/m...](https://www.redhat.com/archives/libvirt-
announce/2020-July/msg00006.html)

That is preventing downstream distros, like arch, from admitting these new
releases into their package repos.

Critical infrastructure, indeed.

~~~
silly-silly
Key exists on pgp.ocf.berkeley.edu.

------
shekharshan
I couldn't understand this: "Domain is an instance of an operating system (or
subsystem in case of container virtualization like OpenVZ and lxc) running on
a virtualized machine provided by the hypervisor"

So the domain itself is a virtual machine? What makes it different from other
guest virtual machinse?

~~~
rwmj
It's unfortunate that when libvirt was originally started (2005) it was a
wrapper around Xen, and in Xen a VM is called a domain.

------
dmacvicar
If you want to use libvirt with terraform, this is the project I started to
learn Go years ago:

[https://github.com/dmacvicar/terraform-provider-
libvirt](https://github.com/dmacvicar/terraform-provider-libvirt)

