Update Manager is useless with VC running in a VM

[shurik]

May be I am missing something but it looks like Update manager is pretty useless when VirtualCenter/UpdateManager is running in a VM. You cant use it to update host because it requires host to be in maintenence mode and you can't shutdown VM - UpdateManager will die.

Even for Guest OS update it does not work with VirtualCenter/UpdateManager running in VM - I tried it couple times it hang VM where VC is running - I could not shut it down (not guest os not VM itseelf. Had to restart entire host. After that guest OS got corrupted and would not start. Thankfully I had snapshot created.

Isn't VC/UM running in VM a supported configuration? Why couldn't update manager be smarter - deposite updates somewhere to be installed on host restart if they can not be installed on the fly?

May be I am missing something (I do not hav vmotion and use local SAS storage so I can not easily move VMs from host to host to run updates) your suggestions are greatly appreciated

Thanks,

Alex

[shurik]

No disagreement here. I actually was torn between physical host and a VM for VC, License server, UM etc clearly recognizing all the potential issues a circular dependency would cause (licensing, VC, updates).

We are a small software developmen company and need quite a few servers for various things. We are trying to reduce our dozen of servers to a smaller number. For a 3 host install base having a separate computer for VC is not resource efficient - more maintenance, more heat in our computer room, more space in our racks. Welcome to small business world :-).

I have to say VMware took care of licensing issue with VM hosted license server nicely just by caching the licenses on ESX hosts. Same can be done with UM - have it deposit updates and metadata on ESX host and let the host take it from there with optional communication back to VC (ie send logs and errors back to VC).

As for single point of failure, how vm running on a spanking new highly redundant server is less reliable (assuming VMWare is rock solid) than VC running on oldder dedicated hardware. Not to say recover VC from full VM backup is much quicker than recover from physical host crash. Not to mention that bigger shops could HA VC VMs.

That said, personally, I would probably still go with a hardware solution if I had over 10 hosts to run

Thank you,

Alex

[spex]

We are very happy running VC within a vm (since about 1,5 years) with sql db outside in a sql cluster (used for multiple applications).

And I share the opinion with http://communities.vmware.com/click.jspa?searchID=1219951&objectType=2&objectID=822572 (eat your own dogfood).

If we can not handle such a little application like VC in our prefered environment, who trusts you?

At the moment update manager is realy a pain with virtualized VC but this is correctable.

Regards

Spex

[Cloneranger]

I dont see how its an 'all your eggs in one basket' thing,

Firstly my environment dosent depend on VC, its just a management tool, I the event of a VC server failure, the ESX hosts are as you know fully capable of running their respective VMs where they lay. I dont 'need' UM, DRS or vMotion capability in the short term if I get a VC server failure,

I can restore the server at my leisure,

I also dont see how the VC server being physical gives you any more resliance, you mention a power outage, but a physical box is just as suseptable to that or any other glich, I personally think VC is more resiliant on a VM in a cluster, so it can at least benefit from HA protection,

I have had a scenario whereby the host currently running the VC VM died, I was not effected in anyway.

Personally I think in some environments (like mine) you can go all virtual,

[mike_laspina]

My view of this is quite different. Imagine you are upgrading your 2.0.1 VC on a VM and all of the sudden BAM! the whole PRODUCTION farm start rebooting. You can't tell what going on because your management tool is foobar. The CIO is breathing down your neck...asking when it will be corrected and what happening so now your have to restore your VM without the management tools before you can even give him a report. Right about now you are thinking of other career options in our thankless IT world. How many other severs are not working? Will autostart work? Strange this did not happen in the lab.

Not a good architecture practice and thus it will never be VM'd on my farm. There are just to many reasons not to do this.

Unexpected Restarts of Virtual Machines on ESX Server 3.0.1 Might Occur When Upgrading to VirtualCenter 2.5 or When Adding ESX Server 3.0.1 to VirtualCenter 2.5 (KB 1003401)

Installing ESX Server Throws an "Anaconda Error" in the Partitioning Options Screen (KB 1003217)

