DEV Community

Cover image for VMware Concepts Mapped to OpenShift Virtualization: VMDK, Port Groups, vMotion and More
Gaganpreet Singh
Gaganpreet Singh

Posted on

VMware Concepts Mapped to OpenShift Virtualization: VMDK, Port Groups, vMotion and More

If you've run vSphere for years, OpenShift Virtualization looks foreign for about a day. Then you notice that almost every VMware concept has a direct counterpart. It just has a Kubernetes name and lives in YAML instead of a vCenter database.

This is the translation table I wish I'd had on day one, taken from the lab I built for The Lab Manual: Migration Edition.

The core table

vSphere OpenShift Virtualization What to know
ESXi host Node with /dev/kvm KVM is built into the RHCOS kernel
VM (the .vmx definition) VirtualMachine (VM) Exists even when powered off
Running VM process VirtualMachineInstance (VMI) + virt-launcher Pod Exists only while the VM runs
VMDK PVC / DataVolume The disk is a PersistentVolumeClaim
Datastore StorageClass Backed by a CSI driver (NFS, FC, iSCSI, Ceph…)
Port group NetworkAttachmentDefinition (NAD) Carries the VLAN ID
vSwitch / VDS Linux bridge built by NMState Declared once, applied on every node
vMotion Live migration (VirtualMachineInstanceMigration) Needs RWX storage
VM template / content library Instance types + preferences + boot sources "How big", "which OS", "which image"
VMware Tools QEMU guest agent + virtio drivers MTV installs them during conversion
vCenter The OpenShift API + the console's Virtualization pages

The three that trip people up

1. VM vs VMI. In vSphere a VM is one thing. Here it's two: the VirtualMachine is the definition (like the .vmx), and the VirtualMachineInstance only exists while it's running. Powering off deletes the VMI and its Pod. The VM object stays.

oc get vm,vmi -n mtv-test
Enter fullscreen mode Exit fullscreen mode

2. Port groups become NADs. A NAD is a small JSON config: which bridge, which VLAN. Put shared networks in the default namespace and any project can use them as default/vlan-110.

oc get net-attach-def -A
oc get net-attach-def vlan-110 -n default -o jsonpath="{.spec.config}"
Enter fullscreen mode Exit fullscreen mode

3. vMotion needs RWX. Live migration moves the VM's memory to another node, but both nodes need the disk at the same time. That means a StorageClass with ReadWriteMany. In my lab, OpenShift Virtualization didn't recognise the NFS StorageClass and would have created RWO disks. One StorageProfile patch fixed it:

oc patch storageprofile nfs-csi --type merge \
  -p '{"spec":{"claimPropertySets":[{"accessModes":["ReadWriteMany"],"volumeMode":"Filesystem"}],"cloneStrategy":"copy"}}'
Enter fullscreen mode Exit fullscreen mode

Where vSwitches went

On each node, an NMState policy (NodeNetworkConfigurationPolicy) builds a Linux bridge, br-vm, on a second NIC that carries a VLAN trunk. NADs then tag each VM's traffic with its VLAN on that bridge. It's the same idea as a distributed switch with port groups, declared as code.

oc get nncp           # the policy
oc get nnce           # did it apply on each node?
Enter fullscreen mode Exit fullscreen mode

Next

The architecture diagram shows all of these objects in one picture, and the free manual walks through creating each one with real output. Next in this series: why my first migration ran at 2.8 MB/s.

Top comments (0)