-
Notifications
You must be signed in to change notification settings - Fork 55
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
config: start building hyperv image for aarch64 #923
Conversation
Follow-up to coreos/fedora-coreos-tracker#1411 Signed-off-by: Jason T. Greene <[email protected]>
PTAL @dustymabe any guidance/redirection on process appreciated! |
LGTM, never even crossed my mind |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. Will let @dustymabe review as well in case he has more context.
@n1hility - I'm good to merge this as soon as someone can confirm they've built one and verified it works on an aarch64 windows machine. |
@dustymabe cool just to confirm you need a second person to verify? (I did test a build and binary on a windows arm device, if you need just one). The challenge is these are only available as physical metal devices atm (mostly consumer), no cloud hosting providers support it (e.g. ec2 bare metal instances do not allow you to provision windows, and azure ampere instances do not support virtualization). That said, I do know someone else on another team who has win arm hardware I could call in a favor for. |
@n1hility just one is enough. I assumed you hadn't done a local build+test but now I see you did:
Though:
I wonder if this is evidence that would argue against us doing this. Seems kind of niche? Do we know a group of users we are trying to target here? Is this podman-machine related? |
Yeah it's a good consideration. Originally there was an exclusivity agreement for Windows on ARM, where its use was largely limited to surface pro consumer devices. That issue plus ARM hardware's nested virtualization capabilities on the hardware side are fairly recent and software support is still WIP (last I checked feat_nv2 support in linux kernel was not yet merged in mainline), which limits hyperscaler support. Finally, Win mainline support only really occurred with Win 11 (there was a special Win 10 variant before that). With the rising popularity of ARM devices for laptops I expect this segment is going to continue to grow in the overall size of Windows users. The x86 _64 win user space process emulation (similar to what Apple did with Rosetta) is very good, so limited friction for business/corporate users (although of course that line ends at virt where we need an aarch64 Linux kernel) The main use case we are thinking of is podman machine Windows users who use an ARM device. A secondary user use case we have seen a lot of interest is developer teams which have Windows usage/requirements but are developing Linux services that target ARM hardware, and wish to do so without a cross-compile toolchain (e.g. edge scenarios in telco, auto, etc). |
I guess let's just get it in and see what happens. |
awesome thanks! |
@n1hility can you give the latest |
Sweet. will check it out and get back to you |
Follow-up to coreos/fedora-coreos-tracker#1411
I am not familiar with your process, so let me know what I should be following. If you think there should be a new issue for this, for example. So far after this I am planning to follow up with additional PRs for the web content.
I tested and verified this works locally on Windows ARM using cost build and cosa buildextend-hyperv.
Thanks!