Proxmox & Z Series IBM Servers

severo

New Member
May 17, 2024
2
0
1
Hi everyone!

I have a client who has two servers - Z10 and Z12 System IBM, and he asked me if it would be possible to install our systems currently in operation on this infrastructure, replacing the environment he currently has installed - z/OS IBM. We have been users of Promox for a few years, but within conventional Intel server environments.
In a quick read on the internet, I found references to the use of this environment in Debian, Ubuntu, Red Hat and Suse.
Given that the proxmox environment operates on Debian, would anyone know if it would work? Would the installation process be the same as normal, or would it require some other format or process?

Thank you and I await your response.

LSevero
 
Those are, AFAICT full on mainframe systems with their custom CPU architecture and not based on the x86_64 architecture. So unless I am wrong with that, and they are x86 based, you won't be able to use Proxmox VE on them.
 
  • Like
Reactions: Kingneutron
Proxmox VE, at least for now, is x86_64 only. So I guess that hardware will be useless in that regard.
 
  • Like
Reactions: Kingneutron
Hi everyone!

I have a client who has two servers - Z10 and Z12 System IBM, and he asked me if it would be possible to install our systems currently in operation on this infrastructure, replacing the environment he currently has installed - z/OS IBM. We have been users of Promox for a few years, but within conventional Intel server environments.
In a quick read on the internet, I found references to the use of this environment in Debian, Ubuntu, Red Hat and Suse.
Given that the proxmox environment operates on Debian, would anyone know if it would work? Would the installation process be the same as normal, or would it require some other format or process?

Thank you and I await your response.

LSevero
IBM mainframes typically are built as virtual machine environments by default, essentially data centres in one case. There are two approaches, logical partitions or LPARs, and VMs within an LPAR.

My main interaction with the technology was when the insurance company I worked for would split the system while implementing and testing of new systems, running the input and data in parallel to compare the results and ensure that the new system didn’t break anything. If data needed to go through a conversion process, a third LPAR would be used to test the run and the accuracy, allowing the results to be reviewed and confirmed that it was correct. That was the process when the life insurance management system was upgraded to a combined life and investment system, designed for more modern financial services - everything from the existing system had to be captured and processed the same way in the new system. That usually involved numerous runs and finding what didn’t convert, which resulted in creating more exacting processes until virtually everything was right, and only a handful needed to be manually translated.

Anyhow, today’s mainframes run all manner of different operating systems concurrently through this design, optimised to leverage the massive throughput abilities in the design of these but also dynamically adjust CPUs and memory to support what is thrown at it. Essentially, they were designed to be hypervisor driven systems from the ground up.