From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44058) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZUzju-0007gr-UH for qemu-devel@nongnu.org; Thu, 27 Aug 2015 12:09:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZUzjq-00083Y-Rd for qemu-devel@nongnu.org; Thu, 27 Aug 2015 12:09:22 -0400 Received: from mx1.redhat.com ([209.132.183.28]:41077) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZUzjq-00083T-L5 for qemu-devel@nongnu.org; Thu, 27 Aug 2015 12:09:18 -0400 Date: Thu, 27 Aug 2015 17:02:17 +0100 From: "Daniel P. Berrange" Message-ID: <20150827160217.GA24486@redhat.com> References: <20150827123234.GB2669@localhost.localdomain> <56530C98-D6B3-417E-BB58-E29412283BF1@gmail.com> <20150827134943.GS24486@redhat.com> <37557843-A1BA-4822-9933-B0B8AD588C90@gmail.com> <55DF1884.2030608@redhat.com> <20150827144253.GX24486@redhat.com> <20150827154057.GE2669@localhost.localdomain> <068B4976-968C-45A3-9219-77FB600BC257@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <068B4976-968C-45A3-9219-77FB600BC257@gmail.com> Subject: Re: [Qemu-devel] Should we auto-generate IDs? Reply-To: "Daniel P. Berrange" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Programmingkid Cc: Kevin Wolf , jsnow@redhat.com, Jeff Cody , Markus Armbruster , qemu-devel qemu-devel , Paolo Bonzini , Andreas =?utf-8?Q?F=C3=A4rber?= On Thu, Aug 27, 2015 at 11:58:22AM -0400, Programmingkid wrote: > > On Aug 27, 2015, at 11:40 AM, Jeff Cody wrote: > > > On Thu, Aug 27, 2015 at 11:20:20AM -0400, Programmingkid wrote: > >> > >> On Aug 27, 2015, at 10:42 AM, Daniel P. Berrange wrote: > >> > >>> On Thu, Aug 27, 2015 at 10:34:05AM -0400, Programmingkid wrote: > >>>> > >>>> On Aug 27, 2015, at 10:02 AM, Eric Blake wrote: > >>>> > >>>>> On 08/27/2015 07:56 AM, Programmingkid wrote: > >>>>> > >>>>>>> If we did have auto-generated names, we would need to come up with a > >>>>>>> scheme that is not going to clash with any existing naming that users > >>>>>>> of QEMU may already be doing, otherwise we risk causing a regression. > >>>>>>> Something as simple as what you suggest has non-trivial chance of > >>>>>>> clashing. > >>>>>> > >>>>>> Actually there is a way to prevent clashing. When QEMU auto-generates a > >>>>>> name, it could scan all the ID's to see if there is a clash. If the ID is already > >>>>>> taken, just increment the ID until it is detected to be unique. The previous > >>>>>> threads on this subject has patches that did just that. This means that a > >>>>>> ID scheme that is just a single number would work without clashes. > >>>>> > >>>>> No, because you cannot predict what FUTURE names the user will request. > >>>>> The name generated by qemu must be IMPOSSIBLE to request manually, and > >>>>> not just one that happens not to clash at the current moment. > >>>> > >>>> If I add a device with an ID that is taken, QEMU can just say sorry that ID is already > >>>> taken. I could just increment the ID myself until I find one that is unique. It is a > >>>> simple algorithm. Maybe you are talking about some program that has hard coded > >>>> ID's it depends on. If that is the case, perhaps this management program could be > >>>> made to be a little flexible. Or use a 160-bit SHA-1 generated ID that is virtually > >>>> guaranteed to always be unique. > >>> > >>> If breaking existing apps was OK, we would just mandate that users always > >>> provide an ID which trivially avoids the problem of not having an ID to > >>> use when deleting the object. We want to /avoid/ breaking existing apps > >>> though, so saying an app should change the way it works in order to cope > >>> with QEMU's ID generation is not appropriate. Hence any use of auto-generated > >>> IDs, must use a separate namespace to avoid such clashes. > >> > >> This is making the assumption that an auto-generated ID system would break any existing > >> application. We don't know this. In fact, I predict a future patch would allow existing > >> applications to continue running without modification. The patch would be a win-win > >> for both users and any management application. > >> > > > > Daniel's assumption is spot on. The idea of "QEMU can just say sorry > > that ID is already taken" will break existing applications. > > > > But we are all striving to make your prediction true, with this very > > conversation. > > Ok, it sounds like some are concerned that Libvirt would not be able to work with this > feature. Let me ask you this: does Libvirt interact with QEMU before the user has a > chance to do so? If the answer is yes, then that means Libvirt will have finished > creating all its devices with their ID's long before the user has a chance to enter > his own devices. Just to be clear - libvirt will *never* use an auto-generated device IDs feature. It is way more complicated to let QEMU assign device IDs and then auto-detect them from some 'info device-list' output, than to just specify IDs upfront at device/object creation time which it already does[1]. There is simply no benefit to auto-generating device IDs for a mgmt app like libvirt, and plenty of downside. Auto-generated IDs will only be of interest to humans talking to the monitor directly without a mgmt app involved. Regards, Daniel [1] we don't provide IDs for qcow2 image backing file chain, but that's part of a bigger story that's being dealt with in this area. -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|