Guest startup and vMotion

I completed an experiment on ESXi 4.0 to confirm what many people have known about guest startup and vmotion since vsphere 3.x which is that the two features don’t work together.

Guest A set to 1 on host X
Guest B set to 1 on host Y
Migrate B from Y to X
B appears in “Any Order”
migrate B back to to Y from X
B appears in “Any Order”

It seems the startup feature is host based and doesn’t know what to do if a guest arrives at or leaves. I will do a bit of digging and see where the startup data is stored: probably on the host somewhere (as opposed to in the guest config).

I think to provide a solution where all the guests in a given datacentre have a defined startup sequence will require a virtualcenter plug-in which stores that information in the database. It will need a “startup resolution” algorithm and a human interface to manage it. As far as I know, no-one as written such a thing but it could be worthwhile.

Vmotion meets JVMs

Last night I finished reading “Land of Dreams” by James P. Blaylock (book review blog in an alternate universe) and was just wondering whether to start reading another book but instead starting thinking about vmotion.

Wouldn’t it be great, I thought, if VMs or applications could be dynamically moved between different types of processor. Now, it’s pretty awesome that we can move VMs between the same type of processors at the moment, even if Vmware’s current vmotion technology is pretty fussy about processor types. But to move between different processors, architectures even, that would be a land of dreams.

Let’s not forget that a few years ago the prospect of moving a running OS from one machine to another was pretty far out. And that virtualisation is not a new concept in computing, the current virtualisation revolution is only an evolution of how to arrange layers of abstraction…that big onion that starts with transistors and ends up with Java or something.

So what would it take to move a running program or OS from one architecture to another? Well it would probably take another layer of abstraction, like say a virtual machine target, something that had an interpreted byte code language, something like a Java Virtual Machine. I believe the catchphrase of Java was (or is) write once, run anywhere? Well, if you had a program running on a JVM on an x86 architecture and the same JVM could run on a Sparc architecture, what’s to stop a piece of vmotion technology moving that application from one to the other?

Many things, probably, and I don’t know enough about JVMs (or vmotion) to even know what they would be. The question being, would they be show-stoppers which could not be overcome?

Anyway, seems like an interesting idea, which is partly the point of this blog even if a) no-one reads it and b) it makes me look silly. At the other extreme of course, if it is do-able, someone is probably trying or has done it already. And let me remember (showing my age again) the early 80’s when I was using the UCSD p-system. Which was an interpreted Pascal based virtual machine designed to run on many different micro-processors (booting from floppy disk). Java, new?

Found a new book to read “Shogun”. I wonder what ideas might come out of that?