Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
> From: Mark Woodward [mailto:markw at mohawksoft.com] > > I was thinking, on my drive into work, about your scenario. On the > surface it sounds like a pretty good use of snapshots, but it is > actually pretty bad. > > The assumed advantage is that there is some "gold copy" of a VM that > will be used for [n] snapshot VMs. It is a short term strategy. Since > there is no resolution process to re-merge changes in the "gold copy" > into the shapshots after the initial creation, you will inevitably fill > your snapshots with duplicative data. Hold on to the assumptions there. ;-) (see below) > Suppose you create a linux vm, and snapshot a number of times to create > virtual machines. In the lifetime of the VMs updates will be applied for > bug fixes and security. You will need to apply the updates to each > snapshot, individually, because there is no correlation of low level > disk blocks. After a few cycles, you will be losing any real advantage > of the snap shot. > > A "net boot" image with shared system components configured with dhcpd > and a mountable home directory is the most efficient and maintainable > solution for this sort of system. In the case of linux machines, duplicates of each other, which don't need machine-specific customizations to survive shutdowns, I fully agree. Make / a NFS mount for that matter. Then you're *really* avoiding duplicating data. ;-) The datacenter snapshot clones of VM's scenario is a really common use case for people using snapshots... Particularly in companies that are virtualizing the windows desktop, where there is no suitable alternative to support a network-mount or similar solution on the boot drive, where machines must join a domain and must survive individually after shutdowns etc. In the windows desktop scenario, if you're creating/destroying generic clone VM's with any regularity, the alternative is *actual* multiple copies of the same data on disk, for different VM's, plus all the time necessary to *actually* copy the data. So any amount of duplicate data (thanks to windows updates and so forth) that gets created incrementally on the fly repeatedly in multiple machines is just incidental, and better than the alternative. Also, who says there's no process to update the golden image? You apply changes to the golden image, and then use the new golden image as the basis for any new machines. As soon as all the clones of the old image are able to be deleted, you're free to delete the old golden image. If you want, you could promote the clones and delete the original golden... Even if it never gets deleted at all, some employee has been at the company for N years, and their VM is N years old... The only cost it has is some GB in the datacenter. So then you have to ask yourself if it would have actually been cheaper to have a physical desktop, and weigh the pros/cons, TCO, etc. To virtualize or not to virtualize...
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |