Intel/64 CentOS VM Running On A Mac M1?

Home » CentOS » Intel/64 CentOS VM Running On A Mac M1?
CentOS 14 Comments

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.

Calling around, I actually got ahold of a sales staff at Parallels who assured me (in broken India-accent English) that “of course all OS will supported when the trial complete” but given that I wasn’t sure that he really understood my question I remain uncertain.

Anybody here have any more information than I do?

14 thoughts on - Intel/64 CentOS VM Running On A Mac M1?

  • Take what I’ll say with a grain of salt. Virtualization solution became fast the moment “on the fly” conversion of guest system calls to host system calls was invented. The first I know of is Cygnus solutions who did it in their cygwin (company was bought by RedHat, and cygwin still exists and still is open source project). This all implies the system of the same architecture on guest system as is of the host system. Otherwise, one has to emulate different architecture CPU, which will make virtualization an order of magnitude slower. That (emulating generic CPU) was what VMware was doing originally. Then parallels desktop emerged and was (without mentioning it) using what Cygwin did. One can not know that about proprietary software, but give better guess than mine, please. And later VMware went same way, and became really fast virtualization solution too.

    Bottom line: guest and host systems should have the same architecture for guest system to be able to talk [semi-] directly to CPU for decently fast virtualization. So, the answer I would give: NO, one can not have guest system of different architecture as it is with decent speed.

    Just my $0.02

    Valeri

  • You need a virtualization solution that is supported on the M1 (currently Parallels preview or QEMU as far as I know). Secondly you need a distribution that supports aarch64 (Ubuntu, CentOS and some others). This should be sufficient to start with. However, all of this is in an early development stage, so several things might not work (e.g. the Parallel Tools are not available for aarch64 right now).

    Kind regards Thomas

  • If you need Intel VMs, there’s no way around Intel hardware at the moment. Especially, if performance matters.

    I would wait until 11th generation Intel CPUs or even better AMD Ryzen are available for Dell’s mobile workstation-line (if you want to stay in that product-line, which is not the worst thing to do).

    Apple’s M1 are (probably) great – but only if you want to run macOS on it. Anything else and the compromises will likely be even more severe than those that had to be made in the earliest days of running Linux on a laptop.

    Personally, I would also consider the Lenovo E15 (AMD Ryzen), it mostly seems to work with Ubuntu, which means you would likely have to use Fedora for the time being.

  • Did you try it or is this just a guess? I use Ubuntu in a VM on the M1. As I mentioned there are currently some restrictions but the direction already looks quite promising. At least far away from any earliest days …

    Kind regards Thomas
    —
    Linux … enjoy the ride!

  • It’s an assumption.

    If it works, that’s great. I use a 2018 MacMini (with 32GB RAM) and run VMs on it.

    I do like macOS, I just wouldn’t want to run a server on it ;-)

    The 16GB RAM limit would be a show-stopper for me.

    Unfortunately, Apple don’t have Fusion or Parallels or VirtualBox installed on their demo-units.

  • Most likely you’re running an Ubuntu arch build then?

    The IP wanted “support IA64 based OS’s and it *needs* to be an exact (VM)
    copy of production” which most likely means “x86_64” code (not really IA64
    which is Itanium, isn’t it?).

    Simon

  • Yep, it’s the Ubuntu aarch64 build. I haven’t the time yet to try other builds as well. I just got the M1, but if I find some time I will also do some tests with other distributions.

    I have no clue if this was a typo or really the intention, only the IP can tell. My understanding was that the VMs are used for development. The compilation could be performed cross platform, the only restriction would be you can’t test it locally, but with IA64 this wasn’t possible before.

    Kind regards Thomas

  • 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.

  • Hello,

    The Apple M1 is an ARM-based chip, which is a completely different architecture from x86_64/amd64 (Intel 64) and IA64 (Itanium). Run “uname
    -m” on one of your production servers to confirm which architecture that you are targeting. You can use qemu to emulate VMs for different architectures, but it will be slower than normal VM’s where the guest and the host run the same architecture.

    I would be surprised if Parallels and other non-qemu VM platforms supported running a x86_64 guest on an Apple M1 chip. Even so, there might be some hiccups. I would recommend looking at regular PC (non-Apple) laptops to ensure the best compatibility for your use case.

    If your servers are truly Itanium, then I don’t know what to recommend.

    Sincerely, Jason
    ————————————————————————-

  • Exactly right – I think 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.

  • 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.

  • 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.

    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.