Bug 2090156 - Migration fails of VM's with VNC password > 8 chars
Summary: Migration fails of VM's with VNC password > 8 chars
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: vdsm
Classification: oVirt
Component: Core
Version: 4.50.0.13
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: ovirt-4.5.1
: ---
Assignee: Milan Zamazal
QA Contact: Qin Yuan
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2022-05-25 09:17 UTC by Jean-Louis Dupond
Modified: 2022-06-23 05:54 UTC (History)
6 users (show)

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.
Clone Of:
Environment:
Last Closed: 2022-06-23 05:54:58 UTC
oVirt Team: Virt
Embargoed:
pm-rhel: ovirt-4.5?
lsvaty: testing_plan_complete?


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github oVirt vdsm pull 226 0 None open virt: Fix long VNC passwords in vm_libvirt_hook.py 2022-06-01 18:58:59 UTC
Red Hat Issue Tracker RHV-46116 0 None None None 2022-05-25 09:33:19 UTC

Description Jean-Louis Dupond 2022-05-25 09:17:29 UTC
Description of problem:
When upgrading oVirt cluster from 4.4.10 to 4.5.0, some VM's failed to migrate to the new hosts.

After checking the logs it gave the following error:
unsupported configuration: VNC password is 12 characters long, only 8 permitted

This was fixed in bz#2064380 for newly generated passwords.
But if the password was still in the libvirt xml, the VM would not migrate.

A simple workaround is to reopen the console on upgraded ovirt-engine for all VM's that doesn't want to migrate.
But of couse it would be better if this was handled automatically.

Comment 1 Daniel Berrangé 2022-05-25 09:50:49 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.

Comment 2 Milan Zamazal 2022-06-01 19:06:49 UTC
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.

Comment 3 Jean-Louis Dupond 2022-06-01 19:42:58 UTC
(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.

Comment 4 Jean-Louis Dupond 2022-06-01 19:43:23 UTC
(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.

Comment 5 Milan Zamazal 2022-06-02 07:38:05 UTC
(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.

Comment 6 Qin Yuan 2022-06-17 23:50:43 UTC
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.

Comment 7 Sandro Bonazzola 2022-06-23 05:54:58 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.