2:51 p.m.
--_000_50EB20226B72D6419356FC320AB62B8719173370SERV070corpeldo_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Hi everyone!
During the development of PPC64 support in the engine, we faced some UX iss=
ues regarding the default Cluster (that Cluster with empty processor name).
Currently, oVirt engine allows the default Cluster to contain empty process=
or name, and the administrator can add VMs and/or Templates to it. The proc=
essor 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 "archit=
ecture" 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 t=
he 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 base=
d on the OS of the first assigned VM, and the processor name could be defi=
ned the same way as currently ... editing the Cluster or assigning a compat=
ible 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, a=
nd it may get ambiguous since the Cluster architecture is still undefined a=
t that point (before the first VM get already created).
Thanks!
Regards.
Leonardo Bianconi
--_000_50EB20226B72D6419356FC320AB62B8719173370SERV070corpeldo_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
<html xmlns:v=3D"urn:schemas-microsoft-com:vml"
xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word"
=
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml"
xmlns=3D"http:=
//www.w3.org/TR/REC-html40" <head <meta http-equiv=3D"Content-Type"
content=3D"text/html; charset=3Dus-ascii"=
<meta name=3D"Generator" content=3D"Microsoft
Word 14 (filtered medium)" <style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";
mso-fareast-language:EN-US;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Calibri","sans-serif";
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";
mso-fareast-language:EN-US;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:70.85pt 3.0cm 70.85pt 3.0cm;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" / </xml><![endif]--><!--[if gte mso
9]><xml <o:shapelayout
v:ext=3D"edit" <o:idmap v:ext=3D"edit"
data=3D"1" /
</o:shapelayout></xml><![endif]--
</head <body lang=3D"PT-BR"
link=3D"blue" vlink=3D"purple" <div
class=3D"WordSection1" <p
class=3D"MsoNormal"><span lang=3D"EN-US">Hi
everyone!<o:p></o:p></span><=
/p <p class=3D"MsoNormal"><span
lang=3D"EN-US"><o:p> </o:p></span></p <p class=3D"MsoNormal"><span
lang=3D"EN-US">During the development of PPC64=
support in the engine, we faced some UX issues regarding the default Clust=
er (that Cluster with empty processor name).<o:p></o:p></span></p <p class=3D"MsoNormal"><span
lang=3D"EN-US"><o:p> </o:p></span></p <p class=3D"MsoNormal"><span
lang=3D"EN-US">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 late=
r, editing the cluster or assigning
a valid host to it.<o:p></o:p></span></p <p class=3D"MsoNormal"><span
lang=3D"EN-US"><o:p> </o:p></span></p <p class=3D"MsoNormal"><span
lang=3D"EN-US">During the implementation of PP=
C64 support on the engine, the field “architecture“ was added t=
o Clusters, VMs and Templates entities.<o:p></o:p></span></p <p class=3D"MsoNormal"><span
lang=3D"EN-US"><o:p> </o:p></span></p <p class=3D"MsoNormal"><span
lang=3D"EN-US">So we have the following questi=
ons regarding how the UI should behave:<o:p></o:p></span></p <p class=3D"MsoNormal"><span
lang=3D"EN-US"><o:p> </o:p></span></p <p class=3D"MsoNormal"><span
lang=3D"EN-US">- Shall we keep allowing the ad=
ministrator to assign VMs and Templates to the Cluster with no processor na=
me or assigned architecture ?<o:p></o:p></span></p <p class=3D"MsoNormal"><span
lang=3D"EN-US"> &=
nbsp; -> If we have an
“yes=
221; for the question above:<o:p></o:p></span></p <p class=3D"MsoNormal"><span
lang=3D"EN-US"> &=
nbsp; -- We will have to
assign the arc=
hitecture to the Cluster based on the OS of the first assigned VM, and =
; the processor name could be defined the same way as currently … edi=
ting the Cluster or assigning a
compatible Host to it.<o:p></o:p></span></p <p class=3D"MsoNormal"><span
lang=3D"EN-US"> &=
nbsp; &nbs=
p;
-- The VM cr=
eation popup will have to be able to indicate the architecture of each OS &=
#8230; some OSes have the same name, and it may get ambiguous since the Clu=
ster architecture is still undefined
at that point (before the first VM get already
created).<o:p></o:p></span>=
</p <p class=3D"MsoNormal"><span
lang=3D"EN-US"><o:p> </o:p></span></p <p
class=3D"MsoNormal">Thanks!<o:p></o:p></p <p
class=3D"MsoNormal">Regards.<o:p></o:p></p <p class=3D"MsoNormal">Leonardo
Bianconi<o:p></o:p></p
</div </body </html
--_000_50EB20226B72D6419356FC320AB62B8719173370SERV070corpeldo_--
3:07 a.m.
This is a multi-part message in MIME format.
--------------060308090303000405080600
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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.
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
--------------060308090303000405080600
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 08/30/2013 10:51 PM, Leonardo
Bianconi wrote:<br>
</div>
<blockquote
cite="mid:50EB20226B72D6419356FC320AB62B8719173370@SERV070.corp.eldorado.org.br"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<meta name="Generator" content="Microsoft Word 14 (filtered
medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";
mso-fareast-language:EN-US;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Calibri","sans-serif";
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";
mso-fareast-language:EN-US;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:70.85pt 3.0cm 70.85pt 3.0cm;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
<div class="WordSection1">
<p class="MsoNormal"><span lang="EN-US">Hi
everyone!<o:p></o:p></span></p>
<p class="MsoNormal"><span
lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">During the
development
of PPC64 support in the engine, we faced some UX issues
regarding the default Cluster (that Cluster with empty
processor name).<o:p></o:p></span></p>
<p class="MsoNormal"><span
lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span
lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">During
the
implementation of PPC64 support on the engine, the field
“architecture“ was added to Clusters, VMs and Templates
entities.<o:p></o:p></span></p>
<p class="MsoNormal"><span
lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">So we have
the following
questions regarding how the UI should
behave:<o:p></o:p></span></p>
<p class="MsoNormal"><span
lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">- Shall we
keep allowing
the administrator to assign VMs and Templates to the Cluster
with no processor name or assigned architecture
?<o:p></o:p></span></p>
<p class="MsoNormal"><span
lang="EN-US">
-> If we
have an “yes” for the question
above:<o:p></o:p></span></p>
<p class="MsoNormal"><span
lang="EN-US">
-- 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.<o:p></o:p></span></p>
<p class="MsoNormal"><span
lang="EN-US">
-- 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).<o:p></o:p></span></p>
<p class="MsoNormal"><span
lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal">Thanks!<o:p></o:p></p>
<p class="MsoNormal">Regards.<o:p></o:p></p>
<p class="MsoNormal">Leonardo
Bianconi<o:p></o:p></p>
</div>
</blockquote>
<br>
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. <br>
So we can keep the cluster attributes - "cpu name" and "arch"
consistent and allow them to be empty on creation. <br>
<blockquote
cite="mid:50EB20226B72D6419356FC320AB62B8719173370@SERV070.corp.eldorado.org.br"
type="cite">
<div class="WordSection1">
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Engine-devel mailing list
<a class="moz-txt-link-abbreviated"
href="mailto:Engine-devel@ovirt.org">Engine-devel@ovirt.org</a>
<a class="moz-txt-link-freetext"
href="http://lists.ovirt.org/mailman/listinfo/engine-devel">...
</pre>
</blockquote>
<br>
</body>
</html>
--------------060308090303000405080600--
7:35 a.m.
> From: Roy Golan [mailto:rgolan@redhat.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 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.
Thanks!!
Regards.
Leonardo Bianconi
> _______________________________________________
> Engine-devel mailing list
> Engine-devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
8:28 a.m.
On 09/02/2013 03:35 PM, Leonardo Bianconi wrote:
>> From: Roy Golan [mailto:rgolan@redhat.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 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.
while above can happen, is it really an interesting use case to solve?
can user edit the arch field of a vm? if so, i'd just block running it
on incorrect cluster (just like we block on moving it between
incompatible clusters) until user fix the issue
10:43 a.m.
-----Original Message-----
From: Itamar Heim [mailto:iheim@redhat.com]
Sent: segunda-feira, 2 de setembro de 2013 10:29
To: Leonardo Bianconi
Cc: Roy Golan; engine-devel(a)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@redhat.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
entities.
>>> herdado
>>> 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.
while above can happen, is it really an interesting use case to solve?
can user edit the arch field of a vm? if so, i'd just block running it on incorrect
cluster (just like we block on moving it between
incompatible clusters) until user fix the issue
Yes, it's interesting solve, because we use the cluster architecture when creating
VMs.
The user cannot edit the arch field, because there is no field for that, it is inherited
from the cluster. The arch is important on creating VMs, because it filters the OS list
and defines the VM architecture.
What should we do?
Thanks!!
11:45 a.m.
On 09/02/2013 06:43 PM, Leonardo Bianconi wrote:
> -----Original Message-----
> From: Itamar Heim [mailto:iheim@redhat.com]
> Sent: segunda-feira, 2 de setembro de 2013 10:29
> To: Leonardo Bianconi
> Cc: Roy Golan; engine-devel(a)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@redhat.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
> entities.
>>>> herdado
>>>> 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.
>
> while above can happen, is it really an interesting use case to solve?
> can user edit the arch field of a vm? if so, i'd just block running it on
incorrect cluster (just like we block on moving it between
> incompatible clusters) until user fix the issue
Yes, it's interesting solve, because we use the cluster architecture when creating
VMs.
The user cannot edit the arch field, because there is no field for that, it is inherited
from the cluster. The arch is important on creating VMs, because it filters the OS list
and defines the VM architecture.
What should we do?
Thanks!!
so worst case the list is not filtered while creating the VM for that
corner case?
thinking about this some more, with all due respect to PPC and this
corner case, I'd just assume if cluster arch is not yet defined, OS list
should be filtered as x86_64.
or, we block creating VMs on clusters which have no arch defined (I'm
specifically not saying no hosts, just in case its useful somehow)
6:39 a.m.
-----Original Message-----
From: Itamar Heim [mailto:iheim@redhat.com]
Sent: segunda-feira, 2 de setembro de 2013 13:46
To: Leonardo Bianconi
Cc: Roy Golan; engine-devel(a)ovirt.org
Subject: Re: [Engine-devel] Cluster default with empty processor name with PPC64 support
On 09/02/2013 06:43 PM, Leonardo Bianconi wrote:
>
>
>> -----Original Message-----
>> From: Itamar Heim [mailto:iheim@redhat.com]
>> Sent: segunda-feira, 2 de setembro de 2013 10:29
>> To: Leonardo Bianconi
>> Cc: Roy Golan; engine-devel(a)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@redhat.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
>> entities.
>>>>> herdado
>>>>> 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.
>>
>> while above can happen, is it really an interesting use case to solve?
>> can user edit the arch field of a vm? if so, i'd just block running
>> it on incorrect cluster (just like we block on moving it between
>> incompatible clusters) until user fix the issue
>
> Yes, it's interesting solve, because we use the cluster architecture when
creating VMs.
> The user cannot edit the arch field, because there is no field for that, it is
inherited from the cluster. The arch is important on
creating VMs, because it filters the OS list and defines the VM architecture.
> What should we do?
>
> Thanks!!
>
so worst case the list is not filtered while creating the VM for that corner case?
thinking about this some more, with all due respect to PPC and this corner case, I'd
just assume if cluster arch is not yet defined, OS list
should be filtered as x86_64.
or, we block creating VMs on clusters which have no arch defined (I'm specifically not
saying no hosts, just in case its useful somehow)
I think both are good solutions, but looking the system behavior, I think the first
solution will be weird for new users and the second has problems when upgrading the data
base.
I would suggest the following behavior:
1. For new data bases: Block the admin to add VMs in the cluster with no processor name
(Cluster Default), i. e. no architecture.
2. For upgraded data bases, If the cluster with no processor name (Cluster Default) has:
2.1 - VMs: Set the cluster architecture for x86_64 and allow admin use it as x86_64.
2.2 - no VMs: Keep the cluster with no processor name, i. e. no architecture (it will
keep the same behavior of the cluster for new data base - item 1)
On the item 2.1, when setting the architecture of the cluster (Cluster Default) for
x86_64, the processor name will be empty. Should we set it for the lowest x86_64 level?
What do you think?
Thanks!!
6:49 a.m.
On 09/03/2013 02:39 PM, Leonardo Bianconi wrote:
> -----Original Message-----
> From: Itamar Heim [mailto:iheim@redhat.com]
> Sent: segunda-feira, 2 de setembro de 2013 13:46
> To: Leonardo Bianconi
> Cc: Roy Golan; engine-devel(a)ovirt.org
> Subject: Re: [Engine-devel] Cluster default with empty processor name with PPC64
support
>
> On 09/02/2013 06:43 PM, Leonardo Bianconi wrote:
>>
>>
>>> -----Original Message-----
>>> From: Itamar Heim [mailto:iheim@redhat.com]
>>> Sent: segunda-feira, 2 de setembro de 2013 10:29
>>> To: Leonardo Bianconi
>>> Cc: Roy Golan; engine-devel(a)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@redhat.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
>>> entities.
>>>>>> herdado
>>>>>> 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.
>>>
>>> while above can happen, is it really an interesting use case to solve?
>>> can user edit the arch field of a vm? if so, i'd just block running
>>> it on incorrect cluster (just like we block on moving it between
>>> incompatible clusters) until user fix the issue
>>
>> Yes, it's interesting solve, because we use the cluster architecture when
creating VMs.
>> The user cannot edit the arch field, because there is no field for that, it is
inherited from the cluster. The arch is important on
> creating VMs, because it filters the OS list and defines the VM architecture.
>> What should we do?
>>
>> Thanks!!
>>
>
> so worst case the list is not filtered while creating the VM for that corner case?
>
> thinking about this some more, with all due respect to PPC and this corner case,
I'd just assume if cluster arch is not yet defined, OS list
> should be filtered as x86_64.
> or, we block creating VMs on clusters which have no arch defined (I'm
specifically not saying no hosts, just in case its useful somehow)
I think both are good solutions, but looking the system behavior, I think the first
solution will be weird for new users and the second has problems when upgrading the data
base.
I would suggest the following behavior:
1. For new data bases: Block the admin to add VMs in the cluster with no processor name
(Cluster Default), i. e. no architecture.
2. For upgraded data bases, If the cluster with no processor name (Cluster Default) has:
2.1 - VMs: Set the cluster architecture for x86_64 and allow admin use it as x86_64.
2.2 - no VMs: Keep the cluster with no processor name, i. e. no architecture (it will
keep the same behavior of the cluster for new data base - item 1)
On the item 2.1, when setting the architecture of the cluster (Cluster Default) for
x86_64, the processor name will be empty. Should we set it for the lowest x86_64 level?
What do you think?
Thanks!!
sounds good to me. roy/omer/michal?
5:07 a.m.
On 09/02/2013 03:35 PM, Leonardo Bianconi wrote:
>> From: Roy Golan [mailto:rgolan@redhat.com]
>> Sent: domingo, 1 de setembro de 2013 05:07
>> To: Leonardo Bianconi
>> Cc:engine-devel@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 (also has a DC part though) and various other vars, must
be homogeneous in order
for VMs to migrate between hosts. So cluster isn't really fully
configured till it has at least 1 host up.
hope this make things clearer
Thanks!!
Regards.
Leonardo Bianconi
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel(a)ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
6:13 a.m.
On 09/02/2013 03:35 PM, Leonardo Bianconi wrote:
>> From: Roy Golan [mailto:rgolan@redhat.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 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.
Thanks!!
Regards.
Leonardo Bianconi
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel(a)ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
7:50 a.m.
-----Original Message-----
From: Roy Golan [mailto:rgolan@redhat.com]
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 support
On 09/02/2013 03:35 PM, Leonardo Bianconi wrote:
>
>>> From: Roy Golan [mailto:rgolan@redhat.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
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
>>> _______________________________________________
>>> Engine-devel mailing list
>>> Engine-devel(a)ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
6:55 a.m.
On 09/04/2013 03:50 PM, Leonardo Bianconi wrote:
> -----Original Message-----
> From: Roy Golan [mailto:rgolan@redhat.com]
> 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
support
>
> On 09/02/2013 03:35 PM, Leonardo Bianconi wrote:
>>
>>>> From: Roy Golan [mailto:rgolan@redhat.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
> 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)
1:25 p.m.
New subject: [Engine-devel] RES: Cluster default with empty processor name with PPC64 support
________________________________________
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:rgolan@redhat.com]
> 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
support
>
> On 09/02/2013 03:35 PM, Leonardo Bianconi wrote:
>>
>>>> From: Roy Golan [mailto:rgolan@redhat.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
> 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-...
> Thanks,
> Itamar
> [1] https://lists.nongnu.org/archive/html/qemu-ppc/2013-08/msg00154.html
> (courtesy of rich jones)
1:34 p.m.
New subject: [Engine-devel] RES: Cluster default with empty processor name with PPC64 support
On 10/08/2013 09:25 PM, Leonardo Bianconi wrote:
________________________________________
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:rgolan@redhat.com]
>> 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
support
>>
>> On 09/02/2013 03:35 PM, Leonardo Bianconi wrote:
>>>
>>>>> From: Roy Golan [mailto:rgolan@redhat.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
>> 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-...
> 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...
4093
days inactive
4132
days old
13 comments
3 participants
participants (3)
-
Itamar Heim -
Leonardo Bianconi -
Roy Golan