[systemd-devel] udev virtio by-path naming

Tue Feb 28 08:47:42 UTC 2017

On 27.02.2017 12:22, Michal Sekletar wrote:
> On Fri, Feb 24, 2017 at 10:56 AM, Viktor Mihajlovski
> <mihajlov at linux.vnet.ibm.com> wrote:
>> On 20.02.2017 17:00, Cornelia Huck wrote:
>>> On Mon, 20 Feb 2017 15:34:49 +0100
>>> Viktor Mihajlovski <mihajlov at linux.vnet.ibm.com> wrote:
>>>
>>>> Hi,
>>>>
>>>> with systemd > v229 all virtio block devices will receive persistent
>>>> device names in the format /dev/disk-by/virtio-pci-<busid>, the
>>>> last component being the udev built-in path_id.
>>>>
>>>> This naming introduces some issues.
>>>>
>>>> First and obvious, there are virtio implementations not based
>>>> on PCI, like virtio-ccw (currently only on s390) and virtio-mmio
>>>> (for which I can't speak). This results in persistent names like
>>>> /dev/disk-by/virtio-pci-0.0.0001, where the bus id is a CCW id.
>>>> One seemingly obvious remedy would be to make the path_id return
>>>> virtio-ccw-<busid> or more generally virtio-<subsystem>-<busid>,
>>>> both easily done with small patches to systemd-udev.
>>>>
>>>> But then, I find this naming scheme somewhat weird.
>>>> A virtio disk shows up as a regular PCI function on the PCI
>>>> bus side by side with other (non-virtio) devices. The naming otoh
>>>> suggests that virtio-pci is a subsystem of its own, which is simply
>>>> incorrect from a by-path perspective.
>>>
>>> From the ccw perspective, this is quite similar: The virtio proxy
>>> device shows up on the ccw bus, just like e.g. a dasd device shows up
>>> on the ccw bus.
>>>
>>>>
>>>> Using just the plain PCI path id is actually sufficient to identify
>>>> a virtio disk by its path. This would be in line with virtio
>>>> network interface path names which use the plain PCI naming.
>>>
>>> Same for ccw: The id on the ccw bus (devno) is already unique and
>>> persistent.
>>>
>>>>
>>>> One could argue about back-level compatibility, but virtio by-path
>>>> naming has changed multiple times. We have seen virtio-pci-virtio<n>
>>>> (not predictable), pci-<busid> and virtio-pci-<busid> already. It
>>>> might be a good time now to settle on a common approach for all
>>>> virtio types.
>>>>
>>>> For the reasons above, I'd vote for <subsystem>-<busid>, which
>>>> would work for PCI and CCW, not sure about ARM MMIO though.
>>>> Opinions?
>>>
>>> I'm not sure whether there is any reason to make virtio special,
>>> although this depends upon what virtio-mmio looks like in the Linux
>>> device model (any arm folks here?)
>>>
>>> In the end, I'd be happy with any naming scheme that does not include
>>> 'pci' for non-pci devices.
>>>
>> Michal, as author of commit f073b1b3c0f4f0df1b0bd61042ce85fb5d27d407
>> that introduced this behavior: can you comment on the reasoning for
>> prepending virtio- to the bus, i.e. why would pci-<busid> not
>> sufficiently identify the device?
> 
> As with many things, it looked like a good idea at the time. In commit
> message I referenced discussion on upstream mailing list. In that
> thread we got reassured that there is one-to-one correspondence
> between virtio and pci devices. IIRC, we had bugs for RHEL and CentOS
> 7 were users requested these symlinks. Hence we went ahead with above
> naming scheme.
> 
> Your argument about virtio being first component of the path makes
> sense to me, but then again, we wanted to distinguish these devices
> (because of user demands).
> 
> In retrospect what we did wasn't probably the best we could.
> Nevertheless, I'd not change the naming. After all, these symlinks are
> for users and since then I didn't hear complains about them. I'd only
> adjust the code so that we produce correctly named symlinks for
> different parent buses (pci, ccw, mmio). IOW we would remove hardcoded
> "pci" string.
Thanks for taking the time to explain the background. As it happens, I
have a local patch to produce virtio-<subsystem>-<systemid> symlinks as
you suggested. However, I wasn't really happy about that for two reasons:

1. The s390x architecture has native disks that show up as devices on
the bus, so it is possible to create persistent symlinks based solely on
the bus id, irrespective of the disk type (virtio or dasd). This helps
in defining OS images that can run on native and paravirtualized disk
setups. Which is broken now.

This might be considered an architecture one-off, but

2. SCSI disk pathids are generally represented as <hba-busid>-<scsi-lun>
(the lun in hba specific notation). For a generic/parallel SCSI HBA the
path id will always be in a format like
 pci-0000:00:03.0-scsi-0:0:0:0
except for the virtio HBA, which would look like this
 virtio-pci-0000:00:03.0-scsi-0:0:0:0
This makes even less sense to me (even if there are probably no more
generic SCSI adapters to be found in the wild).

My fear is that by dodging a potential inconvenience for the users much
more pain will arise further down the road whenever a new virtio device
type shows up. My take would rather be to produce semantically correct
builtin path ids and have the distributions add their custom rules for
virtio-blk if they are wanted.
> 
> Michal
>>
>> --
>>
>> Mit freundlichen Grüßen/Kind Regards
>>    Viktor Mihajlovski
>>
>> IBM Deutschland Research & Development GmbH
>> Vorsitzender des Aufsichtsrats: Martina Köderitz
>> Geschäftsführung: Dirk Wittkopp
>> Sitz der Gesellschaft: Böblingen
>> Registergericht: Amtsgericht Stuttgart, HRB 243294
>>
> 

-- 

Mit freundlichen Grüßen/Kind Regards
   Viktor Mihajlovski

IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Martina Köderitz
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294