[Engine-devel] RES: Cluster default with empty processor name with PPC64 support

[Itamar Heim]

On 10/08/2013 09:25 PM, Leonardo Bianconi wrote:
>
> ________________________________________
> De: Itamar Heim [iheim at redhat.com]
> Enviado: domingo, 29 de setembro de 2013 8:55
> Para: Leonardo Bianconi
> Cc: Roy Golan; engine-devel at ovirt.org
> Assunto: Re: [Engine-devel] Cluster default with empty processor name with PPC64 support
> On 09/04/2013 03:50 PM, Leonardo Bianconi wrote:
>>
>>
>>> -----Original Message-----
>>> From: Roy Golan [mailto:rgolan at redhat.com]
>>> Sent: quarta-feira, 4 de setembro de 2013 08:13
>>> To: Leonardo Bianconi
>>> Cc: engine-devel at ovirt.org
>>> Subject: Re: [Engine-devel] Cluster default with empty processor name with PPC64 support
>>>
>>> On 09/02/2013 03:35 PM, Leonardo Bianconi wrote:
>>>>
>>>>>> From: Roy Golan [mailto:rgolan at redhat.com]
>>>>>> Sent: domingo, 1 de setembro de 2013 05:07
>>>>>> To: Leonardo Bianconi
>>>>>> Cc: engine-devel at ovirt.org
>>>>>> Subject: Re: [Engine-devel] Cluster default with empty processor
>>>>>> name with PPC64 support
>>>>>>
>>>>>> On 08/30/2013 10:51 PM, Leonardo Bianconi wrote:
>>>>>> Hi everyone!
>>>>>>
>>>>>> During the development of PPC64 support in the engine, we faced some UX issues regarding the default Cluster (that Cluster with
>>> empty processor name).
>>>>>>
>>>>>> Currently, oVirt engine allows the default Cluster to contain empty processor name, and the administrator can add VMs and/or
>>> Templates to it. The processor name can be assigned later, editing the cluster or assigning a valid host to it.
>>>>>>
>>>>>> During the implementation of PPC64 support on the engine, the field "architecture" was added to Clusters, VMs and Templates
>>> entities.
>>>>>>
>>>>>> So we have the following questions regarding how the UI should behave:
>>>>>>
>>>>>> - Shall we keep allowing the administrator to assign VMs and Templates to the Cluster with no processor name or assigned
>>> architecture ?
>>>>>>                 -> If we have an "yes" for the question above:
>>>>>>                 -- We will have to assign the architecture to the Cluster based on the OS of the first assigned VM, and  the processor name
>>> could be defined the same way as currently ... editing the Cluster or assigning a compatible Host to it.
>>>>>>                                 -- The VM creation popup will have to be able to indicate the architecture of each OS ... some OSes have the same
>>> name, and it may get ambiguous since the Cluster architecture is still undefined at that point (before the first VM get already created).
>>>>>>
>>>>>> Thanks!
>>>>>> Regards.
>>>>>> Leonardo Bianconi
>>>>>>
>>>>> To add VMs you anyway need a running host in the cluster which means the cpu name and the architecture would be the host's.
>>>>> So we can keep the cluster attributes - "cpu name" and "arch" consistent and allow them to be empty on creation.
>>>>>
>>>>>
>>>> Hi Roy!
>>>>
>>>> There is a way to add VMs in a cluster with no hosts running. Steps to reproduce:
>>>> - Initialize the oVirt engine with a new data base
>>>> - Create a new Cluster (I will call it of newCluster) in the Data
>>>> Center Default
>>>> - Add a host in the newCluster
>>>> - Add a Storage
>>>> - Create a VM in the Cluster Default
>>>> Result: The system allows a VM in a cluster with no Hosts running in it.
>>>>
>>>> Is it a bug or a system functionality? If it's a functionality, the issue above can happen.
>>> Just to clear this one - its a functional thing. its a bit confusing but not too complicated:
>>>
>>> Storage and all its related actions/entities are related to the Data Center (aka, code-wise storage pool). Its possible to create a VM
>>> once the DC is up, without a cluster i.e also provision disks to it and so on.
>>>
>>> Cluster is know as the "migration domain" wrt VMs. so CPU arch stuff, network config etc, must be homogeneous in order for VMs to
>>> migrate between hosts which means we must have a running cluster i.e at least 1 running host in it.
>>>
>> Roy, thank you for the explanation! It`s clear now
>>>
>>>>
>>>> Thanks!!
>>>> Regards.
>>>> Leonardo Bianconi
>
> Hi Itamar, sorry about the late replay.
>
>> Leonardo - slightly related - is this ppc big endian, small endian? any
>> thoughts on current and future plans around endianes?
>
> PPC64 is big endian, but they are working to enable little endian.
>
>> also, can you help with my, well, ignorance - are ppc7+/ppc8[1] a newer
>> cpu level, also not backward compatible, etc.?
>
> Yes, Power7 and Power8 are different on family of processors. On the oVirt wiki, pinatti, from IBM, wrote that the CPUs wouldn't be compatible with each other, so I asked him about the backward compatibility and he answered they don't know what will be the compatibility level between Power7 and Power8.
>
> More information about Power8 can be found here in http://www.pcworld.com/article/2047733/ibms-power8-opens-up-to-component-makers.html
>
>> Thanks,
>>      Itamar
>> [1] https://lists.nongnu.org/archive/html/qemu-ppc/2013-08/msg00154.html
>> (courtesy of rich jones)

ok, i guess we'll handle little endian and power8 when they become 
relevant...