x86-64 is the concept of a plan of an architecture
Now that I have my KVM box running, it's time to make some VMs. I'll spin up four Debian instances, based on the configurations in Kubernetes The Hard Way.
I grab the Debian 12 install iso, upload it through the Proxmox console, then configure the first VM: jumpbox.
I've used Debian before, but never installed it from scratch; usually I work with Redhat family distros. It's a straightforward process, and the install seems simpler than for Rocky or Fedora install (though since my first Linux distro was Slackware ftp'ed into 3" floppies I may have a low bar for "simpler"). I stick with the default options, except for adding an OpenSSH server to the list of software to be installed. The installer completes, prompts me to allow it to reboot, and the new VM starts up- then dies with an error about unsupported machine instructions.
I had selected kvm64 as the CPU type in the VM configuration dialog; I knew the Dell's Xeon processor long preceded x86-64-v2 and the like, and I had found some comments online about incompatibilities between Debian 12 and the most recent x86-64 processors. But was this a mistake in my choice of CPU type, or did I mangle the install?
Settingthe CPU to qemu64 gets the VM to work, but it's obviously going to be too slow for anything useful. This confirms that my install is good, at least. Now I need to figure out which of the Intel processor codenames in the configuration menu best matches the Xeon processor in the Dell box. |
| The Proxmox CPU selection menu in the VM configuration dialog |
I get shell on the host from the Proxmox console (I don't know whether to be awed or horrified at the idea of Xterm implemented in JavaScript), and dmesg provides me a few additional scraps of data about the processor. I'm able to use this to find a range of dates for when the processor was probably manufactured, but not the actual name.
Using the information in Wikipedia's List of Intel codenames, I'm able to come up with a set of candidate names. Luckily, the unsupported instruction error happens early in the boot sequence, so it doesn't take me long to iterate over them, and discover the correct selection for my machine is "Conroe".
Soon the standard GDM login screen displays in the VM's console window. Success! I click on the user name, and wait for the password dialog.
And wait. And wait. Maybe a GUI environment isn't a viable choice for a machine this strapped for resources.
I ssh into the VM and uninstall Gnome, Evolution, and anything else that's obviously a GUI application (I leave the X client libraries), then shutdown the VM.
From the Options panel I remove the VM's mount of the .iso, and enable QEMU Guest Agent. I'm not sure if this is installed, but if it is, this will give the Proxmox console some additional status information from the running VM.
I restart the VM, and in a minute I have a login prompt in the console window, and the Summary panel now shows the VM's IP address.
I then configure VMs for the server and node-0 machines. I bump node-0's CPU count to 2; from the performance stats in the console the Dell is memory-constrained, but still has a lot of compute available.
I choose the non-graphical install, and untick "Gnome" from the list of software to be installed (I still add the SSH server). When prompted to reboot, I halt the VM instead, and repeat the changes in the Options panel I made to jumpbox. I start each VM, and check that I can log in through the Proxmox console.
I could probably create node-1 by cloning node-0's VM, and I definitely want to explore Proxmox' VM management features in the future, but for now I just do another install, with the same parameters as node-0.
I now have four running VMs. Time to provision Kubernetes.