HostHatch Upcoming maintenance - Los Angeles Storage
cybertech
OGBenchmark King YABS 24/7/365
We are emailing you because we have an upcoming maintenance that affects your Storage VM(s) in Los Angeles.
....
....
Your server will be shut down and booted up after the maintenance has been completed. We do not expect any data on your server to change, but as a best practice, we always recommend that you keep the latest copy of your backups.
During this maintenance, we will make updates to the host server, and also boot it into our new cloud platform , from where you will be able to manage your server after it comes back online
....
....
I bench YABS 24/7/365 unless it's a leap year.
Comments
They're migrating all remaining locations expect for Asia and North Europe this week, aren't they?
Yep, quite a few locations
SG got migrated as well.
One of my chi nvme instances was migrated to the new panel
But it seems to have list the network ip details.
Running centos 7... any way to activate dhcp or manually setup the interfaces? Or only option is to reinstall?
Thnx
Have you tried console access via the new panel? I don't have an NVMe in Chicago specifically, but console access seems to work with my "legacy" NVMe servers in other locations.
Website: thomassen.sh
What do you mean exactly by this? Have you opened a ticket with us?
Does the legacy button have any particular meaning like is it removed on reinstallation or will it remain to distinguish between Intel E5 and AMD instances?
We haven't really gotten down to the semantics as of yet, but happy to listen to feedback on how things should be.
Several of my Legacy instances are AMD.
Here is what i see from the novnc console... I didn't create a ticket yet. Guess you guys have full hands with the maintenance..
If you see, my IP is not listed... It should have been there.
Please open a ticket so we can take a look. DHCP should work, static configuration should also work, as long as you're able to get to the console?
Why can only the old images be selected for reinstallation (like Debian 10) but not the new ones (like Debian 11)?
The new AMD ones from black friday and later?
could you help with a quick command to add my network details on the eth interface? CentOS 7
Thanks
What does your /etc/network/interfaces, netplan or network-manager config look like?
No, my old NVMe from like 2019. Think they were their 8th birthday celebration ones.
[donatello ~]# cat /proc/cpuinfo
processor : 0
vendor_id : AuthenticAMD
cpu family : 23
model : 49
model name : AMD EPYC 7502 32-Core Processor
stepping : 0
microcode : 0x830104d
cpu MHz : 2495.310
C7 should have NetworkManager installed by default. Try running nmtui and using that to change your interfaces. Once you're done, exit out and do: nmcli device reapply [interface_name_here] .
I had to run nmtui, manually configure the ip and gateway instead of Automatic.. and then reapply worked!
Thank you so much
I didn't read all of the dozens of migration emails carefully, but I did notice that some said the VM would move to a new server and others did not.
No, the VM stays on the host node (maybe not physically the same but equal setup like CPU etc.).
VM in Milan is supposed to be migrated yesterday? I still see it in the old panel, not the new panel.
My Stockholm and Vienna were migrated yesterday.
I didn't have time to play with, but this new control panel looks nice actually. Simple and clean interface with everything at one place.
I also like how smooth console access run. That's not the case with every host.
Seems like only IPv6 addresses with rDNS set migrated to the new control panel (nothing critical) and I will need to re-enable IPv6 later when I find time to play with but otherwise so far I see no issues.
Observation:
Seems like only IPv6 addresses with rDNS included can be added to the control panel which is okay I guess as others can be set manually.
Once added to the control panel rDNS can be changed, but there's no option to remove/delete added IPv6 addressed from the control panel - once added they stay there permanently.
Not extremely problematic, just a bit inconvenient.
Do you have IPv6 connectivity or is it just available in the panel?
Right now there's not IPv6 connectivity, however that was expected. With migation mail they sent also:
I will try to set it up later today when I come home from work.
My storage VPS'es, London and Stockholm, has been very stable. London was migrated one of the last days.
I think the new panel looks quite nice. And except for one ticket a good while ago, response times has been good, and service both stable and performing well. All in all a good experience
I see this for my newly migrated VPS:
" Your server is currently using our legacy internal networking. We recommend you to upgrade to our new private VLAN networking by clicking the button below. Please note that this will remove your existing internal interface."
Will this button rewrite config inside VPS directly? Or just add new interface which I should configure?
If you read the network documentation they link to it talks how on the new interface you can use whatever ip addressing range you want ( since it's a private vlan ). My guess is it removes the old interface and adds a new one which you can configure. I'm sure HH will correct me if I'm wrong.
Update.
IPv6 work perfectly if you follow https://docs.hosthatch.com/networking/#ipv6-configuration
Just don't forget to replace eth0 with ens3 in case you use new Debian distro.
ie.
nano /etc/network/interfaces.d/90-ipv6
& reboot
This migration to the new control panel went well by my experience.
Congratulations, you are part of the elite group in:
Routed IPv6 Hall of Fame
Include routed IPv6, at least /64 subnet, to get listed.
We accept Karma donations for the last flan. 🍮 affbrr
Reading the docs linked to from IPv6 settings, I still wonder if the panel will replace my config files. (I have experienced that with other panels/hosts previously, had to set immutable flag ...)
I had a bit of a fumble getting IPv6 working after the London migration. It didn't work straight off the bat, and going into the new CP saw IPv6 was disabled, so clicked enable hoping to get it working.
That resulted in a different /64 than previously, changed the config accordingly but still no IPv6, finally tried the old subnet again but with IPv6 enabled and everything sprang back to life.
Just checked today and now both /64 subnets appear in the panel, and both work, so was probably just me being a bit quick off the mark when the node reappeared.
Agreed, no problems with the migration otherwise, short downtime, good communications. Even seems to have fixed a low priority ticket (outbound port 25 blocked) that's been outstanding for 5 months :-)
I noticed some issue tho. I can't re-use old IPv6 addresses from pre-migration VPS (/64 subnet is still the same) on my Oslo VPS which kinda sucks as some of those have rDNS set up (and because of that the they also can't be removed from control panel). They simply don't come online. Newly created addresses work.
I have no this issue with my Vienna VPS. Old re-used addresses work also with the newly migrated and reinstalled Vienna VPS, so it seems like a bug or something from old control panel wasn't purged or something.
Both VPSes are clean installed after the migration.
I opened support ticket - now let's pray
Interesting.
I don't see this option. It write just "ENABLED" without disable/enable option (which is fine by me).
Maybe because of there's "LEGACY" button suggesting that I need to reinstall vps (I did that from ISO) in order to enable all the features.
I don't see any specific addresses configured now in the new control under either of my subnets. I can assign a random address (under either /64) interactively on the interface and it just works, seems to be a fully routed /64. (Edit:) including previously configured ones.
Mine is still a legacy install, I haven't re-installed and wasn't planning on it, I'm not clear what if any advantage there is in that. The IPv6 subpanel just says enabled for me now also, it did say disabled whilst I was testing despite IPv6 being actively used prior, but probably me jumping the gun with the migration still in progress.
I take the difference between routed and non-routed is routed you can use add the ip on the server and it works where non-routed you need to add each ip on the panel first.
That "non-routed" is called linked ipv6 I guess, something that solusvm does.
Had to boot into rescue and fix my network config, didn't happen for any of the other locations
Update
Two identical (Debian 11) hosthatch setups. Fresh re-installed from ISO after the migration.
Vienna:
Oslo:
It seems like it's not about old/new addresses actually. I tryed few things, different setups, etc, but no luck. I can't explain to myself why is that. Everything's seems correct on the VPS side.
Emil J yesterday responded. I hope that he won't give up otherwise I have a VPS without functional IPv6 after the migration
I had a couple of servers migrated over to the new panel and everything (including IPv6) remains working as it was.
"The imitator dooms himself to hopeless mediocrity." — Ralph Waldo Emerson
any improvement in performance?
I bench YABS 24/7/365 unless it's a leap year.
It's just migration to the new control panel, not actual node migration so everthing is pretty much the same (minus this IPv6 issue with one of my VPSes).
I'm actually interested in what @yoursunny considers to be routed vs non-routed IPv6. From what I can tell on the internet, routed seems to be things that use Neighbourhood Discovery...
Someone else here then said it's when you can just use any IP address you like without pre-configuring it.
But, e.g. in my home setup (which is sadly now IPv4 after an ISP switch, and I'd previously relied on IPv6 for accessing home machines from elsewhere), I now have a VM with a wireguard connection to router48.org. That box just has an IP address of 2a06:xxxx:xxxx::1/48 on eth1 (which is a virbr in proxmox shared with other machines I want to share using IPv6) and 2a06:xxxx:xxxx::2/128 on wg0, which uses eth0 to get the default IPv4 route to the tunnel server. Wireguard provides the default :: route from its config.
So, is this "routed" or not? Each vm that also has this shared network connection can use any IPv6 address it wants, and could choose to carve out a /64 if it wanted to. I'm using cloud-init to specify my chosen IP block and a gateway of 2a06:xxxx:xxxx::1.
If that's not what you call "routed" (and personally, I wouldn't call it routed because I haven't explicitly set up any routing or installed NDP), then what would you do differently to make it be considered routed?
This does differ from my old home router which had a /64 from the ISP and gave each machine a random 64-bit suffix (which I originally thought was based on MAC address, until they changed).
panel looks complete with all the specifications
I bench YABS 24/7/365 unless it's a leap year.
Oh, so Neighbourhood Discovery is just the IPv6 name for ARP? I guess I probably am using that then! I guess I still don't know what the difference between routed and non-routed IPv6 is.
After migration, my VPS is stuck on this screen. Did fsck through recovery and it fixed few errors, rebooted and it still doesn't boot, stuck at same screen. Any ideas on how to fix this ?
Did you use the full disk space before migration? They switched from Gib to GB, means 100GiB at the old panel become 100GB during migration which equals 93,2GiB.
Was that true for panel migrations like this? I know new machines but not migrations.
No, I was using hardly 10-15% of disk space
i had one that was migrated as legacy, and showed up correctly as 1000GB.
I bench YABS 24/7/365 unless it's a leap year.
That would be a very stupid move if true.