Re: [Qemu-discuss] virtio device instances identification by guest

[Artem Pisarenko]

> I'm not sure I understand the requirements.

No requirements. That was just a question and some notes about cons of
solutions I found (compared to an ideal way it implemented for specific
virtio devices I listed above).

>>     Forgot to clarify that identification needs to be unique only to
machine
>>     scope. 'virtio-net-pci' has 'mac' property, but if user wants to
>>     instantiate multiple such machines and connect them in one network,
then
>>     'mac' value also needs to be unique per this network. Thus, user
have to
>>     generate 'mac' from some <network host id> and <NIC id> parts and
guest
>>     should find network interface by mac address masked with <NIC id>
part.
>
> You need to create unique MACs anyway. If you don't it isn't guaranteed
networking
> will work.

Not always. It depends on network backend and use case. I've just meant,
that NIC identification by guest and MAC uniqueness are completely separate
issues, and mixing them in one single value of configuration decreases
flexibility of QEMU usage.

> If you are after arbitrary strings, one way would be to add support
> to vpd capability to devices... Want to try coding it up?

If I wouldn't found solutions above I would have to try, but now it seems
to be an overkill (even if it doesn't involves most scare part -
modification of linux guest driver).
Maybe in some future. But now I'm happy with solutions above, and most
users, who searched and found them here, probably, too.


чт, 8 нояб. 2018 г. в 20:08, Michael S. Tsirkin <address@hidden>:

> On Thu, Nov 08, 2018 at 05:20:53PM +0600, Artem Pisarenko wrote:
> > Ok, I found a way better, but it still not elegant, because depends on
> machine
> > hardware configuration. One may use 'addr' property to assign address on
> PCI
> > bus (and, if there are multiple PCI buses, identify bus somehow, but I
> didn't
> > looked at).
> > In my case on x86_64 target with default machine and given '-device
> > virtio-net-pci,addr=<hex_8bit_id>.0,...' on command line guest
> application can
> > get network interface name with:
> > `ls /sys/devices/pci0000\:00/0000\:00\:<hex_8bit_id>.0/virtio*/net/`
>
> I'm not sure I understand the requirements.
> If you are after arbitrary strings, one way would be to add support
> to vpd capability to devices... Want to try coding it up?
>
> >
> > чт, 8 нояб. 2018 г. в 14:56, Artem Pisarenko <
> address@hidden>:
> >
> >     Forgot to clarify that identification needs to be unique only to
> machine
> >     scope. 'virtio-net-pci' has 'mac' property, but if user wants to
> >     instantiate multiple such machines and connect them in one network,
> then
> >     'mac' value also needs to be unique per this network. Thus, user
> have to
> >     generate 'mac' from some <network host id> and <NIC id> parts and
> guest
> >     should find network interface by mac address masked with <NIC id>
> part.
>
> You need to create unique MACs anyway. If you don't it isn't guaranteed
> networking
> will work.
>
> >     Itsn't as elegant as in examples above. Although, it's better than
> >     nothing...
> >
> >     чт, 8 нояб. 2018 г. в 14:18, Artem Pisarenko <
> address@hidden>:
> >
> >         Hi everyone,
> >
> >         Is there are any way to make guest system able to identify
> specific
> >         instances of virtio devices as specified by qemu user (on
> command line
> >         or via qmp command)?
> >         More specifically, I'm interested in virtio-net devices.
> >         I know it's possible for some other devices:
> >         - virtserialport/virtconsole have 'name=<name>' property and
> guest
> >         application accesses serial device via "/dev/virtio-ports/<name>"
> >         - virtio-9p-pci/virtfs have 'mount_tag=<mount_tag>' and guest
> >         application mounts filesystem with "mount -t 9p -o trans=virtio
> >         <mount_tag> ..."
> >         But I cannot find any way to associate '-device virtio-net-pci'
> >         instances with eth<X> network interfaces in guest.
> >
> >         Thanks in advance,
> >         Artem
> >
> >
>