New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
I am going to assume it's Linux but should be fine either way.
Do you specifically need to convert your KVM to OpenVZ?
Or, could you /mnt/custom and pull what you want/need over to a fresh OS install on the OpenVZ?
I haven't used OpenVZ in a long time, but I expect that other than kernel is should be fine as Open VZ7 works with the 4.9 kernels.
I usually maintain a separate
bootpartition so I expect that after OpenVZ boots its kernel it should be able to run my/partition. I am not quite sure of how it works in OpenVZ.vz7 "shows" a 4.9 kernel, it does not use one.
I guess that it uses a 3.10 kernel?
Copying
/should work ok - vz containers inherit the hosts kernel but as long as it's supported by the installed OS you should be good (assuming no extra kernel modules/similar).Yes, but also keep in mind that is a 3.10 vz kernel which is not the same as a regular 3.10 kernel much in the same way the 2.32 vz kernel from vz6 is not really a 2.32 kernel, it is so heavily backported it is probably more up to date than a regular 3.10 kernel now in many ways.
Its confusing, I am glad vz7 has started showing distro specific kernel levels but in reality your kernel version shown in a container is nothing more than the read of a config file on the host node for vz7, I could put you on an version I want really its simply to stop packages complaining about the kernel version when in reality all it has checked is the version number and not the extended functionality.
My inclination would be to first set up an OS on OpenVZ7 and then to copy over what you need from the KVM. Otherwise I would expect trouble.
I guess that you always do an experiment first to see whether it would work.
I'm sure /proc disagrees.
Also, your networking will get messed up and need to be fixed up, so better have a console for if/when network breaks.
Lastly, permission issues. Watch out for that.
It's easier to get a list of installed apps and save to txt file, then install on new machine. Then, you probably really only have unique config for a few apps and firewall, better to do manually.
It's pretty annoying because it's hard to know which kernel features are actually available. One might assume a newer feature is available just due to the version that's displayed, but in reality it's not available.
Yeah, that's true. Once I tried to install something that required kernel 3.10 and I didn't have it, I disabled the kernel check, but installation failed anyway. Because that's exactly it, if your kernel is just being displayed higher (so the application won't complain) but actually isn't, the application might not work. That's usually why kernel requirements are there in the first place.
You may try to use rsync to replicate from KVM VPS to OpenVZ7 Containers.
Do note that your OpenVZ7 Containers should have the same version of Linux, ie Debian 9 KVM VPS and Debian 9 OpenVZ 7 Template.
The reason is that some control panel such as SolusVM will recreate the Network configuration files when it boot up the OVZ7 Containers, if your current container runs CentOS 7 and you rsync a Debian 9 source, it may fail to create the necessary configuration file and networking may be broken.
For Debian 10, I tried on Cam's newest OVZ7 NAT Node.
It works, but some tweak is necessary such as nftable and iptables. For Debian 10, it uses nftable by default and you need to update-alternatives to switch from nftable to iptables so that it is backward compatible with OpenVZ 7 shared kernel module.
Most importantly is to audit your current kernel module that your application required to run, OpenVZ 7 is userspace containers so specialize kernel module may not be able to be loaded and therefore, it can break stuff.