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