Mike D’s Blog

Thanks for the kind words Mike, and yeh, Ricardo... get some real world experience then come back and talk. One of the domains at my place has been running only virtual DC's for over a year, supporting 10K users. Not a problem to date. And if you think time differences in the milliseconds will have any implications for AD replication or authentication in Windows you dont know what the hell you're talking about. I'm a bigger Windows fanboy than most, the difference is I actually know the platform.

Thanks, Rob, for backing me up there. I thought I was going crazy. Yes, those MS PR and MS fanboys are a little ridiculous at times. It's amazing how much FUD they try to spread.

Sounds like Ricardo is an over-hype-v fan or works for Microsoft PR and likes to try and shoot holes in Vmotion with ridiculous claims.

Does that also mean they don't support MS Clustering since they drop packets during a failover??????

Roger,

Do you mean you switched to SQL as the database for Symantec or as the database for VMware Virtual Center?

I am hoping this is subject to change by Symantec, we can hope.

I know that I had issues in VMware with Endpoint server until I used SQL as my database, as the CPU was pegged.

Roger Lund

http://rogerlunditblog.blogspot.com/

You can tell it's the holidays - everyone is highly excitable all of a sudden. Sure, I'll stop blogging about problems with ISV support. That will help no one. We need to have open discussions about problems with ISV support - even if it means we need some education on VMotion along the way.

Like you pointed out, VMotion will pause the processing on a VM. No data is lost. All of the memory and in-state transactions are 100% intact during this transition. The biggest thing that happens is the network stack stops responding for 1 second or less. That's well underneath any normal TCP Abort Connection timeouts in the network which means no in-flight data over the network is ever lost. This is normal for VMotion as well as live migration from any other vendor.

Time keeping in the VM and VMotion are pretty much unrelated. Yes, timekeeping can be an issue to tombstoning in certain applications. This is pretty well documented in several VMware KBs and whitepapers. And yes, if you're going from a very slow processor to a very fast one then this could add to the problem with the timekeeping (damn, tick-oriented time). However, that's about the only time VMotion is going to impact time keeping in an application.

"Go patch ESX. it allows priveledge escalation in VM's.
It's unsafe. this is also a good topic post."

I have no idea where that came from. If you care to explain then I'll be more than happy to post on that topic as well.

Not sure why I've done such an excellent job of ticking people off lately. I'll get back to writing and just hope that what I post next doesn't start another riot.

VMOTION DROPS NETWORK!
even if it is for a few milliseconds... IT STOPS.
the tcp/ip stack in the client is responsible to reconnect and provide the elusive "no downtime" that VMware tries to shove.

THE VIRTUAL MACHINE IS ALSO STOPPED...
see same comment above

and yes, Vmotion can be a problem to some apps.
Active Directory, databases...
mostly anything that uses tombstones and replication, because, guess what, the hosts have different clocks, even if it's only a few milliseconds.. it can send a transaction to lalaland.
and no, ntp does not solve it.

Go patch ESX. it allows priveledge escalation in VM's.
It's unsafe. this is also a good topic post.

You should stick to put out your knowledge on vmware and virtualization, it would make this blog get back to the reason i started reading it.

cheers!