qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Stefan Hajnoczi
Subject: Re: [Qemu-devel] QEMU detachable overlays and Union Mounts
Date: Thu, 9 Jan 2014 17:54:48 +0800

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]