10 Biggies to Help Managers and Admins Avoid Virtualization Pit-Falls

10 Biggies to Help Managers and Admins Avoid Virtualization Pit-Falls

I wish this information was available 10 years ago when I started working with virtualization, but then again, like many reading this, I thought I was an expert and didn’t need it. Now I see myself as a student because of how fast virtualization is changing.

1. First and most important, look at the big picture for why you are implementing virtualization. Most managers look solely at VMware, XenServer, Hyper-V or any other virtual server product for ROI (return on investment). Bad way to make IT decisions! Look at the big picture. How will virtualization affect everything and everyone it makes contact with? For example: How will your storage be affected when you start sharing it with hungry VMs, will the I/O hold up? Or, how will your system administrator handle the new responsibilities? How will you handle the users when they start complaining that everything is slow because you didn’t consider I/O and new responsibilities?

2. Once you have a big picture view of what you want to do with virtualization then consider that you’re still probably missing a few things that you will learn along the way. Just look at these challenges as growing pains, and unavoidable. Virtualization dynamically changes as the environments grow and upgrade. First there’s the experimental ESX or free ESXi, Hyper-V and XenServer host that gets you started. Then when the experimental host(s) get filled up there’s the small farm of host servers that get landed when you actually start purchasing new hardware and the full infrastructure licenses. Beware! of the “wow we can virtualize everything” period that happens from 50 – 200 virtual servers. At this point everything seems to work fine because you haven’t saturated your SAN I/O, or host memory and CPUs. But then there’s that point that happens at VM number 201 (201 is a relative number, it could be more or less depending on a number of factors) where panic is unavoidable if you haven’t prepared properly. That’s why you need to read the rest of this post.

3. Now that consideration 1 and 2 are out of the way, which are mainly to make IT managers think, I’ll get to the good stuff. Have a backup strategy in the beginning that is made for backing up the VM images. Don’t rely on your legacy backup software for physical servers. Yes NetBackup or whatever can still do agent backups of files of a VM, this is a no brainer. However, how are you going to do a full system restore? Unless it’s just data, 5 hours after your backup administrator begins the system restore he is still going to be trying to solve this riddle. You want a good solution that makes an image backup. Solutions: VCB, vRanger Pro, Veeam Backup, Avamar. These are all specific backup tools for virtualization. Avamar can work on any type of virtual environment including Sun containers.

4. Know your storage limits. Capacity is just one part of the storage requirement. The other part is I/O or OIPS (Input/Output Per Second). VMs have different I/O needs. One hungry database or SharePoint VM on a LUN that shares it’s disk parity with multiple LUNs can cause performance problem across all the LUNs in the disk parity group. The best way I have found to avoid this is to design your storage with the biggest I/O pool available. I/O begins at the disk and 15K disks have roughly 200 IOPS where 10K disks have 150 IOPS (SATA have 30 – 50 IOPS). Do the math, which is better? After capacity and I/O is considered, then there is the pathing, which needs to be manually configure to split I/O down multiple paths to the SAN/NAS cache. I’ve seen million dollar equipment brought to its knees because this stuff was overlooked. It’s usually not the equipment (HP, NetApp, EMC) that is causing the problem, its configuration. Whether you plan to use FC, NFS or iSCSI, this is important for your storage administrator to consider. Otherwise, you will be playing VM storage Tetris and I guarantee you will lose.

5. This is in conjunction with 4, VM template configuration. If you’re planning to have a huge pool of I/O then you will never know your template configuration is poor. VM configuration is important and is easy to overlook. Most will find out how important when I/O runs out… I’ve read this best practice on many blogs – “put data and OS, and even swap files on separate LUNs.” I agree this is a good best practice, but I am taking it even further and adding a criteria. “Separate LUN on separate disk parity groups.” Here’s why, ten – 15K disks will give you roughly 1500 IOPS across each LUN it is carved into. Depending on the size of the drive you may have various LUN sizes of 200 to 500 GB (each with 10 – 20 I/O hungry VMs) sharing the same IOPS. Splitting data, OS and swap onto more spindles will give you more IOPS and possibly an alternate path to the 2nd storage processor (active/active), or more cache that is assigned to another FC or NIC port. Make sure data store names include what the LUN is for (Data, OS or swap) and odd even disk parity (data goes on odd, OS go on even).

