VEEAM and Vizioncore (vRanger) both have a feature in their newest backup products that lets you “instantly” restore a vm, so users can get back to work on the machine right away. Both technologies spin up a vm from the backup right on your backup media. You dont have to wait for anything to be copied back across the network. Sweet!
http://www.veeam.com/go/vPower?ad=backup
http://vizioncore.com/sites/default/files/Flash%20Restore%20Datasheet.pdf
Running out of disk space, especially on your boot drive can really create some problems. If your organization is not actively monitoring space usage on drives, they should be. Here is a quick way to run a query using the VMWare Community Powerpack and PowerGUI to be the hero and warn server admins about low space on your vms.
Grab PowerGUI here…
http://www.powergui.org/index.jspa
And grab the powerpack here…
http://www.virtu-al.net/2009/12/18/vesi-powergui-powerpack-v3/
To install the powerpack, go up to file and Powerpack management in PowerGUI.
Now keep an eye out for a query called VM Guest Disk Sizes under the Virtual Machines folder of the community PowerPack.
Click on that query to let it run, and once finished, select the Disk0FreeSpace column to sort by the lowest number first. Scroll on down to where you start getting numbers. These numbers are free space on the C: drive in MB. Personally, I think anything below 1GB is a red flag. Alert the proper admins to clean up the drives and be the hero!
If you really want to go the extra mile, point the admin to a tool called Spacemonger. This is a tool that hasn’t been updated in awhile, but still offers a great graphical view of the entire hard drive. The larger the block, the larger the folder or file. Grab it here…http://www.sixty-five.cc/download/. Look for the Free Software tab and scroll down to SpaceMonger v1.4.0 Its a zip file, but the actual program requires no install. You just run it, select Open, then select the drive you want to look at. Be careful deleting things!
This topic has been covered elsewhere, but from time-to-time I need a reminder. As you may know, vm file and folder names are derived from the name you use when the vm is first deployed. A lot of organizations try to match up the computer name with the vm name in virtual center. The problem comes in if that name ever needs to change. You can click on the name of the vm in virtual center and change it, but this DOES NOT change the name of the files and folders that make up that vm. Fortunately, there is an easy way to fix this. Storage vMotion. If you perform a Storage vMotion on the vm, the folders and files will be changed to match the current name of the vm. Make sure you get all the drives when you do the Storage vMotion, and click advanced if you need the drives to go to different datastores. Once everything is moved to a different datastore, the names will match up again.
How do I know if my existing vm names, folders and files are consistent? For a large number of vms, the easiest way is to grab PowerGUI and the PowerGUI power pack.
Grab PowerGUI here…
http://www.powergui.org/index.jspa
And grab the powerpack here…
http://www.virtu-al.net/2009/12/18/vesi-powergui-powerpack-v3/
To install the powerpack, go up to file and Powerpack management in PowerGUI.
There are a ton of useful queries to run on your infrastructure, but keep an eye out for the VMs & Templates with inconsistent folder names query under the Virtual Machines section of the Powerpack.
I manage the backups for about 400+ vms on a daily basis. We are using a mix of vRanger and VEEAM to backup our vms both at our main site, and at a couple of smaller branch sites. We use vRanger for our main site and VEAAM for the branch sites. As far as features, vRanger and VEEAM have flip-flopped in the past, with VEEAM usually taking the lead and vRanger following suit 6 months to a year later with certain features (CBT support for instance). The main differentiator that caused us to choose one over the other for the our production site is SCALE.
vRanger is our choice for VM backups in our production site. As we must fit all 400 of these backups into reasonable backup windows, we are using the limits available for tasks running per datastore, host, and backup Groups. By using jobs based on backup groups composed of small numbers of hosts, we dont have to constantly edit jobs to exclude new vms, and we have a small number of jobs to deal with. The limits per host and datastore ensure that we are running multiple vm backup tasks at any given time.
This is the key differentiator from VEEAM. VEEAM only processes vm backup tasks one at a time. So if I have 30 vms to be backed up in a job, it will plod through them one at a time. If it hits a particularly large backup, you are stuck waiting. On the flip side, with vRanger we can often have 6-8 vm backup tasks all running at the same time. Sure, it will still take some time to backup the larger vms, but it is working on several others at the same time. I talked with VEEAM at VMWorld about this a couple of weeks ago, and their answer was to setup additional backup servers to run things simultaneously. Wrong answer. Who wants to add another box you have to manage and try to schedule all that out? No thanks. The other option presented was to make a job for each vm. HA! Don’t even get me started on why that is a nightmare.
VEEAM is our choice for the smaller branch sites. These have a small number of vms (about 10). They all have CBT enabled. These 2 factors mitigate the sequential nature of VEEAM, as the backups all finish in the nightly backup window just fine. The killer features that made us use VEEAM for the branches is the Enterprise Manager and the Virtual appliance mode. Enterprise Manager lets us see all of our backups and history for multiple installs of VEEAM across our branches from a single web page. Very nice. Virtual appliance mode will hot-add the vm disks to the VEEAM virtual server installed at each branch for backup, making them faster. This is much easier to do than trying to “mount” the vmdk’s on a physical box like VCB used to be.
What are your thoughts? How are you backing up your vm infrastructure both big and small?
So, here is the scenario. You have a VM with a regular, lets say 40GB OS drive, and a 300 GB Data drive. Now you want to backup the vm using something like vranger or veeam. As part of the backup process, the VM is snapshotted (is that a word?). Only problem is, you get this lovely error….
Uh oh! But my OS and Data drive are on separate volumes! There is plenty of room on both! What gives? It all boils down to where your working directory is, and the block size of the volume that it resides on. As you may know, when you are creating and formatting a volume for use in vsphere, you are asked what block size you would like to use. By default this is set to 1MB block sizes. The block size directly relates to how large of a file that can be created on the datastore. Let’s look at a table of the maximums as it relates to block size.
Block Size Maximum File Size
| 1MB | 256 GB |
| 2 MB | 512 GB |
| 4 MB | 1024 GB |
| 8 MB | 2048 GB |
As you can see, if you go with the default 1MB block size, you can only have a file of 256GB in size. One more piece of the puzzle reveals our underlying issue….the working directory.
In vsphere, when a snapshot is created, there are some checks that are done to make sure that files created can fit into the datastore. BUT this check is done against the datastore that contains the working directory for your VM. In our example, the OS drive. If our OS datastore only has a 1MB block size, it thinks that your 300GB snapshot of your data drive wont fit! It does not base it’s estimation on if it will fit on the datastore where the 300GB vmdk resides, but instead on where the working directory resides……the 1MB block size datastore! We cant fit a 300GB file on a 1MB block size datastore, so the snapshot fails!
Ok great. It failed. Now what? We need to storage vmotion the OS drive and configuration files to a datastore with an 8MB block size. This is to accommodate a secondary drive all the way up to 2TB, while simultaneously changing the working directory. Right click the offending vm, choose Migrate, then Change Datastore, then click the advanced button and select a datastore for the config file and hard disk 1 that has a 8MB block size.
Once the storage vmotion is complete, you can now snaphot your vm and get it backed up!
More info:
http://www.yellow-bricks.com/2009/08/24/vsphere-vm-snapshots-and-block-size/
Over the years, many organizations have come to rely on VMWare for their underlying hypervisor of choice. As the product has evolved, these organizations have been able to leverage additional core functionality that has moved VMWare to the forefront of datacenter operations. Advances in management, availability, backup, and other areas have all fallen under the VMWare umbrella, and they are a nice fit. The pieces of the the datacenter puzzle are fitting together. To complete the puzzle beyond the local datacenter, VMWare started to really focus on the cloud. The cloud was, and is, about offering up core services regardless of location and free from traditional infrastructure limitations. I need some work done, and in a timely manner. I dont really care where my SQL query is running, I just need the results. Fast. I need my email to just work. Again, I dont care where it’s running. It needs to send when I click send. You get the idea.
All these puzzle pieces have been making sense as we build out a more available and scalable infrastructure. But then VMWare bought Zimbra. All of a sudden, the focus is shifted from core available infrastructure to the applications running on that infrastructure. Sure, VMWare has always made sure that any and all applications you want to run are available and scalable, but now they own an email application. The can of worms is wide OPEN. I would offer the following questions to think about…
1. Now that VMWare owns an email platform, what are they going to do with it? Are they really trying to go toe-to-toe with Google and Microsoft in the application space?
2. As they flesh out infrastructure in the cloud, how does VMWare email fit in? Obviously, email is very important. We use it every day. I certainly do care that it is up all the time. But, as a business customer, I also care about features and functionality around scheduling, document management, voicemail, and other features that are very mature on other platforms. Can VMWare email deliver?
3. If we go to the next logical step,as Google and Microsoft have, now we need to start offering vDocs, vPresent, vMessaging, vPhotos. What next? Historically, VMWare has been in the position of being on the forefront of virtualization, constantly innovating and bringing new functionalities to the datacenter. They are the clear leader. Now they are trying to play catch-up in the application space? This kind of ME TOO attitude leaves a sour taste in my mouth.
I do not claim to have all the answers here. All I am asking is that VMWare remember their core business. Please don’t diversify yourself into irrelevance. Focus on what has made you the best!
Update: If you are running the Update 1 or later on your hosts, the vSphere client it now works with Windows 7.
I have been struggling with this ever since going over to the Windows 7 RTM. Over at the vmware community forums, GlenR has posted a zip file that when extracted to the right place, lets you run the vsphere client on Windows 7! Thanks GlenR! I am going to expand on his work with a step-by-step…
1. Go here to get the zip file…
http://communities.vmware.com/thread/211440?start=105&tstart=0
His post is about halfway down. Download that zip file to your computer.
2. Next step is to download and install the vsphere client from your vcenter server if you havent already. Just go to the vcenter IP or hostname in your browser and click Download vSphere client.
3. Once you have the client installed, extract the zip file to c:\Program Files (x86)\VMware\Infrastructure\. Make sure to overwrite the files with what is in the zip file.
4. Now browse to c:\Program Files (x86)\VMware\Infrastructure\Virtual Infrastructure Client\Launcher. You will see a start_viclient batch file in there. That’s what you need to run to launch the client.
5. Now, to make it a little more elegant, edit the vsphere client shortcut on your desktop. Delete the vpxclient reference, and instead reference the start_viclient batch file instead. In the latest version of GlenR’s zip file, you can also use the shortcut’s he has included if you like. You are good to go!
Well, how about this? The GSA has started an “app store” for U.S. government 
agencies. This is not your everyday, fart app. No, these are major applications like Salesforce offered up in the cloud. The agency picks what they want, how many users, etc., and it gets built. I think this is where true virtualization really kicks off. All I have to do is pick my application that I want, how many people are going to use it, and maybe some SLA’s, and I am off and running. Does the agency care about how much storage or redundancy is required on the back end? Nope, they just order it…
Exchange 2007 on vSphere 4…
1. 2K7 has reduced IO with larger cache, etc. This makes it easier to virtualize.
2. Must run it on server 2008 to get MS support.
3. Use 1vcpu 4.5 GB ram, and 500 heavy users as a building block.
4. Use 2vCPU 7 GB RAM, and 1000 heavy users as a larger building block.
5. Only 10 ms send latency enabling FT.
6. Disaster recovery…ha, FT, lcr and scr does not require microsoft clustering.
vCenter AppSpeed
1. Monitors apps performance based on inspecting traffic on the vswitch.
2. You must be able to measure end user performance to troubleshoot it.
3. Appspeed let’s you monitor as you virtualize (assured migration).
4. Appspeed server discovers, maps and monitors performance vs SLA’s. It puts a small vm on each host.
5. Environment map automatically created. Shows interdependencies. This gives you a deeper understanding of how everything is connected.
6. AppSpeed then monitors performance letting you drill down and identify bottlenecks. Alerts automatically. You can trend over time.
7. AppSpeed can then analyze root causes.
PlanetV12N
Modmaven's Weblog 