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.
After connecting to the console in interactive virsh and
disconnecting, I often see all subsequent commands fail:
virsh # dominfo foo
error: failed to get domain 'foo'
error: An error occurred, but the cause is unknown
virsh # dominfo foo
error: failed to get domain 'foo'
error: no call waiting for reply with prog 536903814 vers 1 serial 300
virsh # define bar.xml
error: Failed to define domain from bar.xml
error: no call waiting for reply with prog 536903814 vers 1 serial 301
Closing and reopening the interactive virsh session makes the problem
go away.
Powering down the guest while the console is connected has made the
problem 100% reproducible in the 4 or 5 tries I've given it.
Version-Release number of selected component (if applicable):
0.9.4-4
Hi Dave,
tested with following pkgs , and didn't encounter this bug
But since we can't reproduce this bug even with the old version .Would you please help confirm the patch ?
libvirt-0.9.4-9.el6
qemu-kvm-0.12.1.2-2.185.el6
kernel-2.6.32-193.el6
1. configure guest grub with "console=tty0 console=ttyS0,115200n8" appended in
the kernel command line
2. configure guest with serial device added
<serial type='pty'>
<source path='/dev/pts/5'/>
<target port='0'/>
<alias name='serial0'/>
</serial>
3. start guest
4. enter interactive mode of virsh
# virsh
Welcome to virsh, the virtualization interactive terminal.
Type: 'help' for help with commands
'quit' to quit
virsh # console test1
Connected to domain test1
Escape character is ^]
localhost.localdomain login: root
Password:
[root@localhost ~]# shutdown -h now
initctl: Event failedm root
Stopping sshd: [ OK ]
Shutting down postfix: [ OK ]
Stopping crond: [ OK ]
Stopping auditd:
...
...
Halting system...
virsh # dominfo rhel6
Id: -
Name: rhel6
UUID: 888fe8e8-9b0b-3542-6aec-b120d06d94fb
OS Type: hvm
State: shut off
CPU(s): 1
Max memory: 1048576 kB
Used memory: 1048576 kB
Persistent: yes
Autostart: disable
Managed save: no
Security model: selinux
Security DOI: 0
And tried to make a connect-disconnect loop during guest shutdown , but never meet this bug .
I was testing using a libvirt that I built myself, so perhaps that's the source of the difference. Like I said, it was 100% reproducible for me, so if you've tested it with the latest libvirt and it's not present, I think you can close as WORKSFORME.