On Thu, Jan 9, 2014 at 2:35 PM, kausik pal <kausikpa...@gmail.com> 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
