• Skip to primary navigation
  • Skip to main content
  • Skip to primary sidebar

Yellow Bricks

by Duncan Epping

  • Home
  • Unexplored Territory Podcast
  • HA Deepdive
  • ESXTOP
  • Stickers/Shirts
  • Privacy Policy
  • About
  • Show Search
Hide Search

Howto

VI:OPS – Automating Network Setting Changes and DNS Updates on Recovery Site Using SRM

Duncan Epping · Apr 29, 2009 ·

I just received an email about an excellent article on VI:OPS. The article is titled “Automating Network Setting Changes and DNS Updates on Recovery Site Using VMware vCenter Site Recovery Manager“. It includes a PDF file which contains a description for configuring automatic IP-Changes but also includes batch files for DNS updates.

When performing site failover, IT administrators are often faced with challenges to deal with disparate networks on the recovery site:

  • Network properties of virtual machines need to be customized according to the network specification of the recovery site.
  • Domain Name Server (DNS) records pertaining to these virtual machines need to be updated.

VMware® vCenter Site Recovery Manager (SRM) enables customers to design automated recovery plans that incorporate all these necessary network property changes, relieving them of the repetitive and error-prone manual tasks.

This paper shows the mechanisms that SRM customers can use in order to automate these tasks related to network related changes.

SRM: Automatically rename your datastore back

Duncan Epping · Apr 18, 2009 ·

When doing a failover with SRM your VMFS Datastores get labeled with a “snap-xxxxxxx-name” because they’ve been resignatured. Mike Laverick gave this tip on the VMTN forum which enables you to automatically rename your datastores to it’s original name again:

Edit the vmware-dr.xml file in the C:\Program Files\Site Recovery Manager\Config directory and look for a line that reads:

  • <fixRecoveredDatastoreNames>false</fixRecoveredDatastoreNames>

Change it to:

  • <fixRecoveredDatastoreNames>true</fixRecoveredDatastoreNames>

The Basics: Moving hosts from one vCenter server to the other

Duncan Epping · Apr 17, 2009 ·

It seems to be a question that often pops up on the VMTN forum, how can I move my ESX hosts to my freshly installed vCenter server? The answer is actually pretty simple:

  1. Just to be on the save side, set DRS to manual and disable HA on the “old” vCenter server / cluster
  2. Right click the ESX host and select “Disconnect”
  3. Go to the new vCenter server and add the host

It’s as simple as that. You don’t even need to shutdown your VMs.
Keep in mind though that you will lose your folder structure as well. (Thanks Joop)

Pre-installing the vCenter agent?!

Duncan Epping · Apr 2, 2009 ·

You might wonder why you would want to pre-install the vCenter agent on an ESX box? Well if you have several remote offices which need to be connected to a central vCenter Server it will take a while before these agents are pushed and installed. Especially if the connection between these sites isn’t as fast as most of us are used to at home. (I’m talking 128KB here for instance…) One of my colleagues, as mentioned in a previous article, is doing a major roll out of ESX. With their current bandwidth adding an ESX server to the central vCenter Server took over 20 minutes. With the vCenter agent pre-installed this was cut down to only 2 minutes. That will save you a lot of time when you need to do over 200 hosts…

  • On the vCenter Server, look for the following files in C:\Program Files\VMware\Infrastructure\VirtualCenter Server\upgrade
    vpx-upgrade-esx-7-linux-104215
    vpx-upgrade-esx-7-linux-104215.sig
  • copy the files to the ESX host and run the following commands:
    sh vpx-upgrade-esx-7-linux-104215
    service mgmt-vmware restart
  • wait 5 min…

Managing iSCSI startup with Lefthand and their VSA

Duncan Epping · Mar 30, 2009 ·

Do you have a LeftHand Networks VSA or are you using LeftHand’s VSA for demoing purposes?  Would you like your ESX to shutdown faster, and in fact when it starts up to have the VSA started, and then have the VM’s held on the VSA to be automatically started?

If you have a VSA now, while it may auto start, the VM’s on it will not.  Plus, your ESX host shutdown will take longer than normal.  All of this can be addressed by a great script that LeftHand’s Product Manager Adam C. has posted on the LeftHand Community forums.  Find out more at  http://vsaforum.lefthandnetworks.com/Topic244-9-1.aspx .

Source: Email newsletter, Michael White – Specialist SE.

  • « Go to Previous Page
  • Page 1
  • Interim pages omitted …
  • Page 3
  • Page 4
  • Page 5
  • Page 6
  • Page 7
  • Interim pages omitted …
  • Page 13
  • Go to Next Page »

Primary Sidebar

About the Author

Duncan Epping is a Chief Technologist and Distinguished Engineering Architect at Broadcom. Besides writing on Yellow-Bricks, Duncan is the co-author of the vSAN Deep Dive and the vSphere Clustering Deep Dive book series. Duncan is also the host of the Unexplored Territory Podcast.

Follow Us

  • X
  • Spotify
  • RSS Feed
  • LinkedIn

Recommended Book(s)

Advertisements




Copyright Yellow-Bricks.com © 2025 · Log in