Bug 1421036 - Guest can not start with -chardev pty,id=charserial0 failure
Summary: Guest can not start with -chardev pty,id=charserial0 failure
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: libvirt
Version: 7.4
Hardware: ppc64le
OS: Linux
high
high
Target Milestone: rc
: ---
Assignee: Michal Privoznik
QA Contact: Virtualization Bugs
URL:
Whiteboard:
: 1427804 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-02-10 07:52 UTC by Dan Zheng
Modified: 2017-08-02 00:01 UTC (History)
8 users (show)

Fixed In Version: libvirt-3.1.0-1.el7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-08-01 17:21:45 UTC
Target Upstream Version:


Attachments (Terms of Use)
The guest XML fails to start the guest (2.38 KB, text/plain)
2017-02-10 07:52 UTC, Dan Zheng
no flags Details


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2017:1846 normal SHIPPED_LIVE libvirt bug fix and enhancement update 2017-08-01 18:02:50 UTC

Description Dan Zheng 2017-02-10 07:52:44 UTC
Created attachment 1248984 [details]
The guest XML fails to start the guest

Description of problem:
Guest can not be started. This is a regression.  libvirt-3.0.0-1.el7.ppc64le does not happen to this problem. And this is PPC only, not X86.

Version-Release number of selected component (if applicable):
libvirt-3.0.0-2.el7.ppc64le
qemu-kvm-rhev-2.8.0-3.el7.ppc64le
kernel-3.10.0-560.el7.ppc64le

How reproducible:
100%

Steps to Reproduce:
1. Define a guest using the XML in attachment
2. Start the guest and get failure.
# virsh start dd
error: Failed to start domain dd
error: internal error: qemu unexpectedly closed the monitor: 2017-02-10T20:38:05.063580Z qemu-kvm: -chardev pty,id=charserial0: Failed to create PTY: No such file or directory

3. If remove below sections in the XML, the guest can start successfully.
    <serial type='pty'>
      <target port='0'/>
      <address type='spapr-vio' reg='0x30000000'/>
    </serial>
    <console type='pty'>
      <target type='serial' port='0'/>
      <address type='spapr-vio' reg='0x30000000'/>
    </console>

# virsh start dd
Domain dd started


Actual results:
The guest fails to start.


Expected results:
The guest should start correctly.

Additional info:
Qemu log:

2017-02-10 20:38:05.030+0000: starting up libvirt version: 3.0.0, package: 2.el7 (Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla>, 2017-02-09-04:49:03, ppc-027.build.eng.bos.redhat.com), qemu version: 2.8.0(qemu-kvm-rhev-2.8.0-3.el7), hostname: ibm-p8-garrison-03.lab4.eng.bos.redhat.com
LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin QEMU_AUDIO_DRV=none /usr/libexec/qemu-kvm -name guest=dd,debug-threads=on -S -object secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-10-dd/master-key.aes -machine pseries-rhel7.4.0,accel=kvm,usb=off,dump-guest-core=off -m 1024 -realtime mlock=off -smp 2,sockets=2,cores=1,threads=1 -uuid 399f3797-e0a0-42f3-856e-00e5a62cece9 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-10-dd/monitor.sock,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -boot strict=on -device pci-ohci,id=usb,bus=pci.0,addr=0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x3 -drive file=/usr/share/avocado/data/avocado-vt/images/jeos-23-64.qcow2,format=qcow2,if=none,id=drive-virtio-disk0 -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -netdev tap,fd=24,id=hostnet0,vhost=on,vhostfd=26 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:3d:b3:48,bus=pci.0,addr=0x1 -chardev pty,id=charserial0 -device spapr-vty,chardev=charserial0,reg=0x30000000 -chardev socket,id=charchannel0,path=/var/lib/libvirt/qemu/channel/target/domain-10-dd/org.qemu.guest_agent.0,server,nowait -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 -device usb-kbd,id=input0,bus=usb.0,port=1 -device usb-mouse,id=input1,bus=usb.0,port=2 -vnc 127.0.0.1:0 -device VGA,id=video0,vgamem_mb=16,bus=pci.0,addr=0x6 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5 -msg timestamp=on
2017-02-10T20:38:05.063580Z qemu-kvm: -chardev pty,id=charserial0: Failed to create PTY: No such file or directory
2017-02-10 20:38:05.066+0000: shutting down, reason=failed

Comment 2 Andrea Bolognani 2017-02-15 15:22:43 UTC
The fix has been committed upstream:

commit ee6ec7824d168cfa28bd67f99772aa0a51473bb3
Author: Andrea Bolognani <abologna@redhat.com>
Date:   Tue Feb 14 15:46:23 2017 +0100

    qemu: Call chmod() after mknod()
    
    mknod() is affected my the current umask, so we're not
    guaranteed the newly-created device node will have the
    right permissions.
    
    Call chmod(), which is not affected by the current umask,
    immediately afterwards to solve the issue.
    
    Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1421036


Additional related changes have been committed as well:

commit e04bd5b6fccbbcb664b9af545fb5c4da3ead4c28
Author: Andrea Bolognani <abologna@redhat.com>
Date:   Tue Feb 14 14:42:54 2017 +0100

    spec: Require libacl when building the QEMU driver
    
    For the namespaces feature to work properly we need to be able
    to make a perfect copy of the original /dev, including ACLs.
    
    By adding a BuildRequires on libacl-devel we ensure that ACL
    support will be enabled at configure time and made available
    to the QEMU driver.

commit b57bd206b9bb5fbfb262609bde1a1a521e8aadd0
Author: Michal Privoznik <mprivozn@redhat.com>
Date:   Wed Feb 15 10:06:09 2017 +0100

    qemu_conf: Check for namespaces availability more wisely
    
    The bare fact that mnt namespace is available is not enough for
    us to allow/enable qemu namespaces feature. There are other
    requirements: we must copy all the ACL & SELinux labels otherwise
    we might grant access that is administratively forbidden or vice
    versa.
    At the same time, the check for namespace prerequisites is moved
    from domain startup time to qemu.conf parser as it doesn't make
    much sense to allow users to start misconfigured libvirt just to
    find out they can't start a single domain.
    
    Signed-off-by: Michal Privoznik <mprivozn@redhat.com>


Moving to POST.

Comment 4 Dan Zheng 2017-03-06 09:28:21 UTC
Test packages:

libvirt-3.1.0-1.el7.ppc64le
qemu-kvm-rhev-2.8.0-5.el7.ppc64le
kernel-3.10.0-578.el7.ppc64le

Steps:

1. Use the attachment file to define a guest.
Start the guest and guest can start up successfully.
Log on the guest and do regular operations, no problem.

2. remove two parts below and guest can also start up and be accessible.
    <serial type='pty'>
      <target port='0'/>
      <address type='spapr-vio' reg='0x30000000'/>
    </serial>
    <console type='pty'>
      <target type='serial' port='0'/>
      <address type='spapr-vio' reg='0x30000000'/>
    </console>

Qemu log:

No error.

Comment 5 Jiri Denemark 2017-03-06 17:59:02 UTC
*** Bug 1427804 has been marked as a duplicate of this bug. ***

Comment 6 errata-xmlrpc 2017-08-01 17:21:45 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2017:1846

Comment 7 errata-xmlrpc 2017-08-02 00:01:15 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2017:1846


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