----- Original Message ----- > From: "Sandro Bonazzola" <sbona...@redhat.com> > To: us...@ovirt.org, devel@ovirt.org > Sent: Tuesday, November 25, 2014 7:07:14 AM > Subject: [ovirt-users] [QE][ACTION REQUIRED] oVirt 3.5.1 RC status - > postponed
[...] > The following bugs have been keyworded as Regression and not marked as > blockers: > 1165336 virt ASSIGNED FC20 qemu needs kvmclock > bugfixes Hi, I'd like to elaborate a bit more here for the sake of the openness. TL;DR version - no actual regression in oVirt, meaning 'we applied a patch and we broke something'. - "fix" is underway - to propose the relevant patches to Fedora QEMU package Long(ish) version 1 some time ago we adhered to QEMU/KVM clock settings recommendations (see https://bugzilla.redhat.com/show_bug.cgi?id=1053846) 2 these recommendations are *still* valid as today - I just checked with upstream developers while investigating bz1165336 3 these recommendations may have surprising effects like disabling HPET clock 4 on some old(ish) upstream QEMUs, disabling HPET may hurt migrations - hence bz1165336 5 only *very* recent QEMUs (2.2.0rc0!) have the fixes, which are about improving kvm clock, while HPET clock is still not recommended (see #2 above) 6 if the qemu-kvm-rhev is used (available in the oVirt repo), the experience is significantly better However, the reporter *has* a very valid point, which motivated me to write me this mail: a. F20 is a supported platform b. I *guess* Fedora is the platform of choice to try out QEMU and to initially play with it c. out-of-the box experience with oVirt and Fedora is cumbersome, many steps and tunings are needed. This may annoy users - without a valid reason! d. hence there is an unneededly high first step to try out oVirt, and this is hurting the project Now, I'd like to raise this question * it is true that Fedora is the platform of choice to try out and evaluate oVirt? * if so, is the experience on Fedora streamlined enough or could it made simple, hence we could have a better vector to spread oVirt? * what we could do, as oVirt project, to improve the above? Feedback welcome -- Francesco Romani RedHat Engineering Virtualization R & D Phone: 8261328 IRC: fromani _______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
