On 12/09/2013 04:42 PM, Blaster wrote:
On Dec 6, 2013, at 5:25 AM, Vinzenz Feenstra <vfeenstr(a)redhat.com
<mailto:vfeenstr@redhat.com>> wrote:
> I understand that you're disappointed and we're trying to make our
> best to make the user experience better. You should be considering the
> age of the project and what we're actually already providing. Yes not
> everything is perfect, but we're working hard on improving it.
> We're working in a collaborative way together with the community, if
> you're missing something, there's always the possibility to help out.
> Even if you're not a programmer you can help improving the experience.
Bob pretty much said it all for me already…I’m not so much as
disappointed in ovirt development as I am the marketing of it. ovirt is
being marketed as an ESXi replacement when it surely isn’t. Probably
90%+ of what ESXi is used for is virtualizing Windows. Give ovirt in
it’s current form to a typical Windows user and they’ll self destruct.
The first issue with the agents as I can’t even find any documentation
on what agents really need installing, and what features I’m getting
with that agent!
Another thing is, I would think that Fedora would be integrated enough
with ovirt that it would be able to automatically detect it’s running on
ovirt and install all the required agents automatically.
I forgot my number 5) BIOS needs to work like a standard PC BIOS (as
does ESXi) in allowing you to press F8 to get a boot menu or F12 for
network boot. This run once stuff is silly. It works fine the first
time I create a VM as there’s no bootable OS on the datastore, but if I
need to re-PXE boot a VM, then I have to Run Once..OK, fine, but when
the PXE completes it reboots, back into network boot, then I have to
kill the VM and restart it normally. Under a PC (or ESXi) BIOS, I just
hit F12, network boot, OS re-installs, then reboots normally. Much
better user experience. I gave our Red Hat sales people feedback on
this issue and was told it’s not going to change.
if you open a support ticket for this request, it will be associated
with an RFE, helping its priority (which is via support, not sales, but
we can take that offline i guess).
iirc, the problem on this one is not supported by qemu or libvirt, so
we'd need vdsm manage the restart as a shutdown (which libvirt
supports), then start the VM again without the ISO.
I'm trying to remember if this was supposed to be resolved by qemu
supporting this or the vdsm logic.
michal?