[libvirt] [PATCH] qemu: Forcibly mknod() even if it exists
Michal Privoznik
mprivozn at redhat.com
Wed Nov 20 10:34:24 UTC 2019
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
More information about the libvir-list
mailing list