Repository navigation
Virtual Router fails to deploy with multi-hypervisor zone #7433
Description
ISSUE TYPE
- Bug Report
COMPONENT NAME
VR, Deployment Planner
CLOUDSTACK VERSION
4.18, All before 4.18
CONFIGURATION
Any zone with more than one cluster type: XenServer, KVM, VMware
OS / ENVIRONMENT
SUMMARY
STEPS TO REPRODUCE
1. Create a zone with two clusters of different hypervisor types XenServer/VMware ESXi/KVM
2. Disable One Cluster example: VMware
3. Deploy a virtual machine and create a new guest network, now both VM and VR are created on the XenServer/KVM cluster
4. Disable the XenServer/KVM cluster from Step 3
5. Retart the guest network with clean-up, the new virtual router fails to get created.
(This issue appears randomly(based on the logic mentioned below), retry a couple of times if this is not observed. )
EXPECTED RESULTS
The virtual router should get created
ACTUAL RESULTS
The virtual router fails to get created.
The same could affect SystemVMs as well, the issue is appearing due to the current deployment logic where the new virtual router hypervisor type is decided even before checking if there is any available/suitable host of the same type in the zone and this won't be retried.
Example from logs:
Allocating the VR with id=6 in datacenter Zone .......with the hypervisor type KVM
Deploy avoids pods: [], clusters: [2, 3], hosts: [] , <---- Disabled clusters KVM & VMware
Cluster: 1 has HyperVisorType that does not match the VM, skipping this cluster <---- XenServer Cluser
No clusters found after removing disabled clusters and clusters in avoid list, returning.
state transited from [Starting] to [Stopped] with event [OperationFailed]
Activity
weizhouapache commentedon Apr 14, 2023
@rajujith
rajujith commentedon Apr 14, 2023
@weizhouapache steps got only two clusters since it is the minimum required, my setup has 3 clusters and it can happen if at least one cluster is disabled if it is the only cluster of the same type. The issue continues to appear if the "system.vm.default.hypervisor" value is KVM and the KVM cluster is either disabled or all KVM hosts are in alert/disconnected. If this value is changed to a cluster type that is known to be working this can be considered a workaround but not a permanent fix right? One would assume that cloudstack could create the virtual router in any available cluster.
weizhouapache commentedon May 5, 2023
@rajujith
can you confirm if the issue can be fixed by setting "system.vm.default.hypervisor" in global configuration ?
rajujith commentedon May 8, 2023
@weizhouapache the issue can be fixed by setting the "system.vm.default.hypervisor" value to an available cluster type once the issue appears but it can't be avoided using this setting.
weizhouapache commentedon May 8, 2023
@rajujith
thanks for your confirmation.
I will leave this open, and added the label "status:has-work-around"
weizhouapache commentedon Aug 25, 2023
fixed by #7877