A common question is does virt-v2v preserve sparseness (aka thin provisioning) when you convert the guest from VMware to a KVM-based hypervisor like oVirt/RHV or OpenStack? The very short answer is: “what?”. The medium answer is: The question doesn’t really make sense. For the long answer, read on …
First of all we need to ask what is thin provisioning? For complex and essentially historical reasons when you provision a new guest you have to decide how much maximum disk space you want it to have. Let’s say you choose 10 GB. However because a new guest install might only take, say, 1 GB, you can also decide if you want the whole 10 GB to be preallocated up front or if you want the disk to be thin provisioned or sparse, meaning it’ll only take up 1 GB of host space, but that will increase as the guest creates new files. There are pros and cons to preallocation. Preallocating the full 10 GB obviously takes a lot of extra space (and what if the guest never uses it?), but it can improve guest performance in some circumstances.
That is what happens initially. By the time we come to do a virt-v2v conversion that guest may have been running for years and years. Now what does the disk look like? It doesn’t matter if the disk was initially thin provisioned or fully allocated, what matters is what the guest did during those years.
Did it repeatedly fill up the disk and/or delete those files? – In which case your initially thin provisioned guest could now be fully allocated.
Did it have trimming enabled? Your initially preallocated guest might now have become sparsely allocated.
In any case VMware doesn’t store this initial state, nor does it make it very easy to find out which bits of the disk are actually backed by host storage and which bits are sparse (well, maybe this is possible, but not using the APIs we use when liberating your guests from VMware).
In any case, as I explained in this talk (slides) from a few years ago, virt-v2v tries to avoid copying any unused, zeroed or deleted parts of the disk for efficiency reasons, and so it will always make the disk maximally sparse when copying it (subject to what the target hypervisor does, read on).
When virt-v2v comes to creating the target guest, the default is to create a maximally sparse guest, but there are two ways to change this:
- You can specify the
-oa preallocatedoption, where virt-v2v will try to ask the target hypervisor to fully preallocate the target disks of the guest.
- For some hypervisors, especially RHV, your choice of backend storage may mean you have no option but to use preallocated disks (unfortunately I cannot give clear advice here, best to ask a RHV expert).
The basic rule is that when converting guests you need to think about whether you want the guest to be sparse or preallocated after conversion, based on your own performance vs storage criteria. Whether it happened to be thin provisioned when you set it up on VMware years earlier isn’t a relevant issue.
4 responses to “Does virt-v2v preserve sparseness?”
Might I suggest a rephrasing of the opening paragraph? Does virt-v2v *create* sparse images? Yes, unless told not to, or the backend doesn’t support it. Does virt-v2v query if the source disk is sparse vs. fully allocated and keep the same setting through the conversion? No.
Did I understand you correctly? Thanks Rich!
This is right yes. However the question I keep getting is does virt-v2v preserve a fictional “thin provisioning configuration setting” which users imagine that guests have. My main point is this isn’t how it works at all.
I’m looking at virt-v2v companion virt-p2v (althought it looks as if the virt-p2v uses the same engine – albeit boot from CD-ROM) One thing I’m observing is even if “sparse” is selected I end up with a result file that’s the same size as the physical disk. That’s not something I see with virt-v2v…
The other seen is it looks like its a sector by sector copy – and it seems to halt if it encounters a bad sector. I assumed/hoped that there was a way to skip back sectors…
Do you have any thoughts about the above…?
It’s a bit unclear what you mean by the result being the “same size”. This could be normal, it depends how you are measuring the disk size. Try using a tool like
qemu-img infowhich will show you the virtual and real sizes.
We don’t have a way to skip bad sectors, but it’s a possible future enhancement. I’ll forward the suggestion on.