curious: VirtualCenter as a Virtual Machine

[brugh]

this seems to be fully supported by VMware nowadays according to the whitepaper at http://www.vmware.com/vmtn/resources/798. but there are some catches that this whitepaper doesn't mention.

the problem arises when you connect to the VC with rdp and start the VIclient on there. when you accidentally click on the console button it locks up. now if that was all it wouldn't be that bad since this is to be expected.

but when this happens, the whole network stack of the VC goes down. it somehow repairs itself (???) and after several minutes a new rdp session can be reestablished. and even that wouldn't be the biggest issue.

the biggest issue is that when VC goes into a consoleloop, HA kicks in and orfans the ESX server that the VC is running on. The ESX server goes down, VM's get started on another server and the whole environment gets mucked up. only after 10 minute when DRS did it's job do thing normalize a bit again.

this whole concept of VC in a VM is a nice idea and if you don't have a physical management server where stuff like commandvieweva is running on to install it on, making it virtual has several nice advantages. but having it killed like this with a wrong click in the interface for me makes it not worth the trouble and i'd invest the 1200,- for a dl320 for a physical box.

does anybody recognize these problems or know how to avoid them? this way i don't think vmware should support it! it's too easy to mess things up.

[Texiwill]

Hello,

I am not sure why you would want to connect to the VC server using RDP except for maintenance. I would setup a secondary VM just to use the VIC. That way the VC server is segragated somewhat.

As for VC failing like that, never experienced anything quite so drastic.

Best regards,

Edward

[esiebert7625]

If you have support you might want to contact them about that. Are you using the newly released RDP6 client or the old one. You might try the older one or installing the latest RDP6 update. As Ed mentioned you really will never need to RDP into the server and use the VI Client. I always run my clients on other systems and if you do need to get into the server you can use the VI remote console.

[Thorsten_Schnei]

I'm also connecting via RDP to the server running Virtual Center as the new VIC is very slow over WAN links.

I never experienced the problems you described. I can open remote console and perform all the tasks as I could do with a local client.

I'm using VC 2.0.1 Patch 2 on a Windows Server 2003 SP1. All 8 hosts are running ESX 3.0.1. Standard Edition.

Thorsten

[esiebert7625]

Yeah unfortunately that is a problem, the VI client is painfully slow over WAN even if it is fairly high speed. I use mine at home with DSL/VPN and the performance is bad, I usually RDP in to my desktop to use it instead.

[brugh]

it's not a problem of VI clients connecting to the VC. the problem is running the VI client on the VC itself while the VC is a VM. it looks like when you rdp to it, wether it's a console session or not doesn't seem to make a difference, opening the console of the VC in the VI client locks the whole thing up. and even when HA officially doesn't need VC to function, it does use VC for something since when the VM running VC locks up like that, the whole ESX host goes in isolation mode and shuts everything down. quite unacceptable if you ask me!

[Thorsten_Schnei]

Hi,

I was just able to reproduce this behaviour. But it happens only while connecting to the console of the VM running Virtual Center. I can open all other consoles without any issues.

Must be some kind of infinitive loop...

Thorsten

[Cloneranger]

Really?

I found my VIC awesome over VPN,

Just like being there

What VPN technology do you use?

[esiebert7625]

We use Cisco's VPN hardware/software

[Cloneranger]

Odd it should be slow then,

We use Citrix Secure Access Gateways,

VIC runs like a dream over it,

[Cloneranger]

That sounds odd,

I have had no issues with VC as a VM,

It can even vMotion/DRS itself without a hang up,

To me buying a vulnerable phyical server to run VC on, when I have all this redundancy built into my VI3 environment goes against the grain,

I am Virtual > Physical all the way.

[brugh]

i'm glad that somebody had similar experiences connecting with VIC inside[/i] VC console to the VMconsole that VC runs on. i'm sure it's a invite loop problem but if that were it i could live with it. just that when VC looses it and HA kicks in and orphans the whole ESX server is what bugs me. this cannot be acceptable in a production environment. nobody seen that happen with a virtual VC? if not i'll have to go look for other parameters that makes it behave this way. really big issue..

[fridge]

I am running VC as a guest w/o any problems. Depending on what else I am doing I run the VIC on my VMware Workstation guest at home that is connected to my network over a Cisco VPN or I us a RDP session from that Workstation guest to my PC at work where I run the VIC. They both work fine, but I do notice that the VIC connecting over the VPN is a little bit slower.

My question is why are you running the VIC on your VC console? Don't you have a different guest or physical desktop you can RDP into for that? I look at that kind of like browsing the internet from the console of one of my application webservers; I do workstation tasks from a PC and let the servers do their thing. It's not worth the risk of causing disruption to the server's primary task.

[VMTINC]

brugh - I'd be interested in knowing your config for the VC VM? UP or MP? Amount of RAM? What OS? Database local or remote? License Server local or remote?

Also, are you having issues connecting to ANY VMs console or just the console of the VC VM?

If your VC VM is Win2003 - does it happen if you RDP into the console (mstsc /v:SERVERNAME /console)?

[dkfbp]

We have published VI as an application on our Citrix servers. Normally I am running the VI client locally on my own machine, but when I am on a bad connection I simply run it on Citrix.

[brugh]

it's a one cpu, 2gb ram, windows 2003 R2 standard edition VM with sql2005 and license services locally installed. it's a freshly baked VM, not a migrated one.

and it's only with the connection to the console of the VC VM. the other VM consoles work fine. this happens always wether we RDP to the server using /console or not.

i agree that using VIC on the VC is not ideal and i have my own client installed on my laptop. but some customers i go to don't have elaborate management rules and administrators do browse on production servers and do log on the VC to use the VIC. i normally push for a management server so that they at least dont log on locally on any DC or Exchange server but unfortunately that's usually also the server that VC ends up on. easily fixed ofcourse but not if you have to mind the m$ licenses..

[brugh]

ok, seems the problem's been solved. seems there were routing issues to and from the esx servers to VI clients. stupid network guys :smileywink: once that was fixed there were no more serious issues. still odd it can go wrong like that

[VMTINC]

Also - did you create this as a VM or did you P2V it?

[dpomeroy]

We run VC as a VM and have been happy with the performance and havent seen any problems. We don not use the VI Client on the actual VC VM. I wouldnt ditch the setup just because you found one bug that is easy to work around.

I suggest the best course of action is to open an SR with VMware to make sure they are aware of the problem and then do not use the VI Client on your VC VM.