VM /ETC

Archive for the ‘P2V’ Category

I was helping a customer P2V a large development SQL server this week and ran into a VMFS configuration issue that failed the conversion. We were using the Converter Enterprise for VirtualCenter 2.5 plugin. Almost as soon as we kicked off the job it failed with an error starting with “file size is larger than the maximum size supported by datastore”. The VMFS LUN we were using as the target was an empty 1.5 TB volume, and the new VM consisted of 2 virtual disks that totaled roughly 450 GB. We had plenty of room, but the problem was not the available storage space. Instead, the issue was that we exceeded the maximum possible .vmdk size for the default VMFS 1MB block setting.

When you add new storage to an ESX host and you format the LUN with the VMFS file system you have to choose what block size setting you want to use. See the screenshot for the dropdown box used to make this choice. Notice the Maximum file size description supposedly provided to help you understand this setting. It’s hardly intuitive in my opinion, so let me try to translate – Choosing the block size determines what maximum possible .vmdk size can be created on this LUN.

If you do not change the default setting when you format a VMFS LUN
Read the rest of this entry »

Carlo Costanzo over at ipmer.com has a great post about how to quickly and easily solve issues resulting from VM snapshots. As Carlo points out, too many administrators misunderstand the ESX snapshot to be a point in time backup and unfortunately do not realize it is instead a live and growing file. More often than not the snapshot is forgotten until the LUN is completely out of space at which time the VM is unstable. Trying to commit the snapshot becomes a time consuming burden.

The post 70GB Snapshot, YIKES! explains how Carlo used some “outside of the box” thinking to use VMware Converter to rescue VMs without going through the commit process. The idea is so simple it’s brilliant! Carlo writes:

Read the rest of this entry »

Why is it that migrating to virtual infrastructure (VI) is most often considered to be the responsibility of the server administrators? Anyone who has already done it can tell you it involves much more than servers and hardware. Even for small companies, virtualizing servers potentially (and usually) involves networking, storage, security, and infrastructure services changes. In fact, it is often as involved and complex as moving your physical servers from one data center to another.

So why is there a perception that implementing VI is only a server team responsibility? Obviously, one reason is because on the surface it’s about installing and consolidating operating systems on server hardware. Another reason is because VMware, the source for all the interest in migrating to VI to date, has done such a great job marketing their products as just server installs. Read the rest of this entry »

When planning P2V migrations there is always a handful of servers that have huge disk requirements. A network file share could be as large as several terabytes. User Home Directories can also cause large, cumbersome servers that present unique challenges when migrating to virtual infrastructure. Given that VMware VI3 has a 2 TB VMFS volume limitation as well as a 2 TB .vmdk limitation, there is a better option. Consolidate your shares to a Read the rest of this entry »

It’s good to see other administrators discussing whether or not to P2V domain controllers, and even better to see that others are recommending the same as I did in my recent post Small business P2V migrations. VMware Communities: VMWare esx 3.5& Windows Server 2003 … is a forum discussion where this topic is discussed in detail. What’s great about this discussion is that it goes beyond the P2V strategy and in to whether or not all DCs in your environment should be VMs.

Some highlights from the forum discussion:

“So it is a bad idea to convert dc’s from physical to virtual correct? Read the rest of this entry »

When I hear “we only have 6 servers so our migration to VI should be quick and easy, right?” I hesitate. Not because it can’t be done, but because of how it should be done and the probable challenges. The expectation is usually that the physical servers should be virtualized as is. The reality is often that in order to achieve the best VI design the customer needs to separate applications and services.

A typical small office server infrastructure is usually similar to the following:

The exact placement of the different applications and services varies, but the result is the same. A small company P2V project really should be an infrastructure redesign project so that the features and benefits of VI can be fully leveraged. The following are my recommendations for the VI design of a small company like the example. Read the rest of this entry »

One of the major disadvantages of VMware Converter is that you do not have the option to choose how many virtual cpus (vCPU) your new VM will have. If your source physical server has 2 CPU sockets your target VM will end up with 2 vCPUs. If your source server’s CPUs are dual core your target VM ends up with 4 vCPUs. It’s a well known best practice to minimize the number of multi processor VMs in your virtual infrastructure. So, how do you make sure servers that you p2v result in single processor VMs? Read the rest of this entry »