On 11/20/19 11:05 AM, Daniel P. Berrangé wrote:
On Wed, Nov 20, 2019 at 10:51:47AM +0100, Michal Privoznik wrote:
Another weird bug appeared concerning qemu namespaces. Basically
the problem is as follows:
1) Issue an API that causes libvirt to create a node in domain's
namespace, say /dev/sda with 8:0 as major:minor (the API can
be attach-disk for instance). Or simply create the node from
a console by hand.
2) Detach the disk from qemu.
3) Do something that makes /dev/sda change it's minor number.
Wait, what ?
major/minor numbers for SCSI disks are a defined standard
IIUC
$ grep SCSI ./admin-guide/devices.txt | grep block
8 block SCSI disk devices (0-15)
11 block SCSI CD-ROM devices
65 block SCSI disk devices (16-31)
66 block SCSI disk devices (32-47)
67 block SCSI disk devices (48-63)
68 block SCSI disk devices (64-79)
69 block SCSI disk devices (80-95)
70 block SCSI disk devices (96-111)
71 block SCSI disk devices (112-127)
128 block SCSI disk devices (128-143)
129 block SCSI disk devices (144-159)
130 block SCSI disk devices (160-175)
131 block SCSI disk devices (176-191)
132 block SCSI disk devices (192-207)
133 block SCSI disk devices (208-223)
134 block SCSI disk devices (224-239)
135 block SCSI disk devices (240-255)
IOW, /dev/sda should always be 8,0
There is, however, the possibiity of dynamically assign
major/minor numbers so its possible we'll see a block
device with a changable number, but AFAIK, such a block
device should never be call /dev/sda !??!
IOW, the commit is fine, but is this commit message
really accurate ?
Ah, the bug talks about /dev/nvmeN that has changed MIN number. I
haven't found corresponding docs on NVMe though. Is s/sda/nvmeN/ on the
commit message enough?
Michal
--
libvir-list mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/libvir-list
