Bug 2033491

Summary:	[Machines] vm created by command with non-root user can not be listed on Virtual Machines page
Product:	Red Hat Enterprise Linux 9	Reporter:	Xianghua Chen <xchen>
Component:	util-linux	Assignee:	Karel Zak <kzak>
Status:	CLOSED NOTABUG	QA Contact:	Radka Brychtova <rskvaril>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	9.0	CC:	kkoukiou, kzak, skobyda, wshi, ymao, yunyang
Target Milestone:	rc	Keywords:	Reopened
Target Release:	---	Flags:	xchen: needinfo? (skobyda)
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2023-07-03 07:56:07 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Xianghua Chen 2021-12-17 02:05:19 UTC

Description of problem:
[Machines] vm created by command with non-root user can not be listed on Virtual Machines page 

Version-Release number of selected components (if applicable):
cockpit-machines-256-1.el9.noarch
cockpit-258-1.el9.x86_64
libvirt-dbus-1.4.1-5.el9.x86_64

How reproducible:
100%

Steps to Reproduce:
1. Create a non root user in wheel group by follow command

# useradd -G wheel admin
# passwd admin

2. Create the default pool directory for the new created user, then copy a image to this directory(use cirros.qcow2 in this case), make sure the owner of the dir&image is the new added user: admin

# mkdir -p /home/admin/.local/share/libvirt/images
# cp /var/lib/libvirt/images/cirros.qcow2 /home/admin/.local/share/libvirt/images/subVmTest1-2.img 
# chown admin -R /home/admin/.local/share/libvirt/images

3. Login cockpit with the new created user, then switch to machines page.
After that, switch to admin, create a session VM with the image copied in step 2(user command below)  :
# su - admin
# virt-install --connect qemu:///session --name subVmTest1 --os-variant cirros0.4.0 --boot hd,network --vcpus 1 --memory 128 --import --disk /home/admin/.local/share/libvirt/images/subVmTest1-2.img --graphics vnc,listen=127.0.0.1 --console pty,target_type=serial --console pty,target_type=virtio --noautoconsole

4. The new created vm is not shown on the vm page. Refresh the vm page, the new created vm still can not be listed.
But it can be listed by command: 
# virsh list --all
 Id   Name         State
----------------------------
 2    subVmTest1   running

Actual results:
As shown in step 4.


Expected results:
The vm should be listed on the cockpit-machines page after step 4.

Additional info:
Same problem on RHEL8&RHEL9.

Comment 1 Xianghua Chen 2022-06-20 12:10:06 UTC

It's ok on RHEL8.7 per yunyang's comments, with 
cockpit-machines-270-1.el8.noarch + RHEL-8.7.0-20220605.0 BaseOS x86_64

Only exist on RHEL9.1 now: 
cockpit-machines-269-1.el9.noarch + RHEL-9.1.0-20220608.0

Comment 2 Katerina Koukiou 2022-11-22 11:33:23 UTC

The bug is that running `su - username` does not start a proper Linux session, pam_systemd, and such -- and thus no $XDG_RUNTIME_DIR

IN specific to this bug, the virtqemud socket that gets started when the cockpit-machine page loads, is located at $XDG_RUNTIME_DIR. When the virt-install (or any virt-command runs from the CLI inside the `su - admin` session, it looks at XDG_RUNTIME_DIR, and since that isn't set, it just makes up some path in ~/.cache/libvirt/
The two sockets are completely independent from each other.

Minimal reproducer:

$ virsh -c qemu:///list --all
$ env -u XDG_RUNTIME_DIR virsh -c qemu:///list --all

The above two will create two separate daemons.The first one's socket is in /run/user/1000, the second in ~/.cache/libvirt/

Comment 3 Karel Zak 2023-01-17 17:56:44 UTC

Try 'runuser - username', it uses pam_systemd on Fedora/RHEL

# grep systemd /etc/pam.d/runuser-l 
-session	optional	pam_systemd.so

Comment 5 RHEL Program Management 2023-06-17 07:29:15 UTC

After evaluating this issue, there are no plans to address it further or fix it in an upcoming release.  Therefore, it is being closed.  If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.

Comment 10 Katerina Koukiou 2023-07-03 07:56:07 UTC

Closing as WONTFIX.  This issue is not reflecting some mainstream use case, and the user could use the UI and the embedded terminal with the connected user and avoid this.