Netbox plugin: sync Guest OS name with Netbox "platform" tag

[edaleand]

Is your feature request related to a problem? Please describe.
It would be nice with an ability to find which OSes are running on which XOA VMs in Netbox. For instance, when vulnerabilities are detected or EOLs are approaching admins could browse and find all XOA VMs running the OS in question.

Describe the solution you'd like
I believe syncing XOA Guest OS name -> Netbox Platform would provide this functionality.

Additional context
Guest OS names aren't always clean. For instance, I've noticed a lot or our Windows VMs have "Microsoft Windows Server 2019 Standard|C:\Windows|..." after the OS name. Some cleanup rules might be necessary for this to work as intended.

[pdonias]

Hi, with the latest version of the plugin, the platform field of the VMs should be populated with the VM's os_version.distro. Is that enough for your use case?

[edaleand]

Thanks!
Yes, perhaps. What is the latest version of the plugin? We are running v0.3.7.

[edaleand]

@pdonias I found the answer to my last question. I will ask about upgrading internally and test the feature.
Thanks!

[edaleand]

@pdonias we are now running v1.0.0 of the plugin. "Platform" field in netbox is indeed populated with main distro type (have a look at the image below). Great!

I would be nice to have it a bit more verbose though, like Ubuntu 16.04.7, as opposed to just "Ubuntu". Would that be possible?

[pdonias]

The issue with the verbose name is that it can vary a lot and one of the use cases of that field is to search all the VMs that are running a specific OS. For that use case, it's better if there are as few platform names as possible. A platform object also has a virtualmachine_count, which would become unusable if the platform names vary too much. But I agree it would also be nice to see the OS version, I wonder if we could fit that somewhere else.

[edaleand]

I get that. Fair points.

I wonder though. Looking at the information pulled from VMs: os_version major and minor could possibly be concatenated with distro for the API pull?

"os_version": {
                    "distro": "centos",
                    "major": "7",
                    "minor": "9",

or

"os_version": {
                    "distro": "windows",
                    "major": "10",
                    "minor": "0",

So platform in these cases would say centos 7.9 or windows 10.0? Wouldn't be too verbose in my opinion, but I realize I don't have all info here.

[pdonias]

I guess that could work! What about even only adding major? I think for some OS's like Windows, it would be enough but maybe for Linux distributions, it's too little information?

[edaleand]

I think you're right. Major version might be sufficient. After all, the main point would be to quickly find the amount of VMs running, say, CentOS 6 or Ubuntu 16 and to start planning for upgrades. Minor version is not that relevant.

I have looked through the examples from our setup. All Linux distros and major Windows versions behave as expected. I do find a couple of Windows weirdos though:

"os_version": {
                    "distro": "windows",
                    "major": "6",
                    "minor": "2",
                    "name": "Microsoft Windows Server 2012 R2 Standard

"os_version": {
                    "distro": "windows",
                    "major": "6",
                    "minor": "3",
                    "name": "Microsoft Windows 8.1 Pro

"os_version": {
                    "distro": "windows",
                    "major": "6",
                    "minor": "2",
                    "name": "Microsoft Windows Server 2016 Standard

[pdonias]

Looking a bit more into it, I found some other issues. For instance, in some cases, the major version isn't exposed at all by the guest tools, so you can end up with those platforms in Netbox:

• debian 9 (3 VMs)
• debian 11 (2 VMs)
• debian (2 VMs)

And that could be a problem because if you're checking the "debian" platform object in your Netbox interface, you might think that you only have 2 VMs running Debian, which isn't true.

[pdonias]

Regarding Windows versions: https://learn.microsoft.com/en-us/windows/win32/sysinfo/operating-system-version

[edaleand]

Hmm, I understand the problem. Do you think it's a dealbreaker for this?

Thanks for the Windows info! Learn something new every day :)

[pdonias]

I don't think it's a good idea to implement it like this without finding solutions to the problems we found as it would be confusing. One solution could have been if Netbox had added a platform version to their data models but it has been discussed before and is unlikely to ever be added. This could also be achieved with a custom field on the VM objects, what do you think?

[edaleand]

That might work, sure. I guess the custom fields should be possible to filter through a dropdown selection, as opposed to free text. I think that's possible, not sure about the dependencies on your end for that to work? Perhaps it's possible to automatically populate the values in the custom field as they are created from Xen?

Also, many admins might want to limit the amount of custom fields in their setup. Any chance of making that particular sync optional somehow?

[pdonias]

Yes, I think it would be an optional custom field: XO would check if the custom field exists and populate it if it does.

[pdonias]

There are many ambiguous version numbers that could unnecessarily split VM groups within Netbox so I'm closing this until we either find a better way to do this or the reported versions get more consistent.

Feel free to continue the discussion and suggest solutions :)