weizhouapache commented on pull request #6101:
URL: https://github.com/apache/cloudstack/pull/6101#issuecomment-1070860322


   > Hi Wei, Could you explain why we would want this. on the face of it, it 
doesn't seem a good idea. One of the biggest points of a Cloud Management 
Platform is to abstract the underlying hardware & hypervisor away from the 
users.
   
   Hi @PaulAngus 
   we have a customer issue. the customer has two clusters with different 
hypervisors. They want to deploy user VMs in the cluster A with hypervisor A 
but want the VR to be deployed in the cluster B with hypervisor B.
   since many years ago, cloudstack tries to deploy network VR using same 
deployment destination as user vm, the VRs are created with the same hypervisor 
as user vm, they cannot be started to another cluster because the hypervisor is 
different.
   
   The workaround is, deploy another user vm C in cluster B, after network VR 
is started in cluster B, deploy the user vm in Cluster A. The PR aims to 
provide a resolution.
   
   As said before, The scope of the new setting can be discussed. The higher 
level means bigger impact (e.g. Zone), the lower level means smaller impact 
(e.g. Network Offering or Account).
   
   CloudStack has some settings which impact the vm/vr allocation on hardware, 
some are visible to users (e.g. affinity group,dedication), some are not (e.g. 
host tags, storage tags). the account setting (not limited to this new setting) 
are not visible to users, but yes to root admins and domain admins.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


Reply via email to