High level toolstacks for server and cloud virtualization are very mature with large communities using and supporting them. Client virtualization is a much more niche community with unique requirements when compared to those found in the server space. In this talk, we’ll introduce a client virtualization toolstack for Xen (redctl) that we are using in Redfield, a new open-source client virtualization distribution that builds upon the work done by the greater virtualization and Linux communities. We will present a case for maturing libxl’s Go bindings and discuss what advantages Go has to offer for high level toolstacks, including in the server space.
Unlocking the Future of AI Agents with Large Language Models
XPDDS19: Client Virtualization Toolstack in Go - Nick Rosbrook & Brendan Kerrigan, Assured Information Security, Inc.
1. Client Virtualization Toolstack in Go
Nicholas Rosbrook, Software Engineer, Assured Information Security
Brendan Kerrigan, Principal Software Engineer, Assured Information Security
3. Introduction
• Brendan Kerrigan – Principal Engineer at Assured Information
Security, Inc.
• Hypervisors
• Graphics virtualization
• Embedded
• Nicholas Rosbrook – Software Engineer at Assured Information
Security, Inc.
• Cryptography
• VPNs and Networking
• Go expert
4. Motivation
• We do a lot of client virtualization work
• Utilizing hypervisors to do end point security
• Mostly OpenXT based products now
• OpenXT isn’t the easiest project to work on (10 years of development
means there are lots of components)
• Sometimes key high-security features can be a hindrance to some use
cases
• Client virtualization is pretty different than server virtualization
• Especially when it comes to toolstacks
5. Evaluation
• What’s out there we can leverage?
• XenMgr
• Libvirt (+ qubectl)
• What if we had a clean slate?
6. XenMgr
• XenMgr is high friction
• Haskell
• Esoteric
• Tough to find developers
• Lots of legacy interfaces that are unexercised and unaudited (audit in
progress)
• A lot of cryptic code that essentially reads a database and writes an xl
config and calls exec/fork
• Local and remote APIs are different
• The command line tool is great
7. Libvirt
• One layer of abstraction too many
• XML domain configurations are too complex
• Designed to work with several virtualization technologies – KVM, Xen,
LXC, etc.
• We want to work with Xen and do it well
• Does a lot more than we need it to
• There is an existing Go package (developed by DigitalOcean)
8. redctl
• Introducing redctl, the client toolstack to our Xen
distribution, Redfield
• The good:
• A client toolstack where remote and local management
APIs are unified
• Utilize gRPC
• Don’t dictate transport (IPv4, IPv6, PV channels, Argo, vsock)
• Easy to understand and test language (Go)
• Make the command line tool awesome (like XenMgr’s)
• The bad:
• Still doing exec/fork a lot when dealing with libxl…
9. What is cgo?
• Cgo enables Go programs to call C code through a pseudo-
package, “C”
• Allows access of C types, variables, and functions
• E.g. C.size_t, C.stdout, C.printf
• The “preamble”
• A block comment used to include headers, set CFLAGS, LDFLAGS, etc.
• Immediately precedes the import “C” statement
11. What is cgo?
• C fields that cannot be expressed in Go are omitted
• The C type void* is represented by Go’s unsafe.Pointer
• Cannot call C function pointers from Go
• There are some restrictions on passing pointers between C and Go
12. Writing a Go Package for libxl
• Writing the cgo code by hand is tedious
• Cgo is simple enough to make code generation easy
• We use c-for-go: https://github.com/xlab/c-for-go
• Define translation and generation rules with a YAML configuration file
• Accept or ignore symbols, rename variables, apply rules to a given scope,
and more
17. Future Work
• Continue writing wrappers
• Trim the size of the package
• Integrate into redctl
• Upstream
• Current fork: https://github.com/enr0n/xen/tree/libxl-go