Setting up a new DHCP server

Hi all,

I was setting up some new domain controlers with DHCP and found that the customer had a lot of reservations. Rather than having to retype everything i found this great link to export the scope and import it back into the new server. I tested it from 2003 to 2008 and it worked perfectly.

http://koolbeans.wordpress.com/2007/07/31/howto-import-and-export-dhcp-reservations-in-server-2003/

The dangers of VMware snapshots.

I come across a lot of VMware environments where people have been miss-informed about the use of VMware snapshots and can later on, have a large detrimental effect on storage and performance of their live environments.

First of all, let’s define what a snapshot is. Wikipedia states it to be “Snapshot (computer storage), a set of computer files and directories kept in storage as they were sometime in the past”, or as a lot of people say “a point in time copy”. 

The above has lead people to believe the VMware snapshots can be used as backups or that it’s fine to leave several snapshots on a VM for its entire life, but unfortunately this is NOT how they function. 

VMware snapshots are Delta’s not a true snapshot, when initiated the original virtual disk (vmdk) is locked and made read only and a new delta disk is created which all future changes are made. If you were to then snapshot this again, the original disk is still locked, the 1^st Delta disk is made read only and a 2^nd delta disk is created which all changes are written to.

The 2^nd delta disk is dependent on the 1^st delta disk and the 1^st delta disk is dependent on the original virtual disk of the VM and the more times you snapshot the VM, the more the dependency tree expands.

I have seen cases where by the original disk has been provisioned of 60GB on storage and then a further six 60GB delta drives had been created (all of various sizes on the storage) going back several years, all adding a massive overhead on storage. This also highlights why you cannot use VMware snapshots as backups due to the Delta tree dependency and that they are NOT point in time copies.

There is a well-known case where someone was miss-informed that VMware snapshots can be used as a backup and proceeded to snapshot their main mail system. Several weeks later their storage was reporting that it was nearly out of space and performance was really slow. They hired a VMware expert to investigate who found a 800gb Delta file and due to the amount of data that would be lost had no other options but to commit this snapshot to the VM, which subsequently took nearly a week to roll into the original disk and had a major impact on system performance.

Please use VMware snapshot responsibly; if you need to test a patch, clone the VM, put it on an internal test network in VMware (no physical NIC), patch the clone and test. If the test is successful you can then snapshot the original machine out of hours and patch knowing with confidence that the patch works with your application; after the install commit the snapshot immediately. The only reason I add the snapshot to patching the original VM is if something happens during the install nothing else. Other than this and its use with backup technologies (like backup exec, etc) which snapshot the VM to take a backup and then immediately commit the changes, there is no real reason they should be used.

Thanks for reading, and any comments or questions please feel free to ask.

Cisco UCS / Nexus

I'm just currently running through the Cisco DCUCI certification process, and are really impressed with concepts and business benefits for the high server farm / data centre operations user. Consolidating down the number of connections per rack, saving power on the switch and SAN elements, allowing full data centres to utilise this extra power and space to add extra compute power without the need to expand the physical building or relocate into another building which can be extremely costly.

Check out the Cisco Nexus platform and their UCS (not unified communications server :-)! ) platform.

VNXe NDMP backup Issue

Hi everyone,

I’ve been working with a client installing a VNXe for them along with VMware with Veeam backing up the VMware and Backup exec backing up the file shares on the VNXe and archiving backups to tape.

The setup is a pretty standard one with cisco switches and HP servers, but we ran into a problem when backing up the file shares on the VNXe (using NDMP) which backup exec, where the Backup Exec server would randomly skip a share or two one evening, and then skip a completely different one the following evening. The error that we were getting back was that the VNXe either could not be contacted or that a connection was refused.

The setup of the server was a HP network team in active / active (giving 2 Gbps) and two ports teamed on the VNXe for CIFS. The issues was raised with EMC, and it transpires, that this problem is caused by the HP network team and as soon as this was changed to NFT (active / passive), then the problem went away.

If I get the opportunity, I would like to test this with an Intel network team so see if it is vendor specific, but certainly something that you all might encounter.

Thanks for reading.

vCenter Appliance extra NIC issue

Currently I’m working on a customer install where we are using the new vsphere 5.0 vcenter server appliance. As we were migrating an existing 3.5 environment to a new platform, we had to keep adding and removing servers in and out of vCenter due to the limitations of the appliance.

On one occasion we had to remove the new vCenter appliance from the inventory of one server and add it to the inventory of another. When this happened, the appliance found added a new NIC (eth1) and would not function as it said eth0 was not connected and the appliance is only configured to used eth0.

If you ever get this error, there is a simple fix.

Log onto the vCenter appliance (via the console) and log in as root, for the vCenter appliance the username is root and the password VMware. Edit the file (using vi) /etc/udev/rules.d/70-net-persistent-names.rules.

This file shows all the network interfaces and their associated MAC addresses. Simply remove the entry for eth0 and edit the line for eth1, renaming it to eth0. Save the file with the command :wq and restart the server using shutdown –r now.

Backing up iSCSI targets

One thing you will more than likly need to day when implementing a SAN is backup the content of the iSCSI targets. If you implement something like backup exec on windows, then windows will try and Automount the volumes which will then cause you no end of problems.

To prevent this, before connecting to the iSCSI targets, run the following from the command prompt to prevent this:

diskpart

automount disable

automount scrub

Network IP Error after P2V

Hi All,

Just a quick update to my Blog. For those of you that have VMware and have run Converter on a physical server that has had a static IP address before the Converter was run, you may get an error message saying that the IP Address is already in use when you try and assign the new virtual network adapter with the old IP address.

I personally create a batchfile which looks like this

"set devmgr_show_nonpresent_devices=1
DEVMGMT.MSC"

I then run this on the new virtual machine. This will enable non present devices to be shown in device manager, and then it will open device manager. If you then click View and Show hidden devices, this will show all the old hardware that was present when it was a physical server. Simply right click the old network adapter and uninstall it and this will remove the offending static IP address.

Hope this helps.

Andy