[Question]: Is there an established way to make the VM ephemeral?

[toadslop]

Is your question not already answered in the FAQ?

• [x] I made sure the question is not listed in the FAQ.

Is this a general question and not a technical issue?

• [x] I am sure my question is not about a technical issue.

Question

I'd like to set up my machine, make a few initial changes, have those changes persisted, and then have any further changes reverted every time I restart the VM. Basically, I want an ephemeral machine (my use case is software testing).

I can see that by default dockur/windows is not ephemeral -- it saves all changes. My question is, is there already an established pattern for making the VM ephemeral without deleting the whole volume? If so, can we add that to the README?

[kroese]

If you backup the contents of the /storage folder, you could just overwrite any changes with that before starting the machine in the future. That way you will always start from a "known state". The only thing you have to do is instead of running docker start windows is running cp -r ./backup /example/storage && docker start windows or something similar.

[ErikEngerd]

I was looking at the same problem. I see that the disk image data.img is a sparse file and could be easily backed up and restored using tar with sparse file support (and further compression).

Then, next to the data.img file there is an iso file which is not sparse and also quite big. I assume this file is only used during installation since it is an ISO and is most likely used as a CDROM/DVD device.

So when restoring a windows VM is it sufficient to restore only all file except the ISO? Or in general, what triggers dockurr/windows to do a VM install? Does it just check if data.img is there and will it run windows if the ISO is not there?

[kroese]

The .ISO file will be automaticly removed when you shutdown the container for the first time after installation. So if you see an .ISO that means the container is still running for the first time, and never has been shutdown?

In any case, after it removes the .iso it creates an (empty) file called windows.boot in the /storage directory, and this will cause the container to ignore the missing .iso during the next startup.

There is also another way to create a ephemeral machine I just realized.. When you set:

environment:
  STORAGE: "/local"

the container will store the data.img and other files, INSIDE the container image instead of the /storage folder.

That means you can use all the existing Docker tools (like docker container commit) to manage this container image. This will make it easy to make clones based on that image, without any need to manually copy files anymore.