CentOS - Feb 2021 - Intel/64 CentOS VM running on a Mac M1?

On Thu, 28 Jan 2021 at 20:12, Lists <lists at benjamindsmith.com> wrote:
> My Dell Precision M3800 running Fedora works great but is really starting
> to
> show its age, and I'm thinking about getting a new Mac M1-based laptop
as
> it
> would really be useful for Video production.
>
> But I really need to have a IA64 CentOS 7/8 VMs running locally for
> development as I'm often on the road and flaky Internet makes it a
> necessity to
> keep productivity up. I've been unable to officially confirm that
VMWare/
> Parallels/VirtualBox intend to support IA64 based OS's and it *needs*
to
> be an
> exact (VM) copy of production so I can trial environments and builds prior
> to
> roll out.
>
>
1. The Apple M1 uses a variant of the aarch64 (ARM 64 bit) CPU, and the
hardware architecture is different from aarch64 server class hardware in
multiple ways.
2. Currently the work to get Linux to run on the M1 works great in
emulation and somewhat with a lot of work in native mode.
3. IA64 is the Itanium server which Intel stopped making a while ago and
Red Hat quit supporting in 2017.
4. x86_64 (or amd64 ) is the native processor name for the Intel/AMD 64 bit
architecture. It is what your older system runs.
5. The only way to run x86_64 on an M1 is via 'double' emulation. First
you
would have to run a virtual machine on the M1 and that virtual machine
would have to emulate the x86_64. It would be extremely slow, inefficient
and probably could not emulate all the hardware needed.

If you are needing to update your hardware, you need to keep Linux running
native on the system, and that system needs to be x86_64, you will either
need to get an earlier generation Mac or a current system from Dell, HP,
ASUS, etc.


-- 
Stephen J Smoogen.

On Friday, January 29, 2021 6:30:33 AM PST Stephen John Smoogen
wrote:
> On Thu, 28 Jan 2021 at 20:12, Lists <lists at benjamindsmith.com>
wrote:
> > My Dell Precision M3800 running Fedora works great but is really
starting
> > to
> > show its age, and I'm thinking about getting a new Mac M1-based
laptop as
> > it
> > would really be useful for Video production.
> > 
> > But I really need to have a IA64 CentOS 7/8 VMs running locally for
> > development as I'm often on the road and flaky Internet makes it a
> > necessity to
> > keep productivity up. I've been unable to officially confirm that
VMWare/
> > Parallels/VirtualBox intend to support IA64 based OS's and it
*needs* to
> > be an
> > exact (VM) copy of production so I can trial environments and builds
prior
> > to
> > roll out.
> 
> 1. The Apple M1 uses a variant of the aarch64 (ARM 64 bit) CPU, and the
> hardware architecture is different from aarch64 server class hardware in
> multiple ways.
> 2. Currently the work to get Linux to run on the M1 works great in
> emulation and somewhat with a lot of work in native mode.
> 3. IA64 is the Itanium server which Intel stopped making a while ago and
> Red Hat quit supporting in 2017.
> 4. x86_64 (or amd64 ) is the native processor name for the Intel/AMD 64 bit
> architecture. It is what your older system runs.
> 5. The only way to run x86_64 on an M1 is via 'double' emulation.
First you
> would have to run a virtual machine on the M1 and that virtual machine
> would have to emulate the x86_64. It would be extremely slow, inefficient
> and probably could not emulate all the hardware needed.
> 
> If you are needing to update your hardware, you need to keep Linux running
> native on the system, and that system needs to be x86_64, you will either
> need to get an earlier generation Mac or a current system from Dell, HP,
> ASUS, etc.
You are correct that I don't mean Itanium, but really x86_64 binary 
compatibility. I had the impression that MacOS' Rosetta II might do what I 
need but it seems that it's a sort of precompiler for x86 OSX apps and thus 
would be entirely infeasible for my needs. 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part.
URL:
<http://lists.centos.org/pipermail/centos/attachments/20210203/c1f38e70/attachment-0005.sig>

On Feb 3, 2021, at 5:28 PM, Lists <lists at benjamindsmith.com>
wrote:
> 
> I had the impression that MacOS' Rosetta II might do what I need
That?s rather difficult when the x86 code in question is on the other side of a
virtualized CPU.  It?s a double translation, you see: real x86 code run on a
virtual x86 CPU under your CPU?s virtualization extensions (e.g. Intel VT-x)
under an Apple M1 ARM64 variant.

That?s not an impossible dance to pull off, but you?ll need three parties
coordinating the dance steps if you want a high-fidelity CentOS-on-bare-metal
emulation: Intel, Apple, and your VM technology provider of choice.

If you?re willing to drop one of those three parties out of the equation, you
have alternatives:

1. Full CPU simulation, as with QEMU.  This should be able to run x86_64 CentOS
on an M1, but it?ll be like the bad old days of software virtualization, back
around 2000, where every instruction inside the VM had to be translated into
native instructions.

2. Cross-compilation to x86 code under macOS, which allows Rosetta II to take
effect, but now you aren?t running under CentOS proper any more.  Even if you
port over the whole userland you depend on, you?ve still got the macOS kernel
under your app, which may differ in significant areas that matter.
> I need to have access to a VM that's binary-compatible 
> with production so that I can make sure it "really really works"
before
> pushing stuff out. 
If ?really really works? is defined in terms of automated testing ? and if not,
why not? ? then it sounds like you want a CI system, though probably not a CI/CD
system, if I read your intent properly.

That is, you build and test on macOS with ARM code, commit your changes to
whatever release repository you maintain now, the CI system picks that up, tries
to build it, runs the tests, and notifies you if anything fails.  The resulting
binary packages can then be manually pushed to deployment.

(It?s that last difference that makes this something other than CI/CD.)

Making your code work across CPU types is more work, but it can point out hidden
assumptions that are better off excised.

For instance, this line of C code has a data race in a multithreaded
application:

     ++i;

?even though it compiles to a single Intel CPU instruction, even when ?i? is
guaranteed to be stored in a register!

Whether it bites you on Intel gets you way down into niggly implementation
details, but it?s *statistically guaranteed* to bite you on ARM due to its RISC
nature, because it?s an explicit load-modify-store sequence requiring 3 or 4 CPU
instructions, and that few only if you don?t add write barriers to fix the
problem.