6:48 p.m.
Content analysis details: (-1.0 points, 5.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
-0.0 SHORTCIRCUIT Not all rules were run, due to a shortcircuited rule
-1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP
Cc: users(a)ovirt.org
Subject: Re: [ovirt-users] Console button greyed out (4.2)
X-BeenThere: users(a)ovirt.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Main users mailing list for oVirt <users.ovirt.org>
List-Unsubscribe: <http://lists.ovirt.org/mailman/options/users>;,
<mailto:users-request@ovirt.org?subject=unsubscribe>
List-Archive: <http://lists.ovirt.org/pipermail/users/>
List-Post: <mailto:users@ovirt.org>
List-Help: <mailto:users-request@ovirt.org?subject=help>
List-Subscribe: <http://lists.ovirt.org/mailman/listinfo/users>;,
<mailto:users-request@ovirt.org?subject=subscribe>
X-List-Received-Date: Tue, 20 Feb 2018 17:48:10 -0000
This is a multi-part message in MIME format.
--------------685BB57C4648C7C41BBE28CB
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
On 02/20/2018 12:17 PM, Michal Skrivanek wrote:
> On 19 Feb 2018, at 23:36, Jason Keltz <jas(a)cse.yorku.ca
> <mailto:jas@cse.yorku.ca>> wrote:
>
> Hi Michal,
>
> On 2/15/2018 12:05 PM, Michal Skrivanek wrote:
>
>>> On 15 Feb 2018, at 16:37, Jason Keltz<jas(a)cse.yorku.ca> wrote:
>>>
>>> On 02/15/2018 08:48 AM,nicolas(a)devels.es wrote:
>>>> Hi,
>>>>
>>>> We upgraded one of our infrastructures to 4.2.0 recently and since then
some of our machines have the "Console" button greyed-out in the Admin UI, like
they were disabled.
>>>>
>>>> I changed their compatibility to 4.2 but with no luck, as they're
still disabled.
>>>>
>>>> Is there a way to know why is that, and how to solve it?
>>>>
>>>> I'm attaching a screenshot.
>>> Hi Nicolas.
>>> I had the same problem with most of my VMs after the upgrade from 4.1 to
4.2.
>>> See bugzilla here:https://bugzilla.redhat.com/show_bug.cgi?id=1528868
>>> (which admittedly was a mesh of a bunch of different issues that occurred)
>> yeah, that’s not a good idea to mix more issues:)
>> Seemshttps://bugzilla.redhat.com/show_bug.cgi?id=1528868#c26 is the last one
relevant to the grayed out console problem in this email thread.
>>
>> it’s also possible to check "VM Devices” subtab and list the graphical
devices. If this is the same problem as from Nicolas then it would list cirrus and it
would be great if you can confirm the conditionas are similar (i.e. originally a 3.6 VM)
> I believe it was originally a 3.6 VM. Is there anywhere I can verify
> this info? If not, it would be helpful if oVirt kept track of the
> version that created the VM for cases just like this.
Hi,
well, we keep the date and who did that, but we can’t really keep all
the logs forever. Well, you can if you archive them somewhere, but I
guess that’s impractical for such a long time:-D
I wasn't really thinking in terms of logs. I was thinking a database
field that tracks the ovirt version that created the VM.
>
> VM Device subtab: (no Cirrus)
> <eadpakjggeififdb.png>
so this is a screenshot from VM where the button is grayed out when
you start it?
Hm..it doesn’t look wrong.
Yes.
>> And then - if possible - describe some history of what
happened. When was the VM created, when was cluster updated, when the system was upgraded
and to what versions.
> All I know is that everything was working fine, then I updated to
> 4.2, updated cluster version, and then most of my consoles were not
> available. I can't remember if this happened before the cluster
> upgrade or not. I suspect it was most and not all VMs since some of
> them had been created later than 3.6, and this was an older one. I
> only have this one VM left in this state because I had deleted the
> other VMs and recreated them one at a time...
> I will wait to see if you want me to try Vineet's solution of making
> it headless,
Thanks.
Can you get engine.log and vdsm log when you attempt to start that VM
? just the relevant part is enough.
Sure.. I restarted the VM (called "rs").
engine.log: http://www.eecs.yorku.ca/~jas/ovirt-debug/02202018/engine.log
vdsm log: http://www.eecs.yorku.ca/~jas/ovirt-debug/02202018/vdsm.log
Jason.
--------------685BB57C4648C7C41BBE28CB
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit
<html>
<head>
<meta http-equiv="Content-Type" content="text/html;
charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<br>
<div class="moz-cite-prefix">On 02/20/2018 12:17 PM, Michal
Skrivanek wrote:<br class="">
</div>
<blockquote type="cite"
cite="mid:C1F099C7-BBED-4F94-AE82-8B3F39D5600C@redhat.com">
<div>
<blockquote type="cite" class="">
<div class="">On 19 Feb 2018, at 23:36, Jason Keltz
<<a
href="mailto:jas@cse.yorku.ca" class=""
moz-do-not-send="true">jas(a)cse.yorku.ca</a>&gt;
wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<meta content="text/html; charset=utf-8"
http-equiv="Content-Type" class="">
<div bgcolor="#FFFFFF" text="#000000"
class="">
<p class="">Hi Michal,</p>
<p class="">On 2/15/2018 12:05 PM, Michal Skrivanek wrote:
</p>
<blockquote
cite="mid:2EA3B6C6-C3E8-45D8-8ED4-4DF0AE97D279@redhat.com"
type="cite" class="">
<blockquote type="cite" class="">
<pre class="" wrap="">On 15 Feb 2018, at
16:37, Jason Keltz <a class="moz-txt-link-rfc2396E"
href="mailto:jas@cse.yorku.ca"
moz-do-not-send="true">&lt;jas(a)cse.yorku.ca&gt;</a> wrote:
On 02/15/2018 08:48 AM, <a class="moz-txt-link-abbreviated"
href="mailto:nicolas@devels.es"
moz-do-not-send="true">nicolas(a)devels.es</a> wrote:
</pre>
<blockquote type="cite" class="">
<pre class="" wrap="">Hi,
We upgraded one of our infrastructures to 4.2.0 recently and since then some of our
machines have the "Console" button greyed-out in the Admin UI, like they were
disabled.
I changed their compatibility to 4.2 but with no luck, as they're still disabled.
Is there a way to know why is that, and how to solve it?
I'm attaching a screenshot.
</pre>
</blockquote>
<pre class="" wrap="">Hi Nicolas.
I had the same problem with most of my VMs after the upgrade from 4.1 to 4.2.
See bugzilla here: <a class="moz-txt-link-freetext"
href="https://bugzilla.redhat.com/show_bug.cgi?id=1528868"
moz-do-not-send="true">https://bugzilla.redhat.com/show_bug....
(which admittedly was a mesh of a bunch of different issues that occurred)
</pre>
</blockquote>
<pre class="" wrap="">yeah, that’s not a good
idea to mix more issues:)
Seems <a class="moz-txt-link-freetext"
href="https://bugzilla.redhat.com/show_bug.cgi?id=1528868#c26"
moz-do-not-send="true">https://bugzilla.redhat.com/show_bug....
is the last one relevant to the grayed out console problem in this email thread.
it’s also possible to check "VM Devices” subtab and list the graphical devices. If
this is the same problem as from Nicolas then it would list cirrus and it would be great
if you can confirm the conditionas are similar (i.e. originally a 3.6 VM)</pre>
</blockquote>
I believe it was originally a 3.6 VM. Is there anywhere I
can verify this info? If not, it would be helpful if oVirt
kept track of the version that created the VM for cases
just like this.<br class="">
</div>
</div>
</blockquote>
<div><br class="">
</div>
Hi,</div>
<div>well, we keep the date and who did that, but we can’t really
keep all the logs forever. Well, you can if you archive them
somewhere, but I guess that’s impractical for such a long
time:-D</div>
<div><br class="">
</div>
</blockquote>
I wasn't really thinking in terms of logs. I was thinking a
database field that tracks the ovirt version that created the VM.<br>
<br>
<blockquote type="cite"
cite="mid:C1F099C7-BBED-4F94-AE82-8B3F39D5600C@redhat.com">
<div>
<blockquote type="cite" class="">
<div class="">
<div bgcolor="#FFFFFF" text="#000000"
class=""> <br
class="">
VM Device subtab: (no Cirrus)</div>
</div>
</blockquote>
<blockquote type="cite" class="">
<div class="">
<div bgcolor="#FFFFFF" text="#000000"
class=""> <span
id="cid:part1.802471EC.76DEFB09@cse.yorku.ca"><eadpakjggeififdb.png></span><br
class="">
</div>
</div>
</blockquote>
<div><br class="">
</div>
so this is a screenshot from VM where the button is grayed out
when you start it? </div>
<div>Hm..it doesn’t look wrong.</div>
<div><br class="">
</div>
</blockquote>
Yes. <br>
<br>
<blockquote type="cite"
cite="mid:C1F099C7-BBED-4F94-AE82-8B3F39D5600C@redhat.com">
<div>
<blockquote type="cite" class="">
<div class="">
<div bgcolor="#FFFFFF" text="#000000"
class="">
<blockquote
cite="mid:2EA3B6C6-C3E8-45D8-8ED4-4DF0AE97D279@redhat.com"
type="cite" class="">
<pre class="" wrap="">And then - if possible -
describe some history of what happened. When was the VM created, when was cluster updated,
when the system was upgraded and to what versions.
</pre>
</blockquote>
All I know is that everything was working fine, then I
updated to 4.2, updated cluster version, and then most of
my consoles were not available. I can't remember if this
happened before the cluster upgrade or not. I suspect it
was most and not all VMs since some of them had been
created later than 3.6, and this was an older one. I
only have this one VM left in this state because I had
deleted the other VMs and recreated them one at a time...
<br class="">
I will wait to see if you want me to try Vineet's solution
of making it headless,<br class="">
</div>
</div>
</blockquote>
<div><br class="">
</div>
<div>Thanks.</div>
<div>Can you get engine.log and vdsm log when you attempt to
start that VM ? just the relevant part is enough.</div>
<div class=""><br class="">
</div>
</div>
</blockquote>
Sure.. I restarted the VM (called "rs").<br>
<br>
engine.log:
<a class="moz-txt-link-freetext"
href="http://www.eecs.yorku.ca/~jas/ovirt-debug/02202018/engine.log">http://www.eecs.yorku.ca/~jas/ovirt-debug/02202018/engine.log</a><br>
<br>
vdsm log:
<a class="moz-txt-link-freetext"
href="http://www.eecs.yorku.ca/~jas/ovirt-debug/02202018/vdsm.log">http://www.eecs.yorku.ca/~jas/ovirt-debug/02202018/vdsm.log</a><br>
<br>
Jason.<br>
<br>
</body>
</html>
--------------685BB57C4648C7C41BBE28CB--