Recent Features
| |||||||||||||
KVM, QEMU, and kernel project managementKVM, QEMU, and kernel project managementPosted Mar 23, 2010 20:45 UTC (Tue) by drag (subscriber, #31333)Parent article: KVM, QEMU, and kernel project management
[b]It's a fact that virtualization is happening in the data center, not on the desktop. You think
a kvm GUI can become a killer application? fine, write one. You don't need any consent from
me as kvm maintainer (if patches are needed to kvm that improve the desktop experience, I'll
accept them, though they'll have to pass my unreasonable microkernelish filters). If you're
right then the desktop kvm GUI will be a huge hit with zillions of developers and people will
drop Windows and switch to Linux just to use it.[/b]
(Log in to post comments)
KVM, QEMU, and kernel project management Posted Mar 23, 2010 21:49 UTC (Tue) by mingo (subscriber, #31122) [Link] Nice observations, i agree with most of them. Just wanted to react to this bit:
What i suggested was to move it into the kernel repository (maybe you understood it as such), but still as a user-space project - a'la tools/perf/. That is a plain user-space tool that lives in the kernel repository. It can be built and installed in user-space by doing: cd tools/perf/ make -j installAnd it's a regular Linux app. It is an admittedly very unusual development model to maintain a user-space tool within the kernel repository, but for such a tool with such close ties to the Linux kernel as perf there are many advantages, and it worked out well beyond our expectations. Thanks, Ingo [*] with the caveat that it does make sense to move certain device emulation and paravirt functionality into the kernel, and not emulate it straight from Qemu. Many performance problems of KVM result from excessive execution in Qemu.
KVM, QEMU, and kernel project management Posted Mar 23, 2010 22:25 UTC (Tue) by ejr (subscriber, #51652) [Link]
Very unusual development model. So unusual that it's been how *BSD and Solaris have functioned, well, forever.
KVM, QEMU, and kernel project management Posted Mar 23, 2010 22:59 UTC (Tue) by mingo (subscriber, #31122) [Link] AFAIK it's still quite different from the FreeBSD model. Last i checked (which, admittedly, was many years ago) in FreeBSD a kernel developer with commit access did not have commit access to a user-space package - and vice versa. So it's not really a unified repository in the same way that tools/perf/ is. Plus, most of the user-space packages are imported into FreeBSD and are maintained externally (with local changes applied), so any local changes would have to be contributed back to the upstream project - eliminating most of the unification gains i talked about in the KVM discussion. In any case, my FreeBSD development model knowledge is pretty outdated, so if the model has changed (or if it never existed in that form) please correct me and educate me ... Plus, just to make it clear: i find the integrated repository aspect of FreeBSD rather useful, and i think Linux should learn from that. Thanks, Ingo
Minimal userspace for kvm in linux-2.6.git Posted Mar 24, 2010 0:03 UTC (Wed) by jrn (subscriber, #64214) [Link] As an innocent bystander, I really liked this suggestion that Avi Kivity made and you picked up: That would make sense for a truly minimal userspace for kvm: we once had a tool called kvmctl which was used to run tests (since folded into qemu). It didn't contain a GUI and was unable to run a general purpose guest. It was a few hundred lines of code, and indeed patches to kvmctl had a much closer correspondence to patches with kvm (though still low, as most kvm patches don't modify the ABI). If it's functional to the extent of at least allowing say a serial console via the console (like the UML binary allows) i'd expect the minimal user-space to quickly grow out of this minimal state. The rest will be history. Maybe this is a better, simpler (and much cleaner and less controversial) approach than moving a 'full' copy of qemu there. I still hope it happens.
Minimal userspace for kvm in linux-2.6.git Posted Mar 24, 2010 12:14 UTC (Wed) by nescafe (subscriber, #45063) [Link]
yeah, having a minimal overhead userspace tool that provides just enough to give me a serial console and the virtio drivers would handle most of my VM needs.
It's just not that simple to build userspace binaries that use lots of libraries Posted Mar 24, 2010 8:45 UTC (Wed) by ringerc (subscriber, #3071) [Link] That is a plain user-space tool that lives in the kernel repository. It can be built and installed in user-space by doing: That's exactly what they can't do, because building real world GUI-using userspace binaries isn't that simple. You need a monster like autoconf or CMake to do the grunt work of locating the large variety of (mostly GUI-related) libraries apps like qemu need to link to to achieve the functionality people expect of them. The day I see a makefile.am and configure.in or a CMakeLists.txt in the kernel tree ... Look at the output of: To be able to keep the core kvm userspace code in the kernel tree, they'd probably have to rip up kvm into a core libkvm.so and "the rest". libkvm.so would be usable by an extremely stripped down GUI-less sound-less ....-less kvm-basic that could also be built by simple makefile and stored in the kernel tree. It'd also be used by a full-featured kvm maintained elsewhere and built with regular build tools. It doesn't seem like any improvement to me, it just moves the interface boundary a bit. I (as joe random) happen to share your general sentiment that some userspace really could use being kept in the kernel. udev or whatever device management daemon of the day is used; module-init-tools; etc. I just don't think it's realistic to put kvm in that group unless it does prove useful to move the interface boundary into a user-space library, ie stable library ABI for library shipped with kernel, unstable kernel ABI for talking to that library. And good luck getting that past the stable-kernel-ABI dragons.
It's just not that simple to build userspace binaries that use lots of libraries Posted Mar 25, 2010 12:39 UTC (Thu) by BenHutchings (subscriber, #37955) [Link] You need a monster like autoconf or CMake to do the grunt work of locating the large variety of (mostly GUI-related) libraries... These days most popular libraries support pkg-config which makes this a whole lot simpler.
It's just not that simple to build userspace binaries that use lots of libraries Posted Mar 26, 2010 3:32 UTC (Fri) by ringerc (subscriber, #3071) [Link]
True, and pkg-config has come a long way lately with things like variable support and even msvc syntax handling. It doesn't help very much if you need to test for build options, though there's no reason why it *can't*. pkg-config's --variable feature would let you do build option tests ... but far too many packages fail to set appropriate .pc variables for important build options.
At least pkg-config makes version tests, cflags discovery, etc a whole lot easier.
KVM, QEMU, and kernel project management Posted Mar 24, 2010 8:49 UTC (Wed) by ringerc (subscriber, #3071) [Link] ... though re-reading your comment, you're in fact correcting a prior misunderstanding and pointing out that you're *not* suggesting putting it in the kernel tree and by extension kernel build system, just in the kernel repo. Sorry. Thrown by your analogy to perf - because it's not really like perf at all.
Desktop vs. Server Virtualization Posted Mar 23, 2010 23:47 UTC (Tue) by dowdle (subscriber, #659) [Link]
Just wanted to add that the "client hypervisor" concept seems to be sweeping the industry as the next big buzzword. I mean that as a compliment because I think client hypervisors are worth all of the hype.
What is a client hypervisor?
I assume everyone knows what VMware ESXi is. Ok, want a Linux example? How about Red Hat's RHEV-Hypervisor. Ok, you know what those are, right? Now imagine them built into firmware and put into every desktop and server by default. This is especially a powerful concept when you imagine that a laptop or desktop computer will no longer need to come with an OS because as long as it has a client hypervisor in firmware you can use a generic OS image.
It basically takes the major feature of virtualization as it applies to servers today... that being hardware independence... and applies it to the desktop OS. Pick one or multiple OS images and run them on demand. Combine that with fast networking for booting VMs over PXE for more than just installation. Combine that with remote desktop protocols (SPICE, RDP/RemoteFX, ICA/HSX, PCoverIP, etc) for thin-client access as well... and just imagine what the desktop of the future will look like.
What stands in the way? Getting the client hypervisor working well with the large variety of hardware available in the PC market... or deciding to reduce the hardware supported. Getting accelerated 3D working in VMs painlessly and well. Other than that, the desktop computer as we know it will completely change over the next 2-10 years. You think anyone is interested in that market? :)
KVM, QEMU, and kernel project management Posted Mar 24, 2010 0:01 UTC (Wed) by zamsden (guest, #36686) [Link]
Wow. Sorry, wrong. The money in virtualization is in the data center, not on the desktop, we are talking several orders of magnitude difference.
Yes there are many use cases for desktop virtualization and you point them out, but they are all niche markets which specific products have been optimized to target.
The reason desktop virtualization lags behind and has not caught on is not because it is particularly painful to use, it is because the use cases don't generate as much money and therefore vendors are not putting as much effort into it. Server revenue is far more important.
These ad-hoc statistics we see quoted are absolutely useless. 70-80% of people on LWN is not a great market compared to 1% of corporate data centers.
KVM, QEMU, and kernel project management Posted Mar 24, 2010 0:09 UTC (Wed) by dowdle (subscriber, #659) [Link]
The server virt market will be saturated in a couple of years if not sooner.
Are there more desktops in the world or servers?
If desktop virtualization were built in and the way you ran any OS, which is what client hypervisors are about, it will be a much bigger market.
I'm not saying server virtualization is going away or anything... just that it is going to get much bigger on the desktop.
KVM, QEMU, and kernel project management Posted Mar 24, 2010 0:11 UTC (Wed) by drag (subscriber, #31333) [Link] Wow. Sorry, wrong. The money in virtualization is in the data center, not on the desktop, we are talking several orders of magnitude difference.So? The money is in the datacenter because they are willing to spend obscene amounts of cash no matter what. The users, almost every single one of them, use the desktop. If you follow the users they will lead you to the desktop, follow the money will lead you to the datacenter.
KVM, QEMU, and kernel project management Posted Mar 24, 2010 9:54 UTC (Wed) by till (subscriber, #50712) [Link]
Desktop virtualization is also helpful to test new distribution releases in the FOSS community and therefore imho matters.
KVM, QEMU, and kernel project management Posted Mar 24, 2010 0:19 UTC (Wed) by bronson (subscriber, #4806) [Link]
Great comment Drag.
The reason why Virtualbox and all these other guys (including OpenVZ and Linux-Vserver) are not on every desktop yet is because they all require reading reams of documentation to do even the simplest things.
Why can't a guest be a single file? HW configuration, disk images, etc, all in one large file. Why can't that file be stored anywhere on my filesystem and be opened the way I open all other files?
...$ qemu ~/vms/ie6.kvm
Or even -- gasp -- double click on it.
If I want to clone the guest? cp -r. When the clone boots, the VM notices if it's using a duplicate mac and tells how I can correct it. Why on earth should I have to dig around for virt-clone or equivalent?
If I want to migrate a guest from one machine to another? Shut down the guest, scp guest.img example.com:, fire up the guest on the new computer. There's no need for network daemons or NFS.
Delete a guest? Just rm it! If it's running then its blocks won't be recovered until the file is closed, just like every other file on your filesystem.
Dammit, if I want to run an old copy of Armor Alley, why can't I just scp a single file from a friend and double click on it? Why do I have to click my way through endless guis and google for obscure tools to do any of this?
It's crazy.
Dear qemu/virtualbox/vmware/etc developers, FIRST make the simple stuff simple, THEN add wacky things like COW and live migration, OK? Your tools all feel like they were designed by overcaffeinated VMS dweebs looking for more job security.
Why must libvirt be such a thick shim with such horrible leaky abstractions? Why must it be so difficult to convert a VM from one system to another? Gimp, Photoshop and Inkscape can all share files, why can't KVM, Xen, and Virtualbox? (crazy external conversion procedures don't count of course) And why am I the only person who seems to care?
Today, virtualization on Linux is an absolute mess. If anyone has any explanations for why, I'd love to hear it. (this article hints at one reason of course, but I'm sure there's more to it than what repo stores the userspace code!)
KVM, QEMU, and kernel project management Posted Mar 24, 2010 2:10 UTC (Wed) by HelloWorld (guest, #56129) [Link]
You're talking out of your ass. Setting up a VM in VirtualBox is pathetically easy, as is exporting it to a single file (go to the file menu, click on "export appliance"), as is opening it ("VirtualBox --startvm foobar" or just use the GUI).
And the reason that VMs are not stored as single files is that that would be a really dumb idea. VirtualBox uses different files for CD images, hard disk images, configuration files and log files, so i can process the configuration file with xmlstarlet, the log files with grep and so on. Grouping files together is what directories are for; stuffing unrelated things in a single file only makes things more complicated than they need to be.
KVM, QEMU, and kernel project management Posted Mar 24, 2010 3:04 UTC (Wed) by bronson (subscriber, #4806) [Link]
If by "setting up" you mean installing from installation ISOs, then setting up VMs is pathetically easy in all Linux VM systems. You'll notice I didn't complain about this.
I didn't know about export appliance. Glad to hear it, that's a step in the right direction. Not sure why "export" is needed at all though. My whole point is that VMs are usually just a bunch of files, so why can't I manipulate them like files? And, can any other system import VirtualBox appliances?
You mention "VirtualBox --startv foobar"... That's exactly what I'm talking about.
Why --startvm? Why not "VirtualBox foobar"? I'm happy if that brings up the console, then I can hit "Start"?
Also, foobar isn't a file and can't be treated like a file. No command-line completion, no scp, etc.
As for the value of keeping the config file and disk images separate... Sure, that's very true, in the data center. How often do desktop users want to process config files with xmlstarlet? Right, never. They're all going to use the GUI anyway, so why not make that simple?
If you're still not convinced, here are the downsides: get the files mixed up or out of sync and the errors are impenetrable. Lose a file and your VM is unusable. And there's no single thing to execute or double-click.
If the VM consists of a single file, it can be copied, checksummed, backed up, launched, downloaded from a web page, etc at will. See the Armor Alley reference above.
I never suggested putting the log files in the VM image. Yes, that would be daft.
Does this make more sense?
KVM, QEMU, and kernel project management Posted Mar 24, 2010 4:06 UTC (Wed) by HelloWorld (guest, #56129) [Link]
No, it still doesn't make any sense. On the one hand, you argue that a desktop user doesn't want to manipulate the configuration file with xmlstarlet. On the other hand, you want to use command-line completion and scp in order to mess around with your VMs. Then you complain that "there's no single thing to execute or double-click", but there is. Launch the Virtualbox GUI and you get a list of your VMs. Double click on the one you want to launch and you're done. It doesn't get easier than that. And given that Virtualbox handles all those files automatically and transparently, how would they ever get lost or out of sync? You're just making up problems that don't exist. All your other points are made moot by the "export appliance" feature, you can easily checksum, download or backup those. And of course an exported VM can be imported on another machine, that's the point.
Using the same file for different things is just a bad idea, since it just makes the file format more complex without a real benefit. Keeping different things separate is the POINT of a file system, and it would be stupid not to use it. And a hard disk image and a configuration file _are_ very different things.
KVM, QEMU, and kernel project management Posted Mar 24, 2010 7:35 UTC (Wed) by Los__D (guest, #15263) [Link]
Are you really that daft, or do you just pretend to be?
scp was an example, as in [insert favorite way to copy files between hosts]. Using it to pretend that bronson was contradicting himself is just lame.
KVM, QEMU, and kernel project management Posted Mar 24, 2010 19:26 UTC (Wed) by bronson (subscriber, #4806) [Link]
I suspect you're intentionally missing the point and just want to argue (hm, that would seem obvious given your very first senctence in this discussion). Still, in the off chance that you're serious, some quick points:
Double-clicking on a file in Dolphin/Thunar/Nautilus == desktop win.
"All your other points are made moot by the export appliance feature."
"And of course an exported VM can be imported on another machine."
"Using the same file for different things is just a bad idea."
KVM, QEMU, and kernel project management Posted Mar 24, 2010 19:53 UTC (Wed) by michaeljt (subscriber, #39183) [Link]
>"And of course an exported VM can be imported on another machine."
>By "system" I meant VMWare, Xen, Virt-Manager, etc. Can any other virtualization system >import a VirtualBox appliance? VirtualBox exports in the Open Virtualisation Format [1], which is more or less an industry standard format, and again more or less driven by VMWare. Moving OVF appliances between different virtualisation systems is still a bit shaky but should soon be pretty simple.
KVM, QEMU, and kernel project management Posted Mar 24, 2010 21:02 UTC (Wed) by bronson (subscriber, #4806) [Link]
That is great news! It sounds like an OVF package can be stored as a single unit or a directory of files. That should make everybody happy. :)
The single unit is just a tarfile so performance would be an issue if one were to execute it directly. Still, I agree, as things mature this could become really useful.
KVM, QEMU, and kernel project management Posted Mar 24, 2010 23:00 UTC (Wed) by HelloWorld (guest, #56129) [Link]
If you actually think that double clicking in a custom GUI is painful, you probably shouldn't be using a computer at all.
Your analogy to OpenOffice or vim is completely brain dead. If you want to send an OpenOffice document via email, you *do* have to export it. Yeah right, it's called File -> Save as..., i guess that's what makes it so much easier to use, right? Oh, and speaking of emails: email programs do just the same, they keep a database of your emails so you can read and answer them easily. Do you want to mess around with emails as files? I don't. My emails are buried somewhere deep within ~/.kde, and i don't give a rat's ass about the files they're stored in as long as it works. I guess most desktop users feel the same.
Furthermore, sending VMs via email etc. is just not a common use case. The common use case is that somebody sets up a machine once, say, to use some legacy windows app, and keeps using that as long as he needs it. Also, all the files are there in ~/.VirtualBox, nothing stops you from backing up that directory. It's not rocket science you know. But it seems you just want to whine about how bad the world is anyway, so i don't see a reason to waste further time with you...
KVM, QEMU, and kernel project management Posted Mar 25, 2010 12:28 UTC (Thu) by bronson (subscriber, #4806) [Link]
As with the ssh example, you ignore the point in order to get in a lame insult. Do you feel better now? The point was that custom GUIs tend to be painful, especially when there's a perfectly good alternative.
Save As is not the same thing as Export.
Your email example is actually a good argument wrapped in boring vitriol. The difference is that email involves tens of thousands of messages, whereas desktop users only have a few VMs.
Sending MP3s via email was not a common use case 10 years ago, sending 50 MB PPTs and PDFs via email wasn't common 5 years ago... Limiting design to only serve the common use case would make the future a pretty boring place!
KVM, QEMU, and kernel project management Posted Mar 24, 2010 9:50 UTC (Wed) by till (subscriber, #50712) [Link]
Still with VirtualBox, afaik one has to setup a lot, e.g. adding an ISO to an iso storage and configuring the VM. With KVM one can just create a nice shell alias and boot e.g. Fedora Test release live images with one command:
alias kvm_iso="qemu-kvm -boot d -k de -m 1024 -usbdevice tablet -cdrom"
And when I kill the VM, nothing is left behind (log files, stale configs, ..).
KVM, QEMU, and kernel project management Posted Mar 24, 2010 13:42 UTC (Wed) by HelloWorld (guest, #56129) [Link]
You can completely automate this with the VBoxManage command line tool. It is slightly harder to do, but it can be done.
KVM, QEMU, and kernel project management Posted Mar 24, 2010 14:32 UTC (Wed) by wookey (subscriber, #5501) [Link] Dammit, if I want to run an old copy of Armor Alley, why can't I just scp a single file from a friend and double click on it? To be fair that's exactly how it works these days in wine. Perhaps you don't count wine as 'virtualisation', but from a user's POV it does the same thing: 'runs my Windows programs'. And these days it does it pretty well. I've been doing a lot of building design recently and the world is _full_ of stupid little programs for Windows to spec beams and tanks and do heat analysis and the only easy-to-drive* no-cost 3D drawing package (Sketchup) has no Linux version. Everything I have tried so far works in wine, somewhat to my amazement (sketchup is cranky due to opengl/video hardware options, but it does work). This virtualisation stuff doesn't help me at all because it needs a copy of the host OS and I simply don't have any of those. * And yes I did try Blender first but after about 6 hours I had drawn 3 slightly wonky walls of the garage. In the same time in Sketchup I'd done pretty-much the whole design (house+extension). I love my free software as much as the next man but a) Blender not really technical drawing software - that's not it's heritage and b) Sketchup's interface is _really_ nice, at least for initial more-or-less right models -I'm not sure it's great detailed tech-drawing software either. Bit off-topic there, but I just wanted to point out that download+double-click does in fact now work for lots of Windows software thanks to the marvelous work of wine. I agree that having this work one way or another is an important part of weaning people off Windows. A lot of people have one or two things like this that keep them tied to Windows. And we need critical desktop mass to get drainpipe manufacturers to stop writing Windows-only apps.
KVM, QEMU, and kernel project management Posted Mar 24, 2010 3:27 UTC (Wed) by amit (guest, #1274) [Link]
You're confusing two things.
Desktop virtualization, as in desktops that are served from data centres is what Avi is referring to. He thinks that is an important market.
Desktop virtualization, as in running VMs on desktops, is a niche market, and not where the money is. Ingo refers to this market, where the developers are, and where perf improvements will make sense.
KVM, QEMU, and kernel project management Posted Mar 24, 2010 6:36 UTC (Wed) by smurf (subscriber, #17840) [Link] Desktop virtualization, as in running VMs on desktops, is a niche market, and not where the money is. Ingo refers to this market, where the developers are, and where perf improvements will make sense.There's the "where the money is" development model, sure. There's also the "this is fun to hack on and I've got an itch to scratch" development model, though. Given the history of Linux, the latter model proves itself to be pretty much crucial in getting tools to the stage where they're, well, ready for World Domination.
KVM, QEMU, and kernel project management Posted Mar 24, 2010 8:01 UTC (Wed) by amit (guest, #1274) [Link]
Avi has mentioned that he would accept patches which scratch itches, just that they should be acceptable to him as a maintainer. He won't reject patches just because they're not in the area he's interested in.
Also, lots of people these days are funded to work on Linux, there aren't many scratch-your-itch types who submit big patches (either for the complexity or the time).
KVM, QEMU, and kernel project management Posted Mar 24, 2010 4:15 UTC (Wed) by HelloWorld (guest, #56129) [Link]
You too are talking out of your ass. VirtualBox is _trivial_ to install. The developers offer binary packages for most distros (Ubuntu, OpenSuse, Debian, Fedora, Mandriva and a few others). All in all, VirtualBox is so much easier to use than KVM it's not even funny. And the funny thing is that even though KVM apparently has so many developers, VirtualBox still beats the pants out of KVM in most respects from my perspective.
KVM, QEMU, and kernel project management Posted Mar 24, 2010 10:01 UTC (Wed) by till (subscriber, #50712) [Link]
But afaik VirtualBox is not a good FOSS citizen imho, because e.g. their X client drivers are not integrated into Xorg upstream, but need to installed manually using a client extensions iso image, while everything needed to get the pointer not captured in a KVM guest windows is already included in Xorg. Likewise there kernel module is not heading into integration into the linux kernel and the OSE edition has still less features than the commercial one (no USB support, no RDP or VNC), which KVM both provides. I did not use the USB support recently, though.
KVM, QEMU, and kernel project management Posted Mar 24, 2010 10:43 UTC (Wed) by nix (subscriber, #2304) [Link]
The USB support is still sort of crappy, or was at the end of last year anyway. I tried to use it to populate my mother's new iPod (which of course meant running Windows and iPlayer under KVM, because Rockbox doesn't work with new iPods). After fixing two buffer overruns from insufficiently small USB buffers, it... hung indefinitely, and qemu sprayed error messages out at me. (I never got around to reporting it as a bug on account of the unexpected arrival of Christmas: I'll try again one of these days and characterize it more precisely.)
KVM, QEMU, and kernel project management Posted Apr 3, 2010 10:31 UTC (Sat) by dag- (subscriber, #30207) [Link]
My experience using multiple USB Bluetooth devices within a VirtualBox guest was rather pleasant. Once the correct access rights were granted from the host, it worked as expected and was very reliable.
KVM, QEMU, and kernel project management Posted Mar 25, 2010 12:46 UTC (Thu) by BenHutchings (subscriber, #37955) [Link] Likewise there kernel module is not heading into integration into the linux kernel... Indeed, it's bad enough that Greg didn't want it in staging.
KVM, QEMU, and kernel project management Posted Mar 24, 2010 5:37 UTC (Wed) by eru (subscriber, #2753) [Link] I mean, seriously, look at all the years of f-king work that went into things like Wine. Years and years and years of effort to create a open source win32 implementation that can run on Linux. Apples and oranges: with virtualization you need the Windows license and media. I don't have either (except for some ancient version), and don't want to buy them for my home box. Besides it would not even run KVM (slightly too old processor). These days Wine works very well for the few Windows progs I occasionally need. Wine also allows them to run as normal windows within the Linux desktop, not inside a separate top-level window, like virtualization programs do, and access to native Linux files is painless.
KVM, QEMU, and kernel project management Posted Mar 24, 2010 22:00 UTC (Wed) by sorpigal (subscriber, #36106) [Link]
I am thinking that, eventually, we will have VMs running in windows, too, just like Wine does now. Think "super crazy .app bundle" where you double click the image file, it launches the guest OS, boots, launches a single application, and then makes that app fullscreen and looking like a normal window.
Some trickery would be needed for device access, saving and sharing files, etc., but these are solvable problems. The end result would be desktop app isolation, extreme app portability (I can emulate any platform anywhere, in theory) and if you made the iconify button suspend the guest to disk in whatever state it's in at the moment you could carry your work--exactly as you left it--anywhere with little more than a flash drive.
Once this is happening who cares what data centers are using virtualization for!
KVM, QEMU, and kernel project management Posted Mar 24, 2010 22:43 UTC (Wed) by neilbrown (subscriber, #359) [Link]
... and this would nicely solve the issues brought up in the recent lwn feature "Applications and bundled libraries". Just distribute firefox or chrome or OO.o or whatever as a virtual machine, all dependencies included.
KVM, QEMU, and kernel project management Posted Mar 25, 2010 5:45 UTC (Thu) by eru (subscriber, #2753) [Link] Absurd overkill!If you want to eliminate dependency problems, just bundle the libraries and arrange load paths appropriately. No need to bundle the whole OS as well! I believe PC-BSD and some minor Linux distro I forget already handles packages this way. It seems to me the current virtualization fad is rather sad. It really is motivated by hardware being better at keeping stable interfaces than software, but results in lots of wasted resources and energy.
KVM, QEMU, and kernel project management Posted Mar 26, 2010 15:54 UTC (Fri) by cdmiller (subscriber, #2813) [Link]
As a sysadmin who switched from VMWare to KVM some time ago, my perception is virtualization *is* happening in the datacenter first ($ driven) and on the desktop second. KVM desktop virtualization is not suffering too badly. The libvirt based virt-manager tool has been improving over time and brings a pretty good ease of use to setting up a VM on the Linux desktop. Stuff like VMGL and wined3d enabled VM's at the click of a button would be a killer desktop app, but for us datacenter folks a stable server environment that brings the $ to me, Linux vendors, and their KVM developers is extremely important. Are these two goals really mutually exclusive? Hopefully not. A shakeup in the development model which intrudes on stability and progress of server side KVM/Qemu could actually threaten Linux desktop viability.
|
|||||||||||||