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

[kausik pal]

Hi Stefan,

Thanks a lot for the detailed explanation.

>It seems either we need the tools that understand both block and file
>level or we need to rethink how to package software completely.

In my opinion the first approach i.e. tool that understand both block and file level would be a good idea. Here in our organization we have tested different Application Virtualization tools to package and stream softwares. But Application virtualization has its own limits as it can not package certain kind of applications (like softwares with device drivers, or softwares with system level services).

But with QEMU/KVM snapshots I was able to install complex softwares in different snapshot layers present it to end users.

Though the softwares belongs to different snapshot layers, they are being presented to the end users in a coherent manner, and users feel that they are being served with a single layer of OS.

Can you throw some light in if it is possible to develop new tool combining QEMU and libguestfs to bring out desired operation mentioned in the above mail chain.

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.

On Thu, Jan 9, 2014 at 3:24 PM, Stefan Hajnoczi <address@hidden> wrote:

On Thu, Jan 9, 2014 at 2:35 PM, kausik pal <address@hidden> wrote:
> Actually I have tested the QEMU KVM snapshot features with multiple overlays and found it to be working fine.
>
> Let’s say for an example, I have installed Windows XP as a QEMU virtual machine (The name of the VM is ‘winxp’). Then I created two separate overlays on top of ‘winxp’ as ‘winxp-vm01’ and ‘winxp-vm02’ and renamed the overlay images accordingly on the OS level.
>
> Then I created another overlay on top of ‘winxp-vm01’ as ‘winscp’, boot the overlay image ‘winscp’ and installed WinSCP on it.
>
> Third step what I did was create another overlay file on top of ‘winscp’ as ‘7zip’ and installed 7ZIP on top of it.
>
> The current scenario is like the following :-
>
>
>
>                                                       /winxp-vm01 ---------> winscp ----------> 7zip ------- User1
>                                                     /
>                                                   /
>                                    winxp vm
>                                                   \
>                                                     \
>                                                       \winxp-vm02 ---------- User2
>
>
>
> So if User1 starts the 7zip overlay image using qemu-kvm, he'll be able to see WinSCP and 7ZIP installed and the VM name as 'winxp-vm01'.
>
> So the question is is there any way we can move or copy the two overlays on top of 'winxp-vm02' so that the scenario look like the following:-
>
>
>                                                       /winxp-vm01 --------- User1
>                                                     /
>                                                   /
>                                    winxp vm
>                                                   \
>                                                     \
>                                                       \winxp-vm02 ---------->winscp -----------> 7zip ------- User2
>
>
> So if User2 starts the 7zip overlay image using qemu-kvm, he'll be able to see WinSCP and 7ZIP installed and the VM name as 'winxp-vm02'.
>
> I tried with 'qemu-img rebase' option to simulate the above scenario, but unable to do that.
>
> If this QEMU feature along with 'Libguestfs(which can be utilized to change parameters inside Windows VMs) integrates with oVirt/RHEV , then we can have a good solutions for VDI scneario.

There is no easy solution for this problem today.  What you want is to
move winscp and 7zip from winxp-vm01 onto winxp-vm02 *without* moving
the changes from winxp-vm01 over as well.  qemu-img rebase moves the
data over but will also transfer the winxp-vm01.

As Richard explained, a more powerful rebase operation is not possible
at the block level.  Since qemu-img doesn't know about file systems it
cannot make semantically equivalent changes to winxp-vm02.  We need
file level information in order to do something like that.  In
practice it would mean diffing the contents of winscp and 7zip,
turning them into file level diffs, and then applying that on top of
winxp-vm02.

It's certainly possible to attack this problem by building on top of
libguestfs.  But it's basically a research project that will require
some experimentation and development to get it working right
(nevermind that different OSes may use different file systems which
need explicit support).

Another avenue to explore are distros and packaging techniques where
there is no shared state.  Tiny Core Linux (http://tinycorelinux.net/)
uses a mountable package format.  NixOS (http://nixos.org/) uses a
purely functional package system so data is not shared or overwritten.
 Again, this stuff isn't mainstream and may not be easy for you to use
without additional development.

A practical way to solve this problem is to not use disk image
snapshots for package configuration.  Instead, use a configuration
management tool like Puppet, Chef, Ansible, etc.  If you want to apply
an identical winscp + 7zip configuration to vm02, just run the winscp
and 7zip "recipes" and the machine will end up in the right state.

I think rebasing disk images is a really interesting problem.  It
seems either we need the tools that understand both block and file
level or we need to rethink how to package software completely.

Stefan