Changed VolumeMode to PersistentVolumeBlock#1094
Conversation
|
Hi @Deblazz. Thanks for your PR. I am @kingmakerbot.
Make sure this PR appears in the CrownLabs changelog, adding one of the following labels:
|
Co-authored-by: abellonioandrea <s343884@studenti.polito.it> Co-authored-by: iliy27 <s347640@studenti.polito.it>
Deblazz
force-pushed
the
feature_vdd-fs-to-block
branch
from
7584d29 to
eceffde
Compare
|
/deploy-staging |
|
@Deblazz @abellonioandrea Sorry, I think I lost something, didn't you say on Tuesday that changing to Block was increasing by 100% the startup time? |
|
We are doing some tests, since with a loop disk (so that is not reflecting correctly the reality) seems that the time needed is higher. In any case, another point of our project is to allow Kubevirt VMs to be live migrated, and it is only possibile with the volume mode set to block and not with filesystem. |
This allows live migration to be enabled in KubeVirt
|
I'd say this can be almost merged, would just ask to write a brief test for your new method. |
|
I have just added an annotation, and now live migration it's working. |
| Annotations: map[string]string{ | ||
| PodBridgeNetworkLiveMigrationAnnotation: podBridgeNetworkLiveMigrationValue, |
There was a problem hiding this comment.
we're theoretically not using bridge mode, is this really needed?
There was a problem hiding this comment.
Without this, the live migration is not working
To be precise in the virtual machine I am getting this error:
cannot migrate VMI which does not use masquerade, bridge with kubevirt.io/allow-pod-bridge-network-live-migration VM annotation or a migratable plugin to connect to the pod network
There was a problem hiding this comment.
ok but we're supposed to be using masquerade actually...
There was a problem hiding this comment.
okay I didn't know, so it is only a problem related to the fact we are running vms manually in KubeVirt without the crownlabs infrastructure
There was a problem hiding this comment.
I will revert the changes
There was a problem hiding this comment.
can you please check just in case? I added self-edit on your tenant ns.
There was a problem hiding this comment.
I confirm that on a virtual machine in my tenant namespace I see the same error as before for the live migration enable
There was a problem hiding this comment.
I think that actually VMS are not in Masquerade but are in Bridge mode.
DefaultBridgeNetworkInterface must be changed to DefaultMasqueradeNetworkInterface.
There was a problem hiding this comment.
this explains several things. I'd say it's better to discuss this tonight at the weekly in order to understand together if there could be further implications by switching this...
|
/deploy-staging |
|
Your staging environment has been correctly deployed.
|
chaging working modality from pvc copy in dv to use pmp so the pvc is mirrored
|
/deploy-staging |
|
Your staging environment has been correctly deployed.
|
|
/deploy-staging |
|
Your staging environment has been correctly deployed.
|
|
/deploy-staging |
|
Your staging environment has been correctly deployed.
|
|
/deploy-staging |
|
Your staging environment has been correctly deployed.
|
|
/deploy-staging |
|
Your staging environment has been correctly deployed.
|
|
/deploy-staging |
|
Your staging environment has been correctly deployed.
|
|
/deploy-staging |
|
Your staging environment has been correctly deployed.
|
5 participants
Description
VolumeMode of VMs virtual disks migrated from Filesystem to Block type, to have less layers of abstraction between the running VM and ceph. Also, added the VMDataVolumeStorageClassName function to explicitly forge a StorageClassName used for the DataVolume.
How Has This Been Tested?
This configuration has been functionally tested by running a VM successfully and syntax checked by using make fmt and make vet.