Bug 1501450
Summary: | Race starting multiple libvirtd user sessions at the same time | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 7 | Reporter: | Sanjay Upadhyay <supadhya> |
Component: | libvirt | Assignee: | Michal Privoznik <mprivozn> |
Status: | CLOSED ERRATA | QA Contact: | Yanqiu Zhang <yanqzhan> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | 7.4 | CC: | chhu, dyuan, fjin, jdenemar, xuzhang, yafu, yalzhang, yanqzhan, zpeng |
Target Milestone: | rc | Keywords: | Upstream |
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | libvirt-4.5.0-12.el7 | Doc Type: | If docs needed, set a value |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2019-08-06 13:13:52 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
Sanjay Upadhyay
2017-10-12 15:15:05 UTC
Here are some more details, as I am able to reproduce it. create polkit poicy as such - /* Allow users in kvm group to manage the libvirt daemon without authentication */ polkit.addRule(function(action, subject) { if (action.id == "org.libvirt.unix.manage" && subject.isInGroup("wheel")) { return polkit.Result.YES; } }); restart libvirtd. 1. now login as a user, and create a VM. 2. Make the VM as autostart 3. Let the VM run for a 24 hrs. 4. Log into another window to the same window as the same user. 5. run virsh list --all (or any virsh command, which communicates to libvirtd). 6. Voila a new libvirtd --timeout=30 starts up and a new qemu-kvm with the same VM starts up. [root@ho301 ~]# su - stack Last login: Tue Oct 17 01:08:22 UTC 2017 from 10.60.17.37 on pts/2 [stack@ho301 ~]$ ps -f -C libvirtd,qemu-kvm,virtlogd UID PID PPID C STIME TTY TIME CMD root 1025 1 0 Oct10 ? 00:00:01 /usr/sbin/libvirtd stack 18474 1 0 00:52 ? 00:00:04 /usr/sbin/libvirtd --timeout=30 stack 19002 1 0 00:56 ? 00:00:00 /usr/sbin/virtlogd --timeout=30 stack 19013 1 99 00:56 ? 02:35:22 /usr/libexec/qemu-kvm -name undercloud -S -machine pc-i440fx-rhel7.0.0,accel=kvm,usb=off,dump-guest-core=off -cpu SandyBridge,+vme,+vmx,+osxsa After virsh list --all.. (this hangs..) [root@ho301 ~]# ps -f -C libvirtd,qemu-kvm UID PID PPID C STIME TTY TIME CMD root 1025 1 0 Oct10 ? 00:00:01 /usr/sbin/libvirtd stack 18474 1 0 00:52 ? 00:00:04 /usr/sbin/libvirtd --timeout=30 stack 19013 1 99 00:56 ? 02:36:34 /usr/libexec/qemu-kvm -name undercloud -S -machine pc-i440fx-rhel7.0.0,accel=kvm,usb=off,dump-guest-core=off -cpu SandyBridge,+vme,+vmx,+osxsa stack 26366 1 0 03:31 ? 00:00:00 /usr/sbin/libvirtd --timeout=30 stack 26457 1 0 03:31 ? 00:00:00 /usr/libexec/qemu-kvm -name undercloud -S -machine pc-i440fx-rhel7.0.0,accel=kvm,usb=off,dump-guest-core=off -cpu SandyBridge,+vme,+vmx,+osxsa [root@ho301 ~]# date Tue Oct 17 03:33:01 UTC 2017 Now there are 2 sets of tap interfaces for the same VM and network gets broken. Use of autostart for session daemon is discouraged. Exactly beacuse session daemon may come and go. Fixed upstream as: commit 61b4e8aaf1bce07f282c152de556c3d6aa8d65be Author: Michal Privoznik <mprivozn> AuthorDate: Mon Dec 17 14:42:51 2018 +0100 Commit: Michal Privoznik <mprivozn> CommitDate: Mon Dec 17 18:27:32 2018 +0100 src: Document autostart for session demon The autostart under session daemon might not behave as you'd expect it to behave. This patch is inspired by latest libvirt-users discussion: https://www.redhat.com/archives/libvirt-users/2018-December/msg00047.html Signed-off-by: Michal Privoznik <mprivozn> Reviewed-by: Daniel P. Berrangé <berrange> v4.10.0-92-g61b4e8aaf1 Verified with libvirt-debuginfo-4.5.0-12.el7.x86_64: #vim /usr/src/debug/libvirt-4.5.0/src/libvirt-domain.c 6687 /** 6688 * virDomainGetAutostart: 6689 * @domain: a domain object 6690 * @autostart: the value returned 6691 * 6692 * Provides a boolean value indicating whether the domain 6693 * configured to be automatically started when the host 6694 * machine boots. 6695 * 6696 * Please note that this might result in unexpected behaviour if 6697 * used for some session URIs. Since the session daemon is started 6698 * with --timeout it comes and goes and as it does so it 6699 * autostarts domains which might have been shut off recently. 6700 * 6701 * Returns -1 in case of error, 0 in case of success 6702 */ 6703 int 6704 virDomainGetAutostart(virDomainPtr domain, 6705 int *autostart) 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/RHSA-2019:2294 |