You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
fix: clean up first try disks before arch fallback retry - #14376
When a system vm cant be placed on hosts of the preferred architecture, it retries with the other architecture's template. The first try had already made a root disk and network cards for the vm, and nothing removed them. So the vm ended up with two root disks on the same slot and could not start on any host. This removes the first try's disks and network cards before the retry, for both the secondary storage vm and the console proxy.
Test:
KVM lab with one x86 cluster and one disabled aarch64 cluster, an aarch64 system vm template, and system.vm.preferred.architecture=aarch64. Destroy the console proxy so a new one is made. It cant be placed on aarch64, so it retries with the x86 template.
Also added a unit test for the new cleanup step. VirtualMachineManagerImplTest, ConsoleProxyManagerImplTest, SecondaryStorageManagerImplTest and SecondaryStorageManagerTest pass.
Before: the new console proxy keeps both root disks on slot 0 and every start fails:
Allocating Instance from Template: Template {"id":202,"name":"SystemVM Template (KVM) aarch64"} with hostname: v-4-VM and 3 networks
Unable to allocate proxy Console VM instance {"id":4,"instanceName":"v-4-VM"} with Template {"id":202,"name":"SystemVM Template (KVM) aarch64"}
Allocating Instance from Template: Template {"id":3,"name":"SystemVM Template (KVM)"} with hostname: v-4-VM and 3 networks
Unable to start VM on Host {"id":2,"name":"pr14376-n87-kvm-ol8-kvm2"} due to XML error: target 'vda' duplicated for disk sources '/mnt/8a552ad2-a4fe-375e-b1d1-803e4116c517/11d0ae80-ab12-4641-9970-968d3694d415' and '/mnt/ca52e25a-47cf-3f9d-ab89-96187f87b007/b017ec29-bf06-4aa5-987d-cff96135743c'
volume vm device_id state template
4 v-4-VM 0 Ready 202 (aarch64)
5 v-4-VM 0 Ready 3 (x86)
After: the aarch64 disk is removed before the retry. The console proxy gets one root disk and starts:
volume vm device_id state template
8 v-6-VM 0 Destroy 202 (aarch64)
9 v-6-VM 0 Ready 3 (x86)
v-6-VM Running
❌ Patch coverage is 71.42857% with 2 lines in your changes missing coverage. Please review.
✅ Project coverage is 20.21%. Comparing base (68cff97) to head (6bf7f24). ⚠️ Report is 62 commits behind head on main.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #14235
When a system vm cant be placed on hosts of the preferred architecture, it retries with the other architecture's template. The first try had already made a root disk and network cards for the vm, and nothing removed them. So the vm ended up with two root disks on the same slot and could not start on any host. This removes the first try's disks and network cards before the retry, for both the secondary storage vm and the console proxy.
Test:
KVM lab with one x86 cluster and one disabled aarch64 cluster, an aarch64 system vm template, and
system.vm.preferred.architecture=aarch64. Destroy the console proxy so a new one is made. It cant be placed on aarch64, so it retries with the x86 template.Also added a unit test for the new cleanup step.
VirtualMachineManagerImplTest,ConsoleProxyManagerImplTest,SecondaryStorageManagerImplTestandSecondaryStorageManagerTestpass.Before: the new console proxy keeps both root disks on slot 0 and every start fails:
After: the aarch64 disk is removed before the retry. The console proxy gets one root disk and starts: