On Wed, Feb 17, 2016 at 07:51:12AM +0000, Tian, Kevin wrote: > > From: Neo Jia [mailto:cjia@xxxxxxxxxx] > > 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. We can't change the vgpu configuration behind uses back, especially we have a lot of physical devices and tons virtual gpus can be assigned. Also, if user wants to move the vm configuration to a different host, it is more nature to decouple the vgpu configuration from VM itself. So the VM will only open up the device addressed by the corresponding UUID, what you need is just to describe his vgpu, and it doesn't matter how you describe and doesn't matter how many virtual devices have been created already on that physical device, your QEMU path is always persistent. Thanks, Neo > > Thanks > Kevin -- 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