[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!