Link to home
Start Free TrialLog in
Avatar of Paul Huxham
Paul HuxhamFlag for United Kingdom of Great Britain and Northern Ireland

asked on

How to remediate ESXi (v5) host on the end of VPN without shutting down guest VMs

I have a vCenter server installation with around 15 ESXi 5.5 hosts all located at different offices. I regularly remediate the hosts to keep them all up-to-date, using vCenter Update Manager.

However, one of the hosts is at a remote location connected by a VPN client which runs on a VM on that host.  When the VM running the VPN client is running it allows vCenter to talk to the host to perform all the usual vCenter functions, and this works perfectly well 24/7/365.  However, to remediate that host it normally has to shutdown or vMotion off all VMs so the host can enter maintenance mode.  If I shutdown the VM running the VPN client then vCenter Update Manager can no longer communicate with the host to complete the remediation.  It is a single host at the location so vMotion is not an option.

Is there any way I can remediate the host without shutting down the VPN client VM which needs to run on it for the remediation to complete?

Thanks
Avatar of Andrew Hancock (VMware vExpert PRO / EE Fellow/British Beekeeper)
Andrew Hancock (VMware vExpert PRO / EE Fellow/British Beekeeper)
Flag of United Kingdom of Great Britain and Northern Ireland image

Is it possible to use a physical client you can connect to, using Teamviwer etc
Avatar of Paul Huxham

ASKER

Not really.  There's one other physical server at that site, but that's on the LAN side at the remote site so also becomes inaccessible when the VPN client is down.
and not accessible via Teamviewer, and Internet, we use Teamviewer, as a fallback, because our VPN server is virtual!
No, once the VPN is down, everything on the LAN is isolated completely.  The VM running the VPN is also the firewall, so when it's down there's no access to anything (including the Internet), so TeamViewer isn't really an option.
So maybe time to consider a hardware VPN appliance.

if the host was down, how would you power it back up?
The host is located in a managed datacenter so we can get the local support to power-off/on as necessary but they have no access to what's running on the host.  Yes, time for a hardware VPN perhaps!
If you just need to update the host, it can be done using the Offline Package, SCP the offline package to the host, execute the commands on the SSH remote console, and reboot! (update done!).

If you want to use Update Manager, then you will need a hardware VPN, of different VPN end point, which is not on the Host you are updating.
Hi,
and if you go with the offline package as described by Andrew Hancock don't forget to enable your VM startup option on your esx host (select esx in vsphere client / config tab / software / vm startup options), in order for your vpn VM to automatically boot after your host boot.
Thanks Mr Tortur, but that's already set!
Ok. Then there is no other option than the one already given by Andrew Hancock.
Or add another esx, or set your vpn/firewall on a physical machine..
ASKER CERTIFIED SOLUTION
Avatar of Paul Huxham
Paul Huxham
Flag of United Kingdom of Great Britain and Northern Ireland image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
I've requested that this question be closed as follows:

Accepted answer: 0 points for huxham's comment #a40574770

for the following reason:

There isn't a solution to this problem, this summarizes the workarounds.
Solutions, have been provided, they may not be to your liking!
There are no solutions provided.  There are workarounds provided, but the question I asked is not achievable.  That's why I clearly summaries the workarounds in my final post (http://#a40574770) before I closed the question, for the benefit of anybody reading the thread at a later date.
There are no solutions provided.  There are workarounds provided, but the question I asked is not achievable.  That's why I clearly summaries the workarounds in my final post (http:#a40574770) before I closed the question, for the benefit of anybody reading the thread at a later date.