[LightDestory]

After my mistake on my VPS that requested @deanhills support I tried to emulate a OpenVZ environment on my local machine to figure out how get "Remote Desktop Access" technologies working on OpenVZ6.

My investigation started from the "workaround" provided by @"Hidden Refuge":

Issue: After installing a Desktop Environment the server will not survive the next reboot. I mean it will be unreachable (maybe stuck on booting), you can test it by pinging it: you will receive timeout.

Solution: Remove NetworkManager from the server immediately after the installation of the Desktop Environment.

What changes from the fix provided by @"Hidden Refuge" ? : Well, he named the use of SolusVM to reconfigure the network settings, instead on this attempt we will not need it. That means we can operate without creating troubles to the staff.

Step-by-Step guide to reproduce the fix, we will suppose the use of CentOS:

1. Load on a VPS based on OpenVZ technology a template of CentOS 7
   
2. Access to the container and set a root password:
   vzctl enter <ID>
   passwd root
   

1. Access via SSH and make sure the system is up to date with:
   
   
   Code: (Select All)

   yum update
   
   
   
2. Enable epel repo
   
   
   Code: (Select All)

   yum install epel-release -y
   
   
   
3. Install a DE, we will suppose XFCE
   
   
   Code: (Select All)

   yum groupinstall "Xfce" -y
   
   
   
4. The following command didn't work for me (I had systemctl time out error), but try it:
   
   
   
   Code: (Select All)

   systemctl mask NetworkManager
   
   
   
5. Try uninstalling NetworkManager
   
   
   
   Code: (Select All)

   yum remove NetworkManager
   
   
   

Now rebooting, the VPS should survive. To check if the workaround was successful you can try pinging the VPS. (When pinging you can get as first attempt timeout because the OS is still booting!) 

I didn't want to try it directly on my VPS because I am scared to kill it again.

So, if a staff has some free time, can you test it on a actual VPS?
I just installed OpenVZ without any particular settings, I don't know if VPS providers uses magic settings.

[rudra]

This is weird. What makes you think our forum staff have vzctl access on the host nodes?

Also yes. disabling and removing is cool. then just do manual config and save it and it should work. what is so special about it?

setting up automated test and reapply script could work too.

[Mashiro]

Neither the staff nor the VPS owner have access to vzctl because this is a administrative tool that is only available to the hosting provider with access to the physical host node.

So my point stands. If you break the network by installing a network manager (either on purpose or by accident through other packages) and you don't have control panel access: only staff can fix the issue by applying simple commands to either stop, disable or remove the network manager. If you have control panel access you can fix it yourself using the emergency SSH access that is provided in the control panel.

A OpenVZ VPS gets its network adapters configured at boot by the host node settings for that VPS. The network manager starts afterwards and breaks the configuration that was applied by OpenVZ. Therefore the VPS network simply stops working until the network manager is disable or removed. After that you have to reboot the VPS once so that OpenVZ can apply the correct network adapter settings again.

OpenVZ is limited in many regards and network is one part. You can't do much more advanced stuff because the way the OpenVZ networking stack works is too limited to support necessary features and the kernel is simply too old. The other part is a limited firewall where a lot of modules are disable (fortunately a part can be enable by the hosting provider if they feel like it).

[LightDestory]

@rudra @"Hidden Refuge"
Ops, my bad. I wrote all the steps needed starting from OpenVZ deployment because on my investigation I had to start from scratch building up my test environment. I can say that using OpenVZ is REALLY EASY.

The commands "vzctl enter <ID> && passwd root" were need  because after creating and starting the OpenVZ container I couldn't know what password was set by who created the template. I HAD to set a password for the root user to be able to SSH into the newly created machine. But, if you get a OpenVZ-based VPS from POST4VPS or anywhere you will have already the credentials to login via SSH. So these commands can be skipped.

I will rewrite the steps to be more clear and removing the OpenVZ reference.

So my point stands. If you break the network by installing a network manager (either on purpose or by accident through other packages) and you don't have control panel access: only staff can fix the issue by applying simple commands to either stop, disable or remove the network manager. If you have control panel access you can fix it yourself using the emergency SSH access that is provided in the control panel.

This "workaround" prevents you to break network settings, so you will not need to ask to the staff to fix it. NetworkManager will be activated on the next reboot, but if you uninstall it first the problem will never show up.
I have succeed to obtain a VPS surviving the reboot on my testing environment with BASIC OpenVZ settings. It could be nice if some staff could test it on a spare/unused VPS to check if "Enterprise" Settigns are compatible with this "workaround" 

[Mashiro]

After you disable the networkmanager services with systemctl the network manager will not start up after a reboot. Hence why you use "systemctl disable NetworkManager". This systemctl command deletes all links to the autostart of the NetworkManager services. Til today I have never seen or used "systemctl mask" and I guess I will continue not using it. Given that NetworkManager is simply useless and incompatible with OpenVZ VPSs you should just really uninstall it and be done with it.

