On Wed, Feb 17, 2016 at 02:08:18PM +0100, Gerd Hoffmann wrote:
> Hi,
>
> > For example, how to locate the path of a given VM?
>
> You go ask libvirt, the domain xml will have the info.
>
> > Whoever is going to configure
> > the qemu has to walk through *all* the current vgpu path to locate the UUID to
> > match the QEMU's VM UUID.
>
> No. qemu simply uses the path it get passed from libvirt. libvirt
> simply uses whatever is stored in the domain xml.
>
> i.e. you'll have a config like this:
>
> <domain type='kvm'>
> <name>rhel7-vfio</name>
> <uuid>0990b05d-4fbd-49bf-88e4-e87974c64fba</uuid>
> [ ... ]
> <devices>
> [ ... ]
> <hostdev mode='subsystem' type='pci' managed='yes'>
> <source>
> <address sysfs='/sys/devices/virtual/vgpu/${name}'/>
> </source>
> <address type='pci' domain='0x0000'
> bus='0x00' slot='0x04' function='0x0'/>
> </hostdev>
>
> > I think I has answered this, UUID is not a user space or kernel space
> > concept, it is just a generic way to represent object,
>
> Yes. But the above sounds like you want to use UUIDs to *link* two
> objects, by assigning the same uuid to both vm and vgpu. This is *not*
> how uuids should be used. Each object should have its own uuid.
>
> You can use uuids to name the vgpus if you want of course. But the vgpu
> uuid will will have no relationship whatsoever to the vm uuid then.
>
Agree. I should made it clear that it should be a separate object.
Thanks,
Neo
> cheers,
> Gerd
>
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
