You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@TylerGillson thanks for filing this. we thought about it when trying to deal with TPM - we don't have a way to get it from RHV and even if we get it from vSphere, we won't be able to do much with that data. so asking users to specify the keys and use them this way would make sense, but if the users need to do that per-VM then it goes against the goal to ease mass migrations..
you propose to store it in the storage map because you saw a case that the keys are different for different datastores on the source environment? I'm ok with taking an assumption that the keys are not different per-VM but then I wonder if it wouldn't make more sense to set them per-plan or even per-provider
@ahadas thanks for considering it! I see your point about easing mass migrations. Putting the keys in the plan or provider makes sense to me, since multiple plans can be made if different keys exist for different datastores.
ahadas
changed the title
Support virt-v2v's --key flag for converting VMs with LUKS-encrypted disks
Migrate VMs with LUKS-encrypted disks from vSphere
Jun 2, 2024
Add support for specifying the
--key
flag forvirt-v2v
as per the virt-v2v docs:Possibly via an additional option in the
StorageMap
CRD?The text was updated successfully, but these errors were encountered: