Weekly Edition
Return to the Announcements page
| |||||||||||||
|
| |||||||||||||
Qumranet de-cloaks
Qumranet, the company behind the KVM virtualization subsystem
which quickly found its way into the mainline kernel last year, has finally
unveiled its business plans. The press
release is available in PDF format. "Solid ICE enables
enterprises to host desktops in KVM virtual machines on servers in the
corporate data center, and allows users to connect to them via a remote
protocol called SPICE. The benefits for IT include centralized
provisioning, management, policy enforcement and compliance for desktops.
In addition, due to the KVM and SPICE combination, Solid ICE delivers a
superior end-user experience, especially with respect to graphics and
multimedia."
(Log in to post comments)
Story on this Posted Sep 25, 2007 14:32 UTC (Tue) by dmarti (subscriber, #11625) [Link] I also talked with John-Marc Clark and Rami Tamir about the company, including the idea of "remote presence" -- transparently moving a user's Windows guest to a physically closer server for better response.
Story on this Posted Sep 25, 2007 20:26 UTC (Tue) by kjp (subscriber, #39639) [Link] sounds like a citrix competitor. hopefully less bloated and cumbersome, along with the ability to host multiple os's.
Qumranet de-cloaks Posted Sep 25, 2007 14:45 UTC (Tue) by ken (subscriber, #625) [Link] apparently they are "leading provider of virtual computing solutions" not bad to be leader the same day as the announcement of the company's first product.
Qumranet de-cloaks Posted Sep 25, 2007 16:31 UTC (Tue) by dark (✭ supporter ✭, #8483) [Link] This is normal in press releases. As far as I can tell, it's an indicatorof the size of the company. Medium-sized companies are "leading providers". Small companies are "global leaders". Large companies apparently don't lead anything.
Qumranet de-cloaks Posted Sep 25, 2007 18:56 UTC (Tue) by jengelh (subscriber, #33263) [Link] By the pigeonhole principle, all but one {company claiming to be the leader} is lying.
Qumranet de-cloaks Posted Sep 26, 2007 11:56 UTC (Wed) by phip (subscriber, #1715) [Link] Not necessarily. They could all be lying.
Qumranet de-cloaks Posted Sep 25, 2007 14:50 UTC (Tue) by djabsolut (guest, #12799) [Link] from page 3 of the PDF: Existing desktop-like performance including video, audio etc.This smells of hubris. Playing high-res videos from these virtualised desktops would eat up network capacity rather quickly.
Qumranet de-cloaks Posted Sep 25, 2007 15:30 UTC (Tue) by quintesse (subscriber, #14569) [Link] If you'd read TFA you'd know that it is meant for high-bandwidth LANs:
"The company offers a remote desktop protocol it calls SPICE, which Tamir says is suitable for use over a LAN and supports high-bandwidth uses such as bidirectional audio and video."
Mac OS X is on the roadmap Posted Sep 25, 2007 15:24 UTC (Tue) by acoffman (guest, #4599) [Link] From the FAQ
Which virtual guest client operating systems are supported?
It'll be interesting to see Apple's response to that.
Qumranet de-cloaks Posted Sep 25, 2007 16:05 UTC (Tue) by tzafrir (subscriber, #11501) [Link] Can they get a trademark for SPICE?
Qumranet de-cloaks Posted Sep 25, 2007 16:48 UTC (Tue) by i3839 (subscriber, #31386) [Link] Nah: http://en.wikipedia.org/wiki/Spice_%28disambiguation%29
Qumranet de-cloaks Posted Sep 25, 2007 16:09 UTC (Tue) by tjw.org (guest, #20716) [Link] This sounds interesting, but I have to wonder what advantages SPICE offers over running win2k/winxp instances in KVM then connecting to them with RDP (rdesktop or Terminal Services Client).
Qumranet de-cloaks Posted Sep 25, 2007 16:29 UTC (Tue) by dmarti (subscriber, #11625) [Link] What they told me is that SPICE is snappier over a LAN than RDP, but that RDP still works better over a WAN link. But the idea is that you should just move your whole desktop guest to a server on your LAN instead.
Qumranet de-cloaks Posted Sep 26, 2007 1:20 UTC (Wed) by wilreichert (subscriber, #17680) [Link] Are they targeting small to medium business who typically keep their hardware in datacenters?
Virtualizing desktops is a much more difficult problem than servers as they typically have a much more predictable workload. Would be very curious to see how this scales on multi-core cpus.
Qumranet de-cloaks Posted Sep 26, 2007 19:05 UTC (Wed) by jordanb (subscriber, #45668) [Link] Employee workstations have predictable workload too: relatively low loads during the day, with a period of high load during the lunch hour.
The workloads of managers' and executives' workstations can be a little harder to predict.
Qumranet de-cloaks Posted Sep 25, 2007 16:37 UTC (Tue) by subhashreddy52 (subscriber, #41805) [Link] Dear Corbet,
Any article coming soon on the KVM design and that how KVM compares/differs from other virtualization methodologies?
Thanks,
Qumranet de-cloaks Posted Sep 25, 2007 18:35 UTC (Tue) by hummassa (subscriber, #307) [Link] http://lwn.net/Articles/206014/http://lwn.net/Articles/216794/ http://lwn.net/Articles/223839/
Qumranet de-cloaks Posted Sep 25, 2007 20:09 UTC (Tue) by subhashreddy52 (subscriber, #41805) [Link] Thanks. I looked at those articles before, though.
Qumranet de-cloaks Posted Sep 25, 2007 20:46 UTC (Tue) by khim (guest, #9252) [Link] Short explanation is simple. There are exist a problem with virtualization: classic x86 is hard to virtualize since some privileged commands just return wrong result when called in unprivileged mode Iinstead of causing catchable exception) and so can not be properly virtualized. VMWare, Xen and KVM differ in approach to solve this problem. VMWare is doing on-the-fly binary recompilation - which usually works very well, but now and then everything just blows up. Xen is using modified kernel sources - so offending commands are not used at all. KVM uses hardware solution: Intel VT and AMD-V offer a way to virtualize these "bad" conmmands. Now it should be easy to see why the KVM is the only sane solution - and also why it's so immature right now: support for virtualization in hardware is a new thing, before it existed KVM was unimaginable so all code is new. VMWare and Xen are working solutions but actually without feature - or rather their future is slow conversion to "KVM-style" over many years.
Qumranet de-cloaks Posted Sep 26, 2007 12:21 UTC (Wed) by cpm (guest, #3554) [Link] Thanks very much for that concise explaination. I've been sufferingthrough stuff written as it were important to avoid actually explaining anything.
Qumranet de-cloaks Posted Sep 26, 2007 15:21 UTC (Wed) by pcampe (subscriber, #28223) [Link] VmWare and Xen also offers hardware-assisted virtualization, so they are more pervasive than KVM. As the whole point about virtualization is having an homogenous environment from heterogeneous hardware, they are better because you do not have to buy brand new server to virtualize your current workload.
I agree that some years from now we'll have minimal performance drop in hardware-assisted virtualization, but now and for some time para-virtualization is still better (I don't dig into AMD Barcelona-specific nested-paging that, they say, will help a lot in covering the gap).
Qumranet de-cloaks Posted Sep 27, 2007 18:01 UTC (Thu) by drag (subscriber, #31333) [Link] KVM is Qemu-based, no?
We already have a drop-in for people who do not want new servers.
Kqemu accelerator for Qemu. On the current generation of hardware Xen/KVM/Kqemu offer compariable efficiences when doing full virtualization.
The nice thing is that, right now, you can get virtualization without paying a cent, without adding patches to your kernel, or running it on a hypervisor.
And there is also nice GUIs for managing it. Qemu-launcher works just as well with KVM as it does with Kqemu-accelerated Qemu or just plain Qemu.
Here are just a few of the fun things you can do, right now, with Qemu-based environments.
provide block devices to run as the emulated disk. Much faster then loop-back-file-based virtual drive. This can be done locally by dedicating a partition or, better yet, using software raid and LVM and using logical volumes for drives. This can be done remotely by taking advantage of NBD, iSCSI (open source, high performance, software solutions are Open iSCSI (in the kernel) and iSCSI enterprise target), GFS's GNBD, and probably ATAoE (although, IMO, iSCSI or NBD/GNBD offer better solutions)
You can mount 'partitions' in a partitioned logical volume (or loopback file) by taking advantage of the 'offset' option in mount (and losetup)
For example:
Disk good.img: 0 MB, 0 bytes
Device Boot Start End Blocks Id System
(the -u option has everything show up in 512 byte blocks)
multiply 512 by the 'start' number for and you get your offset to use in the mount command.
So that takes care of (relatively) high performance I/O
Want to have 'headless' virtual servers?
Qemu has the option of connecting a virtual serial port on the hosted OS to the terminal that launched it. So if you configure lilo correctly and configure your console on the hosted OS to output to that serial port then you can have boot prompt access and console access to your sytem. Then with screen running you can go ahead and log out.
Then there are all sorts of other things you can do. It's very cool.
If your using Debian....
The most difficult part is that Debian doesn't set the kqemu module to proper permissions yet (say a kqemu or virtual group or something) so you have to chmod that manually, but it's not a big deal.
On most computers that can run KVM they will still run Kqemu a bit faster. The hardware support just isn't better then software right now. But either way they both can provide a VM that has within 92% the performance of the host cpu performance.
It's to the point were the actual difference in CPU performance is immaterial. What the big bottlenecks are doesn't have much to do with CPU performance, but has much more to do with I/O. Disk I/0, Video output, and network I/O is still MUCH MUCH slower in a VM.
In terms of Linux/FreeBSD/etc we can get OpenGL hardware acceleration over network'd X using AIGLX (I've tried it from Linux host to Linux host and it works great). But now it's possible to get OpenGL acceleration on a desktop running X locally through VMGL. http://www.cs.toronto.edu/~andreslc/xen-gl/
Used to be Xen-GL, but it should work for Qemu-based stuff now also. Should be possible to be used with Windows running in a VM with special windows drivers, but for right now it's *nix only.
If Linux desktop-friendly Qemu-based virtualization efforts (KVM, Kqemu, VirtualBox is also Qemu-based, as is Win4lin (Win4lin paid to get Kqemu released under the GPL, btw)) solve the I/O performance issues then that would definately put Linux and open source on the top of low-to-mid range virtualization market... with high-end enterprise VM going with Xen and Vmware.
I, repeat. The virtual cpu performance differences between Kvm/Kqemu/Xen (non-para-virtualized), and Vmware are negligable. Effectively that is a solved problem when compared to the I/O bottleneck issues.
I suppose Linux will just have to get a special 'virtualization' disk and network driver so that, along with special drivers running in OS in the VM will allow a para-virtualization approach to I/O. Something like that. I think I remember seeing here somewhere people were talking about it.
SPICE Posted Sep 26, 2007 17:41 UTC (Wed) by rfunk (subscriber, #4054) [Link] Obviously the inventors of the SPICE network protocol have never done circuitanalysis.
|
|
||||||||||||