oVirt is an open source management system for KVM-powered virtual machines. Red Hat Enterprise Virtualization (RHEV) derives from oVirt in the same fashion that Red Hat Enterprise Linux is derived from Fedora. oVirt's (and RHEV's) central management component, called oVirt-Engine, is written in Java and runs on top of JBoss. Engine controls dozens of nodes that may run many dozens of VMs each.
Besides sounding like an improper innuendo when pronounced by Spanish-speaking people, "Vdsm" is Engine's per-node agent. It's written in python and is responsible to prepare storage and network connectivity for the virtual machine, as well as for tracking the life cycle of the VM.
When asked to fire up a VM, Vdsm converts Engine's xmlrpc vmCreate command to libvirt's domxml, libvirt converts it to qemu-kvm command line parameters.
Adding a new feature to RHEV can be an intimidating process: you have to work your way from libvirt up the management stack to Vdsm, Engine, REST-API, and UI. Not every user, customer, or partner can afford to do that.
For example, if someone wants to let his/her users choose super-duper fancy networking connectivity for their VMs, or to quickly test how a fresh Linux technology integrates with RHEV, we'd like to facilitate this.
Come Vdsm hooks. Vdsm has several points where it can execute arbitrary scripts, as installed and configured by the local admin. When before a VM is started, right after it was migrated away, or after a hot-plugging of a vNIC has failed ‒ vdsmd's man page (8) lists them all. By far, the most interesting ones are before_vm_start and before_device_create. That's because they serve as a filter between Vdsm and libvirt.
Their input consists of the libvirt xml description of the VM (or the specific device in device-specific hooks), and a bag of "custom properties", exposed as environment variables. The custom properties are attached to a VM (or to a vNIC profile) in Engine via its REST API or a simple GUI.
All kinds of before_vm_start hooks exist in the upstream Vdsm repository. The hook named qemucmdline lets users try unsupported arguments to the qemu command line. macspoof allows guests to spoof their MAC address (which is usually prohibited by RHEV, but is required for in-guest bonding or intrusion prevention appliances.)
I suppose that the best way to show the usefulness of Vdsm hooks is by a recent example. A few weeks ago, a user pinged me on IRC, asking whether RHEV can run VMs on his WiFi-only laptop. My answer was negative: RHEV's network configuration is based on setting up a Linux bridge and connecting it to an external NIC. But in Linux, you cannot connect a WiFi interface to a bridge
$ sudo brctl addif br0 wlp3s0 can't add wlp3s0 to bridge br0: Operation not supported
That's a shame since libvirt supports connecting the Linux bridge to the outer world using
NAT and an oVirt user named "Dead Horse" had to jump through hoops in order to use it as he explained.
More recently, Humble Chirammal reported that another user would like to connect RHEV VMs to an OpenVSwitch bridge instead of the standard Linux bridge. Again, that's impossible out-of-the-box, and that's quite easy with libvirt.
That was the last straw for publishing a new before_device_create Vdsm hook. If you have fancy networking which libvirt supports and oVirt ‒ not yet, define a libvirt
network named "glitter" on your hosts. And do not forget to install the extnet hook, too. The latter step means dropping an executable under /usr/libexec/vdsm/hooks/before_device_create/50_extnet or installing the vdsm-hook-extnet.rpm that includes it.
On Engine, define a vNIC profile with a custom property named "extnet", with a value set to "glitter". Attach this profile to a vNIC in your VM, and have it connected to any VM network defined in your cluster (say, the predefined "rhevm" management network). It does not really matter which, since Vdsm with the extnet hook enabled, is going to ignore that part of your request.
When the VM is started on a host, Vdsm creates the domain xml, to be passed to libvirt. It's <interface> element typically looks like
<interface type="bridge">
<address some-bus-and-address/>
<mac address="52:54:00:59:F5:3F"/>
<model type="virtio"/>
<source bridge="rhevm"/>
<filterref filter="no-mac-spoofing"/>
<boot order="1"/>
<driver name="vhost"/>
<tune>
<sndbuf>0</sndbuf>
</tune>
<bandwidth>
<inbound average="1000" burst="1024" peak="5000"/>
<outbound average="128" burst="256"/>
</bandwidth>
</interface>
But then the hook kicks in: it simply replaces the <source bridge="rhevm"/>
element to <source network="glitter"/> and changes the type of the interface element to <interface type="network"> accordingly. If everything was set as it should have, the traffic of the newly-started VM would now flow through the "glitter" network.
I hope this post shows how useful Vdsm hooks can be, and how easy it is to write one. You're welcome to email vdsm-devel if you have any questions, comments, or rants.
Last updated: August 16, 2022