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

Itamar Heim iheim at redhat.com
Sun Sep 29 11:55:33 UTC 2013


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


Leonardo - slightly related - is this ppc big endian, small endian? any 
thoughts on current and future plans around endianes?

also, can you help with my, well, ignorance - are ppc7+/ppc8[1] a newer 
cpu level, also not backward compatible, etc.?

Thanks,
    Itamar

[1] https://lists.nongnu.org/archive/html/qemu-ppc/2013-08/msg00154.html
(courtesy of rich jones)



More information about the Engine-devel mailing list