Apple M1 support (Ubuntu 20.04, Parallels)

[jnoxon]

Signed-off-by: Jeff Noxon jeff@noxon.cc

This PR adds support for Ubuntu 20.04 on Apple M1 using Parallels

Description

Note that Parallels version 17.0.1 (51482) has a bug where performance falls off a cliff after an ISO is ejected. A simple boot will take over 5 minutes with a detached CD-ROM. This affects building this box. The only workaround I am aware of is to immediately reconnect the ISO to the CD-ROM device after the installer ejects it.

When using this image with Vagrant, v.customize ["set", :id, "--device-del", "cdrom0" ] may be useful, as well.

Related Issue

#1344

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Chore (non-breaking change that does not add functionality or fix an issue)

Checklist:

• I have read the CONTRIBUTING document.
• I have run the pre-merge tests locally and they pass.
• I have updated the documentation accordingly.
• I have added tests to cover my changes.
• All new and existing tests passed.
• All commits have been signed-off for the Developer Certificate of Origin.

[jnoxon]

To test drive the box: https://app.vagrantup.com/jeffnoxon/boxes/ubuntu-20.04-arm64

[jyscao]

Just confirming that @jnoxon's box works great on my M1 Mac Air.

[tas50]

Very interesting. If someone wanted to cut arm64 boxes for other OS releases that would be greatly appreaciated

[gndk]

@tas50 The new box works great on M1, but right now we have to switch between jeffnoxon/ubuntu-20.04-arm64 and bento/ubuntu-20.04 in our Vagrantfile depending on the used architecture of the dev.

Any chance you could publish this new bento/ubuntu-20.04 box for the parallels provider on Vagrant Cloud, too? It seems like there is only vmware_desktop available for this version right now.

Thanks in advance!

[tomjn]

@tas50 is there a blocker preventing the shipping of this functionality that we can't see from here? I'd like to help as would others but it's unclear what the next action that needs taking is and who is able to take it

[swalkinshaw]

👋 apologies for the bump, but a lot of people would be very thankful if you could update the official boxes on Vagrant Cloud. The Parallels one still hasn't been published.

[thbar]

I believe this is still relevant? People are relying on https://app.vagrantup.com/jeffnoxon/boxes/ubuntu-20.04-arm64 but the box has not been updated in 6 months (for good reasons! And thanks @jnoxon for sharing it). Pretty happy to go back the official boxes as soon as possible.

How can we help?

[jnoxon]

@thbar thanks for the kind words! Your comments made me want to update the box. I upgraded Parallels, installed the SDK, and Packer says I don't have the SDK installed:

Failed creating Parallels driver: Parallels Virtualization SDK is not installed

I tried using dtruss to figure out what it was unhappy about. I couldn't figure that out either, it just shows one useless line of output.

I forgot what a pain it was to get this working the first time.

[jnoxon]

I tried a bunch of crazy stuff to make the Parallels SDK work with the provider. It's pretty clear the SDK requires Python 2.7 or 3.7, but Monterey ships 3.9. Homebrew doesn't ship 3.7. The SDK is closed-source, and when I try to force things by putting the prlsdkapi stuff in one of my Python import paths and run /usr/bin/python3 -c 'import prlsdkapi' (which is what the provider does), it just exits with a 0 exit code.

I'm not a Python guy, so I'm not sure what to try next.

[jyscao]

@jnoxon if you require a specific version of Python in order to build the image, then you should be able to use one of the various package/environment managers used by the Python community, such as venv, virtualenv, pyenv, etc. I believe venv is now part of the Python standard library.

I personally use conda. I'm willing to also jump in and help you in trying to get this working if you like, just lmk.

[svpernova09]

I tried a bunch of crazy stuff to make the Parallels SDK work with the provider. It's pretty clear the SDK requires Python 2.7 or 3.7, but Monterey ships 3.9. Homebrew doesn't ship 3.7. The SDK is closed-source, and when I try to force things by putting the prlsdkapi stuff in one of my Python import paths and run /usr/bin/python3 -c 'import prlsdkapi' (which is what the provider does), it just exits with a 0 exit code.

I'm not a Python guy, so I'm not sure what to try next.

I've posted a thread about the SDK issue https://forum.parallels.com/threads/failed-creating-parallels-driver-parallels-virtualization-sdk-is-not-installed.357040/ (it's currently not public, awaiting moderation) I do know a thing or two about Python and tried some trickery and ended up in the same place as you and @jyscao did. Google doesn't seem to help either.

[svpernova09]

As an update to my previous comment: I didn't get any traction from the forum post so I posted a Support request via my Parallels account directly to them. They asked me to verify the behavior that existed on the current public releases of Parallels & SDK and I upgraded and verified I was still hitting this issue. The support team has informed me the issue has been escalated to their development team for further investigation.

[nwtechguy]

I was able to get past the Failed creating Parallels driver: Parallels Virtualization SDK is not installed issue by:

• Installing python 3.7.13 with pyenv
• Adding the path of the SDK to PYTHONPATH

export PYTHONPATH=/Library/Frameworks/ParallelsVirtualizationSDK.framework/Libraries/Python/3.7

[jnoxon]

The SDK was updated and works now with Monterey 12.4. I am uploading a newer build of the box as I type this.

[craigpearson]

@jnoxon with your latest release at 1.0.1, the vagrant box retains the mac address. Therefore if you have multiple boxes, Parallels assigns the same DHCP address to each box, resulting in an internal meltdown within Parallels.

I assume this is possibly related to this setting: config.vm.base_mac as per: https://www.vagrantup.com/docs/vagrantfile/machine_settings

Or due to omitting the --base flag when building the box:

Also, there is a "Vagrantfile." This contains some configuration to properly set the MAC address of the NAT network device, since VirtualBox requires this to be correct in order to function properly. If you are not using vagrant package --base above, you will have to set the config.vm.base_mac setting in this Vagrantfile to the MAC address of the NAT device without colons.

Rel: https://www.vagrantup.com/docs/providers/virtualbox/boxes

Some other people experiencing this issue:

roots/trellis#1253 (comment)
https://unix.stackexchange.com/questions/709220/connection-refused-on-ubuntu-on-vagrant-parallels/709610#709610

[jnoxon]

@craigpearson Apologies for letting this sit for so long, but I'm confused. Vagrant isn't used to build the box. I checked to make sure there wasn't something in the image causing udev to change the MAC, but I don't see anything. It sounds like a problem with Parallels or the parallels vagrant provider causing MAC reuse. Are you able to work around it by overriding the MAC address for your box in Vagrant?