The programme has been published here. Looks pretty good! Lots of Kubernetes/KubeVirt this year.
Tag Archives: virtualization
As usual I’ve placed the proposed RHEL 7.5 libguestfs packages in a public repository so you can try them out.
Thanks to Pino Toscano for doing the packaging work.
Fedora 27 has just been released, and I’ve just uploaded virt-builder images so you can try it right away:
$ virt-builder -l | grep fedora-27 fedora-27 aarch64 Fedora® 27 Server (aarch64) fedora-27 armv7l Fedora® 27 Server (armv7l) fedora-27 i686 Fedora® 27 Server (i686) fedora-27 ppc64 Fedora® 27 Server (ppc64) fedora-27 ppc64le Fedora® 27 Server (ppc64le) fedora-27 x86_64 Fedora® 27 Server $ virt-builder fedora-27 \ --root-password password:123456 \ --install emacs \ --selinux-relabel \ --size 30G $ qemu-system-x86_64 \ -machine accel=kvm:tcg \ -cpu host -m 2048 \ -drive file=fedora-27.img,format=raw,if=virtio &
20:30 < koike> Hi. Is it possible to configure the dmi codes for libguestfs? I mean, I am running cloud-init inside a libguestfs session (through python-guestfs) in GCE, the problem is that cloud-init reads
/sys/class/dmi/id/product_name to determine if the machine is a GCE machine, but the value it read is
Standard PC (i440FX + PIIX, 1996) instead of the expected
Google Compute Engine so cloud-init fails.
The answer is yes, using the guestfs_config API that lets you set arbitrary qemu parameters:
g.config('-smbios', 'type=1,product=Google Compute Engine')
$ virt-builder -l | grep fedora-26 fedora-26 aarch64 Fedora® 26 Server (aarch64) fedora-26 armv7l Fedora® 26 Server (armv7l) fedora-26 i686 Fedora® 26 Server (i686) fedora-26 ppc64 Fedora® 26 Server (ppc64) fedora-26 ppc64le Fedora® 26 Server (ppc64le) fedora-26 x86_64 Fedora® 26 Server
$ virt-builder fedora-26 $ qemu-system-x86_64 -machine accel=kvm:tcg -cpu host -m 2048 \ -drive file=fedora-26.img,format=raw,if=virtio
Why not s390x? That’s because qemu doesn’t yet emulate enough of the s390x instruction set / architecture so that we can run Fedora under TCG emulation.
Debian 9 (“Stretch”) was released last week and now it’s available in virt-builder, the fast way to build virtual machine disk images:
$ virt-builder -l | grep debian debian-6 x86_64 Debian 6 (Squeeze) debian-7 sparc64 Debian 7 (Wheezy) (sparc64) debian-7 x86_64 Debian 7 (Wheezy) debian-8 x86_64 Debian 8 (Jessie) debian-9 x86_64 Debian 9 (stretch) $ virt-builder debian-9 \ --root-password password:123456 [ 0.5] Downloading: http://libguestfs.org/download/builder/debian-9.xz [ 1.2] Planning how to build this image [ 1.2] Uncompressing [ 5.5] Opening the new disk [ 15.4] Setting a random seed virt-builder: warning: random seed could not be set for this type of guest [ 15.4] Setting passwords [ 16.7] Finishing off Output file: debian-9.img Output size: 6.0G Output format: raw Total usable space: 3.9G Free space: 3.1G (78%) $ qemu-system-x86_64 \ -machine accel=kvm:tcg -cpu host -m 2048 \ -drive file=debian-9.img,format=raw,if=virtio \ -serial stdio
libguestfs is a C library for creating and editing disk images. In the most common (but not the only) configuration, it uses KVM to sandbox access to disk images. The C library talks to a separate daemon running inside a KVM appliance, as in this Unicode-art diagram taken from the fine manual:
┌───────────────────┐ │ main program │ │ │ │ │ child process / appliance │ │ ┌──────────────────────────┐ │ │ │ qemu │ ├───────────────────┤ RPC │ ┌─────────────────┐ │ │ libguestfs ◀╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍╍▶ guestfsd │ │ │ │ │ ├─────────────────┤ │ └───────────────────┘ │ │ Linux kernel │ │ │ └────────┬────────┘ │ └───────────────│──────────┘ │ │ virtio-scsi ┌──────┴──────┐ │ Device or │ │ disk image │ └─────────────┘
The library has to be written in C because it needs to be linked to any main program. The daemon (
guestfsd in the diagram) is also written in C. But there’s not so much a specific reason for that, except that’s what we did historically.
The daemon is essentially a big pile of functions, most corresponding to a libguestfs API. Writing the daemon in C is painful to say the least. Because it’s a long-running process running in a memory-constrained environment, we have to be very careful about memory management, religiously checking every return from
strdup etc., making even the simplest task non-trivial and full of untested code paths.
So last week I modified libguestfs so you can now write APIs in OCaml if you want to. OCaml is a high level language that compiles down to object files, and it’s entirely possible to link the daemon from a mix of C object files and OCaml object files. Another advantage of OCaml is that you can call from C ↔ OCaml with relatively little glue code (although a disadvantage is that you still need to write that glue mostly by hand). Most simple calls turn into direct CALL instructions with just a simple bitshift required to convert between ints and bools on the C and OCaml sides. More complex calls passing strings and structures are not too difficult either.
OCaml also turns memory errors into a single exception, which unwinds the stack cleanly, so we don’t litter the code with memory handling. We can still run the mixed C/OCaml binary under valgrind.
Code gets quite a bit shorter. For example the case_sensitive_path API — all string handling and directory lookups — goes from 183 lines of C code to 56 lines of OCaml code (and much easier to understand too).
I’m reimplementing a few APIs in OCaml, but the plan is definitely not to convert them all. I think we’ll have C and OCaml APIs in the daemon for a very long time to come.