Feedback requested for PERSISTENT DISKS DISCUSSION: -e PERSISTENT=true -v "${PWD}/image.img:/image" #326

Open
opened 2025-12-29 00:24:26 +01:00 by adam · 5 comments
Owner

Originally created by @sickcodes on GitHub (Feb 23, 2022).

I have estimated the amount of human time it takes people to create and copy/mv out images and I think it's high. I want to add persistent disks on the first run (add the ability, nothing being removed, all old processes work, as I will never deprecated anything)

Take note, all of this is done OUTSIDE of Docker, but also consider that to get the image from INSIDE the Docker, it will take work also.

Option 1:

Should I add a (default) check (for every single container) where you can say you want

qemu-img create -f qcow2 image.img 512G

    -e PERSISTENT=true \
    -v "${PWD}/image.img:/image" \

Option 2:

Or the same, but it it will just check if you're supplying an image instead of using PERSISTENT, it will just realise /image, is a raw .img, without PERSISTENT=true needed

qemu-img create -f qcow2 image.img 512G

    -v "${PWD}/image.img:/image" \

Option 3:

If users might accidentally overwrite their disk, use date, for example:

This will create in current directory ./image_2022-02-23-16:24:11.img, format it to skip disk utility step.

NEW_IMAGE=./image_$(date +%F-%T).img
echo "${NEW_IMAGE}"

# turn on network block device kernel module from libvirtd
sudo modprobe nbd

# create a disk
# AND FORMAT IT TOO TO SKIP THE DISK UTILITY STEP
qemu-img create -f qcow2 "${NEW_IMAGE}" 512G
sudo qemu-nbd --connect=/dev/nbd0 ${NEW_IMAGE}
sudo mkfs.apfs /dev/nbd0
sudo qemu-nbd --disconnect /dev/nbd0


    -v "${PWD}/${NEW_IMAGE}:/image" \

Option 4:

Or leave everything as-is.

Originally created by @sickcodes on GitHub (Feb 23, 2022). I have estimated the amount of human time it takes people to create and copy/mv out images and I think it's high. I want to add persistent disks on the first run (add the ability, nothing being removed, all old processes work, as I will never deprecated anything) Take note, all of this is done OUTSIDE of Docker, but also consider that to get the image from INSIDE the Docker, it will take work also. ### Option 1: Should I add a (default) check (for every single container) where you can say you want ```bash qemu-img create -f qcow2 image.img 512G -e PERSISTENT=true \ -v "${PWD}/image.img:/image" \ ``` ### Option 2: Or the same, but it it will just check if you're supplying an image instead of using PERSISTENT, it will just realise `/image`, is a raw `.img`, without `PERSISTENT=true` needed ```bash qemu-img create -f qcow2 image.img 512G -v "${PWD}/image.img:/image" \ ``` ### Option 3: If users might accidentally overwrite their disk, use date, for example: This will create in current directory `./image_2022-02-23-16:24:11.img`, format it to skip disk utility step. ```bash NEW_IMAGE=./image_$(date +%F-%T).img echo "${NEW_IMAGE}" # turn on network block device kernel module from libvirtd sudo modprobe nbd # create a disk # AND FORMAT IT TOO TO SKIP THE DISK UTILITY STEP qemu-img create -f qcow2 "${NEW_IMAGE}" 512G sudo qemu-nbd --connect=/dev/nbd0 ${NEW_IMAGE} sudo mkfs.apfs /dev/nbd0 sudo qemu-nbd --disconnect /dev/nbd0 -v "${PWD}/${NEW_IMAGE}:/image" \ ``` ### Option 4: Or leave everything as-is.
adam added the enhancementdocumentationhelp wantedquestion labels 2025-12-29 00:24:26 +01:00
Author
Owner

@sickcodes commented on GitHub (Feb 23, 2022):

Option 5: add all of the above

@sickcodes commented on GitHub (Feb 23, 2022): Option 5: add all of the above
Author
Owner

@spantheslayer commented on GitHub (Feb 23, 2022):

Why don't you add all of them 😂

But personally would love to see (default) check (for every single container) being implemented. This will be a really neat feature to have.

@spantheslayer commented on GitHub (Feb 23, 2022): Why don't you add all of them 😂 But personally would love to see (default) check (for every single container) being implemented. This will be a really neat feature to have.
Author
Owner

@omarahm3 commented on GitHub (Feb 23, 2022):

would be really great if you can add all of the options, but if i had to choose, i would love to see option 3

@omarahm3 commented on GitHub (Feb 23, 2022): would be really great if you can add all of the options, but if i had to choose, i would love to see option 3
Author
Owner

@ballerxdakid commented on GitHub (Feb 23, 2022):

i would agree with above be nice with all but number one but to be honest what ever you choose thanks for you work my g my g

@ballerxdakid commented on GitHub (Feb 23, 2022): i would agree with above be nice with all but number one but to be honest what ever you choose thanks for you work my g my g
Author
Owner

@sickcodes commented on GitHub (Feb 24, 2022):

Adding the most simple way here:

https://github.com/sickcodes/Docker-OSX/pull/456

  • Move /home/arch/OSX-KVM to /home/arch/Docker-OSX/OSX-KVM, but symlink it anyway

  • If you put an image at /image, the image will use that at runtime.

  • Move OSX-KVM to submodule, and symlink for perfect redundancy ln -s /home/arch/Docker-OSX/OSX-KVM /home/arch/OSX-KVM

The submodule move is to make OSX-KVM static, if sometimes we are behind

@sickcodes commented on GitHub (Feb 24, 2022): Adding the most simple way here: https://github.com/sickcodes/Docker-OSX/pull/456 - Move `/home/arch/OSX-KVM` to `/home/arch/Docker-OSX/OSX-KVM`, but symlink it anyway - If you put an image at /image, the image will use that at runtime. - Move OSX-KVM to submodule, and symlink for perfect redundancy `ln -s /home/arch/Docker-OSX/OSX-KVM /home/arch/OSX-KVM` The submodule move is to make OSX-KVM static, if sometimes we are behind
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/Docker-OSX#326