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
