diff options
Diffstat (limited to 'results/classifier/118/hypervisor/1926596')
| -rw-r--r-- | results/classifier/118/hypervisor/1926596 | 97 |
1 files changed, 97 insertions, 0 deletions
diff --git a/results/classifier/118/hypervisor/1926596 b/results/classifier/118/hypervisor/1926596 new file mode 100644 index 00000000..be15ac13 --- /dev/null +++ b/results/classifier/118/hypervisor/1926596 @@ -0,0 +1,97 @@ +hypervisor: 0.974 +virtual: 0.965 +KVM: 0.961 +debug: 0.958 +graphic: 0.921 +VMM: 0.857 +user-level: 0.853 +ppc: 0.842 +device: 0.840 +performance: 0.827 +semantic: 0.807 +register: 0.802 +risc-v: 0.786 +permissions: 0.778 +PID: 0.774 +mistranslation: 0.759 +peripherals: 0.747 +kernel: 0.735 +architecture: 0.718 +x86: 0.702 +files: 0.702 +network: 0.700 +arm: 0.645 +vnc: 0.631 +socket: 0.615 +TCG: 0.574 +i386: 0.548 +assembly: 0.493 +boot: 0.457 + +qemu-monitor-event command gets stuck randomly + +We are using kvm virtualization on our servers, We use "qemu-monitor-command"(drive-backup) to take qcow2 backups and to monitor them we use "qemu-monitor-event" command +For eg:- +/usr/bin/virsh qemu-monitor-event VPSNAME --event "BLOCK_JOB_COMPLETED\|BLOCK_JOB_ERROR" --regex + +the above command stucks randomly (backup completes but still it is waiting) and because of which other vms backup are stucked until we kill that process. + +Can you suggest how can we debug this further to find the actual issue. + + +/usr/bin/virsh version + +Compiled against library: libvirt 4.5.0 +Using library: libvirt 4.5.0 +Using API: QEMU 4.5.0 +Running hypervisor: QEMU 2.0.0 + +cat /etc/os-release +NAME="CentOS Linux" +VERSION="7 (Core)" +ID="centos" +ID_LIKE="rhel fedora" +VERSION_ID="7" +PRETTY_NAME="CentOS Linux 7 (Core)" +ANSI_COLOR="0;31" +CPE_NAME="cpe:/o:centos:centos:7" +HOME_URL="https://www.centos.org/" +BUG_REPORT_URL="https://bugs.centos.org/" + +CENTOS_MANTISBT_PROJECT="CentOS-7" +CENTOS_MANTISBT_PROJECT_VERSION="7" +REDHAT_SUPPORT_PRODUCT="centos" +REDHAT_SUPPORT_PRODUCT_VERSION="7" + +The QEMU project is currently moving its bug tracking to another system. +For this we need to know which bugs are still valid and which could be +closed already. Thus we are setting the bug state to "Incomplete" now. + +If the bug has already been fixed in the latest upstream version of QEMU, +then please close this ticket as "Fix released". + +If it is not fixed yet and you think that this bug report here is still +valid, then you have two options: + +1) If you already have an account on gitlab.com, please open a new ticket +for this problem in our new tracker here: + + https://gitlab.com/qemu-project/qemu/-/issues + +and then close this ticket here on Launchpad (or let it expire auto- +matically after 60 days). Please mention the URL of this bug ticket on +Launchpad in the new ticket on GitLab. + +2) If you don't have an account on gitlab.com and don't intend to get +one, but still would like to keep this ticket opened, then please switch +the state back to "New" or "Confirmed" within the next 60 days (other- +wise it will get closed as "Expired"). We will then eventually migrate +the ticket automatically to the new system (but you won't be the reporter +of the bug in the new system and thus you won't get notified on changes +anymore). + +Thank you and sorry for the inconvenience. + + +[Expired for QEMU because there has been no activity for 60 days.] + |