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):
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.
The serial console stays at the defunct session.
That the console would follow the domU through the reboot.
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
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
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.