[ovirt-users] Hung task in the Tasks tab

[Christopher Cross]

Thanks Eli. This morning I ran the vdsClient command and got back
"{'status': {'message': 'OK', 'code': 0}, 'allTasksStatus': {}}". After
that I decided to try and restart the engine hoping that it would clear the
incorrect status and that worked. Do you think a bug should be opened? I am
not sure that I would be able to recreate it or provide much more
information other than logs. Thanks again for the help.

Christopher Cross
Linux Systems Network Administrator
Colorado Public Radio
7409 South Alton Court | Centennial, CO 80112
303-871-9191, ext. 258
www.cpr.org

On Mon, May 25, 2015 at 3:30 AM, Eli Mesika <emesika at redhat.com> wrote:

>
>
> ----- Original Message -----
> > From: "Christopher Cross" <crcross at cprmail.org>
> > To: Users at ovirt.org
> > Sent: Friday, May 22, 2015 11:01:47 PM
> > Subject: [ovirt-users] Hung task in the Tasks tab
> >
> > Hello,
> >
> > I have been working on a new cluster on 3.5 with CentOS 7 hosts. My
> current
> > production stuff is still on 3.4 So I had to play around a bit to figure
> out
> > the VDSM networking stuff. I got it all sorted but at one point I had a
> host
> > that was not configured correctly and a task, "Configuring networks on
> host
> > vm2", has been sitting in the task tab since then. I was sucsessfull in
> > getting the host configured with all the required bonding, VLANs, and
> > networks I need and the host is functioning fine.
> >
> > My problem is that this task will not go away from the manager web
> interface.
> > I do not think it is actually doing anything but it would be nice to get
> it
> > out of there. I tried making other network changes and re-saving the
> > configuration and also rebooting the host and nothing takes it away. Has
> > anyone else seen this?
>
> please run the following from your SPM host
>
> vdsClient -s 1 getAllTasksStatuses
>
> In case that there is a stuck task, it can be stopped using stopTask (see
> vdsClient --help)
>
> In case that all is OK on the VDSM side, then it seems like a bug in the
> engine side and we will need a BZ for that with engine & vdsm(SPM) logs
>
> We can easily remove that using SQL but lets first see if we can indentify
> the problem origin
>
>
> >
> > Thanks,
> >
> > Christopher Cross
> > Linux Systems Network Administrator
> > Colorado Public Radio
> > 7409 South Alton Court | Centennial, CO 80112
> > 303-871-9191, ext. 258
> > www.cpr.org
> >
> > ...
> >
> > _______________________________________________
> > Users mailing list
> > Users at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/users
> >
>

-- 
...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/users/attachments/20150526/d335601e/attachment-0001.html>