-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Kubevirt-storage-checkup was failing when a virtual machine is already created. #41
Comments
Any update on this? |
Note you are using 4.18.0-rc.1 that has a known hotplug bug. |
Hi @arnongilboa, I tried setting the parm.vmiTimeout parameter to a 10-minute timeout but am still encountering the same issue.
Could you please let us know if there are any other configurations we should try to resolve this? Thank You.! |
@satyakonduri can you please share both the checkup vmi and the other vmi |
Hi @arnongilboa hotplug-volume-vm.log |
@satyakonduri ^^^ |
Thank you @arnongilboa! I will try this once a stable build is released. Just for your information, I executed the above steps in the 4.18-rc3 build. |
Any updates on this defect ? |
To verify the issue is not related to kubevirt-storage-checkup, you can simply create 2 VMs, hotplug a volume to one of them and check if it gets to |
Environment:
OCP cluster version: 4.18.0-rc.1
Openshift Virtualization version: 4.17.2
Only 1 driver storage class is present as default.
Case 1: Running this storage checkup without manually creating any Virtual Machines , the check is passing successfully. While running this test also verified manually that the PVCs being created were all in bound state and using my driver storage class.
Case 2: Creating 1 Virtual Machine manually as shown below and running storage checkup test, the checkup fails with error: hotplug volume ready:timed out waiting for the condition.
Seems not a driver issue as case 1 certifies that.
Why it is failing for case 2. Is it an expected behavior?
Is it related to rc builds that this test throws up this issue because when using Openshift virtualization version 4.17.2 with openshift cluster 4.17 case 2 passes as well.
The text was updated successfully, but these errors were encountered: