Live Blog

Reboot maintenance notification from Vultr, what does it mean?

Content Error or Suggest an Edit

Notice a grammatical error or technical inaccuracy? Let us know; we will give you credit!

Introduction

Someone posted this, I responded and thought the internet would benefit.

Hi, this is the first mail from Vultr I get announcing Maintenance. Especially this sentence got me confused.

Please be aware that as we do not have access to your filesystem, this reboot will not be as clean as if it were done from within your OS, so preparing your software/filesystem with a graceful shutdown of services and the VPS itself would be advised.

Does this mean I have to shutdown the server, because I can only reboot from the GP dashboard.

Response

This is common sentence from Vultr and it’s more technical.

  1. They don’t have access to your VM to shut it down properly. They can’t login and shut-down the server for you.
  2. They’re warning you that they’re going to reboot the host and your guest (VPS) might not shutdown cleanly for a number of reasons.
  • They don’t actually send the shutdown command to your VM, they should.
  • You have services that take too long to shutdown, or hang.
  1. The preparing would be ensuring that your server shuts down when they ask it to, if they ask (I’ll talk more about this). Or shutdown the server for them.

When you login to a VPS, you can check to see what hypervisor it’s using (what allows them to create a VPS on a big server). Sometimes the information is accessiable, and sometimes it’s not.

For Vultr, almost all instances are detected as Microsoft . So I’m assuming they’re using Microsofts HyperV as a hypervisor, it can’t really be a mistake because if it wasn’t detected it would be blank or set to something random. I could be wrong here, but doubt it.

When you shutdown any guests (VPS) on a host (big server), it will send a command to the guest and the guest OS needs to support it. For instance GridPane uses Ubuntu and it’s supported as per https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/Feature-Descriptions-for-Linux-and-FreeBSD-virtual-machines-on-Hyper-V

The problem will be if any of the instances take too long to shutdown or hang. So they will just force shut them down like pulling the plug from behind a desktop computer. Which can lead to data corruption.

However, operating systems are pretty resilient, and usually can recover, or have tools to help you recover. Services such as MySQL also have the same, unless you configure them in a way not to, and you can actually lose data. There’s a slim chance you’ll have any issues, but always backup your data. I would also take a snapshot.

If you do take a snapshot, make sure to confirm with Vultr if it’s an off-host snapshot. That way, if they restart the system and it doesn’t come back up or they can’t restore your VPS. You can re-deploy it somewhere else.

0 Shares: