Re: [Qemu-devel] [RFC PATCH v1 1/1] vGPU core driver : to provide common interface for vGPU.

[Tian, Kevin]

> From: Neo Jia [mailto:address@hidden
> Sent: Wednesday, February 17, 2016 4:41 PM
> 
> On Wed, Feb 17, 2016 at 07:51:12AM +0000, Tian, Kevin wrote:
> > > From: Neo Jia [mailto:address@hidden
> > > Sent: Wednesday, February 17, 2016 3:32 PM
> > >
> > > On Wed, Feb 17, 2016 at 07:52:53AM +0100, Gerd Hoffmann wrote:
> > > >   Hi,
> > > >
> > > > > The answer is simple, having a UUID as part of the device name will 
> > > > > give you a
> > > > > unique sysfs path that will be opened by QEMU.
> > > >
> > > > A descriptive name will work too, and I think it'll be easier to make
> > > > those names persistent because you don't have to store the uuids
> > > > somewhere to re-create the same setup afer reboot.
> > >
> > > Hi Gerd,
> > >
> > > Right, UUID will be persistent cross reboot. The qemu vgpu path for a 
> > > given VM will
> > > not get changed when it gets reboots and multiple other devices have been
> > > created in the middle.
> >
> > Curious why persistence matters here. It's completely OK to assign
> > another vgpu to this VM across reboot, as long as the new vgpu
> > provides same capability to previous one.
> 
> Hi Kevin,
> 
> Those virtual devices might be destroyed and re-created as part of the reboot 
> or
> shutdown. The user doesn't want to change his configuration, if the
> path is not associated with UUID, the user might get a different vgpu than his
> previous configuration, unpredictable.

As long as libvirt keeps configuration under UUID, and then update UUID->
vgpu_path correctly, it won't be a problem:

UUID:
        config1,
        config2,

reboot1:
        UUID -> vgpu1

reboot2:
        UUID -> vgpu2

Then you can always have the configuration applied to new vgpu correctly.

Just want to state it's not a hard limitation. But as I replied in another mail,
I'm not against including UUID in the name, but please keep the option for
UUID not being used.

Thanks
Kevin