I’m running OpenNebula 6.4 with vCenter / vSphere as the backend hypervisor. I deploy VMs from the OpenNebula Marketplace (Ubuntu, CentOS, etc.) and everything works fine.
My issue is with the VM Options → Guest OS Family / Version setting in vSphere. This is very important because:
In the OpenNebula VM template editor (General tab) there’s an option Enable hot resize for CPU/Memory.
Hot-resize in vSphere only works if the VM has the correct Guest OS identifier (guestId) set.
If the OS type is left as a generic Linux, hot-resize does not function reliably.
Questions:
Is there a way to specify the VMware guestId (e.g. ubuntu64Guest, centos7_64Guest, windows2019srv_64Guest) directly in the OpenNebula VM template so that it’s applied when the VM is deployed to vCenter?
If yes, what’s the correct template attribute/section (for example GUESTOS in the OS block)?
If not, is there a workaround (such as a driver customization or post-hook) to ensure the VM gets the right Guest OS identifier in vCenter?
My goal is to have the VMs created by OpenNebula with the proper Guest OS type in vSphere, so that hot-resize of CPU and memory can work without shutting down the VM.
Any guidance, examples, or documentation references would be very helpful.
Perhaps someone in the community has a solution floating around however this does not appear to be something that the old vCenter driver does having looking at the code. We also dropped support for it in newer versions so it’s not something we have been developing or plan to develop further.
You may be able to modify the deployment file at /var/lib/one/remotes/vmm/vcenter/deploy to get this in though. This document could be helpful although it just gives some basic information about the scripts: Virtualization Driver — OpenNebula 6.4.7 documentation
It seems like you could modify that deployment script to scan for the guest OS in the VM template, and then set the guestId appropriately using a case statement or something like that.
While I do understand your goal is to manage vCenter, more recent versions of OpenNebula no longer ship with the vCenter driver at all, however we have been developing a migration tool to move from vCenter to OpenNebula in a semi-automated way: GitHub - OpenNebula/one-swap: Migrate VMware workloads to OpenNebula/KVM , again I understand you’re working towards a specific goal but you may keep that in mind for the future if migration becomes an option for you. It would also allow you to update to the latest version of OpenNebula.
Thanks a lot for the detailed explanation and for pointing me in the right direction. I really appreciate you taking the time to clarify how the old vCenter driver works and what’s possible.
I’ll take some time to review the deployment script and explore whether there’s a practical workaround for this. If I manage to find a functional solution, I’ll make sure to share it here in this post so it might help others too.