spdinis commented on issue #9142: URL: https://github.com/apache/cloudstack/issues/9142#issuecomment-2303860433
Well, this actually makes a lot of sense for cases where the VM is an appliance. I'm at hands with a Cisco ISE appliance that simply won't install because it is expecting the hardware information to be outputted as KVM. An I'm sure there would be several other examples on the enterprise world and security appliances like this one where this would be the case. For reference this is Cisco community article documenting the issue. https://community.cisco.com/t5/network-access-control/cisco-ise-instalation-error/td-p/3091127 In many cases people could care less about cloud init specially when we are talking about enterprise world application where cloud init type of implementations really aren't a thing and you just want to spina VM from an ISO or based on a pre-existent template and there are no lack of examples in my company of specialized appliances we use for all sorts of things that are developed and maintained by the vendor. So being able to accommodate exception changes as we can do already with BIOS legacy vs UEFI, drivers, etc, will make sure that the platform becomes more flexible and universal, because you won't convince Cisco for example to change a KVM image to all potential flavors of orchestrated KVMs that are out there. This way we have 2 choices, either we maintain a clunky hardcoded thing with whatever implications, or we will have to find a dedicated solution like Proxmox, that is likely what we may have to endup doing for these cases, if we don't have a structured and supportable solution. And that kind of defeats the purpose of the CLoud Stack platform of being a one stop shop in on prem cloud. -- 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]
