Have you tried to install Linux on your M* Macs? As fas as I've read, it's still not straight forward as if would be with x86_64.
Proxmox on aarch64 (arm64)
- Thread starter keklick1337
- Start date
Yes, it's very doable via Asahi Linux (Debian 12) or Fedora Asahi Remix.
However, what is more interesting right now is to use an option like Parallels or VMware to run the arm64 version, which is what I'm doing via the fork.
But still not as easy as plugging in a prepared USB key, is it? I don't want to mess with my machine by installing it.
Like I said, tools like Parallels are the current target, especially for using it on newer M4 systems. So yeah, getting Proxmox arm64 non-third-party support is pretty dang important.
Heads up: Proxmox Port has been rebranded to PXVirt, and the repository URL has changed.
Updated instructions here: https://docs.pxvirt.lierfang.com/en/installfromdebian.html
The notice on their Github doesn't inspire much confidence in the project's future... https://github.com/jiangcuo/pxvirt
Could the Proxmox team consider adapting PXVirt into mainline Proxmox, at least for the arm64 support?
Personally I use it just as an LXC management GUI since I don't have much processing power on my ARM servers to run VMs. It works very well though.
Updated instructions here: https://docs.pxvirt.lierfang.com/en/installfromdebian.html
The notice on their Github doesn't inspire much confidence in the project's future... https://github.com/jiangcuo/pxvirt
Could the Proxmox team consider adapting PXVirt into mainline Proxmox, at least for the arm64 support?
Personally I use it just as an LXC management GUI since I don't have much processing power on my ARM servers to run VMs. It works very well though.
yeh a bit sickening that proxmox went after someone helping doing the work they could not be bothered doing
Hi,
The change away from the Proxmox trademark was done much earlier: https://github.com/jiangcuo/pxvirt/commit/55fe0b01a18de6ee7f263108b9a201e42f26490c
AFAIK, there was no legal battle or anything inflicting cost on the project from our company. AFAICS, there was just a request a few months ago to respect the trademark and that was followed. I wouldn't be comfortable working here if the company started suing well-meaning community projects.
please do not put such accusations into the world without checking. Look what the README actually says:
This was changed 2 weeks ago: https://github.com/jiangcuo/pxvirt/commit/747c6f5b9d1d5fbd25e0906ade3baf362060b850
The change away from the Proxmox trademark was done much earlier: https://github.com/jiangcuo/pxvirt/commit/55fe0b01a18de6ee7f263108b9a201e42f26490c
AFAIK, there was no legal battle or anything inflicting cost on the project from our company. AFAICS, there was just a request a few months ago to respect the trademark and that was followed. I wouldn't be comfortable working here if the company started suing well-meaning community projects.
Hi,
unfortunately, I don't think there currently are any plans for officially supporting ARM64 hosts and providing packages for them. We will continue accepting patches that increase compatibility from the community however, e.g.: https://lore.proxmox.com/pve-devel/23ec758b-2f7a-429d-8ae7-916369656f44@proxmox.com/
The new branding is a bit unfortunate. While I was looking at it a coworker walked in on me and asked "How do you pronounce that?" I tried to sound it out and they said "I think it says 'PERVERT'..."...
I was at a loss and just laughed. They said "The X is silent and not pronouncible so my mind says 'pervert' or 'p`virt', which is a very unfortunate and ill chosen name for such a project"...
PLEASE - we IMPLORE YOU - reconsider integration into mainline guys.
I was at a loss and just laughed. They said "The X is silent and not pronouncible so my mind says 'pervert' or 'p`virt', which is a very unfortunate and ill chosen name for such a project"...
PLEASE - we IMPLORE YOU - reconsider integration into mainline guys.
I just bought an orange pi 5 plus 32gb. For a fun project with Proxmox on arm.
How the heck are you guys not supporting or at least encouraging arm compatibility?
Spread like a virus to all the architectures. Let new folks setup labs on cheap raspberry pi's.
It'd make for great school projects even, to get the new generation of IT people working with your products.
How the heck are you guys not supporting or at least encouraging arm compatibility?
Spread like a virus to all the architectures. Let new folks setup labs on cheap raspberry pi's.
It'd make for great school projects even, to get the new generation of IT people working with your products.
That's all there is for Proxmox here ... homelabs .... no income to gain so not worth it commercially. I'd also love it but there is not enough special software for aarch64 that no other architecture has - besides the Mac eco system. It's still a niche market. Powerful aarch64 hardware is not cheaper than x86-64, so only one disadvantage after another.
I am sure we would get at least 2-6 support subscriptions if it supported Mac OS guests (on Apple hardware to keep licenses happy). 5-15% compared to our x86_64 subscriptions. I am sure most companies need at least 5% for mac builders, qa testing, etc... Of course if any arm hardware is better, those numbers could even be reversed in ARM's favor. There are some non apple high end arm server platforms that might even be worth using, but at least for me not without something like proxmox to run on them...
Anyways, there is definitely commercial market. A niche market portion of a huge market can still be large enough to be viable assuming a lot of the code can be reused if cross compiled..
Well how many companys are going to the trouble to provide MacOS X versions of their Software? Here you have your answer.
Sad as it it the costs are propably to high compared to the potential return of investment, otherwise it would have happened already.
Edit: Rephrased for clarity
Last edited:
Uhm... Enormous numbers of companies are providing software for macOS. So much so that I was able to abandon Windows essentially 100% around a decade ago. Very, very easily arguable now that macOS has FAR superior software in every aspect to Windows. The iOS market is also MUCH larger than the Android market when you consider paying customers vs leeches that just slurp down free software.
Sorry, the case is very easy that higher end markets offer much more ROI.
@jlauro is absolutely demonstrably and empirically correct and if you want to start slicing numbers and comparing data - happy to oblige and show you if this is a sincere discussion.
So I went ahead and decided I should followup with you @Johannes S and for any Proxmox devs as well as anyone else who might reference this thread.
Regarding the two main claims here, both of which do not hold when you look at the numbers and where the industry is moving:
1) macOS and iOS aren’t niche; they’re where the paid users live. This actually also translates to the thread about a mobile app for iOS - which I think is very relevant in our discussion here too...:
That’s before any recurring add‑ons (push alerts, on‑call mode, remote console pack, PBS integration). There’s already a third‑party paid iOS PVE app doing fine - market proof that people will pay. Why leave that revenue and product surface to others?
Again, would this translate into profit for an arm64 main product series? I think so and the industry is moving towards ARM64 in the server space, not away. Have you read the news out of China? Why do you think that the Chinese fork exists for this?...
2) “ARM is just homelabs” is outdated:
3) What’s actually hard here (and what isn’t):
TL;DR to the original point:
Regarding the two main claims here, both of which do not hold when you look at the numbers and where the industry is moving:
1) macOS and iOS aren’t niche; they’re where the paid users live. This actually also translates to the thread about a mobile app for iOS - which I think is very relevant in our discussion here too...:
- macOS is a tens‑of‑billions market annually. That alone kills the “nobody ships Mac” premise. Just scan your own stack for things like: Microsoft 365, Adobe CC, JetBrains, Docker, Terraform/CLI stacks, Slack/Zoom/Atlassian, VMware/Parallels, MATLAB, Mathematica, Autodesk, Unity/Unreal, Postgres/MySQL tooling, Cisco/Aruba/Netscout clients, VPNs, MDM, EDR... the list is… industrial.
- Apple Silicon didn’t shrink this; it expanded it. In 2021-2023 most major vendors shipped native arm64 builds for macOS. That’s not what companies do for a “low‑ROI science project.”
- iOS users outspend Android users by a wide margin. Year after year, App Store consumer spend beats Google Play by a lot (industry trackers peg it at roughly ~2x). If you’re going to sell a paid admin app, iOS is the rational first stop... Decision makers are using iOS and this translates into Mac and ARM64 familiarity/adoption for the main product too.
- Enterprise/dev reality: You can dislike it, but a big chunk of engineering orgs mandate Macs for iOS builds and a growing share of dev work. The purchasing centers with budget are heavily Apple these days.
| One‑time price | Net after 30% | 10k buyers | 50k buyers | 100k buyers |
| $ 9.99 | ~$6.99 | ~$ 70k | ~$ 350k | ~$ 699k |
| $14.99 | ~$10.49 | ~$105k | ~$ 525k | ~$1.05M |
That’s before any recurring add‑ons (push alerts, on‑call mode, remote console pack, PBS integration). There’s already a third‑party paid iOS PVE app doing fine - market proof that people will pay. Why leave that revenue and product surface to others?
Again, would this translate into profit for an arm64 main product series? I think so and the industry is moving towards ARM64 in the server space, not away. Have you read the news out of China? Why do you think that the Chinese fork exists for this?...
2) “ARM is just homelabs” is outdated:
- Cloud set the tone. AWS Graviton, Azure Ampere, and GCP T2A aren’t toys. They exist because, for a big class of workloads, ARM delivers 20-40% better price/perf and lower watts per unit of work. That’s why major SaaS, CDNs, and internal platform teams moved real workloads there.
- Ecosystem is done, not “missing.” Debian/Ubuntu/RHEL ship arm64 first‑class. QEMU/KVM on arm64 is mature. LXC/LXD is arm64‑happy. Ceph and OpenZFS build on arm64. Docker/OCI have multi‑arch images; most infra images (NGINX, Postgres, Redis, Kafka, etc.) publish arm64 variants. The “not enough special software” line was true in 2016; it isn’t now.
- On‑prem options exist. Ampere Altra/One boxes from mainstream vendors, edge ARM boxes for telco/retail/industrial, and yes, Raspberry Pi 5s for education and labs. Not every ARM host will be a VM workhorse (RPi is LXC‑centric), but containers are 90% of modern fleet work anyway.
- TCO, not sticker price. Even when capex is similar, opex (power and cooling) eats you. If a node saves ~80-150 W under load and you run a rack for a year, the power bill difference dwarfs any small capex delta.
3) What’s actually hard here (and what isn’t):
- Not hard: Most of PVE’s stack is architecture‑agnostic or already packaged for arm64 in Debian. Build infra, CI, and kernel packaging are the main lifts. LXC, the GUI, corosync, pmg/api pieces - portable.
- Harder but doable: KVM on capable ARM servers (Ampere et al.) - works today. Feature‑testing and tuning are work, not moonshots. Frankly just grab the Chinese fork and use it as a base, no? Most of the work is DONE.
- Out of scope for now: macOS guests under a Linux host on Apple hardware. That’s a licensing and platform boundary. You don’t need it to win or even touch it. Let users think about that if they want to on their own dime. You can still target the Mac‑heavy orgs by:
- Offering first‑class arm64 hosts for their Linux CI/CD, runners, and services alongside their Mac minis, and
- Monetizing an official iOS admin app used by the exact admins who approve subscriptions.
- ARM subscriptions.Even if only a single‑digit percent of the existing paying base adds one ARM node for CI/edge, that’s material. Pick an average subscription of, say, €200 per node‑year:
- 5,000 ARM nodes: ~€1.0M ARR,
- 10,000 ARM nodes: ~€2.0M ARR.
Those are small adoption slices relative to the global PVE footprint.
- Paid iOS app + add‑ons. The conservative one‑time numbers are above. Layer a €9.99/year add‑on for push/on‑call and convert only 20,000 admins: ~€140k net recurring, growing with the base.
- Strategic hedge post‑Broadcom/VMware. The migration wave is real. Offering arm64 now captures schools, labs, SMBs, MSPs, and edge projects choosing between “K8s DIY,” “pay VMware more,” or “Proxmox that runs on what we already have.”
- Phase 1 (public tech‑preview): Official arm64 APT repo; “install on Debian” path; LXC‑first; target Pi 5 (containers) and Ampere servers (VMs). Very clear support policy.
- Phase 2: Certify a short list of ARM servers; enable Ceph+ZFS on those; publish tuned kernels.
- Phase 3: Polish. Heterogeneous clustering guidance (label/schedule by arch), templates, backup/restore across arch (container‑level), and the paid iOS app with push alerts, console, PBS, and 2FA baked in.
Costs stay bounded; upside is asymmetric.
TL;DR to the original point:
- “Few companies ship macOS” → demonstrably false.
- “ARM is homelab only” → was true years ago; not anymore.
- Proxmox gets real, paying users from arm64 hosts and a paid iOS app, with modest incremental engineering compared to the growth and strategic positioning it buys.
I propably shouldn't do this since your text looks like an hallucination from a "bullshit-as-a-service-provider" aka generative AI but still I can't help it, so where we go:
Not for Hypervisors. For them the main targets are NOT home users (whether they use MacOS X or something else) but companys who want to switch their existing hypervisor due to raising costs. Aka: Companys who are not be willing or not able to give Broadcom more money to continue using Vmware. They mostly run amd64 operating systems, especially if they use the system to host commercial "enterprise-grade" (1) software like SAP or windows-only server like an AD controller and special stuff (e.G. Impress Automate as output mangement system and other business software for the Windows/x86 ecosystem)
I might be an exception but I would never want to do maintenance on a small smartphone or tablet screen except in case of an urgent emergency. Non the less: The PVE web interface can be accessed on any mobile system and will be more than enough. : https://pve.proxmox.com/wiki/Proxmox_VE_Mobile
And? They still woudn't use MacOS X as VM host.
But now I think I'm getting where you come from: You want an "official app" for iOS. This is NOT what this thread about but people who want to run ProxmoxVE as operating system on their arm64 hardware (so Raspberry PI or Macintoshs). Both things (an official arm64 ports and an IOS App) have in common that there is quite a limited market compared to the people who are looking for a vmware/esxi alternative.
And if you don't go into the cloud but run on your own hardware you save even more money, even if your on-premise server is x86 based instead of the arm64 aws instance.
We don't talk about Linux here, but stuff in Windows VMs. For them emulation on arm64 is possible but a waste of performance.
You still have more hardware to test.
At least at my place of work subscriptions are not approved by the admins but the bean-counters (aka the people who are (hopefully) good with money and business stragegy not tech. Of course they ask the admins for their input. The last ProxmoxVE case study as a potential Vmware alternative was some years ago when there wasn't a native way to implement snapshots on dedicated storage hardware (SANs) in a clustered setup. That killed the idea of migrating for us at that time. This was before the Broadcome take over of Vmware though and PVE9 introduced snapshots on LVM/thick so a new case study might have a different outcome today. To be fair there are still other things to consider which might block a migration, but the changed circumstances (snapshot support plus raising costs) still will help Proxmox Server Solutions to more revenue than any investment in an IOS app.
Do you happen to have any numbers on the global PVE footprint? As far I'm aware of that's a business secret by Proxmox Server Solutions GmbH. I might be wrong though.
You claim this, you don't actually proove this.
(1) "enterprise-grade" is jargon for: You pay more for less and completely depend on manufacturer support, but then it's the manufacturer's fault and not your own incompetence.
Not for Hypervisors. For them the main targets are NOT home users (whether they use MacOS X or something else) but companys who want to switch their existing hypervisor due to raising costs. Aka: Companys who are not be willing or not able to give Broadcom more money to continue using Vmware. They mostly run amd64 operating systems, especially if they use the system to host commercial "enterprise-grade" (1) software like SAP or windows-only server like an AD controller and special stuff (e.G. Impress Automate as output mangement system and other business software for the Windows/x86 ecosystem)
I might be an exception but I would never want to do maintenance on a small smartphone or tablet screen except in case of an urgent emergency. Non the less: The PVE web interface can be accessed on any mobile system and will be more than enough. : https://pve.proxmox.com/wiki/Proxmox_VE_Mobile
Desktop software like Adobe CC, MS 365, Unreal etc etc isn't relevant since you wouldn't usually use ProxmoxVE on your Linux notebook (irtualbox or virt-manager if I ever need a vm on my notebook) together with gimp, chrome, openoffice or your desktop. The exception of course if you happen to be a Proxmox developer. VMWare/Parallels is for desktop virtualization for which we have (as said) virt-manager or Virtualbox. I doubt that somebody who mainly uses his Mac as his personal workstation would need a server hypervisor and would be willing to pay for it. Docker, My/PostgreSQL etc are also mainly used by developers if they are not on a server. With other words: Your examples have a quite different target audience than a server hypervisor.
And? They still woudn't use MacOS X as VM host.
But now I think I'm getting where you come from: You want an "official app" for iOS. This is NOT what this thread about but people who want to run ProxmoxVE as operating system on their arm64 hardware (so Raspberry PI or Macintoshs). Both things (an official arm64 ports and an IOS App) have in common that there is quite a limited market compared to the people who are looking for a vmware/esxi alternative.
And if you don't go into the cloud but run on your own hardware you save even more money, even if your on-premise server is x86 based instead of the arm64 aws instance.
We don't talk about Linux here, but stuff in Windows VMs. For them emulation on arm64 is possible but a waste of performance.
You still have more hardware to test.
At least at my place of work subscriptions are not approved by the admins but the bean-counters (aka the people who are (hopefully) good with money and business stragegy not tech. Of course they ask the admins for their input. The last ProxmoxVE case study as a potential Vmware alternative was some years ago when there wasn't a native way to implement snapshots on dedicated storage hardware (SANs) in a clustered setup. That killed the idea of migrating for us at that time. This was before the Broadcome take over of Vmware though and PVE9 introduced snapshots on LVM/thick so a new case study might have a different outcome today. To be fair there are still other things to consider which might block a migration, but the changed circumstances (snapshot support plus raising costs) still will help Proxmox Server Solutions to more revenue than any investment in an IOS app.
Do you happen to have any numbers on the global PVE footprint? As far I'm aware of that's a business secret by Proxmox Server Solutions GmbH. I might be wrong though.
You claim this, you don't actually proove this.
And this is the stuff, which would actually need effort from a still quite small team. I'm not convinced that this will get a better ROI compared to implement features enterprise customers are missing from VMWare and are willing to pay for.
(1) "enterprise-grade" is jargon for: You pay more for less and completely depend on manufacturer support, but then it's the manufacturer's fault and not your own incompetence.
Last edited:
Got it. So you go and start ad hominem attacks right off the bat to try to humiliate and minimize my authority so your remarks will stand out more... Pretty shitty move guy. Really does make me wonder why I even try on this forum because the bias towards killing its own product sometimes seems just so strong wrt how some folks seem to really have a skewed view of reality.
I don't really feel like trying anymore with the formatting or making things look nice anymore at this point since you are making this absurd accusations and BS grandstanding.
1. “Not for hypervisors. Enterprise wants amd64, Windows, SAP, AD.”
- No one said “replace x86.” Add ARM. That's it. Keep Windows VMs on x86 nodes (or let ppl run arm64 Windoze), run Linux services, CI, runners, and edge on ARM. Mixed fleets are normal. If you think every VMware migration is 100% Windows VMs, you’re living in one shop, not the market.
2. “I wouldn’t maintain from a phone. The web UI is enough.”
- Good for you. I do too - BUT I like to use my phone more than you might think when I'm in a pinch. I use a paid iOS app right now. Lol. On‑call people buy tools that shorten MTTR. Push alerts and other stuff does matter.
3. “Adobe/JetBrains/etc. aren’t relevant to a server hypervisor.”
- Oh give me a break. You clearly didn't get WHY I shared these. They are relevant to ROI on Mac. Those vendors ship native macOS/arm64 because the paid user base is large. That kills the ridiculous “nobody ships Mac” angle, which was the claim I answered.
4. “They wouldn’t use macOS as a VM host.”
- Maybe you're right here and I don't entirely disagree, but I actually do for some things. I actually run the Chinese fork. But no, I wasn’t proposing that. ARM hosts != macOS hosts. Think Ampere, not Mac minis, but do let macOS users do it if they want - it's a natural extension, especially for those who see some value and want to fiddle in this space.
5. “ARM+iOS app is a limited market compared to ESXi replacement.”
- No. False choice here. This isn’t either/or. ARM support and an official iOS app are additive revenue lines and pull in users who then buy the core subscriptions. You must not have much experience in marketing, right?
6. “On‑prem x86 is cheaper than AWS ARM.”
- Straw man rampage. The point was ARM vs x86 at the SAME location. Lower watts per unit of work is where ARM prints money. Example math: save 150 W at the wall per node, PUE 1.3, $0.12/kWh → about $205/node‑year. 500 nodes is ~$100k/year. That is why finance listens. (and yeah, I can use arrows like that because I'm on macOS and type with some autocompletion that can convert -> to → for me, so no, not evidence of "generative AI")
7. “We talk about Windows VMs. Emulation on arm64 is wasted perf.”
- Which is why you run Windows on x86 nodes. I'm using Windows arm64 more and more... BTW. Labels/constraints pin workloads to arch. You can use ARM wherever you want (Linux guests, containers, appliances - and yeah, even Winbloze). This is not complicated.
8. “You still have more hardware to test.”
- Obviously. Start with a tiny HCL - or even none at all and say it's “not supported” at first. Or do a couple of Ampere systems for KVM and a Pi 5 line for LXC/education. Expand clause if telemetry shows demand. That’s how support matrices are born... Derp.
9. “Bean‑counters decide. Snapshots used to block us. Enterprise features > iOS app.”
- Bean‑counters decide on TCO. Lower power plus subscription deltas is TCO. Also, an iOS app is a SMALL, ring‑fenced product with clear revenue and marketing upside (MARKETING being key; it's used to rope ppl in - STUPID to ignore.). It does not block hypervisor features unless you choose to make it block.
10. “Do you have global PVE footprint numbers?”
- I modeled sensitivity, not secrets. Ask the Proxmox guys for that. Multiply the table by whatever base you believe. Even a small ARM adoption is seven‑figure ARR. That’s the point. If you think it's smaller then I guess Proxmox has more problems than we can discuss here and I'm looking for another effing hypervisor stack... buhbye PVE.
11. “You claim a migration wave; you don’t prove it.”
- We all watched Broadcom change terms and pricing. This forum has migration threads. There's other discussions elsewhere. Call it “directional” if that soothes you. Again, if I'm wrong - we better be going to Xen or something else my guy and we're all stupid being here right now.
12. “Phase 3 polish and the iOS app would eat the small team.”
- Labels/scheduling already exist. Cross‑arch backup/restore at the container level is documentation and guardrails, not a science project. A solid, paid iOS app is 1-2 engineers for a few months plus maintenance. That's no death march. Heck, one guy can build it (I could do it myself and have contemplated it).
Look, if you’ve got counter‑numbers and there's data I'm missing, post them. If this is just a shouting match and name‑calling, I'm out. I'm not interested in participating in some BS that has brick walls for brains trying to damn the community and product.
I don't really feel like trying anymore with the formatting or making things look nice anymore at this point since you are making this absurd accusations and BS grandstanding.
1. “Not for hypervisors. Enterprise wants amd64, Windows, SAP, AD.”
- No one said “replace x86.” Add ARM. That's it. Keep Windows VMs on x86 nodes (or let ppl run arm64 Windoze), run Linux services, CI, runners, and edge on ARM. Mixed fleets are normal. If you think every VMware migration is 100% Windows VMs, you’re living in one shop, not the market.
2. “I wouldn’t maintain from a phone. The web UI is enough.”
- Good for you. I do too - BUT I like to use my phone more than you might think when I'm in a pinch. I use a paid iOS app right now. Lol. On‑call people buy tools that shorten MTTR. Push alerts and other stuff does matter.
3. “Adobe/JetBrains/etc. aren’t relevant to a server hypervisor.”
- Oh give me a break. You clearly didn't get WHY I shared these. They are relevant to ROI on Mac. Those vendors ship native macOS/arm64 because the paid user base is large. That kills the ridiculous “nobody ships Mac” angle, which was the claim I answered.
4. “They wouldn’t use macOS as a VM host.”
- Maybe you're right here and I don't entirely disagree, but I actually do for some things. I actually run the Chinese fork. But no, I wasn’t proposing that. ARM hosts != macOS hosts. Think Ampere, not Mac minis, but do let macOS users do it if they want - it's a natural extension, especially for those who see some value and want to fiddle in this space.
5. “ARM+iOS app is a limited market compared to ESXi replacement.”
- No. False choice here. This isn’t either/or. ARM support and an official iOS app are additive revenue lines and pull in users who then buy the core subscriptions. You must not have much experience in marketing, right?
6. “On‑prem x86 is cheaper than AWS ARM.”
- Straw man rampage. The point was ARM vs x86 at the SAME location. Lower watts per unit of work is where ARM prints money. Example math: save 150 W at the wall per node, PUE 1.3, $0.12/kWh → about $205/node‑year. 500 nodes is ~$100k/year. That is why finance listens. (and yeah, I can use arrows like that because I'm on macOS and type with some autocompletion that can convert -> to → for me, so no, not evidence of "generative AI")
7. “We talk about Windows VMs. Emulation on arm64 is wasted perf.”
- Which is why you run Windows on x86 nodes. I'm using Windows arm64 more and more... BTW. Labels/constraints pin workloads to arch. You can use ARM wherever you want (Linux guests, containers, appliances - and yeah, even Winbloze). This is not complicated.
8. “You still have more hardware to test.”
- Obviously. Start with a tiny HCL - or even none at all and say it's “not supported” at first. Or do a couple of Ampere systems for KVM and a Pi 5 line for LXC/education. Expand clause if telemetry shows demand. That’s how support matrices are born... Derp.
9. “Bean‑counters decide. Snapshots used to block us. Enterprise features > iOS app.”
- Bean‑counters decide on TCO. Lower power plus subscription deltas is TCO. Also, an iOS app is a SMALL, ring‑fenced product with clear revenue and marketing upside (MARKETING being key; it's used to rope ppl in - STUPID to ignore.). It does not block hypervisor features unless you choose to make it block.
10. “Do you have global PVE footprint numbers?”
- I modeled sensitivity, not secrets. Ask the Proxmox guys for that. Multiply the table by whatever base you believe. Even a small ARM adoption is seven‑figure ARR. That’s the point. If you think it's smaller then I guess Proxmox has more problems than we can discuss here and I'm looking for another effing hypervisor stack... buhbye PVE.
11. “You claim a migration wave; you don’t prove it.”
- We all watched Broadcom change terms and pricing. This forum has migration threads. There's other discussions elsewhere. Call it “directional” if that soothes you. Again, if I'm wrong - we better be going to Xen or something else my guy and we're all stupid being here right now.
12. “Phase 3 polish and the iOS app would eat the small team.”
- Labels/scheduling already exist. Cross‑arch backup/restore at the container level is documentation and guardrails, not a science project. A solid, paid iOS app is 1-2 engineers for a few months plus maintenance. That's no death march. Heck, one guy can build it (I could do it myself and have contemplated it).
Look, if you’ve got counter‑numbers and there's data I'm missing, post them. If this is just a shouting match and name‑calling, I'm out. I'm not interested in participating in some BS that has brick walls for brains trying to damn the community and product.