Bug 2209321
| Summary: | Automatic workload update failed after upgrade from 4.11.4->4.12.3 | ||
|---|---|---|---|
| Product: | Container Native Virtualization (CNV) | Reporter: | Debarati Basu-Nag <dbasunag> |
| Component: | Virtualization | Assignee: | lpivarc |
| Status: | CLOSED NOTABUG | QA Contact: | Kedar Bidarkar <kbidarka> |
| Severity: | high | Docs Contact: | |
| Priority: | high | ||
| Version: | 4.12.3 | CC: | acardace, lpivarc, sgott |
| Target Milestone: | --- | Flags: | lpivarc:
needinfo?
(dbasunag) |
| Target Release: | 4.14.0 | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2023-08-14 13:09:27 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Comment 1
Debarati Basu-Nag
2023-05-23 22:31:12 UTC
Hi Debarati,
From the provided information I cannot conclude why the upgrade took unexpected time. The only relevant warning and facts which I would be interested to investigate are:
1. {"component":"virt-controller","kind":"","level":"warning","msg":"Migration target pod for VMI [test-upgrade-namespace/windows-vm-1684797613-5818446] is currently unschedulable.","name":"kubevirt-workload-update-8g2vb","namespace":"test-upgrade-namespace","pos":"migration.go:1092","timestamp":"2023-05-23T00:55:41.091782Z","uid":"d19b62e4-99b0-4fd9-b379-e4f7e8a0bc21"}
The log suggests the target Pod cannot be scheduled. It would be good to check why as this might be the root cause of why it took so long.
2. Migrations in flight. How long did they take and if they did succeed?
It would be great to reproduce this issue and provide cluster access in order to be able to investigate the points above.
|