Re: [ovirt-users] Hung task in the Tasks tab

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 <http://www.cpr.org/> On Mon, May 25, 2015 at 3:30 AM, Eli Mesika <emesika(a)redhat.com <mailto:emesika@redhat.com>> wrote: ----- Original Message ----- > From: "Christopher Cross" <crcross(a)cprmail.org <mailto:crcross@cprmail.org>> > To:Users@ovirt.org <mailto:Users@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 <tel:303-871-9191%2C%20ext.%20258> >www.cpr.org <http://www.cpr.org> > > ... > > _______________________________________________ > Users mailing list > Users(a)ovirt.org <mailto:Users@ovirt.org> > http://lists.ovirt.org/mailman/listinfo/users > ...