NatVPS Migration to KVM Platfrom

JonyBee · October 6

received an email from NatVPS about 3 days ago:

Embracing KVM: A Leap Forward for Your Hosting Experience!

We're thrilled to announce that we're transitioning our hosting platform from OpenVZ-7 to KVM virtualization. This significant upgrade will bring a host of benefits to your hosting experience.

The reason for this migration is not only the numerous benefits of KVM virtualization but also the fact that OpenVZ-7 is no longer maintained and is practically an End-Of-Life platform. As you probably have experienced, we have had numerous issues with OpenVZ virtualization platform which include but not limited to: frequent VM corruption, IPv6 connectivity issues, broken server rebuilds, limited client side controls, ... . Migration to KVM virtualization will provide a stable platform that not only resolves the aforementioned issues but also in conjunction with much more modern VirtFusion control panel, provides a feature-rich interface that provides access to a plethora of features including superior performance due to direct hardware access and minimal overhead, much more secure servers because of isolated kernels, complete server monitoring and statistics interface, domain/port forwarding, IPv6 address management, hostname control, ... .


As part of this migration process, a number of changes will be applied:

• All the current OpenVZ-7 services will be transitioned to KVM virtualization.
• All the clients with 128MB RAM services will be migrated to 256MB RAM service for free.
• Some locations will need to be discontinued because of feasibility concerns as KVM virtualization takes much more resources. These locations include: South Africa, Chile, Hong Kong, Poland, and Switzerland. The active services in these locations will be recreated on one of our other locations.
• Los Angeles & New York will be consolidated to a single location within US for feasibility.
• Clients will get at least 10 days to move their data or make backups of them.


Estimated start date for KVM plans implementation: 4th October 2024
Estimated finish date: 20th November 2024

We're committed to providing you with the best possible hosting experience, and this transition to KVM is a major step in that direction. More details and exact schedule for each location will be communicated later on.

Best regards,

what a pity thing is HongKong will no longer exist.

bliss · October 6

I've been one of Web Horizon's customers since 2021 and very satisfied with the service. NAT VPS in most locations like Japan, Canada are extremely stable ( > 99% uptime). In the meantime many providers discontinued their products or even businesses, but Web Horizon at least survived or even expanded.
There were some problems as the email mentioned, but @Abdullah swiftly responded to my tickets, effectively solved some, as for those needed extra efforts he explained clearly and recorded carefully.

Wish Web Horizon continue to flourish.

JonyBee · October 6

@bliss said:
I've been one of Web Horizon's customers since 2021 and very satisfied with the service. NAT VPS in most locations like Japan, Canada are extremely stable ( > 99% uptime). In the meantime many providers discontinued their products or even businesses, but Web Horizon at least survived or even expanded.
There were some problems as the email mentioned, but @Abdullah swiftly responded to my tickets, effectively solved some, as for those needed extra efforts he explained clearly and recorded carefully.

Wish Web Horizon continue to flourish.

it is correct.I have 7~8 tiny servers with NatVPS and three of them are HongKong Servers.these servers are very decent with rare low prices.it seems that the upstream in HongKong is Hosthatch.I don't know whether it is possible to keep these servers @Abdullah ,but upgrade to KVM is a huge leap definitely.

AK_KWH · October 6

its been almost a year i m offering similar offers but Upgrade to KVM its a big challange for every provider on Lowend with 3-4$/Year price @Abdullah you did your best mate

Ayyub · October 23

Update on Migration:

France KVM services are ready and clients who have service(s) in that location, can now open a ticket and request for creation of France KVM service(s).

KVM services for other locations will become online in coming days.

TigersWay · October 30

I've been one of many @Abdullah / Web Horizon / NatVPS's customers for many years and enjoying all my services.

I'm just starting to play with that new KVM in France and I'm facing a box with 205M as memory and no swap: strange and kinda difficult to install anything. Anyone else in the same situation?

Abdullah · October 30

@TigersWay said:
I've been one of many @Abdullah / Web Horizon / NatVPS's customers for many years and enjoying all my services.

I'm just starting to play with that new KVM in France and I'm facing a box with 205M as memory and no swap: strange and kinda difficult to install anything. Anyone else in the same situation?

Since KVM servers run with an independent kernel, they use up resources directly from your allocation. I’m looking into ways to improve things, and there’s a chance I could bump the minimum RAM to 512MB for everyone in EU locations, depending on how feasible it is.

If we go ahead with this, we might need to adjust the pricing for promotional accounts to bring them closer to the standard rate, around $7 per year.

Is anyone else in a similar situation? I’d love to hear more feedback to help make things better for everyone.

bliss · October 30

@TigersWay said: I'm facing a box with 205M as memory and no swap: strange and kinda difficult to install anything.

No, it's not strange. You should check assigned memory size with

$ sudo dmidecode --type memory

As for the "205M", @Abdullah has explained well.

@Abdullah said: around $7 per year.

I know this is a difficult decision, is that compulsory or a proposal to be discussed?

I had run qb, cloudflared, and darkhttpd on a KVM VPS with 256 MB memory, archlinux OS stably, the only problem is all user programs must be stopped when locale-gen. If switch to Alpine Linux, more programs could be run.

So I think paid upgrade of memory should be optional, accordingly you should limit or lower the resources quota used by those who refuse upgrade to prevent swap abuse. For example stop the VPS if load is more than 0.5 for a few hours.

TigersWay · October 31

@Abdullah I believe I somehow understand the memory logic and I should have no trouble running the set of little app I usually need on these kind of endpoint.
But it seems - once again I'm far from a knowledgeable guy - that I can't find a way to run an ISO install as your "minimal" debian templates are not my "cup of tea".

I'm not against an increase of the price, but for a box which is basically only my own wireguard vpn, I will have to check

But don't misunderstand me, as much as I could say my new box is quite fast and responsive!

bliss · November 20

@Ayyub said: KVM services for other locations will become online in coming days.

Any plans about other locations? The migration email said the estimated end date is 20th November (today), but nothing happened. Not in a hurry though.

nightcat · November 20

Any news for SG location

Abdullah · November 20

@nightcat said:
Any news for SG location

We are waiting for additional capacity in Singapore & Japan before proceeding there.

All resources are completely occupied atm.

Ayyub · November 22

Update on Migration:

Canada KVM services are ready and clients who have service(s) in that location, can now open a ticket and request for creation of Canada KVM service(s).

KVM services for other locations will become online in coming days.

Ayyub · November 23

Update on Migration:

Netherlands KVM services are ready and clients who have service(s) in that location, can now open a ticket and request for creation of Netherlands KVM service(s).

KVM services for other locations will become online in coming days.

sh97 · November 23

@Ayyub I have a vps in HK, which is going to be a discontinued location as per the email. Can I request a recreation in one of these new locations?

Ayyub · November 23

@sh97 said: I have a vps in HK, which is going to be a discontinued location as per the email. Can I request a recreation in one of these new locations?

We really appreciate it if you wait for the migration email that targets that location (Hong Kong).
That's because one the one hand Asian KVM locations are not fully functional yet and on the other hand we don't want to put too much pressure on nodes for providing alternative to discontinued locations.

sh97 · November 23

@Ayyub said:

@sh97 said: I have a vps in HK, which is going to be a discontinued location as per the email. Can I request a recreation in one of these new locations?

We really appreciate it if you wait for the migration email that targets that location (Hong Kong).
That's because one the one hand Asian KVM locations are not fully functional yet and on the other hand we don't want to put too much pressure on nodes for providing alternative to discontinued locations.

Gotcha - thanks for the clarification.
Will wait it out.

bliss · November 23

@Ayyub Thanks for upgrading to KVM platform.

You made a wise decision not to provide an arch Linux template for installation. I can confirm that arch Linux is barely usable with only 256MB of memory, except for idling. Therefore, I've decided to switch to alpine Linux, which is much smaller.

I think disk I/O and CPU usage should be closely monitored or throttled due to the low memory. Otherwise, when some users make a high load (probably unintentionally), it could affect everyone on the host.

Anyway, I really appreciate your efforts. By the way, has anyone tested IPv6? It seems not working out of the box. Thank you!

JonyBee · November 23

oh,I have paid the bills recently,including Japan,Singapore and hk,what if these locations wouldn't be continued?Do I need request refund?

Ayyub · November 24

@bliss said: By the way, has anyone tested IPv6? It seems not working out of the box

Please open a ticket; we will check.

bliss · November 24

@Ayyub said: Please open a ticket; we will check.

It’s very kind of you, and I’m always satisfied with WebHorizon’s stability and reliable support. However, I won’t open a ticket to save your valuable manpower.

Incidentally, I temporarily fixed the IPv6 issue by continuously pinging the assigned addresses, though I’m not sure why it worked or how long it will last.

64 bytes from 2607:5300:6:xxx:f::b: icmp_seq=570 ttl=92 time=32 ms
64 bytes from 2607:5300:6:xxx:f::b: icmp_seq=571 ttl=92 time=32 ms
^C
--- 2607:5300:6:xxx:f::b ping statistics ---
572 packets transmitted, 137 received, 76.049% packet loss, time 576808ms
rtt min/avg/max/mdev = 26.022/32.694/34.685/0.927 ms

elliotc · November 24

I kinder miss the old day that we can satisfy on a 128MB machine and feel 512 are too much.

ofit · November 25

The debian template is not working well. i can't even update packages. The kernel update process just kills itself. Same story with updating locales and so on. It works horribly. I can install wireguard and proxy, but is it a full-fledged KVM? I used KVM NAT with 256 MB RAM a few years ago and everything worked fine. There's obviously some problem here.

kernal update

Setting up linux-image-5.10.0-33-amd64 (5.10.226-1) ...
Killed
dpkg: error processing package linux-image-5.10.0-33-amd64 (--configure):
 installed linux-image-5.10.0-33-amd64 package post-installation script subprocess returned error exit status 137
dpkg: dependency problems prevent configuration of linux-image-amd64:
 linux-image-amd64 depends on linux-image-5.10.0-33-amd64 (= 5.10.226-1); however:
  Package linux-image-5.10.0-33-amd64 is not configured yet.

dpkg: error processing package linux-image-amd64 (--configure):
 dependency problems - leaving unconfigured
Errors were encountered while processing:
 linux-image-5.10.0-33-amd64
 linux-image-amd64
E: Sub-process /usr/bin/dpkg returned an error code (1)
root@s34:~# apt install -f
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
0 upgraded, 0 newly installed, 0 to remove and 37 not upgraded.
2 not fully installed or removed.
After this operation, 0 B of additional disk space will be used.
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
        LANGUAGE = (unset),
        LC_ALL = (unset),
        LC_TIME = "be_BY.UTF-8",
        LC_MONETARY = "be_BY.UTF-8",
        LC_ADDRESS = "be_BY.UTF-8",
        LC_TELEPHONE = "be_BY.UTF-8",
        LC_NAME = "be_BY.UTF-8",
        LC_MEASUREMENT = "be_BY.UTF-8",
        LC_IDENTIFICATION = "be_BY.UTF-8",
        LC_NUMERIC = "be_BY.UTF-8",
        LC_PAPER = "be_BY.UTF-8",
        LANG = "en_US.UTF-8"
    are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
Setting up linux-image-5.10.0-33-amd64 (5.10.226-1) ...
Killed
dpkg: error processing package linux-image-5.10.0-33-amd64 (--configure):
 installed linux-image-5.10.0-33-amd64 package post-installation script subprocess returned error exit status 137
dpkg: dependency problems prevent configuration of linux-image-amd64:
 linux-image-amd64 depends on linux-image-5.10.0-33-amd64 (= 5.10.226-1); however:
  Package linux-image-5.10.0-33-amd64 is not configured yet.

dpkg: error processing package linux-image-amd64 (--configure):
 dependency problems - leaving unconfigured
Errors were encountered while processing:
 linux-image-5.10.0-33-amd64
 linux-image-amd64
E: Sub-process /usr/bin/dpkg returned an error code (1)

update-locale

root@s34:~# dpkg-reconfigure locales
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
        LANGUAGE = (unset),
        LC_ALL = (unset),
        LC_ADDRESS = "be_BY.UTF-8",
        LC_NAME = "be_BY.UTF-8",
        LC_MONETARY = "be_BY.UTF-8",
        LC_PAPER = "be_BY.UTF-8",
        LC_IDENTIFICATION = "be_BY.UTF-8",
        LC_TELEPHONE = "be_BY.UTF-8",
        LC_MEASUREMENT = "be_BY.UTF-8",
        LC_TIME = "be_BY.UTF-8",
        LC_NUMERIC = "be_BY.UTF-8",
        LANG = "en_US.UTF-8"
    are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
/usr/bin/locale: Cannot set LC_CTYPE to default locale: No such file or directory
/usr/bin/locale: Cannot set LC_MESSAGES to default locale: No such file or directory
/usr/bin/locale: Cannot set LC_ALL to default locale: No such file or directory
Generating locales (this might take a while)...
  be_BY.UTF-8...Killed
 done
  en_US.UTF-8...Killed
 done
  ru_RU.UTF-8...Killed
 done
Generation complete.
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
        LANGUAGE = (unset),
        LC_ALL = (unset),
        LC_TIME = "be_BY.UTF-8",
        LC_MONETARY = "be_BY.UTF-8",
        LC_ADDRESS = "be_BY.UTF-8",
        LC_TELEPHONE = "be_BY.UTF-8",
        LC_NAME = "be_BY.UTF-8",
        LC_MEASUREMENT = "be_BY.UTF-8",
        LC_IDENTIFICATION = "be_BY.UTF-8",
        LC_NUMERIC = "be_BY.UTF-8",
        LC_PAPER = "be_BY.UTF-8",
        LANG = "C"
    are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
        LANGUAGE = (unset),
        LC_ALL = (unset),
        LC_TIME = "be_BY.UTF-8",
        LC_MONETARY = "be_BY.UTF-8",
        LC_ADDRESS = "be_BY.UTF-8",
        LC_TELEPHONE = "be_BY.UTF-8",
        LC_NAME = "be_BY.UTF-8",
        LC_MEASUREMENT = "be_BY.UTF-8",
        LC_IDENTIFICATION = "be_BY.UTF-8",
        LC_NUMERIC = "be_BY.UTF-8",
        LC_PAPER = "be_BY.UTF-8",
        LANG = "C"
    are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
*** update-locale: Error: invalid locale settings:  LANG=en_US.UTF-8

bliss · November 25

@ofit said: There's obviously some problem here.

No, there is not. Just out of memory.
By the way, is IPv6 on your VPS working out of the box? Would you share the output of the following command? Thank you.
ping6 -c4 -w5 he.net

Brueggus · November 25

@elliotc said:
I kinder miss the old day that we can satisfy on a 128MB machine and feel 512 are too much.

What annoys me is that most services would still run fine on a 128MB machine. But at some point the f*cking package managers started eating more and more memory so that you're unable to install anything or run an update.

ofit · November 25

@bliss said:

@ofit said: There's obviously some problem here.

No, there is not. Just out of memory.
By the way, is IPv6 on your VPS working out of the box? Would you share the output of the following command? Thank you.
ping6 -c4 -w5 he.net

