Not quite: projects written by Googlers have the 'Google' label, which is unusable by normals.
Official Google products are not hosted as normal 'projects': the URLs are code.google.com/product or code.google.com/apis/product instead of code.google.com/p/project.
I would like to think that Google Code really should not call out whether a project is an official Google project. Ideally all open source projects would live and die on their own merits.
I've been using this at work to rebuild our internal infrastructure for test, file serving, etc. I was intrigued by its ability to manage disk redundancy via DRDB, though I haven't really tested the instance failover features. So far, I've been focused on getting it working nicely for Ubuntu guests. It's pretty cool to bring up a fresh machine with the latest packages in a few minutes. It'll really come in handy when I start working through configuration management and deployment automation for our apps.
I'm not sure why I think this, but I had them impression that they use it for test environments, but I'm pretty sure they also use it to provide "cloud" desktops for employees, I think I saw reference to it in a presentation about the open source NX server they released a little while ago.
They don't use virtualization for any of their normal infrastructure -- it's much more productive to have locality with GFS/BigTable/memcache/App/etc all running in the same OS image on every machine.
I do see them having plenty of use for virtualization when provisioning machines to run non-infrastructure, their client software, other people's software, etc. Its usefulness for software testing should be obvious.
I don't know if they use full x86 virt. for it, but your App Engine processes have several layers of OS sandboxing around them.
1. It's hard to tell which projects are official Google projects and which aren't.
2. The total lack of real names is disturbing to me. e.g. look at http://code.google.com/u/imsnah/ -- it's completely useless.