From Vultr to Packet

October 15, 2018

Equinix, Vultr

A while back I’d opined on spending a couple years moving around different service providers in search of a couple objectives. The objectives, in short, were:

to be able to use the upstream distribution media for installation rather than deploying a pre-packed image.
to be able to use distribution kernels
to be able to use full disk encryption

The rational for these things can be generally argued against based on preferences that one may have for their ecosystems, but these were the primary things I’d wanted to find in a provider for a long time. Personally I’m surprised there isn’t more of a market pressure for being able to control everything from the metal forward, but have the benefit of being in a managed data center.

Vultr handled these things fairly well until I’d realized that there was two more objectives that became necessary:

out of band management, specifically serial over lan via ssh
direct access to hardware instead of being in a hardware shared environment

The desire for these two things is experiential from the time spent with Vultr. SoL control via ssh is a wonderful convenience… something I’ve not had the benefit of since leaving Linode’s Lish. We use SoL via IPMI/BMC for managing metal locally, having someone front that to you over the Internet is extremely helpful for things like entering your LUKS password in early user space. With Vultr the installation process and your prompts from early user space are all managed by a web based ikvm system. This has been good, but if there was ever a externally triggered reboot the password prompt was buried behind two factor authentication and a proper browser.

This leads to the second thing: shared metal is absolute shit for reliability. Vultr, as good as the tech is behind their service offering… originated as a game server company. Which, apparently, hosting game servers for people attracts some of the most toxic folks on the Internet. So, you could be hosting your company/personal service on a fairly large Vultr instance with all of their enhancements and protections in place… when someone sharing your same metal kicks a kid off their minecraft server who knows how to use their moms credit card to buy shared time on a denial of service system. This is a very real problem, I’d say 90% of my tickets to Vultr in the last couple years are just reporting that the host is experiencing packet loss, which historically has been resovled with a metal level reboot (which only they can issue).

Packet #

Packet was around when I’d transitioned from DigitalOcean to Vultr, however at the time they were limited to installation from their defined images. There was a good deal of discussion about “Bring Your Own OS” in their IRC, however it took a while to manifest in a form that was enticing enough to dip my toes in. A couple things that were useful along the way:

Packet has published guides on how to use custom ipxe to whatever environment you choose
You can interact with support and have them set your host to “hybrid UEFI/BIOS”, just make sure to have the disk with the EFI partition set as the top most boot priority. (another interesting thing is that you can view the BIOS changes that support is doing in real time via ssh SoL, hopefully they let us make BIOS changes ourselves via this same interface in the future.)
You can arrange reserved access to metal at a lower rate than their published market rates (another request to support)

The only thing you really need to remember is to add this to your kernel boot parameters:

console=ttyS1,115200n8

So with Packet your remote servers can easily:

be purely installed from my distribution media of choice
use UEFI and systemd-boot
use full disk encryption via LUKS
have the boot password entered via ssh (copy and paste!) through SoL out of band management
be dedicated to your purposes
ride on Packet’s wonderful network that keeps getting peered with more and more useful networks