root@s35:~# ping6 -c4 -w5 he.net
PING he.net(he.net (2001:470:0:503::2)) 56 data bytes

--- he.net ping statistics ---
5 packets transmitted, 0 received, 100% packet loss, time 4077ms

rhinoduck · November 25

For @ofit and everyone else having trouble upgrading packages after installing from the Debian template.

As @bliss said, there is no other problem than the fact that not enough memory is available for such tasks. I worked around the issue by temporarily adding some swap space (96 MB was enough for me after a fresh install from the Debian 11 template, you may need more; all commands need to be run as root).

First run this:
fallocate -l 96M /swapfile && chmod 600 /swapfile && mkswap /swapfile && swapon /swapfile

Now do your apt upgrade and/or regenerate locales.

Then run this when you are done:
swapoff /swapfile && rm /swapfile

Last but not least, be a good neighbour and do not go abusing swap for situations where a 512 MB VPS would be appropriate. The only place that that will ultimately lead you is out the door.

It certainly sucks that upgrading some packages does not work out of the box, but WebHorizon is essentially stuck walking a tightrope between a rock and a hard place here. I, personally, don't mind having to "tinker" with things a bit so that I can keep paying peanuts for the VPS given that otherwise it is perfectly fine for my use case; after all, this is very much in the real spirit of low end.

Ayyub · November 25

@bliss said: By the way, is IPv6 on your VPS working out of the box?

Try disabling IPv6 router advertisement and see if it helps (in Ubuntu, edit the netplan file at /etc/netplan/50-cloud-init.yaml and add accept-ra: false)

ofit · November 25

@rhinoduck said:
For @ofit and everyone else having trouble upgrading packages after installing from the Debian template.

As @bliss said, there is no other problem than the fact that not enough memory is available for such tasks. I worked around the issue by temporarily adding some swap space (96 MB was enough for me after a fresh install from the Debian 11 template, you may need more; all commands need to be run as root).

First run this:
fallocate -l 96M /swapfile && chmod 600 /swapfile && mkswap /swapfile && swapon /swapfile

Now do your apt upgrade and/or regenerate locales.

Then run this when you are done:
swapoff /swapfile && rm /swapfile

Last but not least, be a good neighbour and do not go abusing swap for situations where a 512 MB VPS would be appropriate. The only place that that will ultimately lead you is out the door.

It certainly sucks that upgrading some packages does not work out of the box, but WebHorizon is essentially stuck walking a tightrope between a rock and a hard place here. I, personally, don't mind having to "tinker" with things a bit so that I can keep paying peanuts for the VPS given that otherwise it is perfectly fine for my use case; after all, this is very much in the real spirit of low end.

I'm added 256MB swap storage and it works fire now. Thanks.

TigersWay · November 26

@bliss said:
...
No, there is not. Just out of memory.

That's clearly the problem. As many know now, a little swap is all we need!

Well, maybe for the next generation, a way to start netboot.xyz would be great too, cuz the templates could be improved!

Quentin · November 26

@bliss said:

@Ayyub said: Please open a ticket; we will check.

It’s very kind of you, and I’m always satisfied with WebHorizon’s stability and reliable support. However, I won’t open a ticket to save your valuable manpower.

Incidentally, I temporarily fixed the IPv6 issue by continuously pinging the assigned addresses, though I’m not sure why it worked or how long it will last.
64 bytes from 2607:5300:6:xxx:f::b: icmp_seq=570 ttl=92 time=32 ms
64 bytes from 2607:5300:6:xxx:f::b: icmp_seq=571 ttl=92 time=32 ms
^C
--- 2607:5300:6:xxx:f::b ping statistics ---
572 packets transmitted, 137 received, 76.049% packet loss, time 576808ms
rtt min/avg/max/mdev = 26.022/32.694/34.685/0.927 ms

I also encountered the same issue. The only way to maintain the connection is by continuously connecting to IPv6 using another VPS.

NatVPS Migration to KVM Platfrom

Comments