On Sat, Jun 8, 2013 at 5:21 AM, Alexandru Ionica <alexandru.ion...@gmail.com > wrote:
> This has taken the wrong turn, so my apologies Bryan. It is my fault that > I didn't clearly specify that because you work for <vendor with a space> > you will be biased as you will mostly see their solutions implemented and > support or implement them. > Which is _false_. I see a lot of solutions. Ever see a Red Hat maintainer brought in on a project to solve another distro's issues? I have. Why? Because the components in the other distro is maintained by someone in Red Hat upstream. Seriously dude ... get off it. I know _technologies_, _not_ products. *>RHEV has gained major traction just because of lack of features for Linux > guests. Heck, on the VDI front, RHEV+Spice is the _only_ solution. And > it's 100% open source.* > There are other open source VDI solutions which exist way before spice was > even created (http://freenx.berlios.de/ for example which was a spinoff > from http://www.nomachine.com 's opensourced NX 3.5 components). We can > discuss about how good they are but that doesn't change that they exist > since a long time ago, there are lots of deployments out there and FreeNX > is Opensource. > And I've worked on some of the largest and most distributed NX and other deployments (1,000s of thin clients). Again, do _not_ assume anything about me or Red Hat associates in general. Red Hat has Debian, SuSE and other maintainer experience, some very active in those projects. Stop assuming! Really ... I have been brought in as a Red Hat associate to solve issues that aren't even Red Hat products. Why? Because we have a lot of developers and maintainers on-staff, in addition to flexible consultants like myself. Stop assuming! If you say Spice is the only solution, > Understand RHEV is a stack of integrated capability. _All_ of the components are open source. Other vendors are free to implement them. Most have not. Most distros, who have stated many years ago they would support it, haven't even implemented the oVirt agents, much less the full stack. I said SPICE is the _only_ significant, open source solution integrated into a full Virtual Desktop Infrastructure (VDI) stack, end-to-end, in a solution like RHEV. It's not just KVM. Case-in-point ... you need to maintain _context_ ... > I'll say that last time I tested (around 8 months ago) it wasn't a viable > solution because the moment you have some flash banner or anything like an > animated banner the network traffic will spike to around 30-40 mbit/sec and > keep like that until you get rid of that banner/animation. > And what does VMware have for Linux VDI instances? *NOTHING*! You keep taking things out-of-context. That's what killing me. It's 3rd party licensed (it doesn't even develop it) PCoIP doesn't even run on Linux _clients_ well (displaying Windows desktops). So stop with VMware comparisons! Now on SPICE ... If you have the bandwidth, it will use it. If you don't, it'll slow down the framerate. But if you will still get frames in sequence. That's the kicker. Qumranet designed SPICE to: #1 - Instance and client on _all_ platforms (all other VM stacks are Win-only) #2 - Solve the animation framing order issue (virtually all others don't, widget-focused) #3 - Use bandwidth as available for framerate (all others are are widget-focused) *Qumranet ste**pped back, really stepped back, and looked at what companies use on the desktop. Flash, video, etc... need to come in and not out-of-order. Most other solutions don't even handle animation well at all, or have only specific accelerators for specific components, nothing general, let alone, their OS/component-specific, and often OS/component version-specific.* * * *If you just want basic widgets, then you can launch RDP/ICA, X11/NX, etc... instead. You will get low bandwidth, and animation ignorant protocols. But if you need animation, SPICE works everywhere. It will use as much bandwidth as is available to get the highest framerate, but it will always send frames in-sequence, even over low bandwidth. It's not designed for slow links, one should use RDP/ICA, X11/NX, etc... instead, and deal with lack of animation.* * * Again, all other solutions used in VM stacks are Windows-only instances (inside the VM), and in many cases, don't even support Linux as a client (displaying a Windows desktop). VMware even licenses a 3rd party (PCoIP), and it's Linux client support is poor (and, again, no Linux VDI instances). That's why there are virtually no other solutions, and RHEV is the sole solution. You mentioned VMware, this is why it is _impossible_ to use when Linux is involved. You keep changing the context, but not stopping to understand the requirements that organization have, and where VMware does not work at all. If you try to limit the network traffic (qdiscs + htb from Linux the > gateway) then the VDI solution(aka the desktop) will become unusable > completely while that animation exists. > The framerate slows down, yes. But frame still come in sequence. It's not "unusable," it's just not going to have an animation that is a high framerate. So a flash page, HTML5 animation, WMV video, etc... still shows up, but may not be but 3-5fps. But it's better than a widget-only protocol that sends things out-of-order, if at all, let alone even attempts to do it, and can suck up a lot of bandwidth as well. Animation is a real issue in VDI, and there's no single solution that can compress or otherwise reduce that problem generically. At most, there are plug-ins for specific OSes and specific versions of components that only do those specific things. And they are virtually _always_ Windows-only. > You can't ensure that no banner will ever be displayed or you won't have > any screen items changing in rapid succesion so Spice works. I have even > asked (live) Hans De Goede at a conference about this and he said that the > video compression poses problems as they are working with video frames and > it get's complicated (you can't do things like you do with solutions which > sit on top of Xorg and give drawing instructions). Otherwise Spice is great > (specially because of the working USB transport) but in the VDI world > network traffic is one of the most important things and other solutions > keep it to between 50 - 120kb/sec at most (they are even lower). > For animation? Really? Seriously? Or are you just talking widgets and framing of the underlying platform with_out_ pixmaps? That's the problem. You're making an argument for something that's not relevant. I.e., Do you understand if you just want that, then use RDP/ICA, X11/NX, etc... _directly_. Don't use SPICE. You can do this _regardless_ of the VM stack. So it works on RHEV-H, ESXi, etc... So you can have a RHEV farm, and a _choice_ of connecting via SPICE, generally, _or_ connecting via the underlying, native widget/framing protocol, specific to the OS. ;) Seriously dude ... you are argumentive to an extreme. And you sound like an EMC VMware sales person. Because I've been in the room, and heard this crap too. Why? Because they say things like "RHEV doesn't have vMotion(TM)." Of course it doesn't, it is an EMC VMware trademark. But RHEV has Live Migrate, same thing. ;) For two years I have worked for SMB doing VDI and I would have loved to > replace FreeNX with something better and Opensource, but unfortunately I > couldn't find something like this. > And I'm really starting to question your understanding of open source technologies. You can use _both_ SPICE _and_ NX (and RDP for Windows) with RHEV. ;) Seriously ... stop picking arguments with me ... because you keep assuming my experience is limited more than yours because you think Red Hat people only know Red Hat. Goodbye. -- Bryan J Smith - Professional, Technical Annoyance b.j.smith at ieee.org - http://www.linkedin.com/in/bjsmith
_______________________________________________ lpi-examdev mailing list lpi-examdev@lpi.org http://list.lpi.org/cgi-bin/mailman/listinfo/lpi-examdev
