On 06/02/12 14:54, Peter Ross wrote:
Quoting "Toby Corkindale"<toby.corkindale@strategicdata.com.au>:
On 06/02/12 14:20, Trent W. Buck wrote:
Toby Corkindale wrote:
I'm giving btrfs another go now; pity about losing the block-based dedup (which is great when you have a lot of virtual machine images)
Um, cp --reflink=yes host0.img host1.img.
You don't get *de*dupping (yet), but if you explicitly tell btrfs that the new file should start off with the same blocks as the old file, they'll be non-dupped to begin with.
OK, granted, over time they will drift apart and dedupped would have helped if both VMs made the same changes to the same virtual blocks, but AFAICT --reflink solves the first 90% of the problem.
Ah, it might solve 90% of your problem, but it doesn't for most people, where a VM image is created from scratch via an ISO image of an installer, and then the VM has lots of patches and upgrades applied over time.
You can make a fresh install and a snapshot, that is subsequently used for cloning (so you avoid to install again and again).
Because you create a clone from the same snapshot again and again, you do not duplicate the space.
I rarely create a new image from scratch.
Yeah, but we're talking about virtual MACHINES here. They run. They change. Even if the base install is near enough to identical, after a year or so and the VMs have been release-upgraded, you've diverged from that original snapshot entirely -- yet all the images still share a lot of identical code if they're the same ubuntu/debian/whatever version. Although for those kind of VMs, I tend to use Linux Containers instead anyway; it's more often Windows machines in VM images, which don't enjoy having their images repeatedly cloned at all. (Well, not if you don't want the licensing system bitching at you all the time) -Toby