I'd love to have the ability to install two different OS's to the bare metal of my PC rather then have a host/guest relationship (vmware workstation/virtualpc) or obviously have to have a seperate server to remote into (esxi/hyper-v). Is there anything like that out there? I saw some references to Vmware VDI but can't find any hard evidence that that's what it does (I guess it's Vmware View now?). Think "alt-tabbing" between operating systems like you do programs, but with as much hardware virtualization (not so much emulation) as possible.
![[H]ard|Forum](/styles/hardforum/xenforo/logo_dark.png){kind=logo}
-
Some users have recently had their accounts hijacked. It seems that the now defunct EVGA forums might have compromised your password there and seems many are using the same PW here. We would suggest you UPDATE YOUR PASSWORD and TURN ON 2FA for your account here to further secure it. None of the compromised accounts had 2FA turned on.
Once you have enabled 2FA, your account will be updated soon to show a badge, letting other members know that you use 2FA to protect your account. This should be beneficial for everyone that uses FSFT.
Do bare-metal client hypervisors exist?
- Thread starter oldpablo
- Start date
In short, no.
You'd need support for this in every single hardware component - Motherboard, CPU, Network card, Video Card, Sound Card, anything - and even with that kind of support it'd be incredibly difficult and expensive. The host/client model is here to stay.
You'd need support for this in every single hardware component - Motherboard, CPU, Network card, Video Card, Sound Card, anything - and even with that kind of support it'd be incredibly difficult and expensive. The host/client model is here to stay.
It's coming. Referred to as a Type 1 hypervisor. You'll boot that on bare metal and then virtualize your OS. VMware ESX is close, but not built in to the hardware yet. But..it's coming.
The only systems which are bare-metal Hypervisors are IBM POWER series (including pSeries and System P) and HP sx2000 Cell based systems (rx7640 and up.) These also are arguably not Hypervisors, in that they typically allocate real hardware resources. Only IBM can fully virtualize hardware on POWER5 and POWER6 systems using VIO Servers.
Note; Unisys Cell based systems using Itanium or Xeon have electrical partitioning and virtualization that is directly comparable to HP.
The PC architecture is incapable of supporting this style of Hypervisor, because it requires a level of signalling granularity that the PC BIOS cannot support. Even VIO Servers have specific hardware allocated to them on a per-slot or per-port basis. Because of the way x86 is designed, it basically requires a total redesign of the BIOS at an architectural level. Nobody is currently actively engaged in this, just things that can only accurately be described as half-assed hardware-level (like HyperV and such.)
In short, what you're looking for will not be happening on x86 any time in the next 4 years, unless IBM decides to make it happen on BladeCenter with the next follow on to the X4 Hurricane chipset.
Note; Unisys Cell based systems using Itanium or Xeon have electrical partitioning and virtualization that is directly comparable to HP.
The PC architecture is incapable of supporting this style of Hypervisor, because it requires a level of signalling granularity that the PC BIOS cannot support. Even VIO Servers have specific hardware allocated to them on a per-slot or per-port basis. Because of the way x86 is designed, it basically requires a total redesign of the BIOS at an architectural level. Nobody is currently actively engaged in this, just things that can only accurately be described as half-assed hardware-level (like HyperV and such.)
In short, what you're looking for will not be happening on x86 any time in the next 4 years, unless IBM decides to make it happen on BladeCenter with the next follow on to the X4 Hurricane chipset.
Citrix is coming out with this I watched a video about a week ago I'll see if I can find it.
here it is http://www.citrix.com/English/ps2/products/feature.asp?contentID=1685500
here it is http://www.citrix.com/English/ps2/products/feature.asp?contentID=1685500
See the Citrix post above this. The idea is to standardize the PC so that this can exist...and it will be here within 4 years.
This is not a standardization issue. This is a fundamental design issue, that the x86 architecture is incapable of without tremendous rework. The closest you can get currently is fault-tolerant HT linking of subboards on Opterons (2x 4 socket to combined 8, with capability to run at 4 in a link failure.) Any hardware fault will still result in a reboot or NMI, period.
x86 is not designed for electrical isolation, path segmentation, etcetera. You can standardize yourself into a nice smoking hole in the ground, and it won't solve a single one of the real problems. The hardware is flat out not capable of having anything resembling a bare metal supervisor. Not until you completely rid yourself of the BIOS and replace it WITH a Hypervisor is it possible.
Yep.
Could you clarify: is this a problem with x86, or the BIOS? x86 is just an ISA.
No, x86 is not "just an ISA." x86 is a collection and amalgam of numerous protocols, parts, and such. If I was talking CISC, I'd say ia86. x86 is totally dependent on several key, critical components; CPU, I/O Controller, BIOS. All of this goes to the BIOS, which ia86 is entirely dependent on, with or without IMCs. At the same time, BIOS is severely limited in what it can actually do.
Most self-professed "computer experts" and "system builders" - the Internet smart folks, insert eye-rolling - would be absolutely floored by the path a key press must take to reach the CPU. And frankly, almost all of them would scream how that's not how it works because it's USB not "that old crap" - and be completely and utterly wrong.
BIOS is called that for a reason; Basic Input/Output System. It's a very smart GPIO, in essence, because CISC CPUs do not typically have GPIO pins. Every single action on your computer interacts with the BIOS in some way, from disk writes to mouse clicks - that's an inescapable fact of x86. Sure, folks will scream, wail and cry that various "authoritative" sources say things don't go through the BIOS. But of course, they are completely wrong. EVERYTHING ties back to the BIOS, because it has to. It is the fundamental block upon which everything in a PC is built.
Of course, this results in it cutting both ways. Because it is the most fundamental building block, it's a brick and nothing more. It's not the electrical box, the security, etcetera. It's a brick. Inert, fired clay. It's very, very stupid, because it cannot be smart. Smart is reserved for the CPU, the sub-IO controllers (northbridge, southbridge, SuperIO, etc.) and peripherals. The BIOS only tells them where to talk to each other, it does not tell them how or when or why - which are Hypervisor functions. If it did, it would need to be thousands of times more complex - it would need to evolve into a fully fledged operating system in it's own right. It would also need it's own processor, it's own memory, and so on. To do that, you no longer can physically fit this on ATX or even EATX, and need a very expensive subboard. And hideous R&D and development costs to build the operating system. Congratulations, you've just added somewhere upward of $1,000 to the cost of a single socket motherboard. (And now it makes sense!)
Which brings me around to why I specifically said IBM and BladeCenter. The BladeCenter architecture makes it possible, in theory, for a blade to rely on the BladeCenter itself for the BIOS. In this instance, and only this instance, you have a fully disconnected platform capable of providing the necessary resources. These resources being separate CPU, memory, and I/O management. To a limited extent, the BladeCenter's I/O system already performs some of these functions - but only within the limitations of electrical pathing. You cannot map a mezzanine card to just any I/O bay, you must have an electrical path, and not all I/O bays have all I/O paths. (This isn't untrue of other systems, simply that other systems have all I/O paths and rely on firmware/Hypervisor control.)
Now, do I think IBM is doing such a thing? Honestly, I don't know. I don't believe so, because of the JS-series blades; they have an internal service processor. They would be the prime target for this particular activity, and IBM has given no indication that they are even researching this actively, to my knowledge.
I don't know if this directed at me, but I'm quite aware of the internals of computer architecture. I've worked for some time at a semiconductor company that develops and fabricates x86 cpus and chipsets.
x86 is an ISA. It's commonly associated with the BIOS or alternatively EFI, but this isn't a requirement. I can drop an x86 cpu on a breadboard, hook it up to some sram, set the program counter, and have it execute a program. I'm unable to even get google to convince that the term refers to anything but an ISA.
Also by "ia86" I assume you meant ia32.
In any case, this is purely semantics. The problem seems to lie in the IO system commonly associated with x86 cpus. Thanks for your insight.
Nah, not directed at anyone here in specific. Pardon my acronym fudging, I'm used to a different set from others. (Too much time with salesdroids.) And yeah, you could drop virtually any CPU onto a breadboard and do that. The problem is that all that gets you, is a fixed program. All of the current chipset designs are still dependent on the old 16-bit keyboard controller routines in the BIOS. Even X58 boards without PS/2? Sneaks into the BIOS as obfuscating USB.
In theory, going from the breadboard method, if you can provide the memory controller, I/O, and so on then no, you don't need the BIOS. But that's also going to chew up >25% of your CPU best case, making it far too expensive in resource cost before the R&D costs. (Remember, existing chipsets will enforce the dependency, so you need a new one from scratch. Hence why IBM, who already does chipset design.)
Precisely. Thinking on it, HyperTransport is almost ready-made for it - a semi-arbitrary point-to-point routed protocol is pretty much exactly what you want. It just comes down to the attached chipsets and controllers. Makes me wish I could find an angel investor now. Heh.
