libvirt remote management news

Posted: July 15th, 2007 | Filed under: libvirt, Virt Tools | No Comments »

Last week, after many months development & testing, we finally did a new release of
libvirt which includes secure remote management. Previously usage of libvirt was restricted to apps running on the machine being managed. When you are managing a large data center of machines requiring that an admin ssh into a machine to manage virtual machines is clearly sub-optimal. XenD has had the ability to talk to its HTTP service remotely for quite a while, but this used cleartext HTTP and had zero authentication until Xen 3.1.0. We could have worked on improving XenD, but it was more compelling to work on a solution that would apply to all virtualization platforms. Thus we designed & implemented a small daemon for libvirt to expose the API to remote machines. The the communications can be run over a native SSL/TLS encrypted transport, or indirectly over an SSH tunnel. The former will offer a number of benefits in the long term – not least of which the ability to delegate management permissiosn per-VM and thus avoid the need to provide root access to virtual machine administrators.

So how do you make use of this new remote management. Well, installing libvirt 0.3.0 is the first step. Out of the box, the SSL/TLS transport is not enabled since it requires x509 certificates to be created. There are docs about certificate creation/setup so I won’t repeat it here – don’t be put off by any past experiance setting up SSL with Apache – its really not as complicated as it seems. The GNU TLS certtool also a much more user friendly tool than the horrific openssl command line. Once the daemon is running, then the only thing that changes is the URI you use to connect to libvirt. This is best illustrated by a couple of examples

Connecting to Xen locally 
$ ssh root@pumpkin.virt.boston.redhat.com
# virsh --connect xen:/// list --all
 Id Name                 State
----------------------------------
  0 Domain-0             running
  6 rhel5fv              blocked
  - hello                shut off
  - rhel4x86_64          shut off
  - rhel5pv              shut off
Connecting to Xen remotely using SSL/TLS 
$ virsh --connect xen://pumpkin.virt.boston.redhat.com/ list --all
 Id Name                 State
----------------------------------
  0 Domain-0             running
  6 rhel5fv              blocked
  - hello                shut off
  - rhel4x86_64          shut off
  - rhel5pv              shut off
Connecting to Xen remotely using SSH 
$ virsh --connect xen+ssh://root@pumpkin.virt.boston.redhat.com/ list --all
 Id Name                 State
----------------------------------
  0 Domain-0             running
  6 rhel5fv              blocked
  - hello                shut off
  - rhel4x86_64          shut off
  - rhel5pv              shut off
Connecting to QEMU/KVM locally 
$ ssh root@celery.virt.boston.redhat.com
# virsh --connect qemu:///system list --all
 Id Name                 State
----------------------------------
  1 kvm                  running
  - demo                 shut off
  - eek                  shut off
  - fc6qemu              shut off
  - rhel4                shut off
  - wizz                 shut off
Connecting to QEMU/KVM remotely using SSL/TLS 
$ virsh --connect qemu://celery.virt.boston.redhat.com/system list --all
 Id Name                 State
----------------------------------
  1 kvm                  running
  - demo                 shut off
  - eek                  shut off
  - fc6qemu              shut off
  - rhel4                shut off
  - wizz                 shut off
Connecting to QEMU/KVM remotely using SSH 
$ virsh --connect qemu+ssh://root@celery.virt.boston.redhat.com/system list --all
 Id Name                 State
----------------------------------
  1 kvm                  running
  - demo                 shut off
  - eek                  shut off
  - fc6qemu              shut off
  - rhel4                shut off
  - wizz                 shut off

Notice how the only thing that changes is the URI – the information returned is identical no matter how you connect to libvirt. So if you have an application using libvirt, all you need do is adapt your connect URIs to support remote access. BTW, a quick tip – if you get tired of typing –connect arg you can set the VIRSH_DEFAULT_CONNECT_URI environment variable instead.

What about virt-install and virt-manager you might ask. Well there are slightly more complicated. During the creation of new virtual machines, both of them need to create files on the local disk (to act as virtual disks for the guest), possibly download kernel+initrd images for booting the installer, and enumerating network devices to setup networking. So while virt-manager can run remotely now – it will be restricted to monitoring existing VMs, and basic lifecycle management – it won’t be possible to provision entirely new VMs remotely. Yet. Now the basic remote management is working, we’re looking at APIs to satisfy storage management needs of virt-manager. For device enumeration we can add APIs which ask HAL questions and pass the info back to the client over our secure channel. Finally kernel+initrd downloading can be avoided with by PXE booting the guests.

There’s lots more to talk about, such as securing the VNC console with SSL/TLS, but I’ve not got time for that in this blog posting. Suffice to say, we’re well on our way to our Fedora 8 goals for secure remote management. Fedora 8 will be the best platform for virtualization management by miles.