Bug 212662 - Kernel does not re-activate paravirt console mapping during resume/migration
Kernel does not re-activate paravirt console mapping during resume/migration
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: xen (Show other bugs)
5.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Markus Armbruster
:
Depends On: 218050
Blocks: 234654 211911 211921 227613 240441
  Show dependency treegraph
 
Reported: 2006-10-27 17:39 EDT by Daniel Berrange
Modified: 2007-11-30 17:07 EST (History)
3 users (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:08:10 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)

  None (edit)
Description Daniel Berrange 2006-10-27 17:39:09 EDT
Cloning the original bug, to track the kernel console bits explicitly

+++ This bug was initially created as a clone of Bug #211911 +++

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:

-- Additional comment from berrange@redhat.com on 2006-10-23 17:10 EST --
A similar problem affects VNC console when doing (live) migration across hosts -
tracking in bug 211921

-- Additional comment from pm-rhel@redhat.com on 2006-10-26 15:02 EST --
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.

-- Additional comment from berrange@redhat.com on 2006-10-26 17:10 EST --
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.


-- Additional comment from berrange@redhat.com on 2006-10-26 21:57 EST --
Created an attachment (id=139545)
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 2 Markus Armbruster 2006-11-24 07:44:25 EST
Fixed in the latest patch submitted upstream.  Not yet merged there.
Comment 3 RHEL Product and Program Management 2006-11-27 21:51:47 EST
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 4 RHEL Product and Program Management 2006-11-27 21:51:47 EST
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 5 Markus Armbruster 2006-12-08 04:44:14 EST
Update to backport of latest upstream version (bz#218050) should resolve this.
Comment 7 Konrad Rzeszutek 2006-12-11 11:15:51 EST
(In reply to comment #5)
> Update to backport of latest upstream version (bz#218050) should resolve this.
> 

Markus,

In what RPM and version is the fix included? Or is it not yet there and being
back-ported right now?

Thank you.
Comment 8 Markus Armbruster 2006-12-11 12:02:19 EST
The backport is being tested and reviewed.  It's not yet committed.  Please be
patient.
Comment 9 Markus Armbruster 2006-12-19 13:24:30 EST
Now it is.
Comment 18 Markus Armbruster 2007-01-09 11:01:13 EST
Archana, could you try two things for me?

First:
1. launch guest
   find its domid (in virt-manager, or xm list)
2. xm migrate -l guest localhost
   find its new domid
   ps axlww | grep 'xen[-]'

Second: same, but migrate to a *different* machine instead of localhost.  Does
the  framebuffer work then?
Comment 24 Markus Armbruster 2007-01-23 10:48:14 EST
This problem seems to be a symptom of a more general problem.  I filed
bz 224004 for that, and made this one depend on it.
Comment 27 Markus Armbruster 2007-06-20 13:42:58 EDT
I believe the recent rebase of userland lower levels fixed this.  PVFB works
fine for me now when migrating to another host.  Switching to MODIFIED.

Migration to localhost doesn't work, but that's the entirely separate bug
224004.  I'm breaking the dependency on that bug.
Comment 30 errata-xmlrpc 2007-11-07 12:08:10 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.