There is a similar error for channel.
Same packages as above.

1. attach_channel.xml 
<channel type="pty">
  <target name="virt-test.unix.channel" type="virtio" />
</channel>

2. With a running guest, do attach-device
# virsh attach-device --domain virt-tests-vm1 --file attach_channel.xml --persistent
Device attached successfully

3. DumpXML
# virsh dumpxml  virt-tests-vm1
    <channel type='unix'>
      <source mode='bind' path='/var/lib/libvirt/qemu/channel/target/virt-tests-vm1.org.qemu.guest_agent.0'/>
      <target type='virtio' name='org.qemu.guest_agent.0' state='disconnected'/>
      <alias name='channel0'/>
      <address type='virtio-serial' controller='0' bus='0' port='1'/>
    </channel>
+    <channel type='pty'>
+      <source path='/dev/pts/2'/>
+      <target type='virtio' name='virt-test.unix.channel'/>
+      <alias name='channel1'/>
+      <address type='virtio-serial' controller='0' bus='0' port='2'/>
+    </channel>

4. Destroy the guest and restart it, failed.
# virsh start virt-tests-vm1
error: Failed to start domain virt-tests-vm1
error: internal error: no assigned pty for device channel1

Smells to me like libvirt on power isn't correctly generating the command lines for these cases.  Can someone extract the qemu command lines that are generated in the failing cases so we can check?

Hi, David

libvirt-1.2.17-13.el7_2.2.ppc64le
qemu-kvm-rhev-2.3.0-31.el7_2.3.ppc64le
kernel-3.10.0-327.4.1.el7.ppc64le


1. Attach a console device successfully to a running guest
2. Destroy the guest
3. DumpXML for the guest
# virsh dumpxml virt-tests-vm1
    <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>
    <console type='pty'>
      <target type='virtio' port='1'/>
    </console>
4. Fail to start the guest and below is got from guest log.

2015-12-07 08:15:38.481+0000: starting up libvirt version: 1.2.17, package: 13.el7_2.2 (Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla>, 2015-11-23-07:44:56, ppc-029.build.eng.bos.redhat.com), qemu version: 2.3.0 (qemu-kvm-rhev-2.3.0-31.el7_2.3)
LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin QEMU_AUDIO_DRV=none /usr/libexec/qemu-kvm -name virt-tests-vm1 -S -machine pseries-rhel7.2.0,accel=kvm,usb=off -m 4096 -realtime mlock=off -smp 5,sockets=1,cores=5,threads=1 -uuid cb5bb9dd-3567-464c-8090-4690e80fe363 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-virt-tests-vm1/monitor.sock,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=2015-12-07T08:15:37,clock=host -no-shutdown -boot strict=on -device spapr-vscsi,id=scsi0,reg=0x1000 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x1 -usb -drive file=/home/zhwang/rhel7.2_http_virtio.qcow2,if=none,id=drive-virtio-disk0,format=qcow2 -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x6,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -netdev tap,fd=22,id=hostnet0 -device spapr-vlan,netdev=hostnet0,id=net0,mac=52:54:00:c4:e7:14,reg=0x2000 -chardev pty,id=charserial0 -device spapr-vty,chardev=charserial0,reg=0x30000000 -chardev socket,id=charchannel0,path=/var/lib/libvirt/qemu/channel/target/virt-tests-vm1.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 -chardev pty,id=charconsole1 -device virtconsole,chardev=charconsole1,id=console1 -device usb-kbd,id=input0 -device usb-mouse,id=input1 -device usb-tablet,id=input2 -vnc 0.0.0.0:0 -device VGA,id=video0,vgamem_mb=16,bus=pci.0,addr=0x4 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x3 -object rng-random,id=objrng0,filename=/dev/random -device virtio-rng-pci,rng=objrng0,id=rng0,max-bytes=1234,period=2000,bus=pci.0,addr=0x5 -global spapr-nvram.reg=0x3000 -msg timestamp=on
char device redirected to /dev/pts/6 (label charserial0)
char device redirected to /dev/pts/7 (label charconsole1)

This is really a libvirt bug as virtconsole works well with QEMU ppc64le.

Moreover, if we don't stop/start the guest after adding the virtconsole, it can be used to login (if we have a kernel with the good module and getty configured for this console).

The generated command line seems correct:

-device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x1
...
-chardev pty,id=charserial0 \
-device spapr-vty,chardev=charserial0,reg=0x30000000
...
-chardev pty,id=charconsole1 \
-device virtconsole,chardev=charconsole1,id=console1

It looks like libvirt is not able to start a guest with two PTY (of different kind?). Perhaps the missing "id=" for the spapr-vty can be a problem for libvirt?

My tests have been done using virt-manager.

Fixed upstream.

commit 5f65c96e8de95518d7a8d4cf3cedd9d6ab581f4f
Author: Shivaprasad G Bhat <sbhat.ibm.com>
Date:   Wed Oct 19 18:59:02 2016 +0530

    Allow virtio-console on PPC64
    
    virQEMUCapsSupportsChardev existing checks returns true
    for spapr-vty alone. Instead verify spapr-vty validity
    and let the logic to return true for other device types
    so that virtio-console passes.
    
    The non-pseries machines dont have spapr-vio-bus. So, the
    function always returned false for them before.
    
    Fixes - https://bugzilla.redhat.com/show_bug.cgi?id=1257813
    
    Signed-off-by: Shivaprasad G Bhat <sbhat.ibm.com>

v2.5.0-254-g5f65c96

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. Define and run a guest
# virsh  list --all
 Id    Name                           State
----------------------------------------------------
 5     dd               running

2. Attach a console device
The attach.xml is as below:
<console type="pty"><target port="1" type="virtio" /></console>

# virsh attach-device --domain dd --file attach.xml --persistent
Device attached successfully

3. Check the dumpxml of guest, a new <console> section is inserted for type virtio.
# virsh dumpxml dd
...

4. Destroy the guest and restart it again and no problem.
5. Also try to add another virtio channel.. The guest can start successfully and normal operations in the guest are ok.
    <console type='pty'>
      <source path='/dev/pts/3'/>
      <target type='virtio' port='1'/>
      <alias name='console1'/>
    </console>

    <channel type='pty'>
      <source path='/dev/pts/2'/>
      <target type='virtio' name='virt-test.unix.channel' state='disconnected'/>
      <alias name='channel1'/>
      <address type='virtio-serial' controller='0' bus='0' port='2'/>
    </channel>

So mark it pass.

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

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

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