Who's running VC as a VM in production

[MR-T]

I've always used a physical server for hosting my production VC but I'm starting to make moves towards a virtual machine.

My reason: I have 2 sites, I use SAN replication between sites. I have a Cisco global site selector in the middle which means even if my IP changes, the hostname will always be the same. My VC database is virtual anyway, so is the licence server, so why not go the whole hog?

Anyone else doing this?

We know it's supported so why wouldn't you?

[VirtualKenneth]

Same here, always deployed physical VC's and been testing with virtual VC's lately. I think it's rather a good solution in replication environment's.

Only thing that you need to take care of is manually starting the VC after a failover. I always do this via CLI but you can also do this by connecting to the web interface of ESX itself, register VC on there and give it the start command.

And you could get in the situation in where you need a temporary license server to initially start the VC (if the licensing service also resides on the VC) but this isn't a problem of course.

[sbeaver]

I have it running in production and we are using SDRF to replicate to our DR site and it is so easy to just turn on VC and go from there

[MR-T]

This is good stuff, we're actually using Enigmatec's h-pack to manage the failover, so it could be an automated solution.

I'm very keen on this.

[christianZ]

We have here a reserve VC (created with VMWare Converter) server as vm (the db is on separate server).

I tested it - it worked fine. Just one issue I saw was when you go in VC and want to see the console of this vm (simultan the rdp session to it is opened) the vm will be isolated:

http://www.vmware.com/community/thread.jspa?messageID=596961&#596961

[letoatrads]

I've been running VC in a VM since the first round of Beta.

Never had any issues with it in Beta, and since my first ESX flavor was 3.0, I didn't have the attachment to running a physical VC. I kind of went the 'eat your own dog-food approach'. I was telling my users this systems was fault tolerant enough to handle their boxes....I needed believe it myself.

Kind of went against the grain to have the management server for the farm in the farm itself, but I think this was just standard admin thinking. I never once encountered an issue from having the VC in a VM. One caveat I will mention, while we know it is supported, I have had to convince VMWare support of this 2x when on calls with them. You know, you open a ticket with VMWare to satisfy management, then get your answer on VMTN in 10 minutes or so. Both times, the support tech immediately pointed to VC being in a VM as the issue ( this was during the fun that was upgrading VC from 2.0 to 2.0.1). I calmly asked they point me to the documentation that stated VC isn't supported in a VM, while I forwarded them an email from my VMWare SE stating it was. Added a couple of hours to their response time while they verified it was supported.

All in all, I have had great luck doing it this way, and have been running as such since a couple of weeks after the official 3.0 release, went through the upgrade cycles, and now have a ESX farm of 10 hosts running a variety of production and development boxes on there.

[GabbyIRL]

We are running VC 2.0.1 in production, without issue. However we have a separate 1.3.1 VC server and hosts, and we run the Virtual VC there, so that a problem on our 2.0.1/3.0.1 farm does not cause loss of VC. So our VC server is running on a 2.5.3 host, but managing 3.0.1 hosts. I guess running the VC on a 3.0.1 host will give you High Availability if it's licensed, and the only way to do that with pjysical servers would be clustering.

[dpomeroy]

We are also running VC in a VM and have been since the betas. So far I have not had any problems related to VC being a VM and have even vmotioned it a bunch of times to do maintenance. In our case the DB is a on a physical SQL cluster.

[MR-T]

Thanks again guys, I'm putting the case together now.

The VMware official recommendation is still physical, but... It does depend on who you speak with. I was chatting to a VMware SE who's of the opinion that provided you setup HA, why would you even consider physical.

[canadait]

Isn't this the offical recommendation?

http://www.vmware.com/vmtn/resources/798

[MR-T]

This is simply saying it's supported, not the recommendation.

I wish it was the recommended way of doing things, it would make life easier.

I attended a DR session with VMware the other week and again the presenter stated the VC is recommended to be physical even though they support a vm.

[sbeaver · Accepted solution]

I just did a DR drill at our remote site and rescan the luns, start VC and then start everything else. Took me about an hour to show management what they wanted to see.

[paulo_meireles]

And you could get in the situation in where you need a temporary license server to initially start the VC (if the licensing service also resides on the VC) but this isn't a problem of course.

We have also been running VC in a VM. Never ran it in a physical server, so I can't compare them...

We had to shut down one of our EVAs some months ago and yes, we had troubles restarting VC. What we now intend to do is to copy VC to a VMware Server machine (with VMware Converter) in case of emergency. AFAIK, simple access to VMFS requires no licensing, so it should work.

Paulo

[juchestyle]

Hey Mr-T,

The other day I was going to change out a nic in one of our hosts so I put the host in maintenance mode so it would vmotion off the vm's. Our VC was on that host and it froze up during the vmotion, and took us a few minutes to sort everything out. I am thinking that in the future I will manually vmotion VC to another host if I need to bring one down.

This could have been an isolated incident, but it is easy to vmotion VC real quick.

Respectfully,

[letoatrads]

Yeah, I have had the same issue using maintenance mode when the VC is on the host you want to put in maintenance. Guess I didn't think about it since the first time it happened I just started Vmotioning the VC first, then putting the host in maintenance mode.

Guess that might be something to file an SR on if I can reproduce it.