Bug 2090156
Summary: | Migration fails of VM's with VNC password > 8 chars | ||
---|---|---|---|
Product: | [oVirt] vdsm | Reporter: | Jean-Louis Dupond <jean-louis> |
Component: | Core | Assignee: | Milan Zamazal <mzamazal> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | Qin Yuan <qiyuan> |
Severity: | high | Docs Contact: | |
Priority: | unspecified | ||
Version: | 4.50.0.13 | CC: | ahadas, berrange, bugs, dfodor, jean-louis, lsvaty |
Target Milestone: | ovirt-4.5.1 | Flags: | pm-rhel:
ovirt-4.5?
lsvaty: testing_plan_complete? |
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | vdsm-4.50.1.2 | Doc Type: | Bug Fix |
Doc Text: |
VMs with VNC created by older Engines could fail to migrate to newer hosts due to an incompatible VNC password length. This has been fixed and such VMs migrate now to updated hosts that have this fix.
|
Story Points: | --- |
Clone Of: | Environment: | ||
Last Closed: | 2022-06-23 05:54:58 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | Virt | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Jean-Louis Dupond
2022-05-25 09:17:29 UTC
NB, even if you've previously set a 12 char password for a VM, QEMU/VNC will have been ignoring everything after the 8th character. Technical reason: the VNC password is used as a single-DES key and that key is fixed at 8 bytes in length. The fix here is to simply read the existing password on running VM, truncate to 8 bytes, and set it as the new password, before migrating. Alternatively when providing the input XML for the target host to the migrate API, truncate the passwd at that point, which is probably even easier. Changing the domain XML before migrating is not possible, VMs created by older Engines most likely run on old hosts that wouldn't have such a fix. The proposed patch uses a libvirt hook to apply the fix on the migration destination, before the VM is created there. (In reply to Milan Zamazal from comment #2) > Changing the domain XML before migrating is not possible, VMs created by > older Engines most likely run on old hosts that wouldn't have such a fix. > The proposed patch uses a libvirt hook to apply the fix on the migration > destination, before the VM is created there. The engine sets the password? So it doesn't matter that the host is not updated? This is what the workaround does. It generates a new 8-char password when you reopen the console. And after that you can migrate the VM without issues. So another way would be to reset all the console passwords on upgrade or only those with >8 chars if we can look those up somewhere. (In reply to Milan Zamazal from comment #2) > Changing the domain XML before migrating is not possible, VMs created by > older Engines most likely run on old hosts that wouldn't have such a fix. > The proposed patch uses a libvirt hook to apply the fix on the migration > destination, before the VM is created there. The engine sets the password? So it doesn't matter that the host is not updated? This is what the workaround does. It generates a new 8-char password when you reopen the console. And after that you can migrate the VM without issues. So another way would be to reset all the console passwords on upgrade or only those with >8 chars if we can look those up somewhere. (In reply to Jean-Louis Dupond from comment #4) > The engine sets the password? So it doesn't matter that the host is not > updated? > This is what the workaround does. It generates a new 8-char password when > you reopen the console. > And after that you can migrate the VM without issues. Yes. > So another way would be to reset all the console passwords on upgrade or > only those with >8 chars if we can look those up somewhere. I think the host solution is easier than resetting all the passwords (I don't think we have an easy way to track which VMs use the old password). It's easier to implement and is more robust (it always works, no issues with temporarily unreachable hosts etc.). We also needn't check all the possible scenarios (waking from hibernation, snapshots, imported VMs, ...) and risk unanticipated situations. Verified with: vdsm-4.50.1.2-1.el8ev.x86_64 ovirt-engine-4.5.1.1-0.14.el8ev.noarch libvirt-8.0.0-5.module+el8.6.0+14495+7194fa43.x86_64 Steps: 1. Prepare 4.4 enviroment: - versions: ovirt-engine-4.4.9.5-0.1.el8ev.noarch vdsm-4.40.90.4-1.el8ev.x86_64 - 2 hosts, host1 and host2 - 1 VM configured with VNC console type running on host2, the VNC console has been opened at least once. 2. Upgrade the 4.4 engine to 4.5 3. Upgrade the 4.4 host1 to 4.5 4. Migrate the VM from host2 to host1 Results: The VM with VNC console opened at least once on 4.4 engine can be migrated to 4.5 host. This bugzilla is included in oVirt 4.5.1 release, published on June 22nd 2022. Since the problem described in this bug report should be resolved in oVirt 4.5.1 release, it has been closed with a resolution of CURRENT RELEASE. If the solution does not work for you, please open a new bug report. |