On 12/06/2013 09:14 PM, Bob Doolittle wrote:
On 12/06/2013 06:25 AM, Vinzenz Feenstra wrote:
>> On 12/06/2013 05:33 AM, Blaster wrote:
>>
>> I guess I'm confused as to how Red Hat can be making statements that
>> Ovirt is a viable alternative to ESXi when many simple things that
>> ESXi users take for granted simply don't work or are non-existent
>> under Ovirt. I'm hardly a power user of ESXi, and I've only begun
>> my Ovirt journey, but I've already come across the following:
...
> 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.
True but you'll note that Blaster's overall comments were about Red
Hat's marketing of this project as a solution, given it's status. I
agree that it's a bit premature. oVirt is maturing quickly, but it
still has a ways to go. It will get there, as you point out, and of
course driving demand by a little over-enthusiastic marketing may
actually accelerate that process, which may be a goal (Machiavelli
would approve :). It will also frustrate some users, unfortunately.
> Another thing having to say about your point 4 is that you're basing
> your experience solely on Windows guests, which are a bit more
> troublesome to support the same way we do for example Linux guests.
Here I disagree. My experience is the opposite. You can get almost
everything (that I care about anyway) for Windows by installing
spice-guest-tools (once you find it - there are few clues on the oVirt
Wiki). This includes drivers, better mouse/display handling, and
copy/paste. It does not seem however to include communication of the
IP address (nor, I suspect, clean shutdown handling).
My point was about providing
our own binaries for the oVirt guest agent.
We have not yet solved targeting Windows for the guest agent binaries
for oVirt. My bad that it wasn't explicit enough.
It's on Linux where you have to piece together more things, and in
fact have to build some things (e.g. vdagent) from source.
Once
https://bugzilla.redhat.com/show_bug.cgi?id=1026933 is fixed
(currently slated for 3.3.3 :( ), and assuming that a VFD will be
included and not just an ISO, the experience will be much simpler for
Windows than for Linux for those pieces.
If we were to build vdagent for Linux and make the RPMs for it and the
Linux Guest Agent available in an easy way (incorporate them into an
ISO and pre-populate ISO_DOMAIN with it?) that would be a big step
forward for Linux guests. It's possible that you'd have to build
vdagent from source, using some kind of automated build/install script
on the ISO, to make it work for a variety of Linux distros. That's
effectively what VMware has done. When building from source I find
resolving the dependencies to be a big headache, particularly on Fedora.
Well on
fedora it would be as easy as yum install spice-vdagent, no
headaches here from my point of view.
However requiring all the devel packages just to install the agent on
the target platform from sources is a bit overkill in my opinion.
On linux we rather should go with the default packaging ways. That's
what we're working on at the moment as well. We have already built
packages for Fedora, distributions using EPEL (e.g. CentOS), OpenSUSE
and Ubuntu. Upcoming targets are SLES and Debian.
So for those it would be doable without having to build from sources.
However besides Fedora and EPEL we don't have yet reached inclusion into
the repositories for those packages, for Ubuntu it's on launchpad and
for OpenSuSE on their open build infrastructure.
As I said eventually we'll get there that we'll provide binaries for that.
-Bob
--
Regards,
Vinzenz Feenstra | Senior Software Engineer
RedHat Engineering Virtualization R & D
Phone: +420 532 294 625
IRC: vfeenstr or evilissimo
Better technology. Faster innovation. Powered by community collaboration.
See how it works at
redhat.com