Open DrDonk opened 2 months ago
Can you elaborate how you tested it? How do you run an NBD server? Have you checked IO performance in such setup?
Check the PR for vz I linked to for details (https://github.com/Code-Hex/vz/pull/156), but I applied this PR to the vz code base. I then created a blank QCOW2 60G image using qemu-img:
qemu-img create -f qcow2 -p macos.qcow2 60G
and mounted it with:
qemu-nbd -k $(pwd)/source.sock -f qcow2 -x export --cache=none macos.qcow2
Then using the compiled vz code incorporating the PR, installed macOS Sonoma and then ran the installed macOS.
I can provide you with a compiled executable with the incorporated code and some more detailed instructions if you would like me to.
I haven't done any benchmarking but can do so if you are interested. For me the big benefit is it's a more traditional VM disk format, which could also mean ability to do things such as snapshots.
I need to also raise a new issue as the new tart code for NBD only has one URL scheme and there are several different ones. Specifically nbd+unix would be needed for this functionality to work.
There was a recent change to tart to allow NBD drives to be used as extra drives on the tart run command. https://github.com/cirruslabs/tart/issues/759
This is a great start but you can also use NBD attached drives for the actual macOS boot drive. Can this be added to tart as would be a distinguishing feature that would allow macOS images to be stored both on NAS and also in other virtual disk formats such as QCOW2 or VMDK without the issues of copying sparse files to a non-APFS volume?
I have personally tested it with the Go language bindings test app which demonstrates that you can indeed use a NBD drive instead of the sparse file used as the disk image currently supported. Both creation of the VM from the IPSW and booting the installed macOS works flawlessly with the NBD attached drive.
The sample code is in a PR on the vz GitHub repo. https://github.com/Code-Hex/vz/pull/156