Theo is objecting to the view that VMs are a security necessity.
Of course, I agree that VM's aren't necessary: one of many approaches one can use and don't get the job done by themselves. They are beneficial, though, as running security-critical components on a 4-12Kloc in kernel mode with mediated, simple interface should have way less impact than running it on 1Mloc+ with POSIX-style interface.
Snapshotting alone is a security necessity when patching too. Very easy to rollback to a "good" state.
It's like bulkheads on modern ships. Yeah, if you get a hole in your hull, you're gonna be in some (literally) deep water, but that bulkhead (so long as it's built right) could mean the difference between limping to the nearest harbor or sinking to the nearest seafloor.
Yes, it makes Ops work more difficult, but as someone smart said regarding software: if something hurts, you're not going it often enough :)
Typically the network or SAN becomes oversaturated and the vm's shit the bed. AWS on the other hand was considerably more reliable and I'd argue they've made better decisions rather than cut corners.
OK so I'm not proclaiming to be an expert but as someone working in the area in 2007, buying something off the shelf like it aint no thing, you're getting something like a netapp with a limit of 512 iscsi inititatiors, or a Sun amber road where your only form of automation is an ssh consol with a big warning stating it's unsupported.
From memory, there was no such thing as setting quotas on the amount of IOPs an iSCSI inititatior can do, in fact, I'm fairly sure IOPs quotas just didn't exist period, as the vendors weren't really up-to-speed with this new selling vm's thing. So basically, we're suggesting that it's a good idea to just buy a SAN to run an indetermined amount of vm's that are going to do an indetermined amount of IOPs.
OK, cool, you're now indebted to storage vendors selling you new shelvs at £80,000 a pop for those extra IOPs you so deperately need. Now to be fair, Amazon could probably afford it, but your VMs would still be a lot more expensive and would probably have still been totally disposible when your switch port decides to blip traffic to the SAN or as previously stated, Xen shits the bed.
None of these things might be a problem today, I don't know, I'm more a consumer than a producer of clouds these days, but I'd suggests these criticisms are bullshit. They come from some obviously smart people, but bullshit none-the-less.
Also, it's worth mentioning that EC2 instances are meant to be ephemeral; Amazon doesn't provide any semblance of a guarantee that your instances won't reboot, and assumes that you intend for all your "machines" to be arbitrarily rebootable. Not saying that any hypervisor implementation right now is particularly good; only that Amazon isn't exactly the best representation here.
What you said, on other hand, was meaningless given that OpenBSD has had bugs that could lead to a crash. Real question is, "Do Xen or security-focused virtualization schemes (a) reduce number of vulnerabilities with impact of kernel-mode 0-days, and/or (b) prevent, contain, or facilitate easy recovery from OS- and app-level 0-days?" Prior experience in security-focused efforts show yes to both questions. Xen isn't one of them as the existence of the Xenon project shows. However, it's small size and improvements over time make it substantially less risky than an arbitrary OS + software combination esp if above layer is also addressed (eg MirageOS). Even Galois Inc.'s conservative teams are using it in some work.
Just because there's a nice mouse-navigable GUI for entry level Windows admins doesn't mean it's a good solution.
if you need snapshots for doing updates it's because your software is fragile, undocumented, and you don't have a deployment procedure. Fix that, and upgrades will be easy and not scary.