6. Clean up your messes. Don’t leave old proof of concept (POC) VMs or equipment running after the POC is done. Nothing is harder to do then to clean up a VM environment 2 years after everyone who was on the original project team has left and your VM inventory now has 500 VMs in it. The first place you need to look when you hit your host and storage limits is here. Out of 500 VMs you can bet there are at least 50 VM zombies that are idly running and using up precious resources. Then there’s the clean up of zombie VM folders that are from VMs that were improperly deleted and the files were left on the data store (you know the VM you said you’d delete later – that was 2 years ago). Clean up also helps control “Sprawl”. Sprawl is a fancy word for out of control.

7. You probably didn’t hear me the first time so I’m saying “Backups” again. I’m putting this down again to make sure you have a backup solution that backs up the complete VM image. It’s no easy task to change backup process 2 years and 500 VMs later so make sure you do this right from the start.

8. Establish standards for your environment. All hosts will be on the certified version of ESX or whatever hypervisor you use. Once you allow old hosts to say around after you have decided to build new host on the current ESX version, it won’t be long before your virtual infrastructure is fragmented. Remember, virtualization is evolving almost daily and new features are on each new version of ESX and Hyper-V. Live migration didn’t work on the old Hyper-V version but it work on R2, but it doesn’t work across R1 to R2 or R2 to R1. Get all those R1 upgraded to R2 so all are the same and live migration works. Keeping the standard isn’t easy because VM administrator are also system administrators, they have to land the servers, configure the host, as well as deploy the VM and configure the VM. It’s the same people doing both jobs and in some cases they are storage and network administrators too. Make sure you have enough staff to maintain your standards. I’ve known more than a few overworked, underpaid and miss-understood VM administrators in my time.

9. I hate this one as much as any true IT professional but someone has to keep doing the job if you leave and take a better paying job somewhere else. Make sure you keep good documentation. If it’s required, cool Visio’s of everything is nice for management, but even more important for day to day support staff are “How To” documents. How to land and provision a host (hardware and hypervisor). How to deploy a VM. How to add additional disk space to the “C” drive of a VM. How to P2V a system. How to properly request more storage. How to decommission a VM. How to schedule a VM backup. How to recover a VM from a backup. Also keep the “How To” documents up-to-date. You need a new “How To” for each version of ESX because they are not the same; customization to the SWAP volume for example is different on 2.5, 3.0 and 3.5. Hyper-V and XENserver have their own little tweaks as well.

10. Don’t buy every tool out there thinking its going to fix everything I have spent the last 2 hours writing about. Listen to what I am saying. Listen to your support staff. Carefully listen to vendors who want to sell you something because there is no silver bullet for poor planning. And, while on the subject of vendor, any consult recommendation with direct connection with equipment vendors should also be scrutinized. I’ve seen the best SAN money can buy collapse under 25 VMs because it was haphazardly used (VM storage Tetris).  Many of the problems I have warned you about can be avoided if you plan. Read number 1 and 2 again until this makes sense. To the VM administrators who are fighting the daily battles because most of what I have written about is already occurring in your virtual environment, I feel your pain. To all the new bright-eyed IT managers and system administrator who are licking their chops because they are finally getting a budget to start virtualizing, I warn you and say, “Consider the big picture and plan, plan, plan!”

Hopefully this post has been helpful. Other items that were not covered are: How to monitor VM and host servers, disaster recovery DR of virtual environments, capacity planning, forecasting and hardware (servers, network and storage) brands and types. These can be topics for the next 10 biggie list. My final note is “Backups” will challenge traditional thinking so heed my warnings.

Originally posted 2009-03-29 10:38:28. Republished by Blog Post Promoter

Squeezing Virtual Machines out CPU Cores

images Are you trying to squeeze every CPU cycle out of your dual or quad core processors? Unfortunately for those who like to over-clock CPUs for gaming, over utilizing CPU doesn’t quite work the same on virtual hosts (ESX or Hyper-V).

From my experience, I know you can get anywhere from 8 – 10 vCPUs per core, but I have found a sweet spot of 4 VMs per core will provide decent performance for the user. Remember, you don’t want users waiting 30 seconds for a logon or screen refresh… Over utilizing memory will cause user frustration too.

Eric Siebert has written an excellent article on SearchNetworking.com called “Sizing server hardware” which goes into “nuts and bolts” details for sizing virtual host server hardware.

My opinion is to “Always! Always!” think of the users experience when considering your best practices. Sure 100 VMs on a host sounds good but what kind of performance will users have? I’ve had my share of complaints over slow virtual servers and believe me you don’t want users to start complaining that your (that’s right, your!) virtual servers are slow.

Rule of thumb: Keep it simple, 4 VMs per CPU core. Don’t use more than one vCPU per VM unless the application running on the virtual server requires two or unless the developer demands two and calls your boss. VMs with one vCPU run more efficient and from my experience nobody seems to notice, except for – maybe, over-clockers!

Here’s something I wrote a while back:

The measurement of a successful virtual infrastructure deployment is not how many VMs can be hosted per host, it’s how many users can be satisfactorily serviced without them knowing they are using virtual technology. Virtualization should be invisible. Once users start noticing foot prints in the snow, it’s over…”

Originally posted 2009-02-12 16:30:14. Republished by Blog Post Promoter

Best Fit Virtualization Criteria Checklist

Finding servers which are the “Best Fit” canadates for virtualization can be tricky. I have put together the following criteria checklist to help determine whether a new server provision or a P2V should use virtualization.

The Best Fit checklist uses my own criteria and weight recommendations but it can be modified with more liberal values.  However, remeber the “Best Fit” for virtualizing a server should always consider the user’s experience, too liberal will produce poor performance and complaining users.

The “Best Fit” file has been attached for you to use it as-is or you can make your own.  Open file: best-fit-virtualization-criteria-checklist-vminstall

Best Fit Virtualization Criteria Checklist

Requestor: ____________________________________________ Date: ___________________

Server Name: __________________________ Server Role: ______________________________

Primary Application: ______________________________ Database: ______________________

Purpose:

The purpose of this checklist is to evaluate new server provisions for server virtualization. The checklist criteria are designed to only allow “Best Fit” usage for virtualization. A weight of 3 or more will waive the server’s provision for virtualization.

Instructions:

Each item has a weight assigned. While going down the checklist place the weight value on the line to the left of the items that apply. Once you are complete, total the weights.

Checklist:

  ____ 1. Is the primary application supported when hosted on a VMware VM? Yes/No (If no add 3 Pt.) Self explanatory.
  ____ 2. If this is a database server will clustering be required? Yes/No (If yes add 3 Pt.) Caveat: If clustering is required, high availability is hindered on the host server.
  ____ 3. Is this server considered a fail-over for a physical server? Yes/No (If yes add 3 Pt.)    Caveat: Fail-over servers should be provisioned on an equivalent platform.
  ____ 4. Can recommended system requirements be scaled back (CPU/Memory)? Yes/No     (If no then use items 5 and 6 to calculate weight.
  ____ 5. Will memory requirement be greater than 2 GB? Yes/No (If yes add 1 and .5 for each additional 512 MB)
  ____ 6. Will disk requirements grow beyond a 20 GB (C: or Root disk) and 50 GB of combined additional disk space. Yes/No   (If yes add 1 and .5 for each additional 50 GB) How much? _____GB
  ____ 7. Will this be a temporary installation/deployment?  Yes/No    How many months? _____ (If yes can Lab Manager be used?) (0 Pt.)
  ____ 8. Will a database be hosted on the server (SQL/MySQL/Oracle)? Yes/No   Other ___________ (If yes add 1 Pt.)
  ____ 9. _______________________________________________________
  ____ 10. ______________________________________________________

(           )  A server with a total 3 and greater should not be virtualized.

Evaluation Summary: _______________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________

Originally posted 2009-02-21 09:54:36. Republished by Blog Post Promoter

Google LiveAndroid OS Runs On Virtual Machine

Android Splash 

Google LiveAndroid OS Runs On Virtual Machine

With all the recent buzz going on about Google’s New Android cell phones, I thought it would be worthwhile to blog this on VMInstall.com.

If you’re a techie who likes to spend time testing which operating systems they can get to run on a VM. I found that Google has a version of its popular Android OS that is called LiveAndroid. You download the ISO then you can boot your PC from it or create a VM.

The picture shown is LiveAndroid running on VMware Player but it’s been tested on VirtualBox, too.

 LiveAndroid v0.3 – Features

  • OpenDNS added
  • Audio support
    • VirtualBox – Intel 8×0 AC97
    • VMware – Ensoniq AudioPCI 1371/1373
  • SD card support (512M)
  • Ethernet (DHCP)
  • Mouse wheel support
  • High-resolution support (800*600, 1024*768)
  • Apps added
    • Software Directory
    • AndroidVNC
    • PilotLines, Craigs Races, Super Mario
  • more net card driver added
    • Amd PCNET32 PCI
    • Broadcom 440x/47xx
    • CS89x0
    • Intel PRO/100+
    • NE2000/NE1000
    • Realtek RTL-8129/8130/8139

Browsing VMinstall.com

LiveAndroid - Browsing

LiveAndroid - Browsing VMinstall.com

 Download Your Copy

User Guide

LiveAndroid Desktop
 
LiveAndroid Desktop

LiveAndroid Desktop

Originally posted 2009-11-14 07:39:43. Republished by Blog Post Promoter

To V or Not to V is the Question?

Buzz Word

 

Has virtualization become a buzz word in your strategic plan? Take the advice from someone who has spent years supporting VMware in three different enterprise environments – think before you V.

 

If all you plan is a small experimental cluster of virtual servers, it’s no big deal. The software is even free. VMware ESXi is the best way to go. But, remember, it’s only a seed for future growth. Growth which will evolve into a nest of unexpected problems if you don’t think before you start to roll out ESXi hosts for your DEV, QA and PROD environments.

 

V is not for Vendetta

 

Cynical as this may sound, it’s more truth than fiction! Five months from the day the first ESXi host is deployed in your datacenter you will have users complaining about poor performance, and your smartest system administrators will begin many long hours of research to solve riddles for virtualization backups, migrations, storage and other strange unknown glitches that are attributed to the “V” word.

 

Fix for SCSI Errors Filling Up Logs

 

If you are dabbling, like I said earlier go for it. Virtual servers are fun to work with – that is – until you get too many on one host and you need to reboot the host but you can’t because there is a DEV server that somehow has become a production server and is running a business critical application that absolutely cannot be bounced! Now your are caught between complaining users, worried managers and not knowing for sure if the fix applied by your system administrator will be the solution for the SCSI errors that are filling up the logs and killing performance. All you need to do is bounce the host to see if changing the queue depth does the job. It should because the ESX command was found by your system administrator when Googling “Fix for SCSI Errors Filling Up Logs”

 and reading through 50,000 threads about SCSI errors and VMware.

 

I am not trying to be sarcastic; I am trying to make you think! The incident about the SCSI error is a real situation that has played out in two of the three VMware virtual environments I have worked in. Google “SCSI error” + VMware and see for yourself.

 

Ignorance and Arrogance

 

The two biggest problems I have noticed since I started supporting VMware are ignorance and arrogance. Here’s what I mean.

 

“I” is for Ignorance

 

First, just about every virtual environment starts off with ignorant managers who do not understand what’s required to build a successful virtual environment. They just know everyone else is doing it and it’s supposed to save a lot of money. Unfortunately, all the future saving will go out the windows with support and license costs and lost labor. Support and license costs are easy enough to understand, but what do I mean by lost labor? Well, lost labor is the many hours, days and weeks that your top system administrators spend trying to solve VM riddles. Even when you purchase expensive support the problems don’t go away. In most cases someone just finds a work-around because the solution for the root cause is purchasing a new SAN or more powerful hardware because someone didn’t bother to check the HCL (hard compatibility list).

 

“A” is for Arrogance

 

Oh, then there’s the problems associated with arrogance. Here’s how this one plays out. You and the stakeholders decide to deploy a virtual infrastructure to save money, right? You start with the basic package of three hosts and a virtual center which quickly grows to 16 and 32 hosts (whistles and bells included are: vMotion, HA, DRS). Then you schedule a 30 minute meeting with your systems team and pick your best system administrator to lead the “Virtualization Project” (maybe even send him to training). He/she has built a ton of servers and even has a MCSE or RHCE. VMware is easy to setup. Just load the hosts, install the virtual center, and start building and P2Ving servers into the environment. It’s so easy, anybody can do it, right?

 

A week later, Wow! Everyone thinks you have the VMware god working for you. Pretty soon the VMware god gets vMotion running and HA to work. Next, scripts are running to reboot and auto-config VMs. Another 30 minute meeting is scheduled to plan out migrating servers into the virtual infrastructure; this plan is called the “Server Consolidation” Project. The system administrator has become a VMware expert in two months and this is his/her virtual environment…. Quoting from the good book, “Pride comes before the fall” .

 

I am a firm believer that history repeats itself so here’s what I am predicting happens next. Beneath the surface of your virtual world trouble is brewing. First the problems are small and your VMware expert can figure them out, then the problems get bigger and like any normal person would do, the expert doesn’t tell anyone because they’ve gotten used to being called the VMware god and they don’t want anyone to know they are really mortal. Soon emails starting trickling into your inbox and you are the CC:. The subject states “why is my VM so slow logging in?”. Soon it’s no longer a trickle and you are now the “To:” from all the users and the VMware god is at the end of the list which includes everyone in the GAL and your boss. The cat’s out of the bag, there’s a problem with  VMware and everyone now knows the VMware god is mortal and they come looking for you. No this is not a Steven Spielberg novel it’s real world stuff…

 

How Do You Measure Success – Invisible

 

The worst thing that could’ve happened to your virtual infrastructure has happened. Technically things are fixable but what will not be fixed any time soon is the bad user experience that has affected hundreds or even thousands of users who work on servers that were virtualized. All your effort to sell virtualization to the business units has just been destroyed and users don’t want virtual servers any more. Managers even demand that all their applications are moved off your virtual infrastructure because they can’t handle bad performance and complaining workers any longer.

 

Rule of thumb: The measurement of a successful VMware deployment is not how many VMs can be hosted per ESX host, its how many users can be satisfactorily serviced without them knowing they are using virtual technology. Virtualization should be invisible. Once users start noticing foot prints in the snow, it’s over before a shot is fired.

 

Do It Right the First Time

 

If to V or not to V is still the question then here’s my recommendations? Don’t even setup a single host, even with the free version ESXi if you don’t plan to do it right. It will just snowball from there into a monster with unexpected results and in the end users will think all virtual environments are the same – crap!

 

If I haven’t deterred you and you still want to virtualize, then here’s the right way to do it. (Pardon my arrogance).

 

First, work closely with vendors. Listen to them and let them guide you. Yes, they will try to sell you better equipment, but not because they want to take advantage of you. They can’t tell you this but they know you will have problems if you buy the cheapest equipment. My guess is you will still be tempted to buy the cheap stuff then later you will blame the vendor when the users start emailing you about their bad experience. As I stated earlier, it will be too late and you are to blame.

 

For those who do listen to their vendor’s advice, the next item is more important. Hire an experienced VMware administrator. Don’t try to turn a system or network administrator into a VMware administrator. VMware administrators are specialists just like a DBA. Here’s why, VMware is an infrastructure technology, not a server technology. Sure a system administrator can become a skilled VMware administrator, I did. Here’s why you need someone from the outside, they will be objective about things like storage, networking, and quality. Existing internal staff will cut corners because they always do, you just don’t know about it. And, chances are likely that you will trust an outsider’s discretion more than a buddy or subordinate. If it’s done right the users will never know the difference, if it’s done wrong, everyone all the way up to the CEO will be sending you an email.

 

Third, virtualization requires total collaboration with storage, networking, developers, operations and business unit managers. If you can’t enlist them to work together as the “Virtualization Team” forget it. There’s nothing more frustrating than trying to figure out a problem when storage administrators will not let you verify they are using “Best Practices” for zoning your ESX host server storage fabric, or when a network administrator will not do what you ask when you tell them why curtain VLANs need to be trucked on all four data ports for the same host. The list of people hassles goes on…

 

Forth, this is more important than food and water. Please, heed my warning. After everyone has done the best they can do to make sure your virtual infrastructure will work and be a success. Do not come out of left field with your own ideas and change everything after weeks and months of planning. Don’t change the SAN from tier 2 to tier 3. Don’t buy a cheaper model of server. Don’t redo how the servers will be backed up. Don’t change anything… The time for making changes is during the planning process or when an unexpected problem surfaces. The problem should not be you at the last minute throwing a wrench into the mix. Please!

 

Finally, virtualization is a great technology that will eventually find it’s way into your datacenter whether you want it or not. The way you choose to go is simple: let it evolve into a monster that everyone will hate or, plan and architect its deployment into something nobody knows exists. Remember, virtualization should be transparent to the users. When they know it’s there, someone hasn’t done their job right.

 

Conclusion!

 

To virtualize or not to virtualize is the question? My answer to this question is in the form of a question, “How important are people to you?” If their satisfaction is the most important thing on your list and if happy people pecking away on the keyboard is your top priority then make sure when you begin to assemble your virtualization team and you start scheduling 30 minute meetings, everyone knows from the first day until the project is completed that the objective is “virtualization should be invisible to the user”.

 

Originally posted 2008-11-11 13:04:10. Republished by Blog Post Promoter

Three Ways for Extending a VM’s Disk

gparted_1_smallMost new virtual servers are provisioned from templates that have 12 to 20 GB “C” disk so what do you do when you run out of space?  Here are three methods which might work for you to increase the size of your virtual server’s disk.

  1.  Use VMconverter from VMware to clone the VM and change the size of the drive.
  2. Build a Windows 2003 VM that can be used to mount the “C” drive VMDK of the target VM as an additional drive, then use the VM setting on the tool to increase the disk size. Once the disk size is increased use the Windows “diskpart” command to grow the partition. Don’t forget to un-mount the disk from the tool.
  3. Then there’s a sweet free tool called GParted that boasts the following features:

gparted

 

 

 

 GParted also has a nice GUI as seen in the upper right and best of all, it’s free.

More about GParted:

Gnome Partition Editor

GParted is the Gnome Partition Editor application. Before attempting to use it, here is some basic background information.

A hard disk is usually subdivided into one or more partitions. These partitions are normally not re-sizable (making one smaller and the adjacent one larger). The purpose of GParted is to allow the individual to take a hard disk and change the partition organization therein, while preserving the partition contents.

GParted is an industrial-strength package for creating, destroying, resizing, moving, checking and copying partitions, and the file systems on them. This is useful for creating space for new operating systems, reorganizing disk usage, copying data residing on hard disks and mirroring one partition with another (disk imaging). See Features, before using it.

GParted uses GNU libparted to detect and manipulate devices and partition tables.

Several (optional) file system tools provide support for file systems not included in libparted.
These optional packages will be detected at runtime and do not require a rebuild of GParted.

GParted is written in C++ and uses gtkmm for its Graphical User Interface (GUI). The general approach is to keep the Graphical User Interface as simple as possible. Every attempt was made to conform to the GNOME Human Interface Guidelines.

GParted comes under the terms of the General Public License

Download link http://gparted.sourceforge.net/

Originally posted 2009-03-01 08:39:55. Republished by Blog Post Promoter

Great Websites and Blogs for VMware and other Virtualization Support

Today I did a Google search to see how many people like myself have started a blog or website to discuss or support virtualization (VMware, Hyper-V, Virtual Iron, etc). I was surprised to find so many cool websites with catchy names.

 

Take this name for example: www.vmwarewolf.com. Visiting the site I found quite a few posts on troubleshooting VMware, especially ESX. Lots of information on the old “ESX random disconnect from VirtualCenter” issue.

 

At the top of the Google search list was VMware’s own support community. If you support VMware Virtual Infrastructure and you haven’t visited the community yet, you are missing out. Here’s the link, go there now! Then come back and finish reading this post. http://communities.vmware.com/community/vmtn/suggest/support

 

One of my old favorites is www.VMGuru.com. I remember when this site was just taking off. The owner, Scott Herold, even wrote one of the first ‘worth a darn books” on Virtual Infrastructure. I must have downloaded the free chapters 10 times. Now you can download the whole book, but don’t be a cheap-skate, buy Scott, Ron and Mike book. VMguru.com has quite a few posting on every subject relating to VMware VI, such as platform, networking, storage, management and monitoring, VDI and scripting. Don’t just take my word for it go and visit www.VMGuru.com now then come back and finish reading my post.

 

OK, one site that I have really found useful over the years has been http://blog.scottlowe.org. I have watched this site grow in popularity and mature with every new version of ESX server. I think I might have run into Scott once at VMWorld 2007 in San Francisco, he was standing along the side where the computers for folks to check their email are and blogging away about what was going on at VMWorld. I think that was right after he got a new gig writing articles. If you can’t find what you are looking for on VMware support site, make sure you visit http://blog.scottlowe.org. Scott keeps up with almost every trend and product VMware related, or you will find a link to where you can find help. You go Scott! BTW, Don’t go visit Scott’s blog yet, or you will never finish reading my post.

 

This website, www.vminstall.com has been around since 2007. During that time I was supporting a new VMware Virtual Infrastructure deployment for Arizona State University. One day I happened to visit Godaddy.com and did a name search and lucky me, www.vminstall.com was available. VM Install has been through some changes over its existence as I’ve tried to keep it going with various types content. The original site was done in Drupal, and then last year I got rid of Drupal and the crazy job posting and re-did the site in WordPress with a clean professional template. I know some of my posts are old but they keep visitors coming for now. Heck, I’ve given up on trying to keep up with all the “techies” and now I just blog about niche things I figure will make system administrator or IT Managers think before making a mess of their virtual environment. Okay, I’m done talking about my website, VM Install.

 

A relatively new website that I have found while searching VMware problems is VMETC.com. It has a green and white template and a big presence on the web because so many people are linking to the RSS feeds. Don’t get me wrong, the owner of this site, Rich Brambley, whom I’ve never met, really knows his stuff. You go Rich, and by the way, the picture of you and your kids at the Falcon game is great. Too bad the Cards had to take them out in the play-offs, maybe next season, eh? VMECT.com is packed with posts with command line examples and solutions for all kinds of technical stuff, take this link title for instance: http://vmetc.com/2009/01/19/esxiesx-35-update-3-iscsi-and-fc-alert-queue-for-device-has-been-blocked/. Didn’t I tell you Rich knows his stuff?  

 

There are plenty more good websites, but two final sites I want to mention are www.wmware-land.com and www.VMtoday.com. VMware-Land is the place to go to find out who the “who’s” are in VMware blogging, plus there also hundreds of links to help you find what you’re looking for. Unfortunately, VMinstall.com hasn’t made it to his top ten list yet but that’s okay, just do a search on Google for “VM install”. Here’s the list borrowed from VMware-Land:

 

(1)   Yellow Bricks (Duncan Epping) – 9

(2)   Blog.scottlowe.org (Scott Lowe) – 2

(3) Mike D’s Virtualization Blog (Mike DePetrillo) – New

(4) NTPro.nl (Eric Sloof) – 6

(5) SearchServerVirtualization Blog (Various) – 3

(6) Virtualization Pro (Various) – 4

(7) VM /ETC (Rich Brambley) – 5

(8) RTFM Education (Mike Laverick) – 1

(9) Rational Survivability (Christofer Hoff) – 8

(10) Virtual Geek (Chad Sakac) – New

 

Note: Find more top ten list at http://vmware-land.com/Top_10_Lists.html

 

The other site is www.VMToday.com. VMtoday is a clean VMware News, Views, and How-To’s website, which for a moment I thought I was looking at my own site because the site has so much in-common with VMinstall.com. Jashua Townsend the site owner has good taste and you will find VMtoday informative. 

 

Summing up this blog post about some of the fantastic websites and blogs for VMware support and virtualization, I just want to ask all the webmasters mentioned above to keep up the great work. I’m just one of thousands who visit your site regularly for help and I don’t know what I’d do without you. Now can someone please tell me how to join my VMware VirtualCenter 2.5 to Microsoft Virtual Machine Manager (VMM), just kidding!

Originally posted 2009-02-07 09:29:44. Republished by Blog Post Promoter