Hypervisors: grinding through to bare metal We are generally pretty familiar by now with the concept of virtualisation on the desktop, where a virtualisation application allows a secondary guest operating system (OS) to run within the host OS. Software and hardware have improved dramatically, to the extent that Microsoft even includes a complete virtual installation of …
"snapshots can be easily taken and whole images or just recent changes uploaded to the network."
Well I suppose it depends whether "bare metal" means "just the BIOS". "Just the BIOS" can't take snapshots or do restores, which of course is why "bare metal" usually doesn't have the same meaning here as it does elsewhere. Here, maybe it means a minimal Linux. But hey, IT trendsetters (ie marketing people) have never misled us before, surely they wouldn't do it now, would they?
"Should the PC be left behind, users may be able to log onto a different PC and have the image of their OS loaded onto a server and run via a thin client application - giving them their own personal PC served over the Internet."
If I want thin client computing (and trust me, I do understand the reasons why some people might), wtf do I need a virtualisation-ready desktop system with a bare metal hypervisor? What does that give me that Citrix or LTSP or whatever doesn't already give me (other than a big bill from VMware, of course)?
"If I want thin client computing (and trust me, I do understand the reasons why some people might), wtf do I need a virtualisation-ready desktop system with a bare metal hypervisor? What does that give me that Citrix or LTSP or whatever doesn't already give me (other than a big bill from VMware, of course)?"
Quite a lot.
Not all applications play nice. Plenty of IT Departments waste hours trying to trick badly designed software to work properly in a multi user environment such as LTSP or Citrix XenApp. Solutions like XenDesktop or streamed applications are one solution, but they are complex beasts to setup and maintain, are bandwidth intensive and costly in terms of licensing and the network infrastructure required to support them. They also don't lend themselves to distributed environments.
An interesting read.
Gordon,
In relation to your comment, bare metal means there is software which runs and interacts directly with the CPU architecture, to interact however you require a virtual machine management console which is accessible using the Host OS. The actual virtual hard disks are simply files accessible on the physical hard drive. So yes, it will require an OS before interacting with the virtual machines and carrying out snapshots/restores on the console. The point given is simply that the virtual machine can interact directly with the hardware through a hypervisor and not via another third party host OS.
Again, with a Citrix terminal session, you are being streamed a session and not actaully utilizing any hardware accelleration. With a virtual machine, it will allow the session to use hardware accelleration on the thin client, without having a physical disk. This would require a compressed version of the virtual OS otherwise you're looking at 1gb of memory in thin clients instead of 64/128Mb.
So, it would provide a better experience for the thin client user but potentially more expensive thin clients and technology.
"an engineer for example may have a main Windows PC but have some custom applications that run on Linux"
Far more likely to run Linux as the host OS and have the odd Windows-specific application in a VM. Also the use of VM technology along with capricious HDD allows you to have a number of simple Windows VMs, each with a minor selection of applications (and no AV in most cases to screw things up!) and less problems of conflicts.
With a strict technical point of view, all those benefits do not come from hypervisor being type-1 or type-2, this is completely uncorrelated.
A host OS running (only?) a type-2 hypervisor is enough to enable all the benefits depicted.
Running a type-1 hypervisor is mostly a matter of increasing performances of virtual machines. Don't be fooled, the performance i am talking about is only relevant for servers (latency, throughput), not for everyone's personal computer (which is anyway already slowed down by all the bloated software pre-installed).
While most of the concepts in the this are OK, there some major flaws:
- "We're all familar with virtualization", then the author spends several paragraphs describing it (in the most high-level, basic way) that anyone who is familar would already know.
- No OS (as other people pointed out) means no OS. The VM platform is an OS, but I supposed for a non-IT person it doesn't do GUI so it's not.
- Save copies to the network, download to laptop, etc: if this worked, it would be fantastic. Have my work 'PC' on a server, remotely accessible, etc, etc, but be able to 'check it out' to a laptop if I need to be away from a network. The problem is it generally takes hours to make these backup copies and transfers, even with 1gigE. Do you think someone is going to wait at *least* 30 minutes to transfer a VM before leaving the office?
- Performance of the VM is always less than the OS installed on bare metal. Especially with desktop-type VMs, the hypervisor has to abstract the hardware which slows everything down.
Last I checked, a Type-1 hypervisor ("bare metal") does not have the capability to display the screen of ANY of the VMs running on the system. Therefore, you would be REQUIRED to run a Type-2 hypervisor to be able to have your OS install moved around with you regardless of your machine. Granted, you save time by only requiring the install of the hypervisor, but then you're stuck with 2 full OSes to manage. That's the problem with XP Mode in Windows 7. All the insecurities of XP (albeit, can be severely hobbled to run only the app(s) in question), plus the Win7 host environment to deal with.
Anyone have a lead on a Type-1 hypervisor that actually allows you to view the screens of the hosted VMs and switch between them? With the Type-2 situation, the "host" OS either does nothing and consumes resources, or (more likely) is used as a production OS which needs patches/updates/reboots. Obviously, reboots means having to (at the very least) suspend the hosted VMs and resume them once the reboot is complete. If one of those VMs happens to be a network service (database perhaps?) then the host tends not to be patched or otherwise configured-needing-a-reboot for large spans of time. Always tricky if the host needs to have a program installed that insists on a reboot to "complete."
It's part of the design, and it requires some external hardware (so this may be enough for you to argue), but the PowerVM hypervisor on IBM Power systems is architected so it is possible (using the HMC or IVM partition) allows the console screen of all LPARS to be opened from the console.
The same was true for the daddy of all type 1 hypervisors, IBM VM, which also allows a single master terminal to display the consoles of each of the partitions (IIRC, been some years since I worked with it, and most customers used to want physical consoles anyway).
Yes, I know they are text only, but when you have OSs which do not rely on a GUI to run them, why do you need anything other than a text mode console? You have X11 and if you must, virtual consoles using VNC for that.
Where you are getting confused is believing that VMware and Citrix invented the type 1 hypervisor. They did not.
Of course, anyone in the know realises that there is really no such thing as a "Bare Metal" hypervisor, because, as has already been pointed out, VM is an operating system (used to be actually booted from disk!) and PowerVM is actually a locked down (an not even particularly cut down) Linux kernel in flash storage. But hey! It's convenient for the vendors to sell the hypervisor as a firmware "Black Box", that the customer needs to know nothing about, particularly when the security people come snooping.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
