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 libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
