Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
For bugs related to Red Hat Enterprise Linux 5 product line. The current stable release is 5.10. For Red Hat Enterprise Linux 6 and above, please visit Red Hat JIRA https://issues.redhat.com/secure/CreateIssue!default.jspa?pid=12332745 to report new issues.

Bug 211911

Summary: Paravirt console missing after restoring a previously suspended guest
Product: Red Hat Enterprise Linux 5 Reporter: Daniel Berrangé <berrange>
Component: xenAssignee: Daniel Berrangé <berrange>
Status: CLOSED CURRENTRELEASE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 5.0CC: armbru, xen-maint
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: beta2 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-12-23 01:37:15 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 212662    
Bug Blocks: 211921    
Attachments:
Description Flags
Start VNC daemon upon restore none

Description Daniel Berrangé 2006-10-23 20:04:56 UTC 
Description of problem:
When restoring a guest from a saved image, the paravirt vnc console does not get
activated. Also the VNC feature appears set, the VNC daemon is not started, and
the vnc port is not present in xenstored

Version-Release number of selected component (if applicable):
xen-3.0.3-2.el5

How reproducible:
Always

Steps to Reproduce:
1. Find a domain 'somedomain' running the VNC paravirt console
2. Run  'virsh save somedomain somedomain.img'
3. Run  'virsh restore somedomain.img'
4. Try to connect to VNC

Actual results:
No VNC server running

Expected results:
VNC server running on an appropriate port (either explicit port, or randomly
allocated depending on guest config)

Additional info:
Comment 1 Daniel Berrangé 2006-10-23 21:10:54 UTC 
A similar problem affects VNC console when doing (live) migration across hosts -
tracking in bug 211921
Comment 2 RHEL Program Management 2006-10-26 19:02:08 UTC 
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux major release.  Product Management has requested further
review of this request by Red Hat Engineering, for potential inclusion in a Red
Hat Enterprise Linux Major release.  This request is not yet committed for
inclusion.
Comment 3 Daniel Berrangé 2006-10-26 21:10:06 UTC 
The saved VM image does contain most of the correct VNC settings - only the
password setting is missing. The main problem appears to be that the restore
process does not start up the VNC daemon for the guest.
Comment 4 Daniel Berrangé 2006-10-27 01:57:56 UTC 
Created attachment 139545 [details]
Start VNC daemon upon restore

This patch addresses two issues:

 - The VNC password was being wiped from the config. Stop doing this. Upstream
has a similar fix because it affects HVM reboots in similar way
 - The 'image' sub-object in the XenDomainInfo.py was never being re-created
during restoration. Thus the device model daemons were not being started. This
was not previously a problem since restore doesn't work with HVM anyway. Since
we started using device model daemons for paravirt too, though this was causing
the VNC daemon to not be started upon restores.

This sorts out the XenD bits of the problem, but doesn't quite get VNC working
again.

The next problem is in the kernel space, because the driver is not writing
details of its page-ref & event-channel into xenstore upon resume. eg these
settings:

   vfb = ""
    page-ref = "165784"
    event-channel = "6"
   vkbd = ""
    page-ref = "196818"
    event-channel = "7"

So, the VNC daemon starts up, but is unable to find the framebuffer details for
the guest.
Comment 5 Daniel Berrangé 2006-12-19 18:31:38 UTC 
This should now be operating correctly, as a result of the PVFB upgrade tracked
by bug 218050.
Comment 6 RHEL Program Management 2006-12-23 01:37:16 UTC 
A package has been built which should help the problem described in 
this bug report. This report is therefore being closed with a resolution 
of CURRENTRELEASE. You may reopen this bug report if the solution does 
not work for you.