Re: [Xen-devel] Many same managed domain

[Jim Fehlig <jfehlig@xxxxxxxxxx>]

Daniel P. Berrange wrote:
> On Tue, Jul 24, 2007 at 06:16:57PM -0600, Jim Fehlig wrote:
>   
>> Daniel Berrange wrote:
>> [snip]
>>     
>>>> Thanks for your explanation. 
>>>> I have a question to your logic.  I think that the logic need a VM 
>>>> name check when no VM with same UUID exists.  Am I right?
>>>>
>>>>   - If the UUID is not specified
>>>>         - If a VM with same name exists
>>>>             => Update the config for that existing VM
>>>>         - Else no vm with same name exists
>>>>             => Define a brand new VM with auto-generated UUID
>>>>   - Else UUID is specified
>>>>         - If a VM with same UUID exists
>>>>               - If name is different
>>>>                     => Error
>>>>               - Else if name is same
>>>>                     => Update the config for that existing VM
>>>>         - Else no VM with same UUID exists
>>>> -           => Define a branch new VM with that name
>>>> +             - If name is different
>>>> +                   => Define a branch new VM with that name
>>>> +             - Else if name is same
>>>> +                   => Error
>>>>     
>>>>         
>>> Yes you are correct - if UUID does not clash we still need to check for
>>> a VM with same name, but different UUID.
>>>   
>>>       
>> As a side note, Xen API allows for domains with same name - in spec at
>> least :-).
>>     
>
> That is madness. Name uniqueness is assumed in pretty much every single
> management tool I've ever seen, not least 'xm'. ID is unique amongst all 
> running domains, Name is unique amongst running and inactive guests on a
> single host, UUID is unique globsally.
>   

Well, I agree and thought there was some discussion about this on Xen
API ml quite some time ago but looking through the archives can't seem
to find it.  I do not recall what arguments were made in favor of
domains with same name.  Ewan may have some recollection.

Given the current consensus, I should submit a patch to fix Xen API
documentation and code and put this to rest for good.  Any objections?

Jim


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel