Symptoms:
After rebasing VHI to the newer kernel starting from version 6.0 it became mandatory to specify the guest OS type in the VM's and images metadata.
Cause:
One of the reasons to make it mandatory was to provide proper Hyper-V enlightenments support for Windows guest VMs:
https://www.qemu.org/docs/master/system/i386/hyperv.html
Resolution:
In order to minimize disruptions and ensure VMs are running, creating and restoring from backups correctly on VHI 6.0+ it is required to ensure that each VM's:
- OS_TYPE value is not missing
- OS_TYPE value matches the actual guest OS type
- Image OS_TYPE value matches the actual guest OS type
If the OS_TYPE value is missing:
1) Check which VM has os_type attribute as blank, save each $VM_ID (uuid) which has it missing:
# su - postgres -c "psql nova" <<< "select uuid,os_type from instances where deleted='0' and os_type is NULL;"
2) Set/change* os_type value** for each $VM_ID where it is found absent to the correct one matching the running guest OS type.
For Windows VMs:
# su - postgres -c "psql nova" <<< "update instances set os_type='windows' where uuid='$VM_ID';"
For Linux VMs:
# su - postgres -c "psql nova" <<< "update instances set os_type='linux' where uuid='$VM_ID';"
* Making changes must be done from the primary VHI node
** os_type value for the VM metadata can be either 'windows' or 'linux'
Please note that in order to propagate these changes to the VM's configuration - it is required to stop/start (not reboot) the VM after the os_type tag was set/changed.
If the OS_TYPE value does not match the actual guest OS type:
1) If the os_type value of the VM is not blank - there is no way to automate VM's actual guest OS version retrieval to compare it with this value. Therefore it is required to manually look through each such VM one by one, and check if its actual guest OS differs from the os_type value.
Save each $VM_ID which has os_type value as not blank:
su - postgres -c "psql nova" <<< "select uuid,os_type from instances where deleted='0' and os_type is not NULL;"
2) Compare if os_type values from this list match the real guest OS type, and change them if they don't same way as described above for each $VM_ID.
If the image OS_TYPE value does not match the actual guest OS type:
1) Check that os_type attribute is not blank and has correct values in all existing images metadata, reflecting and matching the actual guest OS type. Save each $IMAGE_ID ($i) which has it blank or incorrect:
# for i in $(vinfra service compute image list -c id -f value); do echo ===$i===; vinfra service compute image show $i -c os_type -c os_distro; done
2) Set/change* os_type value** for each $IMAGE_ID where it is found absent/incorrect:
For Windows images:
# openstack --insecure image set --property os_type='windows' $IMAGE_ID
For Linux images:
# openstack --insecure image set --property os_type='linux' $IMAGE_ID
* Please note that in order to be able to utilize Openstack CLI - you have to source its credentials as described in our documentation.
** os_type value for images metadata can be either 'windows' or 'linux'
Once all above actions are executed - it will ensure guest OS boots properly after VM being migrated from earlier VHI versions, or restored from backups.