Want to win a PS4? Go Premium and enter to win our High-Tech Treats giveaway. Enter to Win

x
?
Solved

vmware common mistakes and horror stories

Posted on 2014-02-02
4
Medium Priority
?
397 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 124

Accepted Solution

by:
Andrew Hancock (VMware vExpert / EE MVE^2) earned 668 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 668 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 664 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

Industry Leaders: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

Question has a verified solution.

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

The following article is comprised of the pearls we have garnered deploying virtualization solutions since Virtual Server 2005 and subsequent 2008 RTM+ Hyper-V in standalone and clustered environments.
In this article, I will show you HOW TO: Install VMware Tools for Windows on a VMware Windows virtual machine on a VMware vSphere Hypervisor 6.5 (ESXi 6.5) Host Server, using the VMware Host Client. The virtual machine has Windows Server 2016 instal…
This Micro Tutorial steps you through the configuration steps to configure your ESXi host Management Network settings and test the management network, ensure the host is recognized by the DNS Server, configure a new password, and the troubleshooting…
This video shows you how to use a vSphere client to connect to your ESX host as the root user. Demonstrates the basic connection of bypassing certification set up. Demonstrates how to access the traditional view to begin managing your virtual mac…

618 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