On Mon, Jul 5, 2021 at 4:06 PM Strahil Nikolov <hunter86...@yahoo.com> wrote: > > >Disks on the export domain are never used by a running VM so there is > no reason to > preallocate them. The system should always use sparse disks when > copying to export > domain. > > >When importing disks from export domain, the system should reconstruct > the original disk > configuration (e.g. raw-preallocated). > > Hey Nir, > > I think you are wrong. In order to minimize the downtime , many users would > use storage migration while the VM is running, then they power off, detach > and attach on the new location , power on and live migrate while the VM works.
Live storage migration (move disk while vm is running) is possible only between data domains, and requires no downtime and no detach/attach are needed. I'm not sure if it is possible to export a vm to export domain when the vm is running, (maybe exporting snapshot works in 4.4). Anway, assuming you can export while the vm is running, the target disk will never be used by any vm. When the export is done, you need to import the vm back to the same or other system, copying the disk to a data domain. So we have: original disk: raw-preallocated on data domain 1 exported disk: raw-sparse or qcow2-sparse on export domain target disk: raw-preallocated on data domain 2 There is no reason to use a preallocated disk for the temporary disk created in the export domain. Nir