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