Bug 1460101 - Output from spapr-vty were not entire while guest booted up & shutdown
Output from spapr-vty were not entire while guest booted up & shutdown
Status: NEW
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: qemu-kvm-rhev (Show other bugs)
7.4
ppc64le Linux
low Severity low
: rc
: ---
Assigned To: David Gibson
Min Deng
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2017-06-09 02:42 EDT by Min Deng
Modified: 2017-08-01 04:58 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-06-13 21:52:41 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Screenshot (146.61 KB, image/png)
2017-06-09 02:43 EDT, Min Deng
no flags Details

  None (edit)
Description Min Deng 2017-06-09 02:42:40 EDT
Description of problem:
Output from spapr-vty were not entire while guest booted up & shutdown

Version-Release number of selected component (if applicable):
qemu-kvm-rhev-2.9.0-9.el7.ppc64le
kernel-3.10.0-675.el7.ppc64le
SLOF-20170303-4.git66d250e.el7.noarch

How reproducible:
2
Steps to Reproduce:
1.boot up guest with (tcp or unix option)
  "...-nodefaults -vga std -chardev socket,id=serial_id_serial0,host=127.0.0.1,port=12345,server,nowait -device spapr-vty,chardev=serial_id_serial0..."

2.nc 127.0.0.1 12345 on host

3.check output of spapr-vty
  Have a look on attachment.

Actual results:
Missing some logs while guest boots up or shutdown,please have a look on the attachment.

Expected results:
All useful logs should be printed via spapr-vty.

Additional info:
Titled with [OK] relevant logs are all missed.
Comment 2 Min Deng 2017-06-09 02:43 EDT
Created attachment 1286309 [details]
Screenshot
Comment 3 David Gibson 2017-06-11 22:03:31 EDT
Could you give the full qemu command line used.

I think this is just because the guest is choosing to use the vga rather than the spapr-vty as the main console, and so most of the logs do not go to spapr-vty.

If you remove the VGA device, I think all the messages will go to spapr-vty.
Comment 4 Min Deng 2017-06-12 04:51:56 EDT
(In reply to David Gibson from comment #3)
> Could you give the full qemu command line used.
> 
> I think this is just because the guest is choosing to use the vga rather
> than the spapr-vty as the main console, and so most of the logs do not go to
> spapr-vty.
> 
> If you remove the VGA device, I think all the messages will go to spapr-vty.

Hi David,
   The full command line is as following,
   /usr/libexec/qemu-kvm -name avocado-vt-vm1 -chardev socket,id=qmp_id_qmpmonitor1,path=/tmp/monitor-qmpmonitor1,server,nowait -mon chardev=qmp_id_qmpmonitor1,mode=control -sandbox on -machine pseries-rhel7.4.0 -nodefaults -device nec-usb-xhci,id=usb1,bus=pci.0,addr=0x3 -device usb-kbd,id=input0 -device usb-mouse,id=input1 -drive id=drive_image1,if=none,snapshot=off,aio=native,cache=none,format=qcow2,file=rhel74-ppc64le-virtio-scsi-latest.qcow2 -device virtio-blk-pci,id=image1,drive=drive_image1,bootindex=1,bus=pci.0,addr=0x4 -device spapr-vlan,mac=9a:93:94:95:96:97,id=idpWdRJ9,netdev=idkTBKmY -netdev tap,id=idkTBKmY,vhost=on,script=/etc/qemu-ifup,downscript=/etc/qemu-down,id=hostnet1 -device virtio-scsi-pci,id=virtio_scsi_pci0,bus=pci.0,addr=0x6 -device usb-tablet,id=usb-tablet1,bus=usb1.0,port=4 -vnc :11 -rtc base=utc,clock=host -boot order=cdn,once=d,menu=off,strict=off -enable-kvm -monitor stdio -monitor unix:/tmp/monitor3,server,nowait -qmp tcp:0:4444,server,nowait -m 8G,slots=32,maxmem=80G -chardev socket,id=console0,path=/tmp/console0,server,nowait -device spapr-vty,chardev=console0 -chardev socket,id=serial1,host=127.0.0.1,port=12340,server,nowait,telnet -device spapr-vty,chardev=serial1 -chardev pty,id=serial2 -device spapr-vty,chardev=serial2 -chardev file,id=serial3,path=/tmp/serial3.txt -device spapr-vty,chardev=serial3 -chardev null,id=serial4,path=/tmp/serial4,server,nowait -device spapr-vty,chardev=serial4 -chardev socket,id=serial5,path=/tmp/serial5,server,nowait -device spapr-vty,chardev=serial5   -device spapr-vty,chardev=serial6 -chardev socket,id=serial6,host=127.0.0.1,port=12341,server,nowait,telnet  -chardev pty,id=serial7 -device spapr-vty,chardev=serial7 -vga std

   If the full of message will be printed while setting
"-vga none",does it work as design if the vga is available only part of logs will be printed through spapr-vty device.

Min
Comment 5 David Gibson 2017-06-13 21:52:41 EDT
Yes, this is expected behaviour.  Only early boot messages go to the vty console unconditionally.  later messages go to the default console which will be VGA if VGA is present.

You can make the messages go to the VTY console either by removing VGA (as in comment 4) or by adding "console=hvc0" to the kernel command line.
Comment 6 Min Deng 2017-06-15 04:26:27 EDT
Thanks for your information and QE still need to raise one issue here.
QE found different phenomenon in rhel6.9BE guest while setting "-vga none" 

1.CLI,
/usr/libexec/qemu-kvm -name avocado-vt-vm1 -vga std -sandbox off -machine pseries-rhel7.4.0 -nodefaults -device nec-usb-xhci,id=usb1,bus=pci.0,addr=0x3 -device usb-kbd,id=input0 -device usb-mouse,id=input1 -drive id=drive_image1,if=none,snapshot=off,aio=native,cache=none,format=qcow2,file=rhel69-ppc64-virtio-scsi.qcow2 -device virtio-blk-pci,id=image1,drive=drive_image1,bootindex=1,bus=pci.0,addr=0x4 -device spapr-vlan,mac=9a:93:94:95:96:97,id=idpWdRJ9,netdev=idkTBKmY -netdev tap,id=idkTBKmY,vhost=on,script=/etc/qemu-ifup,downscript=/etc/qemu-down,id=hostnet1 -device virtio-scsi-pci,id=virtio_scsi_pci0,bus=pci.0,addr=0x6 -device usb-tablet,id=usb-tablet1,bus=usb1.0,port=4 -vnc :11 -rtc base=utc,clock=host -boot order=cdn,once=d,menu=off,strict=off -enable-kvm -monitor stdio -monitor unix:/tmp/monitor3,server,nowait -qmp tcp:0:4444,server,nowait -m 4G -chardev socket,id=console0,path=/tmp/console0,server,nowait -device spapr-vty,chardev=console0 -vga none -vnc 0:10 -msg timestamp=on

2.A listener on host,
nc -U /tmp/console0

Log stopped here,since there wasn't any VGA device there was a problem for user to login guest,in a word,how to login guest via spapr-vty device.Does it work as designed as well ?

Initializing XFRM netlink socket
NET: Registered protocol family 17
turn off boot console udbg0
eth0      Link encap:Ethernet  HWaddr 9A:93:94:95:96:97  
          inet addr:10.16.47.219  Bcast:10.16.47.255  Mask:255.255.248.0
          inet6 addr: 2620:52:0:102f:9893:94ff:fe95:9697/64 Scope:Global
          inet6 addr: fe80::9893:94ff:fe95:9697/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:649 errors:0 dropped:0 overruns:0 frame:0
          TX packets:18 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:54571 (53.2 KiB)  TX bytes:2194 (2.1 KiB)
          Interrupt:22 

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
Comment 7 David Gibson 2017-06-15 23:08:53 EDT
Min,

The command line shown includes both "-vga std" (first line) and "-vga none" (last line).  I'm not sure which will take precedence.  I think you need to pick one to get meaningful results.
Comment 8 Min Deng 2017-06-16 05:50:10 EDT
(In reply to David Gibson from comment #7)
> Min,
> 
> The command line shown includes both "-vga std" (first line) and "-vga none"
> (last line).  I'm not sure which will take precedence.  I think you need to
> pick one to get meaningful results.
  
 1. The "-vga none" took effect.
 2. Tried the cli with "-vga none" again,the issue still be reproduced,thanks.
 CLI,
 /usr/libexec/qemu-kvm -name avocado-vt-vm1 -sandbox off -machine pseries-rhel7.4.0 -nodefaults -device nec-usb-xhci,id=usb1,bus=pci.0,addr=0x3 -device usb-kbd,id=input0 -device usb-mouse,id=input1 -drive id=drive_image1,if=none,snapshot=off,aio=native,cache=none,format=qcow2,file=rhel69-ppc64-virtio-scsi.qcow2 -device virtio-blk-pci,id=image1,drive=drive_image1,bootindex=1,bus=pci.0,addr=0x4 -device spapr-vlan,mac=9a:93:94:95:96:97,id=idpWdRJ9,netdev=idkTBKmY -netdev tap,id=idkTBKmY,vhost=on,script=/etc/qemu-ifup,downscript=/etc/qemu-down,id=hostnet1 -device virtio-scsi-pci,id=virtio_scsi_pci0,bus=pci.0,addr=0x6 -device usb-tablet,id=usb-tablet1,bus=usb1.0,port=4 -vnc :11 -rtc base=utc,clock=host -boot order=cdn,once=d,menu=off,strict=off -enable-kvm -monitor stdio -monitor unix:/tmp/monitor3,server,nowait -qmp tcp:0:4444,server,nowait -m 4G -chardev socket,id=console0,path=/tmp/console0,server,nowait -device spapr-vty,chardev=console0 -vga none -vnc 0:10 -msg timestamp=on
Comment 9 David Gibson 2017-07-04 03:10:41 EDT
Hi Min,

Sorry it has taken me so long to reply.

If the problem still appears with -vga none, then this looks like it might be a real bug (although more likely in the guest than the host).  Can you check a couple of things:

1) Does the problem appear if you remove the USB devices from the guest?

2) Does the problem appear if you add "console=hvc0" to the guest kernel command line?

That will help me to narrow down what component the problem originates in.
Comment 10 Min Deng 2017-07-07 03:56:57 EDT
(In reply to David Gibson from comment #9)
> Hi Min,
> 
> Sorry it has taken me so long to reply.
> 
> If the problem still appears with -vga none, then this looks like it might
> be a real bug (although more likely in the guest than the host).  Can you
> check a couple of things:
> 
> 1) Does the problem appear if you remove the USB devices from the guest?
     Yes,it still can be reproduced
> 
> 2) Does the problem appear if you add "console=hvc0" to the guest kernel
> command line?
     Yes,it still can be reproduced
> 
> That will help me to narrow down what component the problem originates in.

   Any issues please let me know,thanks a lot.
Comment 11 David Gibson 2017-07-09 21:34:17 EDT
Too late for 7.4 now, moving to pegas 1.0 & (possibly) 7.4.z.
Comment 12 David Gibson 2017-07-10 00:15:55 EDT
Oops, realized Pegas only supports a Pegas guest, whereas this bug occurs with a RHEL6 guest only.  I also don't think it's serious enough to justify z-series, so moving to RHEL 7.5.

Note You need to log in before you can comment on or make changes to this bug.