Slashdot Mirror
Dell Considers Bundling Virtualization on Mobos
castrox writes "Ars Technica is reporting that Dell may be considering bundling virtualization on some of their motherboards. No more dual boot or VMs inside the running OS? 'Any way you slice it, though, putting the hypervisor in a chunk of flash and letting it handle loading the OS is the way forward, especially for servers and probably even for enterprise desktops. Boot times, power consumption, security, and flexibility are all reasons to do this ... The big question is: which hypervisor will Dell bundle with its machines? Vance suggests hypervisors from XenSource and VMware as two options, but I think that VMware is the most likely candidate since it seems to be the x86 virtualization solution of choice for the moment. However, if Dell doesn't try too hard to lock it down, this system could easily be modified in an aftermarket fashion to include almost any hypervisor that could fit on the flash chip.'"
Dell's gonna have a hell of a time supporting these complex features while it's closing down its call centers.
--
make install -not war
Dell considers bundling virtualization on mofos
or
Dell considers bundling virtualization on hobos
not pretty either way.
"However, if Dell doesn't try too hard to lock it down, this system could easily be modified in an aftermarket fashion to include almost any hypervisor that could fit on the flash chip.'"
Why wait for Dell to do this?
you know, once you try to enable the hypervisor, connect to an online payment system and charge $X per month to enable the feature, lock the 2nd O/S once the subscription expires. Encase the chips in epoxy. I'm surpised Microsoft hasn't tried something like this yet. Extra points if Dell designs it too run too hot and blowup.
In what way is this functionally different than the same hypervisor being installed on a bootable USB flash drive/IDE-attached CompactFlash card/[insert other stupid-simple method of booting from flash]?
Kid-proof tablet..
How is adding more layers going to make anything faster?
It isn't like Vista will be loading less drivers because of the extra layer.
"In what way is this functionally different than the same hypervisor being installed on a bootable USB flash drive/IDE-attached CompactFlash card"
Its more secure having the actually memory embedded inside the machine instead on the outside in a port, accessible for anyone that have physicall access to your office.
http://www.intellipool.se/ - Intellipool Network Monitor
It's vendor-supported.
can be there within four hours and should actually be carrying a spare.
For a hobbyist at home I doubt there's much of a difference at all, but for folk paying big $$$ for enterprise solutions, this is probably very welcome.
is but one area of my experise -John Hodgman
IBM is already doing this on their iSeries (AS/400). In order to manage it you have to have a Hardware Management Console (an x86 xSeries machine running Linux and their management software). I really think that they have done a good job of the virtualization, it also lets IBM throttle back the CPU. We have a 1000CPW (IBM's performance index) machine that with the Power5 1.5Ghz processor is limited to 43% utilization. In order to get all 100% of the CPU (2400CPW), we would have to pay through the nose.
Well, as I said in this post, not much. The only things I can think of are that it doesn't rely on any external devices and would be directly supported by Dell. It would be a real boon to corporate IT departments using virtualization to consolidate servers, since IT managers are often loathsome to use any such configuration that isn't officially vendor-supported.
My blog
I'm guessing that you might get a slight advantage not having to wait for the bios to reach a point where it has usb functioning - and possibly the ability to read the chip faster off the board than over usb. Just wags on my part. I personally don't get the big deal over doing it this way as compared to the way a hypervisor loads now to run on bare metal. It might take a touch longer to boot - but so what? I'm not bouncing my servers that often anyway. And on the desktop? That's where I really struggle to see the need.
It's hard to believe that's how Micronians are made. Why don't we see it right now by having you both kiss one another?
Pretty soon the old obligatory comment "Yeah, but does it run Linux?" will be updated to read "Yeah, but does it run Linux (in at least one VM)?"
There seem to be a lot more options for "virtualization" lately than VMWare, but never having needed to use multiple OS's at one time, I'm clueless as to the details of how these all work. Are they taking advantage of some new functionality on Intel/AMD chips?
Is there some sort of overview for this stuff?
If moderation could change anything, it would be illegal.
Amusingly, this + a mechanism for telling the hypervisor what programs to trust and how, was the original end goal of the whole TPM/palladium movement..
I personally love how the poster of the article invents a hypothetical security problem with a hypothetical and non existent hardware solution, at which point he/she discusses the details of a potential hypothetical hack.
As others mentioned, similar things can be done now -- an IDE/Flash boot into a minimal hypervisor Linux for Xen or KVM. That would also allow some flexibility, to maybe run a few things directly on the hardware. I would be very interested in an approach like this for my home Linux server.
For larger enterprise uses, the really simple hypervisor is nice. Just slap another box in there, and it is quickly added to your compute cluster. If they do it right, that system could even net-boot and auto-install the latest hypervisor image when it's first added. Factor in VMWare's "VMotion" stuff, where VMs can be moved among compute nodes in a cluster, and that simple compute node, along with a big NAS, is really slick.
Virtualisation I have no doubt is extremely useful in certain applications. I howerver have no use for it on any PC I own or work on. I exclusively use linux and I don't want Windows or OS/X or anything else running alongside it. I *WANT* my OS to have full control over the machine - its faster , its more flexible and theres less to go wrong (not to mention who's to say a hypervisor couldn't be hacked by a virus somehow?). I don't want some virtual hardware locked into the BIOS that may or may not have features enabled depending on what mood the hardware supplier was in one day.
Sure , if you want virtualisation have it as an add-on, but to have it added by default into the BIOS IMO is a slippery slope.
Erm... What?
I think PS3s already get shipping with a built-in hypervisor to manage installing guest OSs in VMs on the console. Ostensibly it's a feature, but doing so has given them enough control to prevent access to accelerated graphics so people don't use the console to play games they downloaded and are instead forced to buy. There's certainly precedent for this, and we're sure to see a lot more of this in the future. Hopefully the PC market is competitive enough that Dell won't be restricting their own hypervisor to restrict certain hardware access, or only allow the use of VMs from "trusted" sources. If this is true, then this is excellent news.
DRM (Score:3, Insightful)
by Frank T. Lofaro Jr. (142215) on Tuesday June 07, @05:12PM (#12751680)
(http://www.linux.com/)
They are doing this for DRM.
Their Hypervisor will enforce DRM, so even linux can't override it.
They'll make it so all device drivers must be signed to go into the
Hypervisor which will be the only thing with any I/O privs that aren't
virtualized.
They'll make it so new hardware has closed interfaces and can only be
supported by a driver at the Hypervisor level.
Any drivers in any OS level won't be able to circumvent the DRM, since
they'll just THINK they are talking to hardware, but will get virtual
hardware instead - and the Hypervisor won't let it read any protected
content through the virtual I/O, it will blank it out (e.g. all zero
bytes from the "soundcard") or something similar.
The drivers designed for the Hypervisor won't work in any higher level,
since they'll need to do a crypographic handshake with the hardware to
verify it is "real" and the hardware will also monitor bus activity so
it'll know if any extraneous activity is occur (as it would if it was
being virtualized).
Everything will have a standard interface to the O/S, so Linux will still
run but be very limited and slowed down - since only Windows will be
allowed "preferred" access to hardware, other O/S will be deliberately
crippled.
They'll say you can still run Linux.
Hardware manufacturers won't release specs, they'll say use the Hypervisor
and you can still use Linux.
You'll still need to buy Windows to use any hardware - Linux won't even
boot on the raw hardware.
MS doesn't care if Linux isn't killed - the above allows them lock in - no
windows - your PC won't boot - since nothing but the Hypervisor will know
how to talk to the IDE card, etc.
What about manufacturers that want to support open interfaces, etc?
Microsoft will deny them a key which they will need to talk to the
Hypervisor - and the Hypervisor will refuse to talk to them.
Support anything other than solely the Hypervisor and you can't use the
Hypervisor. No Windows - lose too many sales.
And they can say other O/S's are still allowed.
They'll just not be able to give you freedom to use your hardware as you
see fit (DRM, need to pay more to get software to unlock other features
on your hardware), only Windows will run well, and you need a Windows
license and Hypervisor for every PC or else it is unbootable.
This frightens me on so many levels that it is difficult to know where to start. Unless that hypervisor is burned into a non-rewritable form of storage (e.g. ROM), it will be subverted.
As it has been demonstrated at Black Hat by the illustrious Ms. Rutowska, (as well as being fairly obvious to anyone familiar with hypervisors) a hypervisor is below the OS and can be impervious to the OS's probing, but it still lies between the OS and the hardware.
Properly implemented, this could be a very good thing. With no disrespect intended toward Dell, I suspect that the first several implementations (at least) will leave the resulting systems vulnerable to subversion, and this subversion would be difficult, at best, to detect.
This is an interesting concept, and it could be used for "good", but as the saying goes "the devil is in the details". The idea is good, it is the potential implementation that worries me.
Full Disclosure: I have a Ph.D. (2006) in InfoSec.
I suppose a hpyervizor doesn't need or take control of hardware components the way an O/S would but even so, I'd be concerned that a virus if it could somehow get into the flash ROM (or be compulsorily included there by the US National Security Agency) might be undetectable to O/S based virus scanning as the Boot ROM doesn't appear as a mountable volume and is never checked....
I have been a user for about 10 years. This ends Feb 2014. The site's been ruined. I'm off. Dice, FU
> Its more secure having the actually memory embedded inside the machine instead on the outside
> in a port, accessible for anyone that have physicall access to your office.
So? CF to IDE bridge taped down in a drive bay. Flash to IDE header gadget plugged direct to an IDE header. They even have em that plug direct to USB headers on the MoBo now. Give em a while and they will have em to direct plug to SATA, assuming they don't now and I just didn't see em last time I was looking stuff like that.
Point being that is almost certainly all Dell will be doing. So why wait, if it is a good idea, just do it!
Democrat delenda est
Anything is vendor-supported if I pay for vendor support. It doesn't have to be embedded in a flash chip.
The advantage of this is that it is vendor-supported by a vendor of Dell's choice. Presumably they then give Dell a kick-back. OK, that's an advantage for Dell, not for the purchaser.
Presumably having Dell's hypervisor load instantly at power-up could prevent other virtualizers from running, including hypervisor-based rootkits like Blue Pill.
yes, but its a marketing feature, not something that is of any real importance
Compromise a guest and you haven't compromised the machine.
What outside the "guest" is of any use to a desktop user?
I'm with the OP, I don't want Windoze or OSX so I don't want a non free VM getting between me and my OS or my OS and hardware. I don't have boot or power management problems with my OS, so the VM offers me nothing.
Friends don't help friends install M$ junk.
1) Cost. They would have to design the mobos and test them.
2) The IDE header is not going to be used in profesional servers. For one, they don't have IDE anymore. They have SATA or SCSI.
3) The USB headers are not going to have as high of an uptime compared to something dell could build onto the motherboard (in theory, supposing dell does'nt screw up. This is required due to what most server buyers need is reliability for servers that run 24/7/365.25. Adding in what you suggested, the first thing to fail would most likely be either the flash or the adapter.
Fly me to the moon Let me sing among those stars Let me see what spring is like On jupiter and mars
For Vista, the only option OS wise will the the more expensive models. Both Vista Basic and Premium aren't allowed to run on any kind of VM. I guess that will limit Dell's usage for home users.
Presumably having Dell's hypervisor load instantly at power-up could prevent other virtualizers from running, including hypervisor-based rootkits like Blue Pill.
Not if it's really doing its job.
A virtual machine should be able to virtualize another layer of similar virtual machines - including instances of itself. Otherwise there's something defective about the virtualization.
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
It's easy to see how moving more stuff from the disk to flash is "slicker" and can make things load a little bit quicker (but seriously: how much? I doubt transferring hypervisors, kernels, or boot managers (e.g. grub) from disk is a major factor in boot times). But what's so special about hypervisors? Forget making this "solution" so specific. Just build a few dozen megabytes of disk-like (bootable) flash into the board, and let the user decide if they just want to use it for a hypervisor, or move a whole bunch more stuff into there in an effort to try to get their modern machine boot as fast as an Amiga.
The one thing that it occurs to me that such an answer would really help with, is working around a certain (dumb) Linux limitation. Booting off EVMS is tricky (or at least it was, last time I looked). Move your boot off-disk, then you can EVMS your whole disk.
And what's this about "security?" The article doesn't explain why it mentions security, and that's not a surprise, because there's no reason it would be more secure. As other have pointed out, "security" is obviously being used as a codeword for something very, very different (i.e. having the machine serve someone else's interest (e.g. MPAA) at the expense of the user's interest).
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
Let's be clear; Dell is talking about servers with built-in hypervisors. Extrapolating these plans to desktop PCs is just unfounded speculation.
Their Hypervisor will enforce DRM, so even linux can't override it.
Servers don't care about DRM.
They'll make it so all device drivers must be signed to go into the
Hypervisor which will be the only thing with any I/O privs that aren't
virtualized.
OK, this is true. ESX requires special drivers.
They'll make it so new hardware has closed interfaces and can only be
supported by a driver at the Hypervisor level.
On the contrary; Dell has been driving companies like Broadcom and Adaptec to open up and offer open source drivers. AFAIK the only reason we have the tg3 driver is because Dell told Broadcom to provide Linux drivers.
Blue Pill doesn't apply to hypervisors without standard hosts OSs, anyway.
"Its more secure having the actually memory embedded inside the machine instead on the outside in a port, accessible for anyone that have physicall access to your office."
c s-adsahdcf-sata-cf-adapter-review-6.html?Itemid=27
The same pieces could easily be inside the case. Not all USB ports are external. Of course, SATA CF adapters have been available for sometime:
http://www.fastsilicon.com/storage-reviews/addoni
By the way, anyone have links to tutorials for installing a hypervisor to such a setup?
"This post is an artistic work of fiction and falsehood. Only a fool would take anything posted here as fact."
If you were paying big $$$ for enterprise support, would you get a server with GRUB or LILO embedded on the motherboard?
Would you buy one with the kernel and initrds on flash installed on the motherboard?
Personally I wouldnt; Dell has no competence in those areas, and even should they try to build it, they'd end up constantly trailing the OS vendors, introducing random bugs and being far less integrated and standardized than what the mainline products are.
I see little difference in the hypervisor area; hardware vendors can just barely manage keeping BIOSes bugfree enough to get an OS running, expecting them to be able to manage and keep hypervisor software up to date isnt even on the horizon.
There, fixed that for you. Asshat.
Question everything
3) The USB headers are not going to have as high of an uptime compared to something dell could build onto the motherboard (in theory, supposing dell does'nt screw up. This is required due to what most server buyers need is reliability for servers that run 24/7/365.25. Adding in what you suggested, the first thing to fail would most likely be either the flash or the adapter.
I take issue with everything you say here.
There is no qualitative reason why USB should not have, as you say, "as high of an uptime" as anything else which plugs into a computer. In fact, the opposite is likely to be true: USB, having finally grown into something that generally doesn't suck, has been tested and revised for over a decade, and is far more likely to be resolutely reliable than any newly-developed interface technology which has not been so rigorously abused. It's a single point of failure, sure, but it share that disadvantage with SCSI, SATA, PCI Express, and all other likely candidates for connection.
I would further like to submit that the first thing to fail in any flash-based installation in a personal computer will be either the flash chip itself, its interface chip (ala "adapter"), or one of the supporting components (resistors, capacitors - that sort of stuff).
Finally, I'd like to speculate that all Dell will be doing is installing a flash device onto a USB bus. The hardware and software to accomplish this were finished years ago, and thus long ago entered the category of being free (as in beer) for Dell (particularly their marketing departments) to take advantage of.
Kid-proof tablet..
It goes against my religion and I have no use for it, therefore it's worthless. Get rid of it, Smithers.
Support and TCO.
If I have a Dell provided chip on a Dell motherboard which goes out, they will fix it. If I have a Mickey-Mouse setup with a USB flash device, you can bet they are going to try and blame that for my woes first. And, guess who is on the hook for fixing it if it goes south? Moreover, the difference in cost is going to be slight. This chip will probably raise the overall price of the motherboard by a couple hundred, at most. The time I spend futzing around with getting an external solution running is going to cost more in the long run, my employer is paying me good money for that time, and any time spent fixing it. Take a quick look at what even a tech is going to cost:
Say they get paid $17/hour as full-time staff. Then you're paying workman's comp, taxes, health care, etc. Overall it's probably costing the employer around $30/hour for that tech. So, if he spends a day on that solution your spending about $240 for it. Just eat the up front cost from Dell, and make them fix the damn thing, that tech has better things to do with his time.
Necessity is the mother of invention.
Laziness is the father.
Forcing me (the computer's owner) to give up control of the lowest level of my computer. At which point they [Computer makers + Media corporations + MS] will be free to insert every kind of phone-home rootkit, DRM, "trusted" computing and other shit they want. Of course, they will because it's in their financial interests to be able to force you and me to pay any price they want, no matter how extortionate it may be. And since they've forced me out of the bottom-most level, there's nothing I can do to get rid of it.
And oh, there will of course be bugs in it. Exploitable bugs. Which crackers will use to pwn me with no possibility of ever being able to secure myself against them, because I can't uninstall the shit they're taking advantage of or block them out.
Virtualization: Good.
Without me at the helm of the root VM: No thank you, let's not ever go down that path. Ever. In fact, hell no.
Admittedly, I haven't had cause to call Dell, but this works well for my ISP:
I'm thinking of writing a guide like this and distributing it, because these same principles do hold for anyone, regardless of technical skill. The language might change a bit -- for example, a nontechnical person should follow step #6 because what they "know" is not always true, and if they really knew everything, they wouldn't be calling for a tech. But the habits are the same.
Don't thank God, thank a doctor!
There are certain chunks of hardware, actual CPU instructions, etc which have been introduced recently to make virtualization more efficient.
However, I don't think it would do very well against something like Blue Pill, because that could just as easily implement a softer virtualizer -- it would just appear to run a little slower.
Don't thank God, thank a doctor!
Why not just "embed" it in the first 20 megs or so of the hard drive? (Or 100 megs, or 1 gig, given the size of modern storage...)
The only advantage I see to doing it with flash is that they could lock it down, and also, you could theoretically hot-swap SATA (or USB) drives, each with an OS on it (and maybe a "saved image" from the virtualizer, like hibernating). Even if you don't actually physically hot-swap them, you could spin down the drive you're not using.
Of course, if it was me doing this, I'd just get 3 drives (or more) and build a software RAID, and run my virtualized OSes on top of that, so I get a nice performance boost (at the cost of more power required to keep them all spinning)...
Don't thank God, thank a doctor!
One thing that bugs me about this article, it claims that it would make boot times faster, how? Sure if the hypervisor boots from flash that would be there in an instant, but we still need to boot a proper os, and that ususally will happen from disk. So no difference to booting the os directly, if anything it would boot a little slower (the hypervisor boot-time). How is there something I'm missing. Cheers Cyco
In what way is this functionally different than the same hypervisor being installed on a bootable USB flash drive/IDE-attached CompactFlash card/[insert other stupid-simple method of booting from flash]?
Is there such a thing? How would one do this?
Give me Classic Slashdot or give me death!
It still is. It's the "I'm afraid of the consequences of my own actions" people who've hijacked the topic for their own ends.
The last Intel IPD conference I was at, Intel was announcing they were going to be including Virtualization on some of their boards.
Gah, typo. Meant to say USB adapter, not USB header. As in the compact flash to USB adapter.
Also, I was talking about what the GGP was saying about a Flash to IDE, which would be a CONSUMER FLASH CARD with a CONSUMER IDE ADAPTER. It was with this following sentence in mind that I wrote (3).
So? CF to IDE bridge taped down in a drive bay. Flash to IDE header gadget plugged direct to an IDE header. They even have em that plug direct to USB headers on the MoBo now.
Both of which would be the most likely to fail in a server over the other things.
Fly me to the moon Let me sing among those stars Let me see what spring is like On jupiter and mars
I have a CF card mounted on an expansion card bracket at the back of the case. A simple thing, really: PCB with a 4-pin power connector, CF slot, 40-pin IDE connector, and a couple of LEDs for status, all fastened to a bracket so that the card protrudes neatly through a slot at the back of the case.
It's definitely a "consumer" adapter -- I think I paid $8, total, to have it delivered to Ohio from Hong Kong. But like most mass-produced electronic items in this millennium, the soldering is quite good, and the connectors look to be of fine quality. I expect that it should prove to be a very durable implement.
I don't know what else I should expect of such an item, nor do I see any obvious manner in which to improve it.
Could you please be more elaborate on the topic of what a professional-grade CF-to-IDE adapter might consist of?
Kid-proof tablet..
A profesional grade CF to IDE adapter wouldn't exist for servers. Partly because servers don't use IDE. By the way, in this case, I am talking about servers coming from companies that build servers to order, not some computer that was custom built by an individual to be a server.
Now, as to what the CF to whatever interface would have, that would be a bit more than you describe?
Lets see, a bit of redundancy, designed and tested to be in use most of the time, temperature extreme testing, guaranteed throughput/read time from the card/interface, basically something quite a bit more 'rugged' than what you'd find at Best Buy. Kind of like the difference between IDE drives and SCSI drives.
Fly me to the moon Let me sing among those stars Let me see what spring is like On jupiter and mars
I am surprised no-one called all these 3 things:
1. The license of MS does not allow DRM content (like playing a dvd) in a virtual machine. Unless dell can get a different license from MS.
2. Virtualsation still comes with performance cost. 3% up to 50%. Not good for your benchmarks. Unless you think a Pentium II 450Mhz still is fast enough.
3. Drivers. Forget directX 9c or directX 10. Forget Vista Aero.
On a company box there is no problem running in a hypervisor since all 3 points are not important there. Performance can be made good for by buying more hardware (Dell like that), and the latest directX is no need on a regular desktop that uses integrated intel video.
Another cool idea for this could be to include some hardware monitor that always will run on the system, so without any OS-dependant things you could easily get a hardware report from the system without installing ANY type of OS monitor except maybe for something that just connects to the hw-monitor and generates a logfile..
And with this maybe we could get a 'driver-independent' environment too. For each hardware just put the drivers on the flash and then just have a generic API for all network-cards etc. Could probably save the companies quite a bit to have one general driver for all different OS'es. Only thing required for this is some type of shared memory between the driver-instance and the os-instance, and since they then would have these drivers on flash the drivers could be optimized for that specific hardware without the need to tune the OS.
And if they dont lock these things down you could write really cool things like a iscsi-initiator that behaves like a scsi-card for the system.. No need to get a iscsi-hba for booting and no need for iscsi-initiators on the host-os that can screw things up like if you are swapping over iscsi on a linux system and you run out of RAM for the networking-part.
Another few cool ideas for the driver-stuff:
- Virtual network-interface for a specific vlan. Would be perfect if you want to have some virtual production-systems and DMZ'ed systems on the same physical hardware as your firewall.
- Semi-hardware raid that uses the main cpu for the work but without having the need for badly written drivers. (ie, just one raid-sw code-tree to maintain)
- Nvidia/ATI etc could write a generic driver for all os'es and then the os would just need to implement a generic driver for all OpenGL cards.. No more need for binary blobs in Linux and less code for nvidia to maintain since the generic opengl-driver stuff would be moved to the OS-vendor and that could also enable sharing of a gfx-card with OpenGL capabilities for multiple virtual systems at the same time.
- Encryption layer for the RAID without having some type of OS support for it. One generic driver works for all and keys could be from anywhere like keyboard-input or USB-memory.
- a REAL os-independent save-to-disk function. Since the os just have generic drivers only those would need to have support for it and it would be the driver-instance that would take care of saving the actual system-state.
- 'Swap-driver' that could map both ram and disk space as 'virtual ram' that would enable the system to share physical memory between the machines. But ofcourse this could cause a ugly-swap state if trying to use to much ram between the systems, but that could be solved by having some type of extension of the os'es that could monitor the total system memory-usage.
All this would both reduce the number of drivers that the OS-vendors need to support and also reduce the number of drivers that the hardware vendors needs to maintain if they want to support multiple-platforms and would probably give us more stable drivers since they will have a bigger testing-ground and also less types of OS-specific configurations.
In the article nowhere is said that this is server software. I can imagine this kind of software just fine on a desktop that runs a browser, mail and office software for the average office warrior. As it won't play dvd they can even save a few dollar cent they won't have to pay to dvd patents holders
I guess I'll play along.
By your definition of "server," it seems we only have three such built-to-order machines here in use here at the shop. They're all Prolaint ML330s of various generations, custom ordered from Compaq or HP. The oldest one has SCSI RAID, the newest one has IDE RAID. All include at least one additional IDE port for the CD-ROM drive.
So I guess that some servers do use IDE, since these particular ones all seem to be serving just fine.
"Ah," I hear you say, "but those machines are ancient!"
So go on and head over to Dell, the vendor in question. Configure yourself a nice new $10,000 Poweredge 6800. Note the distinct inclusion of IDE CD-ROM drives, and thus the obvious inclusion of at least one IDE port.
The rest of your argument is, therefore, without merit. But even if it weren't: CF to IDE adapters are passive devices, need no testing beyond that which a cable would be subjected to, and play no factor in throughput or latency. Furthermore, flash devices can trivially be made as absolutely redundant as any other storage device in a PC.
Finally, ruggedness: This is only a PC. There is no redundant logic. If you go about jabbing screwdrivers into it, hitting it with a hammer, throwing salt water into it, or dropping it, it will fail. The adapter need only be as rugged as anything else inside of the box, which is not a very difficult standard to meet.
Are you done yet?
Kid-proof tablet..
Yes. It's easy.
Anything which can boot and run from an IDE disk can also run from a Compact Flash card, with the right adapter (Google for one). I've got things ranging from an old version of Slackware running on a flash-based 386 laptop, to a diskless Windows XP machine, which use this trick.
You see, CF cards inherently know how to act just like it is a regular IDE disk drive. The adapters are completely passive, and exist merely to supply power to the card and convert the small pin layout of a CF card to the much larger pin layout of a typical IDE cable.
So, if the mythological hypervisor actually exists and the hardware can run it, then it can boot from flash. The software doesn't know, or care, that it's operating from flash.
Most relatively recent motherboards also generally support booting from a bog-standard USB drive. This is often trickier, because whatever operating system/hypervisor/microkernel/whatever you're booting will probably eventually realize that there's USB ports in place and attempt to control them by itself. If it handles this changeover in an inconsiderate fashion, it will crash. But if the software was built with booting from USB as one of the design considerations, it generally will work fine -- Knoppix, for instance, is supposed to be fairly easy to run from a thumb drive on mostly random hardware.
Expect to see more of this sort of activity as programs and data remain relatively small and flash continues plummeting in price.
Kid-proof tablet..