> From: Neo Jia [mailto:cjia@xxxxxxxxxx] > 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: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. 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 -- 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
