Table guest_os_hypervisor (and/or guest_os) mixed up?

[mwaag]

Hi,

today i had a client whose vm wouldn't start again after a shutdown.

By investigating this, i found some kind of mismatch between guest_os-table and guest_os_hypervisor-table:

In fact, vmware stored "mandrake" for this vm in its .vmx

We had trouble before with a huge mixup / inconsistence between those two tables, but i was sure i fixed that (with deleting all user defined entries and copying new clean tables of a fresh installation before one of our latest version-upgrades.

I found the exact same situation in our testing-environment, that is different installation installation of original 4.19.x upgraded lately to 4.20.3.0.

"Fun Fact": I was only able to fix this with setting the vm's guest os in cloudstack to "Mandriva Linux", which has guest_os_id 360 which translates to the correct vmware-guest-os-type ubuntu64Guest in guest_os_hypervisor.

Could be anybody so kind check if this is the default situation in 4.19 / 4.20?

Thanks in advance
Markus

[weizhouapache]

on my env

mysql> select * from guest_os where id in (350,360);
+-----+-------------+------+--------------------------------------+------------------+---------------------+---------+-----------------+---------+
| id  | category_id | name | uuid                                 | display_name     | created             | removed | is_user_defined | display |
+-----+-------------+------+--------------------------------------+------------------+---------------------+---------+-----------------+---------+
| 350 |           7 | NULL | c88a5e98-e25c-4841-90f9-45be4e157fe4 | Mandrake Linux   | 2026-06-10 09:25:51 | NULL    |               0 |       1 |
| 360 |          10 | NULL | c49d1929-9d3e-4ddd-aaba-0888e4c37967 | Ubuntu 22.04 LTS | 2026-06-10 09:25:52 | NULL    |               0 |       1 |
+-----+-------------+------+--------------------------------------+------------------+---------------------+---------+-----------------+---------+
2 rows in set (0.00 sec)

[mwaag]

Hmm, okay, thank you. Seems like our tables are mixed up. Again.

[VectorPeak]

The screenshots do look like the VMware mappings are crossed: the Ubuntu guest OS row is resolving to mandrakeGuest, while the Mandriva row is resolving to ubuntu64Guest. That would explain why changing the VM to “Mandriva Linux” makes VMware receive the Ubuntu guest type.

Safer to verify/fix by name rather than by numeric ids:

select go.id, go.display_name, goh.hypervisor_type, goh.guest_os_name
from guest_os go
join guest_os_hypervisor goh on go.id = goh.guest_os_id
where goh.hypervisor_type = 'VMware'
 and (go.display_name like '%Ubuntu%' or go.display_name like '%Mandriva%')
order by go.display_name, goh.guest_os_name;

If those two are swapped in your DB, the correction should be on guest_os_hypervisor, not by changing the VM to Mandriva as a workaround. For example, update the VMware mapping so the Ubuntu guest_os_id points to ubuntu64Guest and Mandriva points to mandrakeGuest.

[mwaag]

Thank you. Yes, I know, fixing the guest_os_hypervisor is the better way (in fact, that was what we did last year, because we already had the joy to end up in this situation before). For now it was a quick and dirty fix, but i will have a look into that as soon i can spend some time on it.

[weizhouapache]

@mwaag
The records in guest_os_hypervisor are generated based on the guest_os table.

I think your database was still in a consistent state on 2026-05-05 (the creation time of the last record in guest_os_hypervisor), but some changes made afterwards seem to have left it in an inconsistent state.

[mwaag]

Ok, understand. BUT we did not intentionally changed the guest_os table. 2026-05-05 is the date of our upgrade to 4.20.3.0 though...

Any ideas, on what stage of an upgrade there is a risk of this? Especially because we have the exact same situation on our testing-installation (which is not connected to the productive instance in any way, but was updated some time before in the same way).

Unfortunately i didn't have time today for more intensive investigations but what caught my attention lately is that all vms now seems to have their host-name as os-type in the webinterface?

(edit: i just realised, this seems to be a bug, which was fixed for 4.21. #11075
Why not for 4.20?

[mwaag]

@weizhouapache
With the intention of fixing the problems first, would it be possible to just overwrite both tables with a version of a freshly installed cloudstack 4.20.3.0 or is this a bad idea?

like

db-host-of-a-fresh-instance: mysqldump cloud guest_os guest_os_hypervisor > cloudstack420_fresh_guestostables.sql
old-db-host: mysql cloud < cloudstack420_fresh_guestostables.sql

In fact: I did it this way last year to fix our database (and things went fine until the upgrade to 4.20.3.0).