Add Parallels to the download options
StephanStS opened this issue · 19 comments
https://dietpi.com/#download: The support of Parallels Desktop (macOS) shall be added.
A question I wanted to ask on the docs PR already: The existing VM images do not work, e.g. when converting into raw img file, or using the vendor-free VM image? https://dietpi.com/downloads/images/
Because using the native PC image implies several issues, is actually nothing we should promote/document as official solution. We have a PC and a VM hardware ID which our scripts count on to be precise, and the PC images ship a bunch of unnecessary firmware as well. So while this is a working unofficial workaround, if we really want to support it, especially when adding it to the download page, we need a "Parallels" VM image or need to get the vendor-free VM image working. If it does not work, possibly an SATA/SCSI/drive kernel module is missing in the initramfs, which is trivial to add.
I'm not an Apple user, therefore question might be stupid. What about parallels on the M1? If I'm not mistaken this is an ARM based system. Hence require a different image?
I'm not an Apple user, therefore question might be stupid. What about parallels on the M1? If I'm not mistaken this is an ARM based system. Hence require a different image?
This is the reason, why I only mention an X86_64 Mac system. I do not have an M1, so I cannot test this.
Actually a VM installer image should work as well. I'll implement this into the dietpi-build script as a selectable solution. This would work around the initramfs issue (if it is one) since the initramfs is recreated. VM images are shipped with tiny-initramfs, but the Clonezilla installer, AFAIK, uses initramfs-tools shipped with the installer (Ubuntu) system, hence builds a large compatible one. As fast as a kernel update is done, tiny-initramfs from the actual DietPi image is used and creates a much smaller initramfs, adding auto-detected drive-related kernel modules. But much better for a VM IMHO is to skip the installer and create a VM directly from a raw (.img) or VM image type, if we can verify which additional kernel module is required.
@StephanStS
Can you run and paste lsmod from within the VM?
I tried to create a Parallels machine with the BIOS direct flash image
which did not work (Parallels did not accept the .img file, only the .iso file worked).
But I will try to "export" a Parallels VM (I assume they have one single .pvm file -> I have to check this).
lsmod output:
Module Size Used by
intel_rapl_msr 20480 0
intel_rapl_common 28672 1 intel_rapl_msr
intel_pmc_core_pltdrv 16384 0
intel_pmc_core 45056 0
x86_pkg_temp_thermal 20480 0
coretemp 20480 0
ghash_clmulni_intel 16384 0
aesni_intel 368640 0
libaes 16384 1 aesni_intel
crypto_simd 16384 1 aesni_intel
cryptd 24576 2 crypto_simd,ghash_clmulni_intel
glue_helper 16384 1 aesni_intel
rapl 20480 0
snd_intel8x0 49152 0
snd_ac97_codec 180224 1 snd_intel8x0
virtio_gpu 65536 5
ac97_bus 16384 1 snd_ac97_codec
virtio_dma_buf 16384 1 virtio_gpu
snd_pcm 135168 2 snd_intel8x0,snd_ac97_codec
snd_timer 49152 1 snd_pcm
drm_kms_helper 278528 3 virtio_gpu
snd 110592 4 snd_intel8x0,snd_timer,snd_ac97_codec,snd_pcm
pcspkr 16384 0
serio_raw 20480 0
soundcore 16384 1 snd
sg 36864 0
joydev 28672 0
evdev 28672 9
cec 61440 1 drm_kms_helper
virtio_balloon 24576 0
sbs 20480 0
sbshc 16384 1 sbs
pvpanic 16384 0
button 24576 0
drm 618496 5 drm_kms_helper,virtio_gpu
fuse 167936 1
configfs 57344 1
ip_tables 32768 0
x_tables 53248 1 ip_tables
autofs4 53248 2
ext4 921600 1
crc16 16384 1 ext4
mbcache 16384 1 ext4
jbd2 151552 1 ext4
crc32c_generic 16384 0
sd_mod 61440 2
t10_pi 16384 1 sd_mod
sr_mod 28672 0
crc_t10dif 20480 1 t10_pi
cdrom 73728 1 sr_mod
crct10dif_generic 16384 0
ata_generic 16384 0
hid_generic 16384 0
usbhid 65536 0
hid 147456 2 usbhid,hid_generic
xhci_pci 20480 0
virtio_net 61440 0
net_failover 24576 1 virtio_net
failover 16384 1 net_failover
xhci_hcd 303104 1 xhci_pci
ahci 40960 1
ata_piix 36864 0
libahci 45056 1 ahci
ehci_pci 20480 0
uhci_hcd 53248 0
crct10dif_pclmul 16384 1
crct10dif_common 16384 3 crct10dif_generic,crc_t10dif,crct10dif_pclmul
ehci_hcd 98304 1 ehci_pci
crc32_pclmul 16384 0
crc32c_intel 24576 2
usbcore 323584 6 xhci_hcd,ehci_pci,usbhid,ehci_hcd,xhci_pci,uhci_hcd
psmouse 184320 0
i2c_i801 32768 0
i2c_smbus 20480 1 i2c_i801
libata 290816 4 ata_piix,libahci,ahci,ata_generic
lpc_ich 28672 0
scsi_mod 262144 4 sd_mod,libata,sg,sr_mod
usb_common 16384 4 xhci_hcd,usbcore,ehci_hcd,uhci_hcd
virtio_pci 28672 0
virtio_ring 36864 4 virtio_balloon,virtio_gpu,virtio_pci,virtio_net
virtio 16384 4 virtio_balloon,virtio_gpu,virtio_pci,virtio_net
As it is a virtualizer, I'd expect it to accept VMDK, which is supported by all others (though limited, e.g. not expandable in VirtualBox). So the VMware image could be tested.
We could also convert the raw VM image into ISO format if this is the only supported one. But actually I think it is like on VirtualBox, where as external/installer/ROM drive only ISO is accepted, but there is a way to attach a virtual drive directly with other format.
sd_mod and ahci, looks pretty similar to what VirtualBox uses. The VMware .vmdk may indeed work well, when you attach it directly as new virtual drive.
I did some tests:
- BIOS installer image
- Installation process starts and a virtual machine can be created
- VM size of .pvm file (before DietPi firstboot) is 1.39 GB
- VM size of .pvm file (after DietPi firstboot) is 2.09 GB
- VMware image
- Using the .vmdk and .vmx file via the Parallels function "Open" did not work correctly
- Remark: I did not execute the steps described there. This could be a step to investigate (takes actually too much time for me)
- VirtualBox image
- Step 1: Importing the .ova file from the 7z into VirtualBox
- Step 2: Open the .vbox file in Parallels like described there
- Result: Works (with adjustments of the network adapter to "Bridged")
- VM size of .pvm file (before DietPi firstboot) is 770 MB
- VM size of .pvm file (after DietPi firstboot) is 1.23 GB
As a result we could generate a .7z file with the .pvm file (based on VirtualBox) and describe the generation there as a sub page "How to create a DietPi image for Parallels Desktop (macOS)".
Also the description of the installation chapter on the docu dev branch then needs to be reworked.
Many thanks for testing. For the VMDK import it looks like disk splitting needs to be disabled, but otherwise it seems to be generally supported. However, looks like Parallels cannot run a VMDK directly but imports/converts it to PVM in every case, which is not a virtual disk format only, but a container which includes VM configs and other volatile data, like the dedicated files created by VirtualBox and VMware when starting a VM, but all in a single container file. I didn't find details about the container format and the contained files, hence we cannot manually create it like we do with the VirtualBox OVA. And so far I couldn't find any Linux command line utility to do the conversion 😢.
There is one more thing which could be tested to at least skip using VirtualBox as intermediate conversion step:
- The
.ovafile can be extracted withtarfrom the command line:Renaming that file totar xf DietPi_VirtualBox-x86_64-Bullseye.ova
.tarextension should allow GUI extraction as well. - This extracts to a VMDK, an
.mf(checksums) and a generic.ovfVM settings file, hence one that is open/vendor-independent and can be used/imported by VirtualBox and VMware at least. - Would be strange if Parallels did support for vendor-specific VM formats but not the open one, so I hope the
.ovfcan be imported directly. However, if disk splitting still needs to be disabled as of VMDK vs VDI, then probably using the VMware.vmxis quicker.
I guess Parallels has no CLI that can be used from a GitHub action to allow automation for creating these images, does it? I have no Mac that I can regularly use to do this manually, but as long as someone else is okay with doing so once once in a while, it's okay with me.
EDIT: Actually all the steps from within the VM described in the VMware conversion link can be skipped, our VMware VM does not need to be started at all. Do I miss something or is it really just disabling the disk splitting when importing the .vmx and nothing else?
Test with .ova: Renaming .ova to .tar shows the three files like you mentioned.
Tryping to open the .vmdk file with Parallels failed identically to using the .vmdk file from the VMware image. In Parallels, only the .vmdk file can be selected to be opened. The .ovf file (within the same directory) could not be selected.
VMware image: Yes, I did nothing with VMware Player. I only tried to open the .vmdk file contained in the .7z file.
As far as I assume, there is no disk splitting in the VMware DietPi machine. So I did not deal with searching for the option to uncheck this. Actually I have no VMware installed to make a quick test. Would take at bit more time...
So, my proposal to go on keeps stable like mentioned above. :-)
The only problem of generating a .pvm file from time to time is, that in this case we need a licenced Parallels. Actually I am working with a two weeks test version. Possibly we find someone in the community which could do this long term.
I'm wondering that selecting a .vmdk is even possible. .vmx and .vbox (and .ovf) are VM config files, which contain hardware/network definitions and a path to the associated virtual disk image, hence contain info which can be used to create a .pvm. When selecting a virtual disk image only, there is no VM definition, hence a new VM would then need to be created in turn 🤔. A pain that vendor VM configs can be imported but not the open format which all other virtualizers share and use for their own exports.
As far as I assume, there is no disk splitting in the VMware DietPi machine. So I did not deal with searching for the option to uncheck this.
Yes as it's a single VMDK only, there is no disk splitting obviously 😉, probably Parallels is a bit dump and still tries to apply it or looks for split files even when there are none, so that it needs to be actively disabled in any case, at least when importing a virtual disk image instead of a VM config.
Actually I am working with a two weeks test version. Possibly we find someone in the community which could do this long term.
Ah yes, I saw that there is no free version. Hmm, not sure if it's a good idea to provide and official image with docs and download links as long as we cannot guarantee updates? 🤔
Though we can do a free trial rotation and in parallel ask for a developer license and watch our for Parallels users who can generate a new image by times.
Final tests showed:
- The best result arises with the BIOS installer image
- If afterwards all updates were done and the DietPi PREP script runs, the final image (
.pvm) is about 1.15 GB - In case of VMware as the basis, the resulting image is about 1.55 GB
- If afterwards all updates were done and the DietPi PREP script runs, the final image (
- Further investigations may be done later (too time consuming for any marginal optimization now)
So, the next steps are:
- Use a
.pvmgenerated with Parallels Desktop based on the BIOS installer image - Generate the .7z with hash.txt and README.md.
- Generate a DietPi GitHub-Wiki description of the complete process similar to https://github.com/MichaIng/DietPi/wiki/How-to-create-a-DietPi-image-for-VirtualBox
- Upload .7z to the downloads directory of DietPi
- Add Parallels to the download options of the DietPi website download area
- Change the description within https://dietpi.com/docs/install/
- Try to ensure long term image generation with Parallels Desktop
If afterwards all updates were done and the DietPi PREP script runs,
You again run the PREP script? This shouldn't be required at all, simply import the .ova, adjust VM settings in Parallels when required, pack and upload the resulting .pvm. No need to start the VM and do another PREP iteration.
As said, the native PC images cannot be used as they have the wrong hardware ID. Of course when running again PREP over it, this is solved, but for a clean fresh (and small) result we should skip that.
If you do not run the full updates (and afterwards the PREP), the initial installation takes a much longer time due to the whole dist-upgrade duration. That's the reason why I propose to have an actual image by executing DIETPI_PREP once more.
This seems to me to be the more user friendly procedure, I weight this over a slightly size increase of the .7z file.
So, let's roll the dice, who wins with his opinion. :-)
The images have been updated not too long ago (DietPi is on v7.9 already), so there shouldn't be much APT upgrades on Bullseye since then. 2 weeks of APT upgrades shouldn't force us to create this image with latest packages, which are again 2 weeks old in 2 weeks 😉.
Let's find and document a simple and quick way to create a Parallels image from an existing VM image without booting/PREP, hence also created with a PREP version and in case latest fixes/adjustments I did when creating the other VM images. This is then also something which other users can follow safely, which want to help us keeping that image updated. If this implies first flashing an installer, attaching that to a new VM, running the installer, booting the system, running PREP, shrinking and archiving the image again, puhh 😅, much which can go wrong and hence it would again require us to review the resulting image, much too much work all together for something which we actually aim to 100% automate without any manual step involved.
The images have been updated not too long ago (DietPi is on v7.9 already), so there shouldn't be much APT upgrades on Bullseye since then. 2 weeks of APT upgrades shouldn't force us to create this image with latest packages, which are again 2 weeks old in 2 weeks.
May be. I saw the long duration, which was real. :-)
Possibly the long time was due to a kernel update from 5.10.0-9 to 5.10.0-10.
Let's find and document a simple and quick way to create a Parallels image from an existing VM image without booting/PREP, hence also created with a PREP version and in case latest fixes/adjustments I did when creating the other VM images. This is then also something which other users can follow safely, which want to help us keeping that image updated. If this implies first flashing an installer, attaching that to a new VM, running the installer, booting the system, running PREP, shrinking and archiving the image again, puhh sweat_smile, much which can go wrong and hence it would again require us to review the resulting image, much too much work all together for something which we actually aim to 100% automate without any manual step involved.
That could be done. The basic steps are given above.
Remark: The actual .pvm file zipped has about 420 MB.
Yes, a kernel upgrade appears every few weeks, so it cannot and shouldn't be a goal to prevent users from facing one on first boot. More important and beneficial IMO is an as fast/easy as possible image generation/update procedure which allows us to ship new images in shorter frequencies which as well reduces the average APT and DietPi timestamps for end users.
However, of course if you do the fresh/updated PREP image for the first Parallels one now, I have nothing against it, I'm just thinking about a general/future procedure with least possible overhead.
Btw, instead of using our Native PC installer image, the Debian installer as described e.g. for VirtualBox in our Wiki is a clean alternative to run PREP on, which should lead to similar or even better results, regarding the final image size. But not sure which one is faster to apply, as the Debian installer has much more dialogues compared to a DietPi installer + first boot.
Remark: The actual
.pvmfile zipped has about 420 MB.
Not great, but not much we can do about it with this container format, I guess.
The debian netinst.iso gives an image of 1.62 GB (DietPi BIOS image: 1.22 GB) and a .zip of 520 MB.
It is quick done with the netinst.iso.
Interesting, a VM installer image would be awesome then. Probably I find time to create one tonight.
All done.