GNOME Bugzilla – Bug 694386
Support read-only OS images
Last modified: 2016-03-31 13:22:07 UTC
It would be useful to be able to support RO images. That is to say, to have a way to mark a vm-image as being read-only, and have changes written only to short-term memory instead of to disk. Rationale: - Some people need to run older OSes that are out of warranty and insecure in order to run applications developed for them. Sometimes, this apps are run in an open, insecure environment and are at a high-risk for infection. Marking a known, pristine image as RO would mean that you could start the image and use it for a short duration, and shut it down when done w/o worrying that much over the long-term health of the OS. Proposal: - I'm not 100% sure if this is a sysadmin-task or a user task, but if it's a user-task it would be good to put it as an option during the VM installation. Regardless, we probably need a watermark indicating that it's read-only. Maybe a way to know how long a vm has been running for.
Also, i think it might be nice to be able to at some point update the installation. Say if you want to upgrade the OS in the guest, then you can boot it in read-write mode, do the update and then switch it to read-only. Or, you could just do a normal read-only start and at some point say "now make this the new base version". Implementation wise this should be pretty simple using a base image and a copy-on-write qcow image pointing to the base image. Does libvirt have any support for this?
Yes, recent libvirt+qemu can do some interesting snapshots operations http://www.redhat.com/archives/libvir-list/2012-October/msg01258.html , I haven't played with that yet
And if we want something much simpler, I just noticed /devices/disk/transient in libvirt domain XML: http://libvirt.org/formatdomain.html#elementsDisks "transient: If present, this indicates that changes to the device contents should be reverted automatically when the guest exits. With some hypervisors, marking a disk transient prevents the domain from participating in migration or snapshots. Since 0.9.5"
After talking to Jon McCann about this, doing 'readonly' as part of snapshot support seems the right longer-term solution.
(In reply to comment #4) > After talking to Jon McCann about this, doing 'readonly' as part of snapshot > support seems the right longer-term solution. Ah, I didn't know until very recently that we want to support snapshots. We'll need designs for both though, unless a simple checkbox in properties is good enough for RO case?
I think the usecase (described in comment#0) can be easily implemented through snapshots (which we now support): 1. Create a snapshot 2. Install and run the vulnerable app(s) 3. Revert to snapshot