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.
Description of problem:
Add virtio disk identification support in rhel6 qemu-kvm. I noticed same is present in upstream qemu-kvm.
Commit 2930b313dd602d67a568815b0b031b824916cec9
Author: john cooper <john.cooper>
Date: Fri Jul 2 13:44:25 2010 -0400
Add virtio disk identification support
In kdump we need to make sure that we are dumping to right device and due to device renaming issues we don't end up dumping to wrong device. Hence we are planning to read /sys/block/<virtio-device>/serial and store in kdump-initrd
and re-read it again in kdump kernel and match serial numbers before we proceed with saving vmcore.
Current plan is to read /sys directly. Is there a use space tool which can
do the job of getting the serial number?
Version-Release number of selected component (if applicable):
How reproducible:
Steps to Reproduce:
1.
2.
3.
Actual results:
Expected results:
Additional info:
- i think you can try running lsscsi and see if device appears there or not.
- Or parse the device name. I am assuming that all virtio block devices are
going to start with "v".
- Or if scsi_id does not report the device identity, then try to read serial
number.
for virtio devices, udevadm is reporting following path info.
[root@rhel6-vm1 ~]# udevadm info --query=all --name=/dev/vdb
P: /devices/pci0000:00/0000:00:07.0/virtio3/block/vdb
I think you can grep for virtio keyword for recognzing virtio devices.
I think it is boiling down to trial and error thing. We can also probably look into udev and try to figure out what they are doing to identify different kind
of devices.
In long run, we really need udev in second kernel so that all this device identification logic is handled by udev and we don't end up duplicating it in
kexec-tools.
Description of problem: Add virtio disk identification support in rhel6 qemu-kvm. I noticed same is present in upstream qemu-kvm. Commit 2930b313dd602d67a568815b0b031b824916cec9 Author: john cooper <john.cooper> Date: Fri Jul 2 13:44:25 2010 -0400 Add virtio disk identification support In kdump we need to make sure that we are dumping to right device and due to device renaming issues we don't end up dumping to wrong device. Hence we are planning to read /sys/block/<virtio-device>/serial and store in kdump-initrd and re-read it again in kdump kernel and match serial numbers before we proceed with saving vmcore. Current plan is to read /sys directly. Is there a use space tool which can do the job of getting the serial number? Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info: