Solved

vmware common mistakes and horror stories

Posted on 2014-02-02
4
389 Views
Last Modified: 2014-02-11
if you do any sort of vmware healthchecks/audits for external organisations or even those you manage, are there any common virtualisation/vmware configuration or management mistakes organisations make, and any common horror stories on those mistakes that you could share (obviously keep the company name out).
0
Comment
Question by:pma111
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
4 Comments
 
LVL 120

Accepted Solution

by:
Andrew Hancock (VMware vExpert / EE MVE^2) earned 167 total points
ID: 39828206
1. Lack of IP Address management, and hence IP Address conflicts, and therefore the host server goes down.

2. Lack of Storage Management - datastores fill up and no VMs can be started.

3. Not checking VMs for Snapshots, and hence VMs fail.

4. Not checking that Backups run, or Test Restores.

5. Tripping over power cables in the Datacentre and pulling out power cables to Hosts or SAN.

6. Letting Staff e.g. cleaners into datacentres, which is a restricted area, and using a vacuum cleaner, and blowing the phase fuse, resulting in datacentre failure.

7. Not checking that DR Site circuits are complete for failover.

8. Not ensuring that fire detectors are regularly serviced, and hence a fire gets out of hand in the datacentre causing, Datacentre out of action.

9. Completing upgrades to Finance Baking Computers, and not testing the upgrade causing 3 days outage, and customers not able to access funds.

10. Completing upgrade to authentication system, and causing ATM/Debit Cards not to function.

11. Now generator of UPS available, and when the power lines were cut, by contractor, no customers able to make cellphone  calls, because servers were down, no DR site.
0
 
LVL 13

Assisted Solution

by:SagiEDoc
SagiEDoc earned 167 total points
ID: 39829420
1. Not tagging ALL VLAN's or tagging VLAN's that were not present thus causing VM's to lose connection to network after a migration.
2. Not specifying all iSCSI targets causing VM's to lose connection to storage.
3. VMware tools not kept up to date resulting in VM's performing badly.
4. Not paying attention when installing ESXi, resulting in the ESXi installation overwriting VM datastore - client did this three times before realizing the mistake.
5. Storage backup batter failed resulting in the storage cache being disabled - Very bad VM performance as a result.
0
 
LVL 28

Assisted Solution

by:jhyiesla
jhyiesla earned 166 total points
ID: 39829684
Improper use of snapshots.

I've found that a lot of people think that snaps are either a back up scheme or that you can take as many as they want and save them forever.  This is a sure way to get into trouble with VM performance and disk space usage.

In short, when you take a snap you are NOT making a copy of your running VM.. You are making your VMDK file (the file that is the VM) read-only and creating a delta file.  While the snap exists the delta file grows as it keeps track of all the changes that are happening to the VM since those changes can't be written into the VMDK file. When you are done with the snap you have two choices. One is to consolidate it into the VMDK file which in effect keeps everything that has been done on the VM since you took the snap. The delta file goes away and the VMDK file becomes R/W again. The other thing is if you created the snap before making some change and that change went wrong, you can revert to the original VMDK file which means that the delta file is deleted wihtOUT rolling the changes into the VMDK file, the VMDK file becomes R/W again and the VM goes back to it's state before you did the changes.

Unless you store your snaps elsewhere, you also need about as much free space on the drive as the delta file is big. In other words if you've let the delta file grow to 2 GB you will most likely need 2 GB of free space in order to consolidate it back into the VMDK file.
0
 
LVL 3

Author Comment

by:pma111
ID: 39829689
Good pointers, thanks
0

Featured Post

Free Tool: Port Scanner

Check which ports are open to the outside world. Helps make sure that your firewall rules are working as intended.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

HOW TO: Upload an ISO image to a VMware datastore for use with VMware vSphere Hypervisor 6.5 (ESXi 6.5) using the vSphere Host Client, and checking its MD5 checksum signature is correct.  It's a good idea to compare checksums, because many installat…
When rebooting a vCenters 6.0 and try to connect using vSphere Client we get this issue "Invalid URL: The hostname could not parsed." When we get this error we need to do some changes in the vCenter advanced settings to fix the issue.
Teach the user how to join ESXi hosts to Active Directory domains Open vSphere Client: Join ESXi host to AD domain: Verify ESXi computer account in AD: Configure permissions for domain user in ESXi: Test domain user login to ESXi host:
How to Install VMware Tools in Red Hat Enterprise Linux 6.4 (RHEL 6.4) Step-by-Step Tutorial

749 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question