Virtual Machine on RDM Shared Storage Becomes Invalid After Migration from ESX Server 2.5x to ESX Server 3.5 or ESX Server 3i (KB 1003092)

VMotion is Disabled after ESX Server Upgrade (KB 1003060)

[Cloneranger]

Sorry if I am missing something here, but I fail to see how the VC server being physical is going to somehow give you immunity from those issues you posted,

If your VC is going to go postal and randomly reboot your VMs after a 2.01 to 2.5 upgrade, it was going to anyway, physical or not,

I dont see how the VC server being a VM makes it more likely to fall prey to any particular issue, and if I believed that running virtual servers made my environment less stable I wouldnt run a single thing on VI3.

I go through this a lot with the anti-vm/vm is not for production/its ok for labs crowd (i am not painting you with that brush btw ), I say to them that if I thought that virtualizing ANY server somehow diminished it in ANY way, I would not use VMWare period.

[mike_laspina]

Hello,

Thanks for your responce.

I am definitely Pro VM. I have been for 25 Years. Well before The VMware product. I am not arguing that you and anyone else do not virtualize VC at all. In some cases it is OK. In an enterprise environment the management tool should not be subject to it's own managment policy. My example is not about the VM's dropping. It's about not having the tool available which is supposed to help you. The tool is now the subject of a failure of services for which it is intended to manage. It's a loop that should not exist.

It's about best practices.

Tell you what. Open a call ticket with VMWare an ask them if they would recommend or can fully support the original post's configuration detail.

And if they say yes. I will buy into it.

Ahh heck tell you what I'll call them myself. Bet's anyone?

[Cloneranger]

If VC server was somehow responsable for my virtual servers remaining functional I would agree with you,

But fact is that it is just a managment tool, VC server can blow up, disapear, implode whatever platform its on, but that wont effect the services delivered to my end-users,

My ESX servers arent suddenly going to freak out and shed their workloads because VC isnt there, even HA doesnt depend on it,

Nothing depends on it, VC is only there to monitor and change your infrustructure, its not in anyway integral to the infrustructures fuctionality,

'The tool is now the subject of a failure of services for which it is intended to manage. It's a loop that should not exist'

Saying this would mean maybe I should have a totally separate Nortel LAN to house my CISCO managment server, because in the event of a total CISCO network failure I would not be able to use my CISCO managment server, to manage my CISCO LAN.

[chandlm]

Nothing specific to the OP's configuration but I have been 'unofficially' told that not only is there no problem running it in a VM, but I have been told all of the positive reasons why it's a great idea (DRS, HA, etc...). Now to be fair my environment isn't that large (8 hosts currently, moving to about 16 in the next 6 months). We currently still have a VC 1.x physical server that is being decommissioned as part of the upgrade. I've been using physical VC servers for about 3 years and it wasn't an easy sell for me. So far we haven't had any issues (almost 1 year of being in a VM), it is sometimes a bit slow, but not unusable and I am the only one regularly accessing it anyway.

I can honestly say I've not had anyone tell me it isn't a good idea (officially or unofficially) for a while. Even when it was first supported I know I did hear that from VMware employees, but nothing lately and they seem to be embracing it now.

I really agree with the 'eat your own dog food' comment because when I have to go up the chain of management to get backing for migrating physicals from teams that are...hmmm...less than cooperative...I hate having to also explain why I needed physicals for my own environment. I might have to change my mind if my own environment got much larger though.

[mike_laspina]

Ok,

Cloneranger,

The pint's are on me. You win this one. VMware said they will support it up, down, left, right yada yada yada ... way I want to set it up. (To be proven of course) lol

They did not however provide any position on what configuration is a best practice (No backbone). It was like talking to a politician (Bloody annoying)

So I'll buy into it bud.

p.s. It would be more like you were running a VC in the cisco switch....lol ...you wouldn't realy use a Nortel would you?

Mike

[Cloneranger]

As I was saying they cant very well not support their own product on their own platform, and expect us to run far more important services like SQL and Exchange on the same platform,

Nah I wouldnt use a Nortel, just being flippant lol