Description of problem: When rebooting a (PV) domainU with the Virtual Machine Manager/Console while the serial console component is open, The serial console does not follow the virtual machine and stays at the old (defunct) vm. Version-Release number of selected component (if applicable): rhel5.1 prebeta How reproducible: every time Steps to Reproduce: 1. initiate a virtual machine manager session and start up a domU, with the serial console (VM Console -> view -> serial console) 2. reboot the domU 3. As it reboots watch the serial console window. Actual results: The serial console stays at the defunct session. Expected results: That the console would follow the domU through the reboot. Additional info: It's possible to attach the serial console to the new session by (VM Console -> view -> serial console) while or after the new boot.
This is still the case in beta 1.
Still seen in rc2.
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release.
Okay, I've reproduced this. I'll see if I can work up a fix.
Created attachment 317103 [details] Refresh serial console on domain reboot. This is the upstream cset that (inadvertently?) fixed this issue.
QE ack for 5.3.
we can reproduced this issue on rhel5.3s5 serial console do not follow VM
If i'm reading you right Peng, then this bug FAILS_QA. Please provide us with more details ASAP, as it's getting very late in the release cycle to do much else to get this fix in. We need to make a decision on what to do very quickly.
just follow the BUG Description and we hit the bug . we reboot the pv . graphical console will show the whole reboot process . but serial console dont
Hmm, seems to work here: # rpm -q kernel-xen xen virt-manager kernel-xen-2.6.18-126.el5 xen-3.0.3-78.el5 virt-manager-0.5.3-10.el5 My steps: 1) Start a pre-existing rhel5 x86_64 PV guest 2) When VNC console opens, go to View->Serial Console Startup output starts flowing on the serial console. 3) When serial console reaches a login prompt, login, run 'reboot' Watch shutdown output scroll by, VM momentarilly stops, VNC window and serial console remain open the whole time. 4) VM starts up, start up output starts flowing on serial console. I tried rebooting from inside the guest, use 'xm reboot', and using 'Shutdown' and 'Run' options from the virt-manager vnc window session, and it all worked for me. Does this look like what others are doing? Is anyone using non default preferences options in virt-manager?
I filed the original bug over a year ago. rhel5.1 xen was considerably different from rhel5.3 xen. I don't recall if it was even possible to do a graphical install when the bug was filed. Much has changed. For one thing, it appears that current versions do not allow you to use the serial console as a working console, it only displays boot messages. Probably a moot point as virt-manager allows you to access virtual consoles independent of the serial console. If the serial console is intended to be a live shell, then that is a different issue. Having just installed rhel5.3s5 and attempted to recreate the bug, I find that the serial console does in fact respond to a reboot and displays a booting system. I set this up with serial=ttyS0 and console=ttyS0 as boot options (separately) and the behavior is the same. From my point of view the original bug has been addressed.
Another install using rh5.3s5 and the serial console is quite usable. This is with console=ttyS0 as an append line in /boot/efi/efi/redhat/elilo.conf (ia64). So this issue appears to be fixed, as long as it makes it into a production release. I now find that a reboot command in serial console, a virtual console in the virt-manager console or via the X interface merely shuts down the pv. I'll file a different report on that.
Ok thanks, moving this bug back to on_qa then...
I'm going to revise my "works for me" comment #19. This works sometimes and doesn't sometimes. I can find no rhyme or reason for it. If I reboot 10 times, it's likely to follow the boot 5 times and need to be re-viewed the other 5. So I'm changing this to Fails_QA.
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 therefore 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/RHBA-2009-0137.html