Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Checked in latest CI job for libvirt 2.0.1, with latest audit packages:
audit ppc64le 2.6.2-1.el7 brew_rhel-7.3-candidate 237 k
audit-libs ppc64le 2.6.2-1.el7 brew_rhel-7.3-candidate 84 k
The problem is fixed.
This bug is same with upstream bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1351995
which is closed with NOTABUG with require install audit >= 2.6.2-1, so feel free to close this one also.
(In reply to Wayne Sun from comment #2)
> Checked in latest CI job for libvirt 2.0.1, with latest audit packages:
s/2.0.1/2.0.0-1/
> audit ppc64le 2.6.2-1.el7 brew_rhel-7.3-candidate 237
> k
> audit-libs ppc64le 2.6.2-1.el7 brew_rhel-7.3-candidate 84
> k
>
> The problem is fixed.
>
> This bug is same with upstream bug:
> https://bugzilla.redhat.com/show_bug.cgi?id=1351995
>
> which is closed with NOTABUG with require install audit >= 2.6.2-1, so feel
> free to close this one also.
(In reply to Wayne Sun from comment #2)
> Checked in latest CI job for libvirt 2.0.1, with latest audit packages:
> audit ppc64le 2.6.2-1.el7 brew_rhel-7.3-candidate 237
> k
> audit-libs ppc64le 2.6.2-1.el7 brew_rhel-7.3-candidate 84
> k
>
> The problem is fixed.
>
> This bug is same with upstream bug:
> https://bugzilla.redhat.com/show_bug.cgi?id=1351995
>
> which is closed with NOTABUG with require install audit >= 2.6.2-1, so feel
> free to close this one also.
Closing as duplicate, thanks! :)
*** This bug has been marked as a duplicate of bug 1351995 ***
Description of problem: unprivileged user failed to start domain Version-Release number of selected component (if applicable): libvirt-1.3.5-1.el7.ppc64le qemu-kvm-rhev-2.6.0-11.el7.ppc64le kernel-3.10.0-327.el7.ppc64le How reproducible: always Steps to Reproduce: 1. # su - new_user $ virsh list --all Id Name State ---------------------------------------------------- - avocado-vt-vm1 shut off $ virsh dumpxml avocado-vt-vm1 <domain type='kvm'> <name>avocado-vt-vm1</name> <uuid>1c2363d5-90da-4f59-b1f8-25fbb4bec2d8</uuid> <memory unit='KiB'>1048576</memory> <currentMemory unit='KiB'>1048576</currentMemory> <vcpu placement='static'>2</vcpu> <os> <type arch='ppc64le' machine='pseries-rhel7.3.0'>hvm</type> <boot dev='hd'/> </os> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> <on_reboot>restart</on_reboot> <on_crash>restart</on_crash> <devices> <emulator>/usr/libexec/qemu-kvm</emulator> <disk type='file' device='disk'> <driver name='qemu' type='qcow2'/> <source file='/tmp/autotest.img'/> <target dev='vda' bus='virtio'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> </disk> <controller type='usb' index='0'> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> </controller> <controller type='pci' index='0' model='pci-root'/> <controller type='virtio-serial' index='0'> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> </controller> <interface type='bridge'> <mac address='52:54:00:f4:85:91'/> <source bridge='virbr0'/> <model type='virtio'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x0'/> </interface> <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> <input type='keyboard' bus='usb'/> <input type='mouse' bus='usb'/> <graphics type='vnc' port='-1' autoport='yes'> <listen type='address'/> </graphics> <video> <model type='vga' vram='16384' heads='1' primary='yes'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/> </video> <memballoon model='virtio'> <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/> </memballoon> <panic model='pseries'/> </devices> </domain> 2. start domain $ virsh start avocado-vt-vm1 error: Failed to start domain avocado-vt-vm1 error: Failed to connect socket to '/home/new_user/.cache/libvirt/virtlogd-sock': Connection refused some problem with virtlogd, as on x86_64 this works 3. start virtlogd under this user to workaround virtlogd problem $ virtlogd --daemon $ ps aux|grep virtlogd new_user 143900 0.0 0.0 209344 12032 ? Sl 05:08 0:00 virtlogd --daemon root 144096 0.0 0.0 209344 17024 ? Ssl 05:10 0:00 /usr/sbin/virtlogd new_user 146793 0.0 0.0 111040 2816 pts/0 S+ 05:48 0:00 grep --color=auto virtlogd 4. start domain again $ virsh start avocado-vt-vm1 error: Failed to start domain avocado-vt-vm1 error: internal error: /usr/libexec/qemu-bridge-helper --use-vnet --br=virbr0 --fd=24: failed to communicate with bridge helper: Transport endpoint is not connected stderr=libvirt: error : internal error: cannot apply process capabilities -1 Check virbr0 # brctl show bridge name bridge id STP enabled interfaces virbr0 8000.5254006a8738 yes virbr0-nic # virsh net-list --all Name State Autostart Persistent ---------------------------------------------------------- default active yes yes # cat /etc/qemu-kvm/bridge.conf allow virbr0 # virsh net-dumpxml default <network> <name>default</name> <uuid>3fd1334e-5d47-4058-a7c8-ec08c8949f79</uuid> <forward mode='nat'> <nat> <port start='1024' end='65535'/> </nat> </forward> <bridge name='virbr0' stp='on' delay='0'/> <mac address='52:54:00:6a:87:38'/> <ip address='192.168.122.1' netmask='255.255.255.0'> <dhcp> <range start='192.168.122.2' end='192.168.122.254'/> </dhcp> </ip> </network> Actual results: failed to start Expected results: succeed Additional info: