Does kubevirt support live migration of local disks?

[Cheng Chen]

Hello,

The hostDisk only supports raw format, not qcow2 format, and does not support live migration. 

The emptyDisk supports qcow2 format and live migration, but does not support specifying the qcow2 file path, and the disk is deleted when the virtual machine is shut down or deleted.

My requirement is: does kubevirt have a disk type that can combine the characteristics of hostDisk and emptyDisk? That is 

1. qcow2 format; 

2. Can specify the qcow2 file path on the host; 

3. Supports live migration; 

4. The disk is retained and not deleted when the virtual machine is shut down or deleted.

[Alexander Wels]

The short answer is no

The long answer is if you want persistence you should be using persistent volumes and persistent volume claims to store the VM disks. A long time ago we decided to use RAW disk images instead of qcow2 images. Having to deal with all the details of qcow2 images was not something we wanted to tackle given that most of the properties that make qcow2 useful could be pushed into the kubernetes storage layer, and depending on your storage provider you potentially got them for free (snapshots, etc).

So you should look for a CSI provisioner that gives you the properties you are looking for, and put your disks in that storage provisioner. Note if you want live migration, right now you will need a provisioner that supports ReadWriteMany volumes, otherwise you won't be able to live migrate.

--
You received this message because you are subscribed to the Google Groups "kubevirt-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubevirt-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubevirt-dev/2421cdb3-0ff2-4d61-ac8f-e0621b1f7903n%40googlegroups.com.

[Cheng Chen]

Thank you for the answer. I understand that ReadWriteMany is needed. My core question is, based on my previous understanding, for local disk migration, whether it's raw format or qcow2 format, the initiator of the migration is always libvirt/qemu. If using pvc, then libvirt/qemu will not be aware of the underlying local disk storage during migration, which will lead to failed live migration. Do you mean that through the CSI provider, the underlying storage can be made aware of the existence of local disks and perform migration accordingly?