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 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 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 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 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.
Fixed in the latest patch submitted upstream. Not yet merged there.
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.
Update to backport of latest upstream version (bz#218050) should resolve this.
(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.
The backport is being tested and reviewed. It's not yet committed. Please be patient.
Now it is.
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?
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.
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.
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