From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jim Fehlig Subject: Re: PATCH: Fix name uniqueness check Date: Thu, 27 Sep 2007 13:42:10 -0600 Message-ID: <46FC0792.2040602@novell.com> References: <20070927165051.GK17433@redhat.com> <46FBE56B.4040708@novell.com> <20070927173915.GM17433@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20070927173915.GM17433@redhat.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: "Daniel P. Berrange" Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org Daniel P. Berrange wrote: > On Thu, Sep 27, 2007 at 11:16:27AM -0600, Jim Fehlig wrote: > >> Daniel P. Berrange wrote: >> >>> Changeset 15124:f5459c358575 altered check_name() in XendDomainInfo so that >>> it compares domain IDs instead of UUIDs. This breaks a number of things >>> >>> - You can no longer use 'xm new' to define a persistent config file for >>> a running guest. This breaks the key OS provisioning scenario where >>> you boot a kenrel+initrd for the installer, and at the same time define >>> a permanent config with pygrub. >>> >>> - It lets you define multiple inactive guests with different UUIDs, but >>> the same name because all inactive guests have a domid of None. So you >>> can now end up with multiple guests with same name, which is contrary >>> to the goal implied by the patch which was name uniqueness. >>> >>> It is unclear from the original commit logs just what scenario it was trying >>> to protect against, but the original checking of uniqueness based on UUID >>> was correct & is what was used in previous releases XenD. >>> >>> >> Yes, I was not sure what this patch was attempting to fix either. There >> was some discussion about the patch in this thread >> >> http://lists.xensource.com/archives/html/xen-devel/2007-05/msg00887.html >> > > Ok, so if I follow that correctly, the crux of the issue is that it was > possible to start 2 unmanaged domains with same name and same uuid. So > I think we can probably address that by checking for UUID, and the only > if both are running, also check for domid match. So really a combo of > both the original & current code. > Unstable, but not 3.1.1, also has http://xenbits2.xensource.com/xen-unstable.hg?rev/207582c8d88b I did a little testing on a 3.1-based system that includes the above c/s and your reversion of c/s 15124. No problems noticed testing create, new, reboot, save, restore. Did not test migration or hvm guests. So perhaps reverting 15124 is fine for unstable but not sure about 3.1.1 *without* c/s 15642. Regards, Jim