design proposal: new migration process for backend-storage PVCs

[jean-edouard]

NONE

[jean-edouard]

Hi @jean-edouard ! Thanks for this much-needed work. I have a few questions, whose answers can be incorporated into the proposal?

Thank you for the review! Comments answered in github, I will amend the design proposal to reflect them.

[jean-edouard]

This could also be a concern: https://github.com/libvirt/libvirt/blob/e40a533118efdc3d5f6fd1dcc9bb8143b54691e2/src/qemu/qemu_tpm.c#L571 (if the TPM is stored under a "shared" (nfs/ceph) storage, it looks like it's automatically considered as shared between the source and the target)

[mhenriks]

This could also be a concern: https://github.com/libvirt/libvirt/blob/e40a533118efdc3d5f6fd1dcc9bb8143b54691e2/src/qemu/qemu_tpm.c#L571 (if the TPM is stored under a "shared" (nfs/ceph) storage, it looks like it's automatically considered as shared between the source and the target)

Interesting. So could be possible to ask for a RWO FileSystem PVC, get nfs, and at migration time, data will not be copied to the new PVC?

I believe we've encountered a similar problem before, but the reverse. User requests RWX PVC but get ext4 because VM is scheduled on the same node as the nfs server. I believe LD_PRELOAD hacks were used to get around the issue until there was a proper fix

[kubevirt-bot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: Once this PR has been reviewed and has the lgtm label, please ask for approval from jean-edouard. For more information see the Kubernetes Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment Approvers can cancel approval by writing /approve cancel in a comment

[xpivarc]

/sig compute