Bug 252359 - Prompted for VNC password after live migration
Prompted for VNC password after live migration
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: xen (Show other bugs)
5.1
x86_64 Linux
low Severity high
: ---
: ---
Assigned To: Chris Lalancette
Virtualization Bugs
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-08-15 12:19 EDT by Jason Solan
Modified: 2009-12-14 16:17 EST (History)
1 user (show)

See Also:
Fixed In Version: RHEA-2007-0635
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-11-07 12:11:24 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Simple patch that seems to fix it (584 bytes, patch)
2007-08-27 16:45 EDT, Chris Lalancette
no flags Details | Diff

  None (edit)
Description Jason Solan 2007-08-15 12:19:49 EDT
Description of problem:
After migrating a FV guest vm, I am prompted for a vnc password on the new
server, even though none is set in the config.

How reproducible:
always

Steps to Reproduce:
1. Set the following parameters in xend-config.sxp:
(vnc-listen '0.0.0.0')
(vncpasswd '')

Also enable relocation server with the correct ports/relocation addresses

2. Create a FV guest VM with parameters in the vm config:
vnc=1
vncunused=0
vncdisplay=9

3. Log into the vm using vnc:  dom0_1:9  to verify no password is prompted and
it is working

4. Migrate the domU.
  xm migrate -l domU dom0_2

5. After migration attempt to log into the vm using vnc on dom0_2:  dom0_2:9
  
Actual results:
Prompted for a password which does not exist

Expected results:
Not prompted for a password and let into the domU via vnc

Additional info:
If i set the vncpasswd parameter to an actual value, vnc after migration works
correctly.
I also have not tested this against a PV guest.
Comment 1 Chris Lalancette 2007-08-27 14:40:22 EDT
I'm fairly certain I know what this is now.  Basically when you do an "xm
create" of a guest with an empty vncpasswd, you get *no* entry in xenstore (you
can check by doing "xenstore-ls | grep -i vnc", and seeing that there is no
"vncpasswd" entry).  However, after a live migrate, if you do the same check,
you will see a "vncpasswd" with an empty string.  My guess is that because of
this, the QEMU device model actually gets vncpasswd of blank (or something along
those lines), when it really should be empty (== NULL).  I'm not quite sure how
to fix it yet, but that's the general problem.

Chris Lalancette
Comment 2 Chris Lalancette 2007-08-27 15:10:10 EDT
Arg, never mind my last comment.  It seems that the vncpasswd is getting set to
'None', which is the python None.  We fixed this before in the PVFB stuff, but
it seems to have cropped up again with the HVM stuff.  I just need to find out
what we did to fix it last time.

Chris Lalancette
Comment 3 Chris Lalancette 2007-08-27 16:45:10 EDT
Created attachment 174361 [details]
Simple patch that seems to fix it

Applying this patch to the xen package seems to fix the issue; the basic
problem was that we were adding a bogus "None" in the image string, which
includes vncpasswd.  This made it so that when you reach the remote side, it
was looking for a password of "None" (without the quotes).  That is, by the
way, the workaround.

Chris Lalancette
Comment 5 Daniel Berrange 2007-09-04 14:25:46 EDT
Fix built into

* Fri Aug 31 2007 Daniel P. Berrange <berrange@redhat.com> - 3.0.3-38.el5
- Avoid bogus VNC password prompts after migrate/restore (rhbz #252359)
Comment 8 errata-xmlrpc 2007-11-07 12:11:24 EST
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHEA-2007-0635.html

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