Hello to all.
I plan to reinstall my Centos 7 VPS because OpenVZ is not compatible with Alma Linux Elevate migration tool, but unfortunately today the VPS provider said Alma Linux 9 has issues with OpenVZ only Alma Linux 8 works fine. The EOL of RHEL 8 is in 4 years, searching I discovered VZLinux that have a migration tool and is compatible with OpenVZ, the VPS provider does not have VZLinux in his OS images. I am going to try OpenVZ 9, in their web page they say:
Fully free and open-source
Forever fully free and always open source 1:1 Red Hat Enterprise Linux clone developed for and with the Linux community.
Supported as guest OS
Supported as a guest operating system under different hypervisors (Virtuozzo, OpenVZ and KVM) with templates in hyperscaler marketplaces.
Easy upgrades
Ready-to-use conversion utility for simple and on-the-fly conversion from CentOS 8 to VzLinux 8 plus the possibility to convert CentOS 7 directly to VzLinux 8.
Since VZLinux claims “1:1 RHEL clone” can I use Virtualmin and restore the domains via Virtualmin to VZLinux 8?, so later on migrate to VZLinux 9.
The key question is: Will Virtualmin run fine on VZLinux?
Thanks and regards
joejac
If it’s actually RHEL compatible (which is harder to achieve than it used to be), then it should work, though it probably won’t be detected correctly, and you may need to fool the installer into believing it is RHEL or Alma or Rocky. The simplest method for tricking the installer is to change the contents of /etc/redhat-release to match that of the closest supported distribution (probably any of the RHEL rebuilds would work).
Thanks to all for your kind answers.
Since I knew it would be hard, I moved all the first VPS customers to my second VPS server.
I will try in the first server, since all customers are now moved to the second server, following @Steini advice.
Virtuozzo docs are sparse but clear, I like their docs, thanks @Joe for the warning, fortunately, VZLinux has this feature, that probably will make webmin/Virtualmin work:
Steps 1 to 5 were fine. Step 6 is optional and I skip it.
On step 7, in the “upgrade check” it failed with the error: IOError: [Errno 2] No such file or directory: ‘/boot/grub2/grub.cfg’
Following is the command output: # vzupgrade check --skip-vz with the error:
# vzupgrade check --skip-vz
==> Processing phase `configuration_phase`
====> * ipu_workflow_config
IPU workflow config actor
==> Processing phase `FactsCollection`
====> * read_openssh_config
Collect information about the OpenSSH configuration.
====> * root_scanner
Scan the system root directory and produce a message containing
====> * repository_mapping
Produces message containing repository mapping based on provided file.
====> * system_facts
Provides data about many facts from system.
Process Process-112:
Traceback (most recent call last):
File "/usr/lib64/python2.7/multiprocessing/process.py", line 258, in _bootstrap
self.run()
File "/usr/lib64/python2.7/multiprocessing/process.py", line 114, in run
self._target(*self._args, **self._kwargs)
File "/usr/lib/python2.7/site-packages/leapp/repository/actor_definition.py", line 72, in _do_run
actor_instance.run(*args, **kwargs)
File "/usr/lib/python2.7/site-packages/leapp/actors/__init__.py", line 289, in run
self.process(*args)
File "/usr/share/leapp-repository/repositories/system_upgrade/common/actors/systemfacts/actor.py", line 65, in process
bios_grubcfg_details = systemfacts.get_bios_grubcfg_details()
File "/usr/share/leapp-repository/repositories/system_upgrade/common/actors/systemfacts/libraries/systemfacts.py", line 326, in get_bios_grubcfg_details
with open('/boot/grub2/grub.cfg') as fo:
IOError: [Errno 2] No such file or directory: '/boot/grub2/grub.cfg'
=============================================================================================
Actor system_facts unexpectedly terminated with exit code: 1 - Please check the above details
=============================================================================================
============================================================
ERRORS
============================================================
2024-09-25 09:01:22.857386 [ERROR] Actor: repository_mapping
Message: The repository mapping file is invalid: the JSON does not match required schema (wrong field type/value): The value of "mapping" field is None, but this is not allowed
Summary:
Hint: Read documentation at the following link for more information about how to retrieve the valid file: https://access.redhat.com/articles/3664871
============================================================
END OF ERRORS
============================================================
============================================================
UPGRADE INHIBITED
============================================================
Upgrade has been inhibited due to the following problems:
1. Inhibitor: File "/etc/default/grub" does not exist!
Consult the pre-upgrade report for details and possible remediation.
============================================================
UPGRADE INHIBITED
============================================================
Debug output written to /var/log/leapp/leapp-preupgrade.log
============================================================
REPORT
============================================================
A report has been generated at /var/log/leapp/leapp-report.json
A report has been generated at /var/log/leapp/leapp-report.txt
============================================================
END OF REPORT
============================================================
Answerfile has been generated at /var/log/leapp/answerfile
No upgrade blockers found!
I consulted with the VPS provider and this was his response:
I have not tried this particular upgrade method and would also not recommend it. Upgrades are generally problematic in my experience, a clean install is always preferable when it comes to maintaining maximum long-term stability.
He also recommended AlmaLinux 8, not 9 and unfortunately he does not have VZLinux images, which is supposed to be ideal when working with OpenVZ.
I appreciate your valuable opinion, on which would be the ideal solution to this migration, if the above error would be easy to fix or if it is better to reinstall, keeping in mind that the OS will be running in OpenVZ virtualization and has to be compatible with Webmin/Virtualmin.
Took a look at the site. Have you tried this on a test server yet? Just cuz you read something that sounds ‘cool’ and ‘state of the art’ doesn’t mean it’s what you really need.
Thanks, @ID10T I took precautions, and I moved all customers to other VPS. So I can do tests on this server and if something goes wrong I can reinstall an OS, and no customer will be affected. Then, with the new OS, I will move some personal websites to test for a couple of weeks and then move the customers who have the simplest websites. My goal is to install a long-term support OS in this case a good clone of RHEL 9.
Any suggestions are welcomed.
Thanks and regards.
PS. I also have 2 sets of Virtualmin backups of all customers in 2 different locations.
Thanks @Joe I understand, I posted the error in case someone has an idea of the possible solution. In the end, I will try to install AlmaLinux 9 to see if it works fine or not, I do not want to install version 8.
Regards.
.