Virtualization? Nothing But Lies!

With virtualization, lying has become respectable. Processors lie to user mode processes about memory addresses. Computers lie to operating systems about installed hardware. Storage systems lie to everybody about the location of data. The virtualization hype transforms honest down-to-earth systems into lying medusas.

Virtualization = Lying

This sounds frightening, and it probably is to old school IT pros who are used to doing everything by hand. So let me put it differently: virtualization is the art of lying according to pre-defined rules.

Take the popular example of virtual machine software, e.g. VMware ESX, Microsoft Hyper-V or Citrix XenServer. When you install a guest operating system, it thinks it the machine it is running on has a certain amount of RAM, say 1 GB. That is not true. The host most likely has much more RAM, but the virtualization software lies about this fact to the guest operating system.

Every good liar chooses a story and sticks to it. In other words, he implicitly defines rules to which he adheres. Otherwise it would be easy to see through the lie because the liar would contradict himself constantly. The result would be chaos - both in real life and in IT.

Going back to the virtual machine example, it is easy to see the simple truth of this. If the VM host did not stick to one story (i.e. the exact hardware specification to present to the guest) the whole concept of virtualizing an entire computer would fail miserably. After all, which (guest) OS would tolerate frequent and major hardware changes - online while running?

Why Lie At All?

There is an inherent power to lying: by hiding reality behind a set of lies, what is real becomes interchangeable. If an OS inside a virtual machine knows nothing about real hardware, it is possible to recreate the same set of lies on an entirely different host computer and transfer the guest over without it knowing about the process. It will happily go on “living” without ever knowing that its “soul” has been moved to a different body.

Wow. If we could only do stuff like that outside of IT…

Back to computers, what is the benefit? Why, flexibility, of course! Virtualization decouples applications from the OS, the OS from the hardware, storage from disk drives, and so on. With virtualization, you can move each piece around individually, without affecting other components in the system.

Migrations become a piece of cake. Increasing capacity is suddenly possible without overtime and admins get to see their family even if they have to upgrade critical systems. Brave new world!

The Cost of Lying

Everything comes at a cost. Even (or especially) lying. As anyone who ever got entangled in a web of lies knows, it can greatly increase complexity.

If you employ virtualization in your network, you not only need to know the (simple?) truth, but also the lie. There are always some components that see the truth and deal with reality (e.g. your hypervisor), whilst many others are happy believing the lie. But you, as an administrator, have to understand both. You need a mental mapping between fact and fiction, and on many levels: apps, storage, hardware, memory, to name a few.

We IT people need to play along with the lie, but know the truth.

Many thanks to Joe Nord from Citrix who planted the idea of “virtualization = lying” in my head.

Virtualization

Comments

Related Posts

Compacting Hyper-V VHDX Files of Ubuntu Linux VMs

Compacting Hyper-V VHDX Files of Ubuntu Linux VMs
Note: if your guest OS supports the trim command you can use the faster method described in this article. If you configured your Hyper-V virtual machines with dynamically expanding virtual disks you will find that the VHDX files backing the virtual disks always grow in size, they never shrink. Eventually this becomes a problem either directly because of increased storage requirements or indirectly because backups take longer. Compacting VHDX files is possible but more complicated than I feel it should be. I have described the process for Windows VMs here. This article shows how to do it for Ubuntu Linux VMs.
Virtualization & Containers

Docker (Compose) Cheat Sheet

Docker (Compose) Cheat Sheet
This is a collection of tips and tricks I picked up while learning and working with Docker and Docker Compose on my home server and web server. Container Configuration Environment Variables Where to Define Environment Variables Environment variables are a common way to configure containers. To keep things organized, don’t put them in your Compose file but into dedicated files with the extension env. env_file vs. .env .env file: this “special” file can be used to set environment variable for use in the Compose file. The variables specified in .env are not available in the container. env_file: this section in the Docker Compose file lets you specify files that contain environment variables for use in the container. The variables specified in this section are not available in the Compose file. Bind Mounts vs. Docker Volumes Bind mounts let you control the directory structure. This has the advantage that you know exactly what gets stored where in the host’s file system. It has the disadvantage that you need to create the directory structure before you can start a container. Docker volumes are managed by the Docker engine. They’re stored in /var/lib/docker, “far away” from the Compose file. Personally, I very much prefer bind mounts because of the control they offer. I use subdirectories relative to the Compose file, e.g., ./data:/data. Keeping the container configuration and the container data in one place facilitates backups. Networking Expose vs. Ports Expose serves as documentation which ports a container is accessible on. Note: container ports are always accessible from other containers on the same Docker network. Ports makes container ports accessible to the host. Most of my services are accessible through the Caddy reverse proxy only. Opening ports to the host is, therefore, only rarely necessary. Static IP Address on the Host Network Use the Macvlan Docker network to attach a container directly to the host’s local network. Assign a static IP address by specifying the ip_range parameter in the ipam section of the Docker Compose file. See this configuration for an example. Disable Macvlan Container/Host Isolation Containers on a Macvlan network are isolated from the host. While the container can contact other machines on the local network, communications with the host are blocked. To work around that, create a virtual link with a route that points to the container’s IP address (example). Time Zone Containers should know about your local time zone. To achieve that, make it a habit to pass in /etc/localtime as a read-only volume to every container:
Virtualization & Containers

Latest Posts