Repository navigation
router service offering tags are not honored #6084
Description
ISSUE TYPE
- Bug Report
COMPONENT NAME
Router Deployment
CLOUDSTACK VERSION
4.16
CONFIGURATION
Having both VMware and Xen clusters
custom offering for router with host tag: xen
Have a XenServer/xcp-ng host tagged with tag: xen
system.vm.default.hypervisor = XenServer
router.service.offering = [uuid-of-custom-offering]
SUMMARY
When a user has 2 types of hypervisors, and he wants to create VRs on one of the types (say Xen), he would create a host tag in the custom router offering and tag a xen host/cluster. Then they would change the system.vm.default.hypervisor to XenServer.
Steps
- set the configuration described
- deploy a vmware template in a newly created network
- observe the failure
EXPECTED RESULTS
deployment successful, router on xen
ACTUAL RESULTS
deployment fails, cloudstack tried to deploy an ova to xen
Activity
weizhouapache commentedon Mar 16, 2022
the current logic to start VRs is (since many years ago)
(1) find destination of user vm
(2) create VRs in the same cluster as user vm (so same hypervisor)
(3) start VRs
in step 2, the hypervisor type of VRs is set to the hypervisor of user vm (vmware in the example), therefore in stpe 3 it cannot be deployed in hosts with other hypervisors (e.g. in a xenserver cluster).
in my opinion, the results in the description is expected, this is not a bug. the offering tags are not considered in step 2, but tags are considered in step 3 which caused the failure deployment.
I would regard it as a feature request (the requirement needs to be discussed)
@nvazquez @borisstoyanov
nvazquez commentedon Mar 17, 2022
I think it is a limitation on the setting 'system.vm.default.hypervisor'. Since we have the option to let the administrators decide which hypervisor to use for system VMs then the current logic to start VRs could be adapted as well. IMO the step 1 could be extended to consider the value of this setting when finding a destination for the user VM (destination host hypervisor should be the same as the one in the setting). What do you think @weizhouapache @borisstoyanov ?
weizhouapache commentedon Mar 22, 2022
According to our discussion, this issue should has been fixed by #1839, but reverted by #4304
weizhouapache commentedon Apr 13, 2022
fixed by #6160