On Fri, Mar 1, 2019 at 9:47 AM Ron Jerome <ronj...@gmail.com> wrote: > Thanks Michal, > > I think we are onto something here. That request is getting a 401 > unauthorized response... > > ssl_access_log:10.10.10.41 - - [01/Mar/2019:09:26:46 -0500] "GET > /ovirt-engine/api/vms/?search=id=dc0a6167-3c36-48e4-9cca-d69303037859 > HTTP/1.1" 401 71 > > I guess it should be noted here that I'm accessing the engine through a > squid proxy on one of the hosts. I just tested a direct connection to the > engine (without going through the proxy) and it works, so the next question > is how to fix the proxy issue? Could this be an SSL certificate issue? >
Oh, squid :) Please verify that you have "login=PASSTHRU" set. Like in #14 here: https://www.ovirt.org/documentation/admin-guide/chap-Proxies.html#installing-and-configuring-a-squid-proxy > Ron. > > On Fri, 1 Mar 2019 at 04:50, Michal Skrivanek <mskri...@redhat.com> wrote: > >> >> >> On 1 Mar 2019, at 02:34, Ron Jerome <ronj...@gmail.com> wrote: >> >> Here is the JS error that is being generated when I push the "Migrate" >> button... >> >> DataProvider failed to fetch data SyntaxError: JSON.parse: unexpected >>> character at line 1 column 1 of the JSON data DataProvider.js:35:8 >>> >>> value/< >>> DataProvider.js:35:8 >>> A/</< >>> >>> es6.promise.js:75 >>> >>> A/< >>> es6.promise.js:60 >>> l >>> _ >>> microtask.js:18 >>> >> >> >> Hi, >> without a reproduced you’d need to provide a bit more info. Is there >> anything else in the console? >> It would be best to understand which requests returned invalid data, for >> that you can enable the network monitoring and grab the request and >> response perhaps? We need to see if it’s really the migration request or >> anything else, and what was the actual response >> >> Thanks, >> michal >> >> Ron. >> >> On Wed, 27 Feb 2019 at 17:26, Greg Sheremeta <gsher...@redhat.com> wrote: >> >>> Hi Ron, >>> >>> Please attach your browser console log and engine.log snippet when you >>> have the problem. >>> If you could dive into the console and grab the actual REST API >>> response, that would be great. >>> The request will be something like >>> <engine>/api/hosts?migration_target_of=... >>> >>> Greg >>> >>> On Tue, Feb 26, 2019 at 6:32 PM Greg Sheremeta <gsher...@redhat.com> >>> wrote: >>> >>>> It sounds like a bug. I'll talk with Michal about reverting this dialog >>>> to the 4.2 version. >>>> >>>> Greg >>>> >>>> On Tue, Feb 26, 2019 at 1:47 PM Ron Jerome <ronj...@gmail.com> wrote: >>>> >>>>> Hi Sharon, >>>>> This happens with all the VM's, regardless of uptime. I've never >>>>> tried to migrate a VM if it's not completely up. >>>>> >>>>> When I select a VM and push the "Migrate" button, I never get to the >>>>> "Migrate" dialog box, I just presents the error show in the attached >>>>> image. >>>>> >>>>> I know for a fact that manual migration did work on this cluster, >>>>> unfortunately, I don't know if it ever worked in 4.3.0 or if I was still >>>>> at >>>>> 4.2.8 when I last used it. >>>>> >>>>> Ron. >>>>> >>>>> On Tue, 26 Feb 2019 at 11:59, Sharon Gratch <sgra...@redhat.com> >>>>> wrote: >>>>> >>>>>> Hi Ron, >>>>>> >>>>>> What is the VM state when you try to manually migrate it? Is the VM >>>>>> in the beginning of the "powering up" state? >>>>>> If so then please wait 1-2 seconds and then try to migrate again and >>>>>> see if it is reproduced. >>>>>> You can't migrate a VM on "Wait for Launch" state and once the VM >>>>>> enters the "powering up" state then it sometimes takes time for UI to be >>>>>> refreshed with state and data. It was reproduced to me too. >>>>>> >>>>>> Greg, does it sound reasonable? >>>>>> >>>>>> Thanks, >>>>>> Sharon >>>>>> >>>>>> >>>>>> >>>>>> Can you please send a screenshot of the "Migrate VM(s)" dialog with th >>>>>> >>>>>> On Tue, Feb 26, 2019 at 5:33 PM Ron Jerome <ronj...@gmail.com> wrote: >>>>>> >>>>>>> I've toggled all the hosts into and out of maintenance, and VM's >>>>>>> migrate off of each as expected, but I still can't manually initiate a >>>>>>> VM >>>>>>> migration from the UI. Do you have any hints as to where to look for >>>>>>> error >>>>>>> messages? >>>>>>> >>>>>>> Thanks in advance, >>>>>>> >>>>>>> Ron. >>>>>>> >>>>>>> On Mon, 25 Feb 2019 at 19:56, Ron Jerome <ronj...@gmail.com> wrote: >>>>>>> >>>>>>>> >>>>>>>> It's a 3 node cluster, each node has 84G RAM, and there are only >>>>>>>> two two other VM's running, so there should be plenty of capacity. >>>>>>>> >>>>>>>> Automatic migration works, if I put a host into Maintenance, the >>>>>>>> VM's will migrate. >>>>>>>> >>>>>>>> Ron >>>>>>>> >>>>>>>> On Mon, Feb 25, 2019, 6:46 PM Greg Sheremeta, <gsher...@redhat.com> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Turns out it's a bad error message. It just means there are no >>>>>>>>> hosts available to migrate to. >>>>>>>>> >>>>>>>>> Do you have other hosts up with capacity? >>>>>>>>> >>>>>>>>> Greg >>>>>>>>> >>>>>>>>> >>>>>>>>> On Mon, Feb 25, 2019 at 3:01 PM Ron Jerome <ronj...@gmail.com> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> I've been running 4.3.0 for a few weeks now and just discovered >>>>>>>>>> that I can't manually migrate VM's from the UI. I get an error >>>>>>>>>> message >>>>>>>>>> saying: "Could not fetch data needed for VM migrate operation" >>>>>>>>>> >>>>>>>>>> Sounds like >>>>>>>>>> https://bugzilla.redhat.com/show_bug.cgi?format=multiple&id=1670701 >>>>>>>>>> >>>>>>>>>> Ron. >>>>>>>>>> _______________________________________________ >>>>>>>>>> Users mailing list -- users@ovirt.org >>>>>>>>>> To unsubscribe send an email to users-le...@ovirt.org >>>>>>>>>> Privacy Statement: https://www.ovirt.org/site/privacy-policy/ >>>>>>>>>> oVirt Code of Conduct: >>>>>>>>>> https://www.ovirt.org/community/about/community-guidelines/ >>>>>>>>>> List Archives: >>>>>>>>>> https://lists.ovirt.org/archives/list/users@ovirt.org/message/5OBUNZHUPVEDZ5YLTXI2CQEPBQGBZ2JT/ >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> GREG SHEREMETA >>>>>>>>> >>>>>>>>> SENIOR SOFTWARE ENGINEER - TEAM LEAD - RHV UX >>>>>>>>> Red Hat NA >>>>>>>>> >>>>>>>>> <https://www.redhat.com/> >>>>>>>>> >>>>>>>>> gsher...@redhat.com IRC: gshereme >>>>>>>>> <https://red.ht/sig> >>>>>>>>> >>>>>>>> _______________________________________________ >>>>>>> Users mailing list -- users@ovirt.org >>>>>>> To unsubscribe send an email to users-le...@ovirt.org >>>>>>> Privacy Statement: https://www.ovirt.org/site/privacy-policy/ >>>>>>> oVirt Code of Conduct: >>>>>>> https://www.ovirt.org/community/about/community-guidelines/ >>>>>>> List Archives: >>>>>>> https://lists.ovirt.org/archives/list/users@ovirt.org/message/VVSXK3WO4AA5B7T6LGEYWRBNAO56G46V/ >>>>>>> >>>>>> >>>> >>>> -- >>>> GREG SHEREMETA >>>> >>>> SENIOR SOFTWARE ENGINEER - TEAM LEAD - RHV UX >>>> Red Hat NA >>>> >>>> <https://www.redhat.com/> >>>> >>>> gsher...@redhat.com IRC: gshereme >>>> <https://red.ht/sig> >>>> >>> >>> >>> -- >>> GREG SHEREMETA >>> >>> SENIOR SOFTWARE ENGINEER - TEAM LEAD - RHV UX >>> Red Hat NA >>> >>> <https://www.redhat.com/> >>> >>> gsher...@redhat.com IRC: gshereme >>> <https://red.ht/sig> >>> >> >> -- GREG SHEREMETA SENIOR SOFTWARE ENGINEER - TEAM LEAD - RHV UX Red Hat NA <https://www.redhat.com/> gsher...@redhat.com IRC: gshereme <https://red.ht/sig>
_______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-le...@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/4V5NAEXZMEA2GSGUXJLMIQ2PCBWDXEG2/
