Bug 831939 - guest os crash after guest os open chardev pty
guest os crash after guest os open chardev pty
Status: CLOSED NOTABUG
Product: oVirt
Classification: Community
Component: vdsm (Show other bugs)
3.1 RC
Unspecified Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: Dan Kenigsberg
Haim
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-06-14 02:37 EDT by Xu He Jie
Modified: 2014-01-12 19:52 EST (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-06-17 14:21:54 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)

  None (edit)
Description Xu He Jie 2012-06-14 02:37:16 EDT
Description of problem:
Create Virtual macine use vdsm. when guest os startup graphic, the guest os crashed.

Version-Release number of selected component (if applicable):
fedora16 for host
fedora16 for guest
ubuntu 11.10 for guest
vdsm-4.10.0-0.32.git61ecfc0.fc16.x86_64
qemu-0.15.1-5.fc16.x86_64

How reproducible:
create vm with python script as below:

import vdsm.vdscli                                                              
s = vdsm.vdscli.connect()                                                       
                                                                                
vmId = 'f7c1b02f-b304-4e68-8565-3659b1214cba'                                   
boot_dev="d"                                                                    
img_location = [dict(path='/home/soulxu/VM/images/linux.img', device='disk', iface='virtio', format='cow')]
s.create(dict(vmId=vmId,                                                        
                  drives=img_location,                                          
                  macAddr="52:54:00:59:F5:3F",                                  
                  nicModel="e1000",                                             
                  bridge="virbr0",    # Use the libivrt default network         
                  memSize=1024,                                                 
                  display="vnc",                                                
                  vmName="vm1",                                                 
                  boot=boot_dev,                                                
                  vmType='kvm',                                                 
                  vmchannel='false',                                            
                  guest_agent_timeout=10,                                       
                       )                                                        
                  )

Steps to Reproduce:
1.
2.
3.
  
Actual results:
Guest os crashed when startup X window

Expected results:


Additional info:
This should be qemu's bug. It can reproduce with qemu 0.15.1, but it had already fix with qemu 1.1.50. 

Startup guest os with single mode. Then in terminal execute 'setsid agetty hvc0 9600' can reproduce this problem directly.

if use command 'screen' open the pty on host, then guest os can startup sccussful. if execute qemu with command line that copy from vdsm and remove the pty chardev, then guest os can startup sccussful.
Comment 1 Yaniv Kaul 2012-06-14 02:40:15 EDT
Would be helpful to get more information on the crash itself, the guest OS version, host and a lot more information on how to reproduce, but in any case, this is not a VDSM bug - I suggest you file it to the right component/project - qemu, for example, in Fedora (and if it already has a fix with newer qemu, what is the expectation here?
Comment 2 Xu He Jie 2012-06-14 02:51:06 EDT
(In reply to comment #1)
> Would be helpful to get more information on the crash itself, the guest OS
> version, host and a lot more information on how to reproduce, but in any

I add guest and host os version in "Version-Release number of selected component"
And more information in Additional info

> case, this is not a VDSM bug - I suggest you file it to the right
> component/project - qemu, for example, in Fedora (and if it already has a
> fix with newer qemu, what is the expectation here?
this can reproduce on qemu 0.15 with pty chardev, but vdsm depend on this version, and create vm with pty chardev, so we can should change require version of qemu, or other hack for pty chardev? I am not sure, so fire this bug to here.
Comment 3 Yaniv Kaul 2012-06-14 02:54:03 EDT
(In reply to comment #2)
> this can reproduce on qemu 0.15 with pty chardev, but vdsm depend on this
> version, and create vm with pty chardev, so we can should change require
> version of qemu, or other hack for pty chardev? I am not sure, so fire this
> bug to here.

Does VDSM RPM has hard dependency on that specific qemu version? If so, this is the BZ - please file it as such.
I'd also try to move to Fedora 17, if you use Fedora as a host. I'm surprised VDSM does not require a newer version of lvm2, which I thought is only available on F17.
Comment 4 Xu He Jie 2012-06-14 04:57:17 EDT
(In reply to comment #3)
> (In reply to comment #2)
> > this can reproduce on qemu 0.15 with pty chardev, but vdsm depend on this
> > version, and create vm with pty chardev, so we can should change require
> > version of qemu, or other hack for pty chardev? I am not sure, so fire this
> > bug to here.
> 
> Does VDSM RPM has hard dependency on that specific qemu version? If so, this
> is the BZ - please file it as such.
No, vdsm doesn't hard dependency on qemu 0.15. vdsm require qemu-kvm >= 2:0.15.0-4. I tested vdsm can work with qemu v1.1.0
> I'd also try to move to Fedora 17, if you use Fedora as a host. I'm
> surprised VDSM does not require a newer version of lvm2, which I thought is
> only available on F17.
I think I should move to f17, I get new version of lvm2 from http://comments.gmane.org/gmane.comp.emulators.ovirt.vdsm.devel/640
Comment 5 Dan Kenigsberg 2012-06-17 14:21:54 EDT
(In reply to comment #4)

> I think I should move to f17, I get new version of lvm2 from
> http://comments.gmane.org/gmane.comp.emulators.ovirt.vdsm.devel/640

I think it's best. Please reopen if you can specify something specific that vdsm 4.10 should fix.

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