De: Itamar Heim [iheim(a)redhat.com]
Enviado: domingo, 29 de setembro de 2013 8:55
Para: Leonardo Bianconi
Cc: Roy Golan; engine-devel(a)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:firstname.lastname@example.org]
>> Sent: quarta-feira, 4 de setembro de 2013 08:13
>> To: Leonardo Bianconi
>> Cc: engine-devel(a)ovirt.org
>> Subject: Re: [Engine-devel] Cluster default with empty processor name with PPC64
>> On 09/02/2013 03:35 PM, Leonardo Bianconi wrote:
>>>>> From: Roy Golan [mailto:email@example.com]
>>>>> Sent: domingo, 1 de setembro de 2013 05:07
>>>>> To: Leonardo Bianconi
>>>>> Cc: engine-devel(a)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
>>>>> So we have the following questions regarding how the UI should
>>>>> - 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
>>>>> -- 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).
>>>>> 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
>>> - 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
>> 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
>>> 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 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
>  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