Hi,
## TL;DR:
Migrations between servers coming in the near future for the purposes of
a hardware refresh, with an upgrade to VM specs, a bit like in 2015–2016.
## Hardware refresh
In the coming weeks we hope to get started with a long overdue hardware
refresh. This will include some sort of upgrade to the base VM
specification, the exact details of which haven't yet been decided.
The last time we did this was in 2015–2016 and I expect things to go in
much the same way, although slightly less complex as we also did some
changes to VM disk layout that time. Here's more info on how that went:
https://tools.bitfolk.com/wiki/Hardware_refresh,_2015-2016
Three of the existing servers have some life left in them but they do
not currently have 25GE network interfaces, so it's going to be a
priority to clear customers off of those first so they can be taken out
of service for that to happen. Those servers are "elephant",
"limoncello" and "talisker".
I anticipate sending a direct email to the main tech contact for each VM
on the candidate server asking if they would like to have their VM
migrated to new hardware and get the upgraded specs at the same time.
Past experience has shown that the majority of people won't be
interested in the upgrade and would rather not have to do anything, so
this communication is going to have to say something like, "if we don't
hear back from you to schedule this within 15 days, we will schedule it
ourselves for a date no sooner than 30 days from now".
Since eventually all servers do require at least an OS upgrade even if
they are not being decommissioned, it is I am afraid inevitable that all
customer services will have to be migrated between servers. This is
going to take many months. We will try to be as flexible as possible
with people who need that.
For those who have never experienced their VM being migrated between
servers, it is not a big deal. We shut it down and boot it a few
seconds later on its new server. At your option¹ we can also do a live
migration which works most of the time² and results in no actual
shutdown. Nothing about the VM changes, except that its specs will be
upgraded.
## IPv6 changes
We also need to change how we do IPv6 and there's no reason why we can't
start doing that at the same time so unless things are getting
overwhelming you might see something soon about that also.
Basically we need to start assigning customer VMs IPv6 address space out
of BitFolk's 2a0a:1100::/29 rather than the /48 of Jump's that we've been
using since 2005.
I expect to be reserving a /48 for each VM but as the majority of people
use either zero or one IPv6 address, only one IPv6 address from the new
assignment will initially be routed to your VM. For those wanting more we
will add a feature to the Panel and/or Xen Shell to expand the routing to
a /64 or the full /48 (and maybe something in between there also). The
goal is for that to not require a support ticket.
This sort of thing is desirable to prevent neighbour table exhaustion
attacks, where someone cycles through many addresses in a /64 (or larger).
I do not expect to take away the legacy assignments from out of the
2001:ba8:1f1::/48 provided by Jump from existing VMs, but after we begin
rolling this out new VPS orders and new self-installs will not have the
legacy IPv6 space. At some point in the fairly distant future a retirement
date will be announce for that range.
## Feedback?
So that's what's coming up. If you have any feedback or questions we're
keen to hear them.
There is no need to volunteer now to be first for upgrades or anything as
you will be contacted and that will be your chance to do that!
Thanks,
Andy
¹
https://panel.bitfolk.com/account/config/#prefs
² There have been some rare problems with this in the past which resulted
in disk corruption but in the case of migration between servers we do
always have a copy of your disk on the source server, so it's pretty
safe. All of BitFolk's own VMs live migrate.
--
https://bitfolk.com/ -- No-nonsense VPS hosting