Skip to content
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

Merged
merged 1 commit into from
Nov 14, 2023

Conversation

n1hility
Copy link
Contributor

@n1hility n1hility commented Nov 8, 2023

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!

@n1hility
Copy link
Contributor Author

n1hility commented Nov 8, 2023

PTAL @dustymabe any guidance/redirection on process appreciated!

@baude
Copy link
Contributor

baude commented Nov 8, 2023

LGTM, never even crossed my mind

Copy link
Member

@jlebon jlebon left a 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.

@dustymabe
Copy link
Member

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

@n1hility
Copy link
Contributor Author

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

@dustymabe
Copy link
Member

dustymabe commented Nov 14, 2023

@n1hility just one is enough. I assumed you hadn't done a local build+test but now I see you did:

I tested and verified this works locally on Windows ARM using cost build and cosa buildextend-hyperv.

Though:

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.

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?

@n1hility
Copy link
Contributor Author

@n1hility just one is enough. I assumed you hadn't done a local build+test but now I see you did:

I tested and verified this works locally on Windows ARM using cost build and cosa buildextend-hyperv.

Though:

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.

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

@dustymabe
Copy link
Member

I guess let's just get it in and see what happens.

@dustymabe dustymabe merged commit d3bc79d into coreos:main Nov 14, 2023
2 checks passed
@n1hility
Copy link
Contributor Author

awesome thanks!

@dustymabe
Copy link
Member

@n1hility can you give the latest testing-devel hyperV aarch64 image a spin? download from: https://builds.coreos.fedoraproject.org/browser?stream=testing-devel&arch=aarch64

@n1hility
Copy link
Contributor Author

Sweet. will check it out and get back to you

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants