64-bit guests
This article explains why, if you haven't already done so, you should switch to a 64-bit guest.
TL;DR:
If you're doing an install now, make sure it is a 64-bit one, not a 32-bit one.
64-bit is default at BitFolk
If you've been a customer for less than 4 years then (unless you went out of your way to change this) your VM is already 64-bit, as the default was switched around that time.
Those who have kept the same account for longer than this quite possibly are still running 32-bit. If you are, you should start to think about how and when you will change over to 64-bit. Here's why.
Reasons to switch
- 32-bit x86 isn't getting much upstream kernel attention
- There are multiple reports of 32-bit-only bugs being ignored in the upstream Linux kernel because no one is interested in working on them.
- 32-bit Linux is less secure
- Possibly as a consequence of the above, 32-bit Linux lags behind even on security fixes. For example, full Spectre and Meltdown mitigations were in the 4.13 kernel for the amd64 architecture, but didn't arrive in the i686 kernel until 4.19.
- More and more Linux distributions are dropping 32-bit support
- So far we're talking at least CentOS, Fedora and Ubuntu. Debian talk about it from time to time, too.
- Xen has deprecated 32-bit PV guest support, too
- Xen, the hypervisor software we use, has indicated that 32-bit PV guest support is now deprecated, and will be removed after a release or two, which probably means a couple of years. This isn't the end of the world because we will by then have switched to PVH mode which will be able to run 32-bit guests. However it's probably not a good idea to make things more complicated.
How to tell what you're running
There's three different places where the architecture of a BitFolk VM matters:
- The bootloader
- The kernel
- The rest of the operating system ("userland")
You can see which architecture of bootloader you have by looking at the summary page of the BitFolk Panel, or using the "arch" command of the Xen Shell. You can only boot kernels of the same architecture as your bootloader, so a working VM will have a bootloader of the same architecture as the kernel.
The architecture of your kernel should show up in your package manager and the output of the uname -a command.
64-bit kernels can run both 32- and 64-bit binaries, so possibly you have a mixture in the rest of your operating system. Your package manager should tell you, but presumably you would know if you had done this.
How to switch to 64-bit
So you have a 32-bit guest but you want to end up with a 64-bit one. There's several ways to achieve this, and which way you choose depends on a number of factors.
Reinstall
This is probably the quickest way to do the switch, with the obvious downside that you have to set up everything again. Depending on how thorough you were with backups and configuration management maybe it is a matter of minutes to have all your stuff running on a new base server install, or maybe you have no real idea how everything works on the snowflake server you have been lovingly caring for. More likely you are somewhere in the middle of that spectrum.
You can reinstall at any time with BitFolk's self-serve installer. Just remember to use the "arch" command of the Xen Shell to switch your architecture to 64-bit first.
Migration VPS then reinstall
If you can't bear to have everything down while you piece it all back together on a new server then you may want to take advantange of BitFolk's migration VPS offer. With this option you would have a new account set up, you'd install a new OS into it, and have two weeks to move everything over into it. If you didn't get moved over in time then you'd need to start paying for the extra VM, but as long as you did get it done in time your older one would be shut down and there'd be nothing extra to pay.
Install a 64-bit kernel
Linux distributions that support multiarch can install both 32- and 64-bit packages, so one way to keep going is to install a 64-bit kernel and only gradually switch to 64-bit packages. Two such examples are Debian and Ubuntu. If for example you follow these Debian instructions up to but not including the step named "Crossgrade `dpkg` `tar` and `apt`" then you would be running a 64-bit kernel with an entirely 32-bit userland.
The only BitFolk-specific difference to a procedure like this is that you must tell BitFolk to use a bootloader of the correct architecture for your kernel. You do that with the arch command of the Xen Shell, so if using the above procedure you would do that after installing the 64-bit kernel and shutting down, but before trying to boot it. If you forget it will be rather obvious because BitFolk's grub will just complain that it can't load your 64-bit kernel. You then have chance to go and run the arch command, or else try again booting into the 32-bit kernel. For this reason you should also never remove the known-working 32-bit kernel until you've verified that your 64-bit kernel works.
Note that under the default Debian (and probably Ubuntu) grub configuration, the menu option named "Debian GNU/Linux" — which is the default — will still boot the 32-bit kernel, not the 64-bit one you just installed. This first time you need to go into "Advanced options for Debian GNU/Linux" and select the amd64 kernel.
If you did perform the next step, "Crossgrade `dpkg` `tar` and `apt`", you would have a system which believes its primary architecture is amd64 but almost all of its packages will still be i386. The package manager would therefore forever complain of broken dependencies until you went ahead with the huge task of reinstalling many many packages. You would not be able to install anything new as apt would also want to fix what it sees as broken dependencies every time. So don't do that unless you are going to commit to doing a full crossgrade.
Fully cross-grade to 64-bit
This is like the previous option but more so. You complete the full procedure of switching to 64-bit kernel and then carry on to reinstall every package with its 64-bit replacement.
There is dubious value in doing things this way. It takes a really long time, is totally unsupported by both Debian/Ubuntu and BitFolk, and is extremely easy to get wrong resulting in the destruction of your operating system. It cannot be completed without doing things that the package manager normally refuses to do. You get most of the benefit of 64-bit from switching the kernel anyway, and can replace individual packages on a package-by-package basis anyway.
Again, don't forget that before you boot into your newly installed 64-bit kernel you must switch your bootloader to 64-bit with the "arch" command of the Xen Shell.
Frequently Answered Questions
I have less than 4G memory. What's the point in going 64-bit?
While it's true that you absolutely need 64-bit processes if you want to address more than 4GiB memory, that's not the only advantage of 64-bit. It's the disadvantages of 32-bit that are making developers leave it behind, and that's having an effect at the level of Linux distribution, upstream kernel and hypervisor.
Will my guest run faster or slower as 64-bit?
It's difficult to guess. While data types are bigger in 64-bit, leading to slightly increased memory use, there's more and larger registers, leading to better use of processor cache. You most likely won't notice any difference.
Things that don't work or aren't available in 32-bit x86
An incomplete list.
- CentOS from 7 release onwards (some availability still in AltArch)
- ZFS
- zstd compression in btrfs boot filesystem