docker-machine-parallels
docker-machine-parallels copied to clipboard
M1 support
Parallels is working on support for M1 Macs. This is just a blanket issue to ensure compatibility (or document incompatibility) with the M1 version of Parallels. This should probably be parked until at least a beta of Parallels M1 is available.
BTW, I volunteer my M1s as guinea pigs if needed (MBP and DTK).
Since Parallels is now officially supporting Macbook M1 in version 16.5. Is there any update on this?
@alvint @tobernguyen Could you please elaborate - which exact use case are you interested in?
Docker Machine project has been put into the maintenance mode back in 2018 (https://github.com/docker/machine/issues/4537), so it is less likely that Apple M1 support will be added there.
Or, are you trying to use it with minikube (which also leverages our driver)?
@alvint @tobernguyen Could you please elaborate - which exact use case are you interested in?
Docker Machine project has been put into the maintenance mode back in 2019 (docker/machine#4537), so it is less likely that Apple M1 support will be added there.
Or, are you trying to use it with minikube (which also leverages our driver)?
Ah, my experience with Docker for Mac is it is still very slow and I just want to try if running the Docker in Ubuntu VM in Parallels could improve that.
You should be able to start Docker on an Ubuntu VM, using something like Vagrant rather than Machine:
https://boot2podman.github.io/2020/07/22/machine-replacement.html
http://parallels.github.io/vagrant-parallels/docs/ ("bento/ubuntu-20.04")
Otherwise you would need boot2docker for arm64, which is not available. But I'm working on a replacement.
Does parallells require something special for UEFI, or can it run the images right out-of-the-box ?
My normal target is Raspberry Pi, which uses SD cards and a special kernel, rather than an ISO. But there is a renewed interest in making regular disk images, so swapped ISOLINUX for GRUB.
Basically I'm wondering if this minimal buildroot image works, after gunzip
: disk-arm64.img.gz ?
With QEMU, we use something similar to:
qemu-system-aarch64 -M virt -cpu cortex-a53 -bios /usr/share/qemu-efi-aarch64/QEMU_EFI.fd ...
Does it also work, when run with Parallels ?
Basically I'm wondering if this minimal buildroot image works, after gunzip: disk-arm64.img.gz ?
I gave it a try. Unfortunately it hangs on boot and it's not clear why. Will try to investigate. But anyway this has nothing to do the Docker Machine.
I gave it a try. Unfortunately it hangs on boot
Thanks for testing! It's related in the sense that the minikube.iso is based on buildroot, and it uses libmachine
We are preparing a version for arm64, but it's not yet ready for public testing.. See https://github.com/kubernetes/minikube/issues/9228
But anyway this has nothing to do the Docker Machine.
I do have a version of the ISO with only docker, but it is not yet compatible with machine (like automount and so on)
So assuming that the basic platform eventually works, one could make something that would work with docker-machine.
For EFI Boot, it seems there is a setting for it: https://kb.parallels.com/en/122735
Eventually we will have better access to the Mac M1, then we can test ourselves.
Is there any update on this? Because I'm having the exact same issue
@mauricemojito
Is there any update on this? Because I'm having the exact same issue
Were you able to get any of the ISO running with Parallels, on Mac M1 ?
Some people are working over summer to make an arm64 minikube.iso
.
We will assume that if it works with QEMU (+UEFI), it will also work here...
The main target is Docker's HyperKit, though. https://github.com/kubernetes/minikube/issues/11219
@afbjorklund
Were you able to get any of the ISO running with Parallels, on Mac M1 ?
Parallels Desktop for Mac with M1 boots operating systems from ISO-images successfully. Ubuntu, Fedora, Debian and others work nicely on arm64.
Can someone explain what could be done from docker-machine-parallels' side in scope of this ticket? Frankly speaking I'm a bid disoriented between all these arm64-related tickets in minikube project :-(
The main ticket (in minikube), is getting an arm64 version of the amd64 ISO. Unfortunately it has been delayed, in that we don't even have a new amd64... 😟
If docker-machine-parallels works OK with something like Ubuntu, then I guess there is nothing more to do in the driver - the issue is on the OS and ISO side
I don't have Parallels here, but something similar to --kvm-boot2docker-url
?
Looking through the source, it seems there is a --parallels-boot2docker-url
Another approach is replacing boot2docker.iso
with Ubuntu: https://github.com/kubernetes/minikube/issues/9992
The current workaround for that is to start the VM yourself, then use SSH driver: ("generic"*) https://minikube.sigs.k8s.io/docs/drivers/ssh/ (currently you also need to install Docker)
That was the reason I mentioned Vagrant above, since docker-machine
is dead upstream.
NOTE: If you don't use minikube but Docker Machine with parallels, the docs are here: * https://docs.docker.com/machine/drivers/generic/
Can someone explain what could be done from docker-machine-parallels' side in scope of this ticket?
You could start with building amd64
and arm64
versions of the binary, I suppose ?
https://github.com/Parallels/docker-machine-parallels/releases
docker-machine-driver-parallels
docker-machine-driver-parallels: Mach-O 64-bit x86_64 executable
Also, as indicated above, I would interested to know what is required for the arm64 ISO to boot...
https://github.com/Parallels/docker-machine-parallels/issues/99#issuecomment-828360856
Either what is wrong with the "hello world" img, or maybe just some pointers/URL to working ones.
I get the opposite issue, when trying to run with Debian ISO with KVM:
BdsDxe: failed to load Boot0001 "UEFI Misc Device" from VenHw(93E34C7E-B50E-11DF-9223-2443DFD72085,00): Not Found
BdsDxe: loading Boot0002 "UEFI Misc Device 2" from PciRoot(0x0)/Pci(0x2,0x0)
BdsDxe: starting Boot0002 "UEFI Misc Device 2" from PciRoot(0x0)/Pci(0x2,0x0)
Synchronous Exception at 0x00000000B8425288
Synchronous Exception at 0x00000000B8425288
debian-10.10.0-arm64-xfce-CD-1.iso (ran it with qemu-system-aarch64)
EDIT: Typical, that exact image release is broken: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=990190
debian-10.9.0-arm64-xfce-CD-1.iso runs just fine
There is a CD version (.iso) now, in case it works better than the HD version (.img)
https://github.com/afbjorklund/minimal-buildroot/releases/tag/0.2 (it requires UEFI)
I would be interested in knowing if it works on Paralllels too, either amd64 or arm64 ?
It will form the base of the new multi-arch ISO for minikube (possibly also machine)
The image mentioned above can't boot as a boot2docker image? Any other solutions? Thanks
You can use this boot2docker-arm64.iso image for testing, if needed (should boot, without disk)
@afbjorklund
I run docker-machine create --driver=parallels --parallels-memory=16384 --parallels-disk-size=65536 --parallels-cpu-count=8 --parallels-boot2docker-url https://github.com/afbjorklund/boot2docker-debian/releases/download/a12e50d/boot2docker-arm64.iso prl-dev
command
and the log shows:
Creating CA: /Users/hirakujira/.docker/machine/certs/ca.pem
Creating client certificate: /Users/hirakujira/.docker/machine/certs/cert.pem
Running pre-create checks...
(prl-dev) Image cache directory does not exist, creating it at /Users/hirakujira/.docker/machine/cache...
Creating machine...
(prl-dev) Downloading /Users/hirakujira/.docker/machine/cache/boot2docker.iso from https://github.com/afbjorklund/boot2docker-debian/releases/download/a12e50d/boot2docker-arm64.iso...
(prl-dev) 0%....10%....20%....30%....40%....50%....60%....70%....80%....90%....100%
(prl-dev) Creating SSH key...
(prl-dev) Creating Parallels Desktop VM...
(prl-dev) Starting Parallels Desktop VM...
(prl-dev) Waiting for VM to come online...
And then I get stuck in Waiting for VM to come online...
. Seems that the VM is booting but the host machine can't ssh into the docker VM. Do you know what I missed to configure? Thanks!
Do you know what I missed to configure? Thanks!
It is probably just missing the setup, the image is only half-done - it should boot and show a console, not sure about ssh yet
The old scripts needs porting over, from init to systemd
https://github.com/afbjorklund/boot2docker-debian/blob/master/scripts/autoformat.sh (newer versions exists as well, for TCL)
@hirakujira : Note that both docker-machine and boot2docker are dead upstream now
So any continued development would need a new name (moby?), in order to continue
It was supposed to look something like this: