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/
Search This Blog
Wednesday, 18 July 2012
Wednesday, 11 July 2012
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 1st
Delta disk is made read only and a 2nd delta disk is created which
all changes are written to.
The 2nd delta disk is dependent on the 1st
delta disk and the 1st 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.
Subscribe to:
Posts (Atom)