>> GERTZFIELD: So, the real gist though is that with any computer, what you want is applications.
You know, you might want your Safari for web browsing, you're iTunes, or maybe you want
your web services application.
You know, on the server side.
And the problem is, until today, outside of the web, all of your applications are tied
physically to an OS.
You know, by APIs, ABI's, other things.
You know, it's not true for the web of course.
And you're OS, until today has been tied to your hardware.
So, Windows runs on Intel machine from Dell, Compaq, whatever.
Mac runs on the shiny silver laptops that we see peeking out here and there.
How--one, to three, okay.
I think we've met quorum of laptops--of Mac laptops.
This is, you know, quickly becoming--yes, thank you.
The mating--the mating call of the Macbook pro.
It's quickly becoming a way of the past in virtualization, and Google are, as well, are
trying to break these chains.
And that's kind of the point of my talk here, is virtualizations frees your apps from silicon
chains.
Before, you know, you wanted to run your favorite Windows app, you know, heaven forbid Outlook
or IE when you happen to do some web testing.
You had to have a physical install of Windows that was tied to that box.
The aim of VMware and Google is to just break that chain.
Wherever you are, you apps go with you.
From Google's point of view, it's basically your apps are hosted for you.
You go use your Picasa, you go use your word editing, your presentation editor, it's all
hosting for you.
VMware takes kind of an inverse look where you just take your entire computer in a little
bundle, stick it on your iPod or your single hard drive and just plug it in wherever you
go.
It runs on your Mac, your pc, Windows, Linux, it doesn't matter.
You've got the same platform underneath.
So, I wanted to just like, to tell you a little bit about how we got to this stage.
Application development has gone through a lot of different eras.
You know, back in the 80's, application development was really centered around source level APIs.
We got the birth of [INDISTINCT] for the first time and people were able to say "Hey, I can
distribute my application just by giving you the source code and it doesn't matter where
I [INDISTINCT] running, you can recompile it and it'll basically work more or less."
You know, the good example is Fork.
You know, entire operation systems were designed around this one API.
To really know Fork, you really have to know UNIX and vice versa.
To have Fork, you have to have UNIX.
And, you know, in the 90s when business computing got a lot more popular, people kind of seized
on the notion that "Okay, I've got these applications.
I want the same application to work as I upgrade my hardware.
I want binary compatibility for my applications."
And Microsoft really seized on this.
They made them a lot of money.
But as we're finding out, you know, in the current era, this is changing really, really
fast.
People don't want their application to be tied to a physical computer or a location
at all.
So, in the current decade, what we're moving more towards is a virtualized infrastructure
where applications can actually go with you anywhere.
Specifically, what virtualization does is it brings the Intel--oh, I'm sorry, VMware
virtualization, brings the Intel binary layer, the ISA, to any platform anywhere.
It gives you a whole set of virtual hardware.
It perfectly emulates the Intel instruction set without people having to recompile or
change a single byte of their existing programs.
So, they can take their ancients, you know, Windows 3.1 development environment and just
copy, import into a VM and bring it around and there's a shiny new Macbooks.
Or, a good example is, you know, there's all sorts of people in Japan, they run power plants
off Windows 98, and that's all that they have.
There's offer runs on Windows 98 and they--you can't even buy hardware for it.
But the Intel ISA actually stays the same.
So you can actually install this, you know, you could--you could run a power plant [INDISTINCT]
of your Mac if you want to know.
An important thing to know is that there's a lot of other people who have tried and failed
at this.
Java really promised to provide another virtual, you know, ISA that people could code to that
would give their promise of being able to be portable everywhere, run the same apps
no matter where you go.
We're pretty sure that Java's promise to do that has failed to this point.
Two main reasons, one is, they didn't really have a stable ISA to work from.
You know, the Intel ISA has been around for a long time.
It's cruddy.
The current processors don't even really implement it, they just--they just emulate it on a virtual
processor inside.
But with Java, you know, I've already had to rewrite their programs, you know, nth times,
once for every version of the Java virtual machine when they broke the backwards compatibility.
The VM gives you perfect backwards compatibility at the machine instruction layer and--because
it virtualizes out the restrictions of the hardware, you don't actually need to depend
on, you know, the version requirements that Java introduced.
But VMware didn't introduce this.
Like VMware did not invent this notion of virtualization and people--people have been
doing this for four years now.
IBM introduced that way back when with system 360, 67, you know, we're time sharing again.
You know, we've got server loads that are completely spread out all over the place and,
you know, we're just revisiting the past.
Like, everything goes in cycles.
Virtualization really isn't just about, you know, installing monster machines and partitioning
though, because it gives you an individual container that has identical hardware wherever
you go, identical machine compatibility.
You can just lift it up and move it form your PC to your Mac, to your Linux box.
Or you can have a cluster of server farms, and maybe the hardware isn't exactly identical
but I'm sure anybody who's worked in IT knows you spend all your time installing operation
systems, and, you know, your applications are tied to that particular install unless
you have a really clever folks like the Google people who know how to write massively parallel
applications.
I mean, most system administrators and IT organizations aren't quite up to snuff [INDISTINCT]
huge, you know, massively parallel architectures just yet.
So, VM what gives those people a way to make fault tolerance, distributed systems from
another aspect, you know.
You basically take the computer out of the picture and move the [INDISTINCT] into their
own little compartment that you can take around.
So, what I wanted to--what I wanted to get at is what VMware brings the table is, specifically,
x86 virtualization.
So, this wasn't really hard--this isn't really hard.
A lot of people said this couldn't be done.
There's a really seminal paper by Popet and Goldberg that a lot of people latch on to
instead.
You know, you can't actually virtualize the Intel ISA, it's not possible.
There's all sorts of instructions that actually mess with internals of the processor that
you can't trap.
You know, several things like call and return, push up and pop off.
I mean, you can't actually trap them and emulate those at any time.
So, you know, what VMware innovated in is actually being able to rewrite this on the
fly so that they are safe to virtualize and that let's us do it on Linux, Windows, Mac,
whatever.
The reason I bring up the Intel point is, for the Mac market, there was a really momentous
occasion in summer of 05 when Steve Jobs got up with Intel on stage and basically said,
"Okay, we were wrong all along, [INDISTINCT] wasn't the light and it's time to actually
jump ship."
I know it's hard to believe for the Mac had to--who heard all the [INDISTINCT] promises
and--what was 3 gigahertz but 20065 wasn't it?
Or 2004?
Yeah, it never happened.
They jumped on to the Intel ISA bandwagon again, which basically says it's another platform
that the Intel ISA is supported on that can become another way to have virtual machines
on.
So, the engineers at VMware really knew, you know, "this is going to be something momentous,
this is really huge."
So, you know, a couple of us just started hacking around for fun and eventually came
up with what became VMware fusion.
I heard that happens a lot at Google, people just messing around to start their spare time
and coming up with something that gets procuctized.
Funny, how that works.
The difference on the Apple platform is Apple builds products specifically for one purpose.
Their products are meant to run Apple applications.
They give you all the APIs you need to run iTunes, iPhoto, Safari, but they're not actually
going to give you the kind of robust tools to develop a huge client server network or
a massively scalable, you know, database infrastructure.
I mean, that's just not what they do.
If you're coding to make a really cool image browser or a multimedia editor, it's totally
the way to go.
It's really easy.
It's fast, you know, it's well understood.
But if you're going out of the box, it's tough.
Of course, there's one product that people want to run on Apple apps on is that, that
is the iPhone.
I wrote this slide before this morning.
So, I missed this morning's announcement of the new Apple API, but it is--it was true
when I wrote the slide that the iPhone did not run the Apple apps, but if you didn't
hear this morning, Steve announced from on high that we will get an API to run--to write
our own iPhone application.
That's actually pretty exciting, even more VMware.
Virtual machine on an iPhone [INDISTINCT] Intel.
So what we did in Fusion is we focused on one and use case which was totally new for
VMware which was consumers want their Macs to run PC apps.
They really want to run their Outlook.
They want to run their IE for web testing.
There's a million little PC apps.
I use it to update the firmer on my phone.
You know, there's all these crazy little apps that require Windows support in hardware and
software and these--I don't expect Sony to go out and write drivers from Mac for my phone.
It's not very likely.
But they will support and write drivers for Windows and not use a virtual machine to flash
my phone.
The whole point of virtualization is that, unlike things like boot camp, you don't have
to stop all the applications you've been using, shut everything down and reboot.
Your PC apps and your Mac apps are both first class citizens for the virtualization.
So you can actually drag and drop between your PC and your Mac.
You can copy and paste text, share your files and, you know, more and more, the lines get
blurred.
There's even something called unity that we worked on that completely gets rid of the
Mac desktop and you just got your Windows application just floating there on your Mac.
I'll show you guys a little bit later.
It's pretty exciting.
It makes you want to jump out and go, you know, grab a Mac, like this lady.
So, she's really excited about Leopard.
And--this is the new OS 10.5 that's coming out.
It sent all of the Mac developers into a usual Steve Jobs Beetle style hysteria.
Lot of things are really nice on the Mac platform, but it's not perfect.
And what I wanted to tell you guys about was--some of the lessons we've learned from developing
VMware fusion and some of the internals of how we brought the VMware fusion to the Mac.
So, the Mac platform, it's a--kind of a bipolar situation, and I kind of like to given an
analogy from my favorite 60s TV show called The Prisoner.
So, The Prisoner was a 60s TV show about a super spy who came to this--he was shipped
off to this idyllic island and everything was perfect and planned for you.
There was this beautiful scenery everywhere and you could never leave the village.
You were never allowed to escape.
Everyday he tried to escape and there was a new face of the number two who ran the village.
And--it's pretty similar to the Mac development world.
You know, you're kind of enticed into it by saying, "Oh, what a cool platform.
We're going to make exciting new apps for it," and then you kind of dive into the inside
[INDISTINCT].
Inside, it's actually four or five different operating systems, kind of jumbled together
in different pieces.
And as Apple needed different pieces to build iTunes, safari, iPhoto, iWeb, they use each
of this piece and develop them, but there's really no cohesive whole.
To learn these different pieces, you kind of got to learn through trial by fire, and
I kind of call it the Mac Club.
And as the first rule of Mac club and everybody knows the first rule of Mac club is "You don't
talk about the Mac Club."
So, what I mean by that is, you know, the APIs, there's documentation, but they're not
telling you what's going on under the hood and they're not telling you about all the
side effects, the scary, you know, callbacks that are being registered for you under the
hood.
You know, you really have to dig deep.
With good books like "Mac OS X: Internal Assistance Approach" by Mr. Amit Singh, you can actually
start to learn some of the internals under the hood.
But seriously, before that existed, there was nothing and it was all just handed down
over the years.
Very interestingly, you know, how many people here have done like Windows development, professionally?
So--I mean you've interacted with Microsoft, with MSDN.
It's kind of frightening but it's thorough, right?
And if you have a problem, you can write to somebody.
Apple's equivalent is a once a year conference called WWDC.
And you can sign up with WWDC, pay a couple of thousand, and get direct access to the
engineers.
But other than that, you know, there's no way to get information about the actual innards
of the operating system.
You can submit support request, but they're more intended to shield the developers from
the hoards of hungry third party application vendors than anything else.
So, here's some of the real rules of the Mac club.
So I wanted to share these, for anybody who's doing Mac application development, because
if I could travel back in time and give myself a couple of tips before I started down this
road and helping VMware fusion with my team, I wish somebody would have told me.
The first big rule, know and fear Carbon.
Carbon is scary.
So, before OS came out, there was this huge legacy of APIs, all jumbled together based
on C and a little bit of C++ called Carbon.
Carbon is intended, basically, to support older applications, to get imported with a
minimum of fuss.
If you start using an OS10 though, you have to be really careful.
Some of the stories that we actually learned when we started using a little bit of Carbon,
VMware fusion is basically based on our Linux application, VMware work station, and as such,
we use a lot of Linux APIs.
You know, pull, select, fork.
And we kind of assumed that Mac was then being UNIX or "UNIX underpinnings" as Steve put
it, was a true UNIX.
The truth is that, it's really splits among the UNIX side and the Carbon's side, and they
really don't interact.
A good example is when you--there's a library in Mac, was called disc arbitration and they'll
tell you when discs are plugged or unplugged.
You can know when an iPod's connected or disconnected.
If you don't actually respond in time--a disc arbitration function will secretly, behind
the scenes, register a bunch of callbacks and Mac will assume that you will receive
those callbacks by processing something called the CFrunloop which every thread has one of
these.
Well, if your app isn't based around that concept of a CFrunloop, you can just hang
the entire system for 15 to 30 seconds while Mac [INDISTINCT] tries to repeatedly send
messages to your runloop saying, "Hello, there's a new disc.
Are you there?
Hello, there's a new disc," even if you didn't know the API that you called have the side
effect of registering with CFrunloop.
So, be very careful and know your side effects.
Sometimes, you have to go down to the disassembly level as we know, to figure out what these
APIs are really doing.
Next rule about Mac Club, you have to be really careful of angering the Universal Buffer Cache.
So, on Mac OS, virtual memory is kind of a virtual notion again where it's cached by
the same buffers that hold your disc cache.
So, if your photo shop or VMware fusion and you're reading a gigantic, you know, 1.5 gigabyte
file, OS10 is going to cache all of that memory, maybe even in priority over other programs,
forcing them to maybe even swap out the disc.
You have to be really careful and very explicit about, you know, when you do and don't anger
the buffer cache.
They do provide API's to that, but again, there's no document that says, "PS," you know,
"if you read a large file, you better," you know, "disable caching on this file or you
can make every single program on the systems swap the disc."
So be very careful about the buffer cache.
The last real rule that I wanted to share, whenever you're doing dynamic 2D, you have
to go straight OpenGL in Mac OS.
If you're doing things like static layout of curves and text and buttons, it's great
to use Quarts and coco and these very high level obstructions.
But if you need to render, you know, video or a fast 2D drawing stream, you need to use
other technologies.
One of them is OpenGL.
And normally, I mean, people don't think of OpenGL as a 2D technology, right?
You think of it for video games, doom, and quake, and that kind of stuff.
On the Mac OpenGL is really the closest thing you're going to get to bit [INDISTINCT] on
Windows.
You don't get direct access to the video rom on the hardware, but you got the next best
thing which is access to video rom that will be composited later by the Window manager.
Meditate heavily upon OpenGL because it will reward you once you learn that there's lots
of fast paths and slow paths.
You have to make very, very sure that you can recognize when you're being kicked off
to the slow path in OpenGL.
Good candidates are if you're using the wrong texture type, has to be BGRA.
You know, make sure that's a, you know, you're not using anything but 15 or a 24 bit color
or you're going to be booted off to the slow path.
So, be very, very careful.
I have mentioned before, OS X is kind of bipolar as we learned through developing VMware fusion.
It's got a chunk called Mac.
So, you know, the Mac 5 is not a very good logo for Mac, but it was the best I can find.
They don't have a cute penguin or a demon or anything.
So, the Mac OS came from CMU, as everything good seems to come from, just kidding.
And it's a really simple operating--it's a really simple operating system that just manages
memory management, message passing, scheduling, and a little bit of threading.
You know, really, really basic stuff.
And this was the reason of the foundation of OS X, but that didn't give them any actual
functionality.
It just gave them a really cool abstraction.
So, in a hurry, back in the next step days, they dumped a huge monolithic guy called BSD
right on top.
And the reason they did this because they needed file systems, they needed TCPIP, they
needed, you know, UNIX interoperability, most of all.
So they said, "Ah, well kind of [INDISTINCT] of BSD layer on top of Mac and see what happens."
So it kind of got this top heavy, two headed demon that has half Mac and half BSD, and
they call it Darwin.
So, they--this one does have a cool little mascot.
It's kind of like the platypus with the devil's head.
I don't know.
It's kind of sinister.
But we have to remember is that even inside Apple, their own kernel is called X and U
which stands for X and U is not UNIX.
This is really true.
I mean, it's UNIXish, sort of, but if you really depend on UNIX's semantics for things
like, just as simple as, you know, when you call a--when you flush, right?
If you want to flush--if you want to Msync all your pages to disc, Msync does everything
except for Mmap pages.
They don't tell you that.
Every other UNIX in the world, if you Msync, any page in their Mmap will also be written
to disc--excuse me, Fsync.
Msync is the one that does work, right?
Excuse me, Fsync.
So, you know, there are always little needly things that aren't documented anywhere that
you just kind of have to discover through trial by fire, but just keep in mind that
if you're porting UNIX code, expect the unexpected because it's going to keep happening.
Ann so what we did for fusion was we took the VMware platform that was, you know, VMware
work station, server, player, and we moved it all to the Mac.
There's several components of this that we ended up porting using a nice sprinkling of
different programming languages and libraries along the way.
The first chunk I like to portray it here is like bit from Tron.
It's our faithful UI.
It's says "Yes", it says "No", it does whatever the virtual machine tells it to do.
It's, you know, its job is basically to look pretty and connect to one or more virtual
machines running behind the scenes.
One of the neat things about our infrastructure though, is that it's actually completely client
server based in that UIs can talk to separate virtual machines running behind the scenes.
So, any number of UIs can connect to any number of virtual machines and manage them locally
or remotely.
So, the VMX is the separate process that runs--that manages a single virtual machine.
This is like hardworking Tron with his, you know, with his faithful data disc.
He does the heavy lifting of actually binding a virtual machine, emulating discs, network
cards, graphics.
He does--he does all the stuff of making the bits actually show up on the screen of the
Mac.
So, he'll do all the OpenGL drawing, all the core audio for sound, and the mouse and keyboard
input.
So the UI and VMX kind of work together.
Those of you who have seen Tron probably know where I'm going with the third member of the
triumvirates.
And this is--this is the most interesting part of VMware, it's called The Monitor.
It's kind of like the master control program in Tron of this giant spinning.
We actually have giant spinning top.
It just kind of stares at us all day long while we're coding, tells us what to do.
The monitor's job is basically--it's a bit of Intel code, you know, that's identical
on all VMware platforms.
You know, Linux, Windows, Mac, and all specific releases of software can use the exact same
monitor.
Its job is basically to manage the few physical resources that a virtual machine actually
needs.
Virtual Machines basically depend on processor resources and memory resources.
And the monitor's job is to make sure that these are available when we switch a thousand
times a second or more, to and from of virtual machine back to the host virtual machine,
back to the host.
The monitor actually makes sure that every--all the registers are set correctly, the memory
is all available for the virtual machine that needs it and vise-versa, that the virtual
machine doesn't overstep its bounds.
So, we talked back earlier about the Intel ISA.
Intel ISA is really hard because you have to trap all these exceptions that aren't trappable.
So, what the monitor actually does is, he'll actually rewrite a fending instructions on
the fly into a completely equivalent but safe version, except that the virtual has no idea
they were rewritten, but it gets the same effect on--when it comes back.
The reason for that is if the virtual machine could, say, do any raw interrupt call that
it wanted, what will stop a virtual machine from rebooting your physical machine, or taking
all the memory, or scribbling all over your disc?
So, it's provides that boundary between the virtual machine and the actual hardware.
So--oh crap, just kidding.
So, what we learned in fusion development is that, you know, you want to stay out of
the kernel of OS X absolutely as much as possible.
You know, there's some times that you can't avoid it, but by large, the vast majority
of the work that you need to do in OS X can be done in user space.
And if you need some raw kernel access, the best thing to do is actually to set up a communication
channel, whether it's a BSD socket or a Mac port to communicate back and forth between
user space and the kernel.
And--so a good example is like, user space can actually do pretty much every Mac operation.
You know, open ports, create tasks, it can do everything.
A lot of these--I see aren't publicly available inside the kernel itself.
So if you write that kernel extension you can't actually do these things, but user space
can, vice-versa.
We just found we needed to work around the bug and one of the kernel drivers in OS X;
we had to check what version of the kernel extensions was loaded on the machine.
You can actually do that from inside the kernel, but you can ask user space to do it for you.
Do a little processing and send you a message backup over a socket of a Mac port.
So, the lesson to be learned here is stay out of the kernel if you can.
I'll talk about the technology that you can use instead.
Again, I don't mean to pitch.
I misspoke again.
But if you do need to go into the kernel, the only resource out there is basically Amit's
book.
So read it.
It's really good.
So if you have to go inside the kernel, there's two main inter-phases for you to use when
you're writing your kernel extensions.
And VMware fusion uses both of these, which is why I kind of want to talk about them.
So, I/O kit came from some research from the next days.
It's kind of scary actually.
It's a big C++ framework for use inside of a kernel.
I'll say that again, it's C++ inside the kernel.
If that doesn't scare you, I don't what will?
It is--it is a restricted [INDISTINCT] of C++.
So, there's no exceptions, no multiple inheritance, no templates, but what it does give you is
transparent access to things like busses.
So if you need to interact with USB devices, PCI devices, [INDISTINCT], any of that kind
of stuff.
You want to notify when the machine goes to sleep or wakes up, you know, synchronously,
you have to do through I/O K. On the other side of the Jekyll and Hyde personality inside
OS X's kernel is BSD.
So BSD, you need to interact with it in your kernel extensions if you need to do any file
system work, any networking.
So if you want--one big thing that VMware fusion does a ton of is transparently bridging
the networking inside of virtual machine, to networking outside.
And maybe that's not too hard for like, physical Ethernet but think about that for a second
for things like, wireless, right?
A wireless card has one IP and one Mac address, and you can't just put it into promiscuous
mode and start blasting packets on the network that you could with Ethernet.
So, there's a lot of work that fusion has to do under the scenes to make sure that things
like networking are just, you know, they just work for the end user.
So if you need to do any of that, you know, go to the BSD layer.
And like I said, if you must, you must.
Fusion has three main kernel components that actually use I/O kit and BSD.
We [INDISTINCT] called VMX 86 for the VM on.
His job is actually--is mostly an optimization task.
He's the one who's actually responsible for getting the monitor, that huge master control
program--well, [INDISTINCT] pretty small, kind of cute.
Getting him inside the physical memory of the machine and locking those pages down,
so that we can reliably jump to and from it and make it actually run a virtual machine.
VMnet is the one I just mentioned.
You know, this is what actually talks to the BSD layer, makes virtual machines, networks
inter-phases, bridge, if you want them to be bridged, or be nodded if you want them
to be in nodded to be protected from viruses or, you know, you don't want it--or maybe
you don't have a DACP server on your local LAN.
You know, it will handle transparently setting up virtual networks.
What's interesting about VMnet is it can be a simple or as complicated as you want.
You know, by default, fusion comes out of the box with one bridge network, one net network,
and one host to only network which means that you're VM can only talk to the physical machine
for like researching viruses or honey pots, that kind of stuff.
But you can make it as complicated or as simple as you want just by editing some shell script
in the library applications support in VMware fusion directory.
So if you need to have, you know, a network that, you know, specifically binds with specific
[INDISTINCT] demon that has specific behavior or only allows two machines at a time, what's
another good example [INDISTINCT]?
>> [INDISTINCT] the firewall, you know.
Have a machine that has [INDISTINCT] and [INDISTINCT].
>> GERTZFIELD: So, what we just said is, you know, you could develop an entire network
of virtual machines that have layers of firewalls between them and you can have, you know, three
virtual networks.
You can set all these up with the VMnet.
And they're as separate as physical--they're really just like physical switches or hubs
from the virtual machine's point of view.
And the last kernel component that fusion uses is called VMIO plug.
So, VMIO plug is a necessity born on the Mac.
One big thing that fusion does that I mentioned earlier, is you can take any random USB device
like a cell phone, an iPhone, or a printer, scanner, whatever.
Even if Mac OS X does not have drivers for it, you plug it in while a virtual machine
is running and VMIO plug's job is to seize that and connect it virtually to one of the
open ports in the virtual machine.
So, Windows will just pop up say, "Hey, I detected a new--a new scanner."
And even though OS X doesn't have drivers for it, all it knows is the VMIO plug is handling
the USB traffic for that guy.
And just because it goes to Windows, Mac OS X doesn't have to know--know any better.
That's actually really handy.
That's where we completely using I/O kit as it must.
But--so far I just talked about how virtual machines interact on the outside with, you
know, MAC Os and the kernel components.
But what's inside virtual machine is actually really important, too.
This is the other story of the application is so important to the virtual machine.
With full inoperability and integration between windows, [INDISTINCT], Linux, BSD, even network,
believe it or not, we found out in network because we just broke the network build last
and I am really embarrassed.
The tools basically handle full integration for drag and drop.
So you can drag files in and out of your Windows virtual machine to Mac, or Linux, or Solaris,
or free BSD.
You can literally drag files in and out of the window, copy, paste to synchronize.
So you just go into your text editor in Linux and you can paste it in to your web browser
on the Mac.
And it also do more advanced things like, you know, if the host needs more--has pressure
on it's memory, we can ask the virtual machine to swap some of its memory out son that we
can get that back for the physical machine, its called ballooning.
It's a pretty cool technique.
So, you know, it's really important to know that, you know, integration with the applications
is really what we're aiming for.
So, another really interesting story I wanted to share about fusion development is, we learned
this: You don't actually need a Mac to build Mac software.
Traditionally, people who develop, you know, apps for Mac like the Picasa up-loader.
You know, you just start hacking on it in X code and, you know, eventually, you know,
it becomes a full pledge product, but you need to have automated builds.
You need to have, you know, the--your build team needs to have a way to generate builds
on demand and you may need, you know, your friends maybe modifying some shared coding.
He might need to build it.
What we do with VMware fusion is we actually do the entire build on Linux.
So, the entirety of VMware fusion is cross compiled on Linux--a cluster of Linux virtual
machines at VMware.
The real big advantage here is, you know, you don't need a physical Mac to run the Mac
build.
So, I don't know if anybody here--have anybody here worked on cross platform software development?
Okay, a lot of people have.
I mean it's really common for somebody to edit something in shared code, the string
library, or the formatting library and, you know, they break some of the secure platform
because they have no way of testing the build.
Well, you know, when you concentrate on cross-compiling, they can just pop open a virtual machine,
cross compile inside that virtual machine if they're running Windows, or if they're
running Linux, they can just cross--they can just compile--cross compile it directly and
test the build before they check in.
That was a real big boon for us.
But you have to be kind of careful.
There are a couple of things--even though GCC is completely open source, Apple's moribund,
open Darwin tools are--they're kind of only mostly dead.
The linkering, what not, are still available.
But there couple of things that aren't yet available.
Actually, packaging up a Mac--Mac's software for distribution, people [INDISTINCT] .PKG
and .DMB bundles.
The disc images and what not, are still completely proprietary and you do need a Mac for that
final packaging step, unless you're clever enough to reverse engineer it.
We're not that clever.
So, you do need a Mac for a couple of things, but actually for the building--for the actual
development and making sure that, you know, things compile and--compile okay, you can
actually do it all complete outside a Mac.
And then in the future, you know, if Steve Jobs gives the okay, there's no reason my
Mac virtual machine can't run on physical Windows or physical Linux boxes.
You know, so far it's basically been mostly a licensing issue, but there's no telling
what will happen in the future.
I mean, if you run, you know, Mac OS inside a virtual machine, you know, the possibilities
are pretty--pretty limitless there.
But you have to be careful, right?
Because Apple is a hardware vendor, they sell hardware.
They sell shiny metal, beautiful shiny metal boxes, they seem--one, two, three.
All right, there's like twelve of them now.
They're multiplying.
Apple sells hardware and they don't want OS X running on average Dell and Compaq boxes.
So, you know, the virtual machine world and Apple kind of collide.
They want to sell more boxes.
You know, we want everybody to kind of consolidate everything into one box and save power and
energy and maintenance cost.
So, you know, we got to find a way to cut the Gordian knot, as it were, to make sure
OS X can run as a virtual machine.
So, what I want to finish out with is, to talk a little bit and demonstrate some of
fusion's features.
We really thought outside the box with fusion.
This is a demonstration--this is a screen shot of one of our features called Unity.
This was kind of born of necessity.
Anybody who's used Parallels has heard of their feature, Coherence.
This is a similar idea where virtual machines can be running Windows and the host OS Mac
can actually display them as floating stand-alone applications from the user's point of view
random at desktop.
So, even things like Expose' were great.
You know, each of your individual Windows application shrink down and displaying your
desktop just as if they're Mac apps.
I mean, it totally breaks down the walls and again, kind of focus on the point that the
application is king, whether you need to, you know, contact it over a web interface
to a server ring somewhere, or run it natively in your Mac because you need, you know, the
speed, 2D or even 3D, right?
One of the big--the big sticking points for a lot people I know with Mac users is, they
still hate to play those PC games.
You know, everyone wants to play BioShock or Halo 3 or whatever comes out.
Is Halo 3 app for PC?
Probably not.
We will, in a year of two.
So there's always--there's always those, but virtualization is getting to the point where
you can start to play 3D games and fully interact with your virtual machines there ran on--your
virtual machines apps run the desktop.
So, I want to give a quick demo of some of--some of fusion here.
So--all right.
Let's see if I can actually get to my Window here.
So, that will do it.
Ah, okay, cool.
So, we have Windows running here.
This is all inside a virtual machine in full screen mode here.
So, you know, I have very, very important work to do on my Windows desktop.
You know, I often have to play solitaire.
It's very, very important to me and it's a very huge a shortcoming on the Mac that we
don't have things like solitaire.
But, you know, why stop there?
I mean, why not go for things like full 3D games?
So, this one--I have a pretty old 3D download here, but I'll show you guys some of the stuff
that fusion can do now.
So, this is just, you know, a pass mark test.
I can do 3D graphics.
So this is just in the Window here.
So you can actually, you know, you can actually do--this is actually using hardware acceleration.
So it's actually translating everything to OpenGL on the fly.
You know, it's--it's pretty cool.
You can do things like 2D games.
So, you know, I can run my very, very important Bookworm adventures.
You may--you have to have Bookworm adventures.
You know, you can run your IE for testing, your Google desktop.
You know, very important on Windows.
And if I don't want to interact with a full screen, you know, I can just leave and go
to a window.
So, I can interact with it, you know, anyway I want.
You know, whether I want it to be just a window, you know, floating around.
No, I don't want that.
Yes.
So this is also a very key feature for me, its playing Bookworm adventure between builds.
So, well, I got a good word here.
Squeezy.
Squishiest.
Oh, very exciting.
Nice.
Get them.
Okay, cool.
But let say I don't want to have to deal with, you know, the Window's desktop.
I can actually escape from the confines of the Windows desktop and go into Unity mode.
So now my Windows applications are just kind of floating here on my Mac desktop.
So, you know, I can have my Mac apps and my Windows apps, kind of side by side.
I don't know why my desktop showed up there.
You can do a lot of interesting things because your Mac apps become, kind of fully integrated
with--with Windows and vice-versa.
So, it's pretty exciting there.
Let's get out of unity mode.
Oh, actually that was my--that wasn't my windows desktop.
That was Mac desktop.
I was forgetting because I didn't see my--my icons there.
That wasn't very exciting actually.
Let's get--let's get the Mac talk over there.
Here we go.
You can see we're actually in Mac quest here.
So, if I need to open up, you know, I don't know, IE or something because you have to--you
know, a lot of things that fusion is all about is getting access to those apps that don't
exist otherwise.
So, I can go into Unity mode.
And there you go.
So now we have IE and my Mac applications kind of side by side.
So, I can open up, you know, finder and let's see.
Where's my finder window?
Here it is.
So, I have my finder windows, my IE windows and they are all kind of--they're all kind
of interacting.
So, you know, if I minimize them, they go into the dock.
I un-minimize them they come back.
It's a pretty cool way of interacting with virtual machines.
So, that's basically--that's basically my gist is, you know, virtual machines are really
coming along.
Their--we're looking at it from an application development and distribution standpoint.
We really want people to think about--if they have to interact with the hardware and they
don't have the resources or the know-how to make a widely distributed fault tolerance,
client service system like you guys at Google do.
You know, they can take it from the other direction and take their existing Intel apps.
As crummy as they are, maybe they were written 20 years ago and packaged them up on a virtual
machine that will run in any Intel box, Mac, Windows, Linux, whatever they have lying around,
and run perfectly.
Like there's no--there's no Java, VM that might be different on Mac, Window, or Linux.
It's literally identical and the same virtual hardware's available wherever you go.
So, yes, so that's basically my presentation.
I want to take any questions.
I have--so, it is first internal and then external?
Amit?
First, external then internal or internal then external?
>> What?
>> GERTZFIELD: The Q&A session?
>> Oh, no, it's [INDISTINCT].
>> GERTZFIELD: Okay, soů >> [INDISTINCT]
>> GERTZFIELD: Okay guys.
So come on up and ask any questions.
You can up to the microphone or come on up.
I'd love to answer anything about Mac developments, fusion in specific, how we did, what we did,
how we got here and what we learned along the way.
Right there.
>> I was wondering about the--you use VT?
The VT instruction set?
Do you need to [INDISTINCT] monitor if you use VT?
>> GERTZFIELD: So, the question is, do we still need VT--do we still need the monitor
if we use VT?
So VT is an extension, developed by Intel at--VMware work pretty closely with Intel,
any hardware vendors to provide hardware assisted virtualization.
The big thing that was really hard with virtualization and Intel to begin with, was like I said,
trapping this naughty instructions, like return and, you know, push up and pop up.
VT extensions basically gave--made the task of writing a virtual machine monitor a lot
easier.
What we found with VT was the performance with VT is much better for certain tasks and
much worst for others.
So things that require a lot of context switches like system calls, perform way better under
better VT.
So we provide it as an option in VMware fusion.
Certain things you have to have VT for, like segmentation protection was actually removed
from the original 64 bit Intel I64 instruction set.
I'm sorry, not I64, the AMD 64 instruction set.
So we actually had to use VT to emulate segmentation--to remove the need for segmentation.
We offer the availability for VT, but we don't depend on it because VT basically, it boils
down to making--writing a virtual machine monitor a lot easier.
That's why you see a lot of new products coming out that require VT.
It's just much, much easier than writing a binary translation monitor that performs really
well.
So, we justů >> We're actually using free virtualization
technologies.
One of them is VT binary translation [INDISTINCT]?
>> GERTZFIELD: You want to repeat yourself?
>> Yes, thanks.
We're actually using [INDISTINCT] kinds of virtualization technologies.
One of them is VT binary translation that Ben described earlier, which is effectively
just a time compiler.
We compile--we take X36 code and we write it to X36 code that is safe to run on the
host.
That's one technique.
The other one is VT or a--it's called also SVM on AMG processors which is not ready [INDISTINCT]
but just mentioning for completeness.
And the third one is power of virtualization which is the approach that the Zen folks have
taken where you effectively rewrite your OS so that it doesn't use the non-neutralizer
but instructions of the X36.
The difference between the VMware and the competition in that space is that VMware has
the free technologies.
We do not focus on just one, and we can also switch dynamically while you are--we're executing
the VM between these [INDISTINCT] of technologies.
So we always get the one that's the best for the workload that we are running depending
on what we are running, we adapt.
And that gives us a lot of flexibility.
And we usually don't mention that a lot in our documents because to us it's an implementation
detail.
What we are trying to do is run the VMS files as possible.
That's what the customers care about.
>> I was just wondering, in a situation like this for example, what do you do with files
that you want to share between the different virtual machines?
>> GERTZFIELD: So the question is, what do you do with files that you don't share between
the virtual machines?
>> That you--well, that you do want to share or--I mean, how do you control that?
>> GERTZFIELD: There's a couple of different technologies.
So, we explicitly have the user opt in if they want to share, for example, their home
directory or their documents directory.
You can create shared folders one by one and specifically share them.
So, a good example is--let's see if I can do it here.
So, here's the virtual machine.
Here's the VMware window.
And I can actually pull up the settings for this guy.
And you can actually add shared folders on the fly.
So right now, I have a shared folder that maps my home directory then read only, but
I can actually make more shared folders on the fly, you know, on the fly or manually
that actually share explicit more stuff.
You can also--there's nothing stopping you from doing what you do with the physical machine
and using technologies like SMB, NFS, or AFP, it actually share your files back and forth.
And, you know, each--the nice thing about shared folder is that they don't require any
network set up.
The nice thing about things like SMB and NFS is they're really tuned and they, you know,
Windows does SMB really, really well.
And so, if you want to do things like, you know, really heavy workloads, you know, you
can use network files systems as well.
>> Best case, what kind of overhead that is introduced by virtualizing?
>> GERTZFIELD: So, what kind of overhead is introduced by virtualizing?
It depends very heavily in the workload.
With today's technology is, what you're going to find is CPU intensive workloads very, very
fast.
You're not going to have very much overhead at all.
So things like compiling or number crunching, work really well.
When you start getting into IO heavy workload, you know, lots of disc network, those kind
of things, there's more overhead because the cost of those is often, you know, all the
context switching copies that you have to make them happen.
So, until you get--and that's really an interesting point because we're actually starting to see
virtualized IO hardware supports.
So you're starting to see more and more things like fiber channel on the server side start
to be aware of virtualization such that we can actually start offloading some of the
work of IO to the hardware because today, you know, discs network and what not, that's
all emulated in user space.
We try to accelerate it by putting some of the work into the kernel, but there's only
so much you can do.
It's not as fast as talking to the hardware.
So--but overall, I mean, you know, things like, you know, I can--I can go into my virtual
machine right here, open up a folder and the performance is really good, I think.
You know, I mean, it's pretty close to native.
>> Well, I guess I was asking more from a server perspective.
This is not necessarily from a desktop becauseů >> GERTZFIELD: From a server perspective,
it's pretty ideal unless you're doing really heavy IO bound workloads.
So, if you're doing things like, you know, web, you know, web services, you know, lot's
of things that stay in cache, it's not that bad.
But if you're doing, you know, heavy disc, you know, like a file server or something,
you may see not see as much gain.
>> Okay.
>> GERTZFIELD: Thanks.
>> What's the plan on multiple snapshots?
>> GERTZFIELD: Multiple snapshots, so you're saying when are they coming?
>> Yeah, when are they coming?
> GERTZFIELD: So, multiple snap shots.
So, the VMware platform supports something called snapshots.
When you have virtualized hardware, you don't actually--you can do some things you can't
do with physical hardware.
You can just think called snapshots where the entire state of the machine, devices,
memory, CPU is frozen in time and you can keep going forward form that point on.
At any point, you can decide, you know what?
I'm going to go back to that point of my snapshot.
It's kind of like TVO for virtual machines.
So, I'll show you.
I don't know how long will it take here.
I actually read--it might take a little while.
Snapshots basically let you, you know, just go back to the exact state.
So if you want to test out some new service pack for Windows, I know service pack 3 is
about to come out for XP for example, you can take a snapshot, install it, if it totally
trashes your software, you just go back to the previous snapshot.
The question I was asking, you know, what about multiple snapshots?
So, in VMware workstation, there's a feature called multiple snapshots that gives you an
entire history in a tree form where you can have, you know, one snapshot that branches
out into three possible different scenarios.
Maybe install application version one, two, and three all separately in separate snapshots,
you want to kind of toggle between them.
The abilities in the platform of the VMware fusion today, and we just didn't have time
to write the user interface for it.
So, we just have--we haven't announced when the actual user interface for that is coming
out, but it's pretty--it's a pretty logical next step.
The one thing that we want to do with virtual snapshots on the Mac specifically though,
on Linux you have this giant tree and anybody who's ever used a tree interface in consumer
software knows the consumers are completely bewildered by it.
They don't want to have to navigate through branches and, you know, figure out a parent-child
relationship.
Any computer science geeks, we know trees.
We eat, breath, and sleep trees, but consumers don't think in terms of trees.
They don't know what pointers are or, you know, red black trees or [INDISTINCT].
So, we want to come out with a better metaphor.
Some of the ones we've been talking about, you know, are pretty, pretty novel.
So I think you guys were like, overcoming up with.
So I love to answer more questions about fusion, Mac, go ahead.
>> From a virtualizing hardware, I don't understand how unity would work.
How would you tell something is window versus something that's just artifact on screen?
>> GERTZFIELD: So the question is, you know, how does unity actually tell at the hardware
level, what is a window, what isn't?
And that's the trick; it's not done at the hardware level.
So, I don't know how much I can talk about the internals, but it's basically all done
inside the guest.
So, inside Windows, we actually have a process that knows when windows are placed, shaped,
or moved.
And we echo that on screen with physical--well, physical "coco" windows that, you know, refresh
themselves with the contents of the virtual machine.
So, you know, if I run things like, Windows media player is a good example, as a perfect
example for unity, because its really--it's a funky, funky window.
So here I am in my single window, I'll go into unity, and here's media player slowly
trying to connect to the internet and failing, here it goes.
All right, so you can see this is like a crazy shaped window here, check out the edges here.
So we actually have--I don't know if this would work on the projector, we'll see, oh
my God it does.
You can actually see we went to the trouble of making the shadow actually curve as the
window curves.
There's a lot of love here.
I have to tell you.
So even funky shaped windows like this work, and the speed is actually really good.
So I can do things like play some Beethoven and, you know, the video speed is actually
pretty good.
So we've done--we've done a lot of work to, you know, really transparently integrate the
applications with the host.
I mean, you know, that's--that's pretty if--that's pretty much as obvious that I'd like.
Okay, let's get some Beethoven.
It's pretty cool.
There was one--there's another question?
>> At book talks, they typically hand out a few copies of the book at the end, are you
going to be handing out VMware fusion copies?
Because I really miss BioShock.
>> Come talk to me later.
>> So I got my copy the other dayů >> Thank you.
>> ůbut I have a question.
I haven't figured out everything.
So if I'm running multiple--multiple OSS, multiple guest, is there a way to [INDISTINCT]?
As to one guess more CPU and, you know, resources from the--from the Mac OS versus the others
becauseů?
>> So from a resource point of view, are you talking about CPU, memory, disk?
Because there's also two different resources that you would want to purchase.
>> Right.
Just CPU, you know, if you [INDISTINCT] takes up like, you know, half my, you know, CPU
and I'm thinking "Well," you know, "I just want to swallow it down completely," you know,
"by 115 % or something so thatů" >> On the server products, we do have the
capability.
We can partition, you know, you can have a physical machine that has four [INDISTINCT],
whatever--as many processes as you want, and you can partition off the amount of CPU.
We didn't put that in fusion because it's not really consumer oriented feature, but
from a server perspective, it makes a lot of sense and we did do that.
We just--we just by the way, [INDISTINCT] our original VMware head, he's awesome.
>> There is another reason why we don't do CPU partitioning on the Mac is because again,
you know, Apple provides APIs to sweet Apple applications, and they don't provide what
they don't need and there is actually no way to do CPU affinity on Mac OS whether from
[INDISTINCT] or form the kernel--from a kernel extension.
>> Thanks.
>> Can we set the VMX priority?
>> The question is, can we set the VMX priority?
We can set the priority of the--of the threads inside the VMX.
We didn't expose that to the user.
Amit might know more about what affect that might have and we can push the thread priority
up and down programmatically.
So we need--from that point of view, you know, we could come up with some sort of interface,
but we haven't done that yet.
>> [INDISTINCT] >> Sorry?
>> Do not [INDISTINCT] >> Yes.
So, Amit's saying basically, you know, setting thread priority isn't a knob that really make
sense for the end user because the gain--the gain or the, what's the opposite of gain?
The gain to the user, the performance characteristics aren't going to change that much by change
just the thread priority.
Any more questions on VMware fusion for Mac, the development cycle orů?
So one thing I wanted to bring up was, one of the really cool features of the VMware
fusion that I haven't demonstrated here is something on the inside.
We support for--even OSS that are still 32 bit, you can run 64 bit operating system as
a guest.
So, if you need to do testing of XP64 bit or Linux 64 bit, you can actually run them
on your Mac book pro with core two duo or your Mac pro with Xeon processors.
And even though the OSS itself is pretty much strictly 32 bit and the kernel is strictly
32 bit, even in Leopard, that's not [INDISTINCT] anymore, right?
That's public?
It's out now, so I don't have--I don't have to pretend.
The 64 bit [INDISTINCT] runs really well and on top of that, we also support virtual SMP.
So if the host has multiple processors, you can actually give the guest multiple virtual
processors and it will actually--inside, you know--you know, you can write activity monitor
in windows and see the multiple processors, you know, the actual load graphs on each.
It's actually pretty cool.
And that's really good for CPU bound things, like compiling and number crunching.
That's a really cool feature that we put in there.
Any more questions on fusion?
>> [INDISTINCT] >> Can you hear me there?
>> I can hear you, yes.
>> Okay.
I was wondering what the story was with Mac OS as a guest operating system.
>> Mac OS as a guest.
So, about 50 minutes ago, we talked about it a little bit.
Technically, it's very doable.
VMware, you know, doesn't sanction piracy at all.
And one of the big--the big hoax--hang ups has been licensing.
Mac OS X is not licensed to run on anything but physical Apple hardware.
We hope that the situation will change.
And--but technologically there's not a lot of barriers.
Here's [INDISTINCT].
>> There are few differences between the Mac hardware and the PC hardware.
One of them is the Mac uses high performance timer device called HPET and that is not usually
standout on normal PCs.
So we have to neutralize new hardware.
Another piece of hardware that might be useful is the securing--what they call the securing
device which I Amit told us is not a--is not a TPN but--so essentially it means more work,
right?
We have to emulate a different kind of virtual machine.
One was [INDISTINCT] virtual hardware, but it's a--it's a matter of time and implementing
that.
There is no--nothing--there is no technical thing that prevents it from being done.
It must be a legal [INDISTINCT] and--and putting resources on it.
>> But I will mention one thing and that is, initially we met with some resistance talking
about this because there are--not created by VMware, but hackers have actually used
VMware's disc format as a popular way of distributing hacked copies of OS X and, you know, while
that's it, you know, that's a pity that they chose the VMware because, you know, we don't
condone piracy or anything, but people have started doing this thing called Hacking Tosh
where they distributes copies of VMware running--OS X running in VMware virtual machines for Dell
or Compaq that have been hacked to smithereens to remove all Apple's hardware protection.
>> Another difference also that most PCs today boot way what's called a Vios and Mac's boot
was something called EFI, and there are ways to reconcile both but again, its more--more
things to implement.
>> Right.
Hope that answered your question.
That's kind of cool.
It's like magic voice on Mr. [INDISTINCT] Theater.
Do we have any other questions from the other cameras?
I see a bunch over there.
That's kind of cool.
I've never seen that before.
All right, well its 2 O'clock.
Thank you guys very much for attending my talk.
I appreciate it very much.