Is there something I'm missing? All this fuss hassle about a small issues!?!?!?

[deanhills]

This is weird. What makes you think our forum staff have vzctl access on the host nodes?

Also yes. disabling and removing is cool. then just do manual config and save it and it should work. what is so special about it?

setting up automated  test and reapply script could work too.

Maybe it's not special for you @rudra.  Because you're so capable and a specialist.  But for me it's special, and I'm sure many others who are learning, and one day may try VPS 9, and this way they will be prepared.

I totally admire @LightDestory 's efforts and also courage to share his learning with us.  With excellent writing and describing ALL of the steps with no steps missed.  Now that definitely works for me.!  

This way too, he can test the steps, seems to be more than willing to listen to your comment, like someone like @"Hidden Refuge" helping to perfect it. This is the kind of collaborative tutorial that really works for me.

I will rewrite the steps to be more clear and removing the OpenVZ reference.

This "workaround" prevents you to break network settings, so you will not need to ask to the staff to fix it. NetworkManager will be activated on the next reboot, but if you uninstall it first the problem will never show up.
I have succeed to obtain a VPS surviving the reboot on my testing environment with BASIC OpenVZ settings. It could be nice if some staff could test it on a spare/unused VPS to check if "Enterprise" Settigns are compatible with this "workaround"

OK thanks @LightDestory.  This is much appreciated.  I don't have time immediately to do this, but will check one of the unused VPS 9 at a later stage by following your steps.  

Can you just explain to me again why you needed to follow this course of action - like in what situation is there the potential for "breaking network settings"?  Like what were you loading that needed the NetworkManager to be de-activated?  Also potentially what else can be loaded that would need this kind of remedial/preventative action to be implemented?

Wait a minute.  I've just read your OP again - this is something that another member had an issue with too when he wanted a VNC to be created.  "Remote Desktop Access" technologies.  Got it!  And then @"Hidden Refuge" helped the member fix the problem, probably by doing exactly what you suggested in this tutorial on top of installing the VNC.

Another thing we learned however is that once you've got a remote technology established, not to install a panel as well.  There is just so much you can get away with once you've got the remote technology in place.  Don't try to do too many things.  It may seem to work for a while, until it needs to be updated, and it's when it updates, that the fun with conflicts may start and completely break the system.

For me this part has been proven over and over again and @"Hidden Refuge" hits it right on the nail with this:

OpenVZ is limited in many regards and network is one part. You can't do much more advanced stuff because the way the OpenVZ networking stack works is too limited to support necessary features and the kernel is simply too old. The other part is a limited firewall where a lot of modules are disable (fortunately a part can be enable by the hosting provider if they feel like it).

Point I'm making @LightDestory. You may think you have an "aha" moment, like you've solved the issue, but the main problem is the OpenVZ kernel that is dated, and its potential for so many conflicts with applications. You can't get past that. So again one has to keep it simple. Or if you need to experiment more it's much better to get a VPS with a KVM virtualization.

But yes, I'm sure it must also be fun to be able to work your way around something. Well done!

[LightDestory]

After you disable the networkmanager services with systemctl the network manager will not start up after a reboot. Hence why you use "systemctl disable NetworkManager". This systemctl command deletes all links to the autostart of the NetworkManager services. Til today I have never seen or used "systemctl mask" and I guess I will continue not using it. Given that NetworkManager is simply useless and incompatible with OpenVZ VPSs you should just really uninstall it and be done with it.

Is there something I'm missing? All this fuss hassle about a small issues!?!?!?

The main difference between "disable" and "mask" is that:

1. By using "systemctl disable name.service",as you said too, you will delete the symlink located in "ect/systemd/system" that points to the Unit file located in "lib/systemd/system". With this you will prevent the service to be loaded at boot-time. But the unit file is still there and it can be requested and loaded by other services if they need it. If that happens, you are done. You will kill the network settings again.
   
2. By using "systemctl mask name.service" the Unit file will be linked to "dev/null". This makes impossible for the service to be requested and loaded. So you will not risk an inadvertent loading of that service.
   

When I tried to mask the service I got some "systemctl timeout errors". so as you said, I decided to uninstall it.

This small issue caused by mine distraction requested the support of @deanhills because I was basically cut off, I was unable to do anything. Moreover it ended up on reinstalling from scratch the OS. I don't want to create troubles to anyone and when I had to open a support ticket I felt really bad.

So again one has to keep it simple. Or if you need to experiment more it's much better to get a VPS with a KVM virtualization.

I am loving my VPS 9! OpenVZ is the main cons, but its specs rocks!
The only concern is what VirMach will do after November 2019, let's see and hope!

[rudra]

@deanhills
I guess i should have worded it differently. Now that I think about its with your point of view, i understand. yes , i am happy that he is so willing to experiment and learn and we should welcome and encourage it.

Thanks @LightDestory
I also learned about mask from you today. cool