Hide Forgot
Created attachment 1204743 [details] after migration, desktop crashed while terminal works well Description of problem: After migration, guest's Desktop GUI crash while terminal works well Version-Release number of selected component (if applicable): Host version: RHEL7.3-20160914.1 qemu-kvm-rhev-2.6.0-25.el7 SLOF-20160223-6.gitdbbfda4.el7.noarch Guest onfiguration: RHEL7.3-20160914.1 kernel:3.10.0-510.el7.ppc64le How reproducible: 1/7 Steps to Reproduce: 1.Boot a guest in src host and des host with the same command, and append the command :-incoming tcp:0:5802 2. 3. Actual results: the GUI on vncviewer crashed while terminal works well Expected results: Migration can finished and successfully, the GUI on vncviewer and terminal should work well both Additional info: the full command as follows: /usr/libexec/qemu-kvm \ -name 'avocado-vt-vm1' \ -sandbox off \ -nodefaults \ -machine pseries-rhel7.3.0 \ -vga std \ -device virtio-serial-pci,id=virtio_serial_pci0,bus=pci.0,addr=03 \ -device virtio-scsi-pci,id=scsi1,bus=pci.0,addr=0x4 \ -chardev socket,id=devorg.qemu.guest_agent.0,path=/tmp/virtio_port-org.qemu.guest_agent.0-20160516-164929-dHQ00mMM,server,nowait \ -device virtserialport,chardev=devorg.qemu.guest_agent.0,name=org.qemu.guest_agent.0,id=org.qemu.guest_agent.0,bus=virtio_serial_pci0.0 \ -device ich9-usb-ehci1,id=usb1,addr=1d.7,multifunction=on,bus=pci.0 \ -drive file=/root/R1.qcow2,if=none,id=blk1 \ -device virtio-blk-pci,scsi=off,drive=blk1,id=blk-disk1,bootindex=1 \ -drive id=drive_cd1,if=none,snapshot=off,aio=native,cache=none,media=cdrom,file=/root/RHEL7.3.iso \ -device scsi-cd,id=cd1,drive=drive_cd1,bootindex=2 \ -device virtio-net-pci,mac=9a:7b:7c:7d:7e:72,id=idtlLxAk,vectors=4,netdev=idlkwV8e,bus=pci.0,addr=05 \ -netdev tap,id=idlkwV8e,vhost=on,script=/etc/qemu-ifup,downscript=/etc/qemu-ifdown \ -m 8G \ -smp 8 \ -cpu host \ -device usb-kbd \ -device usb-mouse \ -qmp tcp:0:8882,server,nowait \ -vnc :2 \ -msg timestamp=on \ -rtc base=localtime,clock=vm,driftfix=slew \ -boot order=cdn,once=c,menu=off,strict=off \ -monitor stdio \ -enable-kvm
Xianxian, Could you check whether this is a ppc64le only bug? If so, please adjust the hardware filed. Thanks.
In addition, what exactly to you mean the "GUI crashed"? Were you using the existing vncviewer which was connected to the VM before migration? If so, you may need to reconnect. If not, what were the symptoms seen within the VNC on the crashed GUI? When you say the terminal kept working, what terminal do you mean? I don't see an spapr-vty device on your command line, so it doesn't look like you have the normal hypervisor console terminal.
(In reply to David Gibson from comment #3) > In addition, what exactly to you mean the "GUI crashed"? > > Were you using the existing vncviewer which was connected to the VM before > migration? If so, you may need to reconnect. > > If not, what were the symptoms seen within the VNC on the crashed GUI? > > When you say the terminal kept working, what terminal do you mean? I don't > see an spapr-vty device on your command line, so it doesn't look like you > have the normal hypervisor console terminal. 1."GUI crashed" means only desktop crashed via VNC; 2. No, I opened a new vncviewer after migration, not the existing vncviewer before migration; 3.the detail symptoms seen in VNC is as attachments; 4."terminal kept working" means that the guest works well via network connection, for example, ssh to guest in terminal can connect to guest and do other operation successfully
(In reply to Qunfang Zhang from comment #1) > Xianxian, > > Could you check whether this is a ppc64le only bug? If so, please adjust the > hardware filed. Thanks. I have tested in X86 10 times,and not reproduced this problem,so,this very likely is a only ppc BUG, I will change the hardware field to ppc64le
I've tried to reproduce this issue, but so far in vain: I installed a RHEL-7.4-20161124 with "Server with GUI" selection (i.e. GNOME desktop) in a qcow2 image, then booted the guest, logged in at the GDM screen, opened a gnome-terminal window, started "top" there (to see that the guest is still alive), and then ping-pong migrated the guest between two QEMU instances for 20 times. I did not see any guest crashes so far. Using qemu-kvm-rhev-2.6.0-27.el7.ppc64le and kernel-3.10.0-514.el7.ppc64le on the host. So some questions: 1) Can you still reproduce this issue with the current snapshot of RHEL 7.4 ? 2) Which command did you use for migration? Simply "migrate tcp:0:5802"? Or did you use something more sophisticated like postcopy migration? 3) What did you run in the guest? Did you log into the system and run something in the GNOME desktop environment, or was it just sitting at the GDM login screen? 4) Did you see this issue only once or can you reproduce it each ~7th boot? 5) When you reproduce it, could you please fetch /var/log/messages and/or the output of journalctl, and /var/log/Xorg.0.log from the system and attach it to this BZ? Or even take a crash dump of the system? Thanks!
(In reply to Thomas Huth from comment #7) > I've tried to reproduce this issue, but so far in vain: I installed a > RHEL-7.4-20161124 with "Server with GUI" selection (i.e. GNOME desktop) in a > qcow2 image, then booted the guest, logged in at the GDM screen, opened a > gnome-terminal window, started "top" there (to see that the guest is still > alive), and then ping-pong migrated the guest between two QEMU instances for > 20 times. I did not see any guest crashes so far. Using > qemu-kvm-rhev-2.6.0-27.el7.ppc64le and kernel-3.10.0-514.el7.ppc64le on the > host. > > So some questions: > > 1) Can you still reproduce this issue with the current snapshot of RHEL 7.4 ? > > 2) Which command did you use for migration? Simply "migrate tcp:0:5802"? Or > did you use something more sophisticated like postcopy migration? > > 3) What did you run in the guest? Did you log into the system and run > something in the GNOME desktop environment, or was it just sitting at the > GDM login screen? > > 4) Did you see this issue only once or can you reproduce it each ~7th boot? > > 5) When you reproduce it, could you please fetch /var/log/messages and/or > the output of journalctl, and /var/log/Xorg.0.log from the system and attach > it to this BZ? Or even take a crash dump of the system? Thanks! Hi,Thomas: 1)Does "the current snapshot of RHEL 7.4 ?" means only the guest with RHEL 7.4? or both host and guest with 7.4? please tell me the detail version,then, I will retest this case to check. At that moment, there were 3 guests booting at one host, and every guest has its own qcow2 disk, not snapshot. 2)The migrate command is "(qemu)migrate -d tcp:desIP:5802"; I didn't use other sophisticated migration, and every guest has its own qcow2 disk.The qcow2 is shared for guest in source host and destination host by nfs server between src and des. 3)Before do migration, I have logged into the guest via vnc and check the desktop is right,then I have exit vnc, and then opened a terminal to continue to do stress operation.During do migration, the 3 guests were stressed with command "stress --cpu 4 --io 4 --vm 2 --vm-bytes 128M". 4)This issue is prodeced only once, and I have test total 7 times; 5)As for 1), If I want to reproduce this bug, which version is batter for host and guest or you want to let me use?
Hi, sorry, I apparently forgot to take note of the RHEL version on the host and it has been reprovisioned inbetween, so I can not look it up anymore. But I'm pretty sure that it also was a RHEL 7.4 build already. Sorry also for the confusion with "snapshot" ... I did simply mean "the current version of RHEL 7.4" here, I did *not* mean to talk about the qcow2 snapshot feature. Could you please try to reproduce the bug by using the latest version of RHEL 7.4 on both, the guest and host? Thanks!
I agree with David, let's close this bug for now since it is not reproducible with the latest version anymore ... we can open it again in case the problem happens again.