[Qemu-devel] QEMU detachable overlays and Union Mounts

[Qemu-devel] QEMU detachable overlays and Union Mounts

[kausik pal]

[-- Attachment #1: Type: text/plain, Size: 3578 bytes --]

If this message should go elsewhere, my apologies.


It would be great if QEMU have the capability of detachable overlay or
union mount.
So administrators can keep each software as separate individual qcow2/qed
disks and can put those disks on different layers so that the end user
would see combination of the softwares available to them.



The desired scenario is like the following:-



   -- --------------------
-----------------------                               ----------------------

    User1 Disk (RW)                            User2 Disk (RW)   \
User3 Disk (RW)

   -----------------------    \
----------------------        \
-----------------------

                |                 \                                 |
\                              |

                |                    \                              |
                          \                          |

                |                       \                           |
                              \                      |

    -------------------------              \
----------------------                       \
----------------------

      Software 1 Disk                  \         Software 2 Disk
                           \      Software 3 Disk

      (Read Only)                          \        (Read Only)
                                   \   (Read Only)

    --------------------------
-----------------------
----------------------











     ---------------------------
--------------------------
------------------------

     (Hostname (VM1)                            (Hostname (VM2)
                              (Hostname (VM3)

      IP Address                                     IP Address
                IP Address

     Unique Data) Disk                            Unique Data) Disk
                             Unique Data) Disk

        (Read Only)                                    (Read Only)
/      (Read Only)

     ---------------------------
---------------------------                         /
--------------------------

                            \                                         |
                                      /

                              \                                       |
                                    /

        \                                     |
                                   /

          \                                   |
 /

            \               ---------------------------------------
/

   \            | OS Updates Disk 2(RO)   |          /

                                          \         -
---------------------------------------        /

                                            \       | OS Updates Disk 1 (RO)
|      /

                                              \
-----------------------------------------
   /

                                                \   | Base VM Image (RO) |/

                                        ---------------------------





To User1:-
To User2:-                                                               To
User3:-

Hostname: - VM1                                                        H
ostname:-VM2
Hostname:-VM3

Software Installed: - Software1+Software2                     Software
Installed: - Software2+Software3                  Software Installed:-
Software3

Writable Disk:- User1 Disk                                           Writable
Disk:- User2 Disk                                       Writable Disk:-
User3 Disk



Please let me know if the above scenario is possible utilizing QEMU.

[-- Attachment #2: Type: text/html, Size: 9926 bytes --]

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

[Richard W.M. Jones]

On Wed, Jan 08, 2014 at 11:26:28AM +0530, kausik pal wrote:
> If this message should go elsewhere, my apologies.
> 
> It would be great if QEMU have the capability of detachable overlay or
> union mount.
> So administrators can keep each software as separate individual qcow2/qed
> disks and can put those disks on different layers so that the end user
> would see combination of the softwares available to them.
> 
> The desired scenario is like the following:-

[easier to see the diagrams here:
https://lists.gnu.org/archive/html/qemu-devel/2014-01/msg00819.html]

qemu already supports snapshots.  However they don't work like docker,
ie. you cannot arbitrarily compose snapshots (I don't think this works
properly in docker either, but that's another matter).

Basically because snapshots are block-based, not file based, it is
never going to be possible to compose them in the way you want.
Filesystems at the block layer simply don't work this way.

Have you considered using 9p? [http://wiki.qemu.org/Documentation/9psetup]

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming blog: http://rwmj.wordpress.com
Fedora now supports 80 OCaml packages (the OPEN alternative to F#)

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

[kausik pal]

[-- Attachment #1: Type: text/plain, Size: 1717 bytes --]

Hi rich,

Thanks for the answer.

I was wondering how unidesk has solved the problem using disk layering.
They have the solution for VMware, so if similar feature can be built on
qemu for KVM hypervisor then we will have a great solution for application
management from VDI perspective.

Please let me know your thought about this.

Thanks
Kausik
On Jan 8, 2014 11:11 PM, "Richard W.M. Jones" <rjones@redhat.com> wrote:

> On Wed, Jan 08, 2014 at 11:26:28AM +0530, kausik pal wrote:
> > If this message should go elsewhere, my apologies.
> >
> > It would be great if QEMU have the capability of detachable overlay or
> > union mount.
> > So administrators can keep each software as separate individual qcow2/qed
> > disks and can put those disks on different layers so that the end user
> > would see combination of the softwares available to them.
> >
> > The desired scenario is like the following:-
>
> [easier to see the diagrams here:
> https://lists.gnu.org/archive/html/qemu-devel/2014-01/msg00819.html]
>
> qemu already supports snapshots.  However they don't work like docker,
> ie. you cannot arbitrarily compose snapshots (I don't think this works
> properly in docker either, but that's another matter).
>
> Basically because snapshots are block-based, not file based, it is
> never going to be possible to compose them in the way you want.
> Filesystems at the block layer simply don't work this way.
>
> Have you considered using 9p? [http://wiki.qemu.org/Documentation/9psetup]
>
> Rich.
>
> --
> Richard Jones, Virtualization Group, Red Hat
> http://people.redhat.com/~rjones
> Read my programming blog: http://rwmj.wordpress.com
> Fedora now supports 80 OCaml packages (the OPEN alternative to F#)
>

[-- Attachment #2: Type: text/html, Size: 2461 bytes --]

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

[Richard W.M. Jones]

On Wed, Jan 08, 2014 at 11:37:44PM +0530, kausik pal wrote:
> Hi rich,
> 
> Thanks for the answer.
> 
> I was wondering how unidesk has solved the problem using disk layering.
> They have the solution for VMware, so if similar feature can be built on
> qemu for KVM hypervisor then we will have a great solution for application
> management from VDI perspective.

I have no knowledge or interest in how proprietary software works.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top

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

[kausik pal]

[-- Attachment #1: Type: text/plain, Size: 3516 bytes --]

Hi Rich,

Sorry if my mail annoys you.

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.

Again sincere apologies from my side, my intention was not to know the
internals of any proprietary software, but as a follower of QEMU KVM I was
just curious to know if application layering can be done with QEMU.

Please put your valued input into this.

Thanks

Kausik







On Thu, Jan 9, 2014 at 3:57 AM, Richard W.M. Jones <rjones@redhat.com>wrote:

> On Wed, Jan 08, 2014 at 11:37:44PM +0530, kausik pal wrote:
> > Hi rich,
> >
> > Thanks for the answer.
> >
> > I was wondering how unidesk has solved the problem using disk layering.
> > They have the solution for VMware, so if similar feature can be built on
> > qemu for KVM hypervisor then we will have a great solution for
> application
> > management from VDI perspective.
>
> I have no knowledge or interest in how proprietary software works.
>
> Rich.
>
> --
> Richard Jones, Virtualization Group, Red Hat
> http://people.redhat.com/~rjones
> virt-top is 'top' for virtual machines.  Tiny program with many
> powerful monitoring features, net stats, disk stats, logging, etc.
> http://people.redhat.com/~rjones/virt-top
>

[-- Attachment #2: Type: text/html, Size: 5226 bytes --]

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

[Stefan Hajnoczi]

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

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

[kausik pal]

[-- Attachment #1: Type: text/plain, Size: 7505 bytes --]

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 <stefanha@gmail.com> wrote:

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

[-- Attachment #2: Type: text/html, Size: 8739 bytes --]

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

[Stefan Hajnoczi]

On Thu, Jan 9, 2014 at 7:45 PM, kausik pal <kausikpal.1@gmail.com> 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

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

[kausik pal]

[-- Attachment #1: Type: text/plain, Size: 6117 bytes --]

Hi stefan,

Thanks a lot for the elaborate explanation.

>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

I completely agree with you for the point mentioned above. The topmost
image file must be read write.

How about giving the end user a read-write layer on the top. The scenario
would be like the following :-

win-base <- vm01 <- firefox <- winscp <- User1 Disk (Read-write)   (given
to user1)
win-base <- vm02 <- winscp <- 7zip <- User2 Disk (Read-write) (given to
user2)

So if the user invokes the command 'hostname' of 'ipconfig' etc. the
results would be read from 'vm01' disk, and if the user initializes firefox
or winscp the applications would be invoked from the respective disks.

I also agree with you about  the point 1 regarding registry. I hope
'libguestfs' which is an excellent tool, would be able to compose registry
files from different layers.

Actually I'm trying design a new VDI architecture comprising of some open
source tools and will be based on oVirt/RHEV.

At present in the architecture most of components are available either with
their full blown feature or in a stage of minimum viable product.The only
missing component is the "detachable overlays" as being discussed in this
mail chain.

If the above mentioned QEMU/KVM overlay feature can be made into existence
then we can bring out a cost effective VDI management or VM management
solution that can compete with the commercial vendors.

Looking forward for your thought regarding this.

Thanks
Kausik





On Fri, Jan 10, 2014 at 7:05 AM, Stefan Hajnoczi <stefanha@gmail.com> wrote:

> On Thu, Jan 9, 2014 at 7:45 PM, kausik pal <kausikpal.1@gmail.com> 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
>

[-- Attachment #2: Type: text/html, Size: 7576 bytes --]

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

[Stefan Hajnoczi]

[-- Attachment #1: Type: text/plain, Size: 798 bytes --]

On Jan 10, 2014 1:52 PM, "kausik pal" <kausikpal.1@gmail.com> wrote:
> If the above mentioned QEMU/KVM overlay feature can be made into
existence then we can bring out a cost effective VDI management or VM
management solution that can compete with the commercial vendors.

It's an interesting problem to solve. I suspect others would find
detachable overlays useful too.

I hope you want to develop this feature as open source software.

It's also in scope for a Google Summer of Code project. In that case a
student could work on the project for 12 weeks during the summer. More
requirements and design details need to be fleshed out before it can be
packaged as a GSoC project idea though.

Let me know if GSoC sounds like a good route to create this feature. Not
sure if it fits your timeframe.

[-- Attachment #2: Type: text/html, Size: 967 bytes --]

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

[kausik pal]

[-- Attachment #1: Type: text/plain, Size: 1670 bytes --]

hi Stefan,

Off course we can develop this feature as open source software.

Not sure whether GSoC would be a good route, because as far as I know GSoC
projects will be completed by coming October.

Please let me know of any other possible way we can work together (i.e.
organizational approach).

Basically myself a System Integrator and have very little knowledge of
coding, but I have worked with different Virtualization technologies and
have always found there are challenges/difficulties which the administrator
faces for their day to day activities.

I believe QEMU/KVM along with oVirt can address these challenges and have
the great potential to become a frontrunner in virtualization/VDI front.

Looking forward for you reply.

Thanks

Kausik







On Fri, Jan 10, 2014 at 3:50 PM, Stefan Hajnoczi <stefanha@gmail.com> wrote:

>
> On Jan 10, 2014 1:52 PM, "kausik pal" <kausikpal.1@gmail.com> wrote:
> > If the above mentioned QEMU/KVM overlay feature can be made into
> existence then we can bring out a cost effective VDI management or VM
> management solution that can compete with the commercial vendors.
>
> It's an interesting problem to solve. I suspect others would find
> detachable overlays useful too.
>
> I hope you want to develop this feature as open source software.
>
> It's also in scope for a Google Summer of Code project. In that case a
> student could work on the project for 12 weeks during the summer. More
> requirements and design details need to be fleshed out before it can be
> packaged as a GSoC project idea though.
>
> Let me know if GSoC sounds like a good route to create this feature. Not
> sure if it fits your timeframe.
>

[-- Attachment #2: Type: text/html, Size: 2370 bytes --]

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

[Stefan Hajnoczi]

On Sat, Jan 11, 2014 at 2:42 AM, kausik pal <kausikpal.1@gmail.com> wrote:
> Off course we can develop this feature as open source software.
>
> Not sure whether GSoC would be a good route, because as far as I know GSoC
> projects will be completed by coming October.
>
> Please let me know of any other possible way we can work together (i.e.
> organizational approach).
>
> Basically myself a System Integrator and have very little knowledge of
> coding, but I have worked with different Virtualization technologies and
> have always found there are challenges/difficulties which the administrator
> faces for their day to day activities.
>
> I believe QEMU/KVM along with oVirt can address these challenges and have
> the great potential to become a frontrunner in virtualization/VDI front.

I'm not sure if anyone will step forward to implement this feature in
their own time.

The options are:
1. Contributing code yourself or from your organization
2. Paying someone to do it (there are freelancers in the community who
take on custom projects)
3. Google Summer of Code
4. Waiting and hoping someone else will do 1, 2, or 3 sometime soon :)

Stefan