Re: [Qemu-devel] QEMU detachable overlays and Union Mounts

[Stefan Hajnoczi]

On Thu, Jan 9, 2014 at 7:45 PM, kausik pal <address@hidden> wrote:
> From an Administrator's perspective the software/package layering and VM
> operation should go like the following:-
>
> 1. Administrator install Windows as a Base QEMU/KVM vm (Say win-base).
> 2. Using qemu-img create with -b option create an overlay named win-vm01
> 3. Utilizing libguestfs administrator give the proper name/IP address to
> win-vm01 in the OS level
> 4. Again utilizing QEMU/KVM another overlay is being created on top of
> win-vm01 with the name as Software1.
> 5. Administrator installs a software (say Firefox) by either utlizing
> libguestfs or manually.
>
> Please correct me if I'm wrong up to point 5 it is possible with current
> features of QEMU and libguestfs.
>
> Now the new features/tools are needed (as per my understanding) for the
> following operations:-
>
> 6. The administrator separates Software1 snapshot/overlay disk from the
> win-base VM and keep it as a independent 'Read only' disk.
>
> 7. Now the administrator  repeats the steps from 4 to 6 for other softwares
> as well say for 'Google Chrome' 'Adobe Reader'.
>
> Up to this point the administrator have several independent read-only
> software VM disks (i.e. Firefox, Chrome etc.)
>
> 8. Now the administrator repeats the step 2 to 3 to create more VM overlays
> for the end users (Say win-vm02, win-vm03)
>
> Up to this point the administrator has a single base VM disk (win-base) with
> multiple overlays/snapshots VMs.
>
> 9. The administrator now applies the single read only software disks to
> mulitiple VMs. So in that way a single software disk can serve multiple VMs.
>
> Request you to let me know if the above operations are at all possible by
> adding features to QEMU/libguestfs or my thought process going in the wrong
> way.

The use case makes sense from an administrator perspective.  There are
two unsolved issues here:

1. Composing overlays (e.g. winscp, 7zip, firefox) is not possible
today for the reasons we've discussed.  If file level logic is added
it would become possible to compose overlays in some cases.  But
special handling would be necessary for changes to shared files like
the Windows registry.  Since each overlay may modify the registry
there needs to be some conflict resolution logic that is smarter than
just replacing the registry file wholesale.  It needs to know how to
add/remove/modify single registry keys automatically for each overlay.

2. The backing chain actually doesn't make sense:

win-base <- vm01 <- firefox <- winscp
win-base <- vm02 <- winscp <- 7zip

The topmost image file must be read-write so the guest can persist
data to disk.  That means vm01, vm02 should be topmost instead of the
overlay files (winscp/7zip):

win-base <- firefox <- winscp <- vm01
win-base <- winscp <- 7zip <- vm02

Now the next problem is that winscp actually has a different backing
file in both VMs: firefox (vm01) and win-base (vm02).  Furthermore,
the winscp image file will contain slightly different data at the
block level because the file system that it is based off is different
between vm01 and vm02.

This means we actually have something a little different:

win-base <- firefox-on-win-base <- winscp-on-firefox-on-win-base <- vm01
win-base <- winscp-on-win-base <- 7zip-on-winscp-on-win-base <- vm02

Notice that winscp-on-firefox-on-winbase != winscp-on-win-base.  This
means the winscp overlay needs to be duplicated or "specialized" for
vm01 and vm02.

I think it's perfectly possible to tackle all these issues through
tooling that works at the block and file level.  However, it's really
a brute-force solution.  Perhaps it's smarter to solve this problem
inside the guest using package managers or configuration management.

The amount of effort required to solve this problem should be a little
clearer now.  A simple script won't solve this, it requires serious
work to diff and apply changes from the file level, as well as a
workflow tool (GUI and/or command-line) for manipulating overlays.

Stefan