I tweeted that I was looking for some info about how to get more redundancy out of my virtual networking setup. Prior to that, I really didn’t have a clue about how to effectively utilize my networking resources. After I tweeted for help, a fellow by the name of Scott Lowe popped up and offered to help (as always, not trying to name drop, just making sure to give credit). I showed him my current setup, and he offered some suggestions on what I could do. It was that little bit of help that served to unlock an understanding of virtual networking that I did not have before (and for which I am eternally grateful). It is in that same vein that I wish to pass on what knowledge I have gained, in hopes that it will be of use to someone who is like I was only a short time ago.

In my previous post on the subject of virtual networking, I promised that this would be where I describe various scenarios based on different numbers of NICs present in an ESXi host. However, as I write this, I have quickly come to realize that the following bit about the goals/broad considerations regarding virtual networking could be a blog article all by itself. Additionally, the scenarios could each stand on their own as separate posts. To avoid turning a blog post into a book, I shall fragment these articles a bit.

Essential Goals for a Good Virtual Network

If I had to narrow down what one should hope to gain out of an effective virtual networking environment to two requirements, it would be these two: Segregation of services and redundancy. In order to obtain the best performance possible out of your virtual network setup, it is best to try to separate the various types of traffic that will travel through your server’s physical network interfaces – LAN traffic, vMotion, management, and storage. However, this should be done with an eye toward redundancy – ensuring that if a physical interface fails, there is another one available for fail over.

The goals of segregation and redundancy can be achieved with varying degrees of success based on how many physical NICs your server contains, and how you choose to distribute these various services. Obviously, the more NICs you have the better. Personally, I’d recommend no less than four NICs in an ESXi host in order to achieve the minimum levels of redundancy and segregation, and ideally, eight would be best. Of course, if you have a DMZ in which you will need virtual servers, you may need even more. However, there are ways of getting by with less, and I shall attempt to give some examples of each scenario. Bear in mind that this is in no way an exhaustive list, and really only reflects my opinion on the matter.

More on Segregation

Ideally, according to everything I’ve read on networking best practices, it is best to keep all of your various types of network traffic separate either physically or via vLANs. This is done both for security reasons and to increase performance. For example, you don’t want traffic like iSCSI, which is very I/O intensive traveling across the same pipes as your LAN traffic. Also, you don’t want users to be on the same network subnet as your management interfaces for your servers as this would pose a security risk.
From a small business perspective, however, a problem I see with this is that quite often, small businesses do not possess or can’t afford the equipment needed to properly implement this kind of design – especially if you just dropped a pile of cash on servers and storage for your virtualization project! . I’ve tried to come up with various ways to implement this approach myself in my own environment, but certain obstacles, such as lack of equipment to route between the different subnets that such an approach would create, has stopped me in my tracks. Furthermore, I have yet to see a small business that keeps their servers on a different subnet from their users.

The only thing that definitely needs to be kept separate is storage traffic. You are more than likely going to be using iSCSI or NFS in a small business virtual infrastructure. These protocols both run over IP networks, and are very I/O intensive. In order to ensure best performance, every measure should be taken to keep this traffic separate from LAN traffic. In my opinion, the best way to do this would be to use a separate gigabit switch (preferably one that supports jumbo frames) to create a private network for storage traffic.

Now that that is out of the way, on to the network scenarios, which as I mentioned earlier, will be in the next post!

Although virtualization is often touted as the most cost effective way to run your datacenter, the initial costs involved in rolling out a proper vSphere environment can actually be cost prohibitive. The largest part of that cost is, of course, storage. A SAN can be very expensive, and often after purchasing the servers, there is little left in the budget for proper storage. Sure, you can leverage local storage using a VSA like the vSphere storage virtual appliance, but to truly take advantage of all that virtualization has to offer, the best way to go is to find some way to obtain proper shared storage (plus, the vSphere storage appliance is expensive). There is no shortage of devices to fill this gap. A great many NAS boxes will do iSCSI. Boxes, such as the ones available from iOmega can be excellent alternatives to larger, enterprise class SANs, especially for the small business looking to virtualize.

In a proper virtual network design, you should keep storage traffic, such as iSCSI separate from the rest of your LAN. Still, you need a way to manage the storage device from the LAN. The larger SANs make this possible by providing dedicated management interfaces in addition to redundant interfaces for the actual storage traffic.  The problem with the smaller NAS solutions is that they usually only have one or two network interfaces. In the case of a NAS box with two network interfaces, you could dedicate one to storage traffic, connecting it to your storage network, and the other for management, connecting it to your LAN. However if you want redundancy in your storage network – using both interfaces for storage traffic, or if you just have one interface on your NAS, you will be left with no easy way to manage it. Sure, you could temporarily connect a laptop to your iSCSI switch, assign it an IP address in the same subnet as the NAS’s interface(s), and manage it that way, but that could be inconvenient sometimes – or even impossible if you aren’t physically in the datacenter where the storage is located. Not to fear, though. I have come up with a trick!

*Bear in mind this is from a small business perspective. I am assuming a physically separate storage network and no route from the LAN to it – no vLANs or anything of that nature.  In my own environment, I don’t have the proper equipment to do this (like a good fast router with multiple interfaces or a layer 3 switch), and neither do the few friends I’ve assisted with their virtualization initiatives.

In a typical virtual network design, you would probably have a vSwitch dedicated to storage (like iSCSI), with no port groups for VM traffic. The solution here is simple:

1. Create a virtual machine port group in your storage vSwitch. Name it something recognizable – like “Storage Management”.
2. Add a second virtual NIC to a VM of your choosing, and from the “Network Label” in the virtual NIC’s settings, choose your newly created network – in our case, it would be called “Storage Management”
3. From within the VM, assign the newly created NIC a static IP address in the same subnet as the interface(s) on your NAS.
4. Now, all you have to do to manage your NAS is to remote into this VM, and either install and run the NAS’s management tool (if it isn’t web based), or use the VMs web browser to management (if it is web based).

The only thing to bear in mind is that when you create new VMs or virtual NICs from now on, you will need to be careful to choose the right network to connect them to – whereas before there was probably only one choice.

As is my usual custom here, I must bow ask: DO you have any nifty tricks (or even a better way to do this) that can assist our small business brethren?

Fin

My vSphere trial license in my lab environment is about to expire. No problem, I’ll just start over. After all, vSphere will run for 60 days un-licensed, so I can just start over. I can back up all of my VMs, reload ESXi on my hosts, re-configure vCenter, put my VMs back on, and completely re-do all of the work I already did. Not a big deal at all – reload everything, and I’m good… for 60 days! (I hope you can detect that this is dripping with sarcasm). If only VMware had a way for hobbyists and enthusiasts, as well as IT professionals to legally run VMware software in their lab environments without having to pay full price.

Microsoft has such a program – it’s called Technet. Technet is awesome. For about $250.00 a year, I get 5 copies of every single piece of software Microsoft makes to use for testing. Technet plays a crucial role in any experimentation I am able to do. So why doesn’t VMware have such a program? After all, they have almost a cult following of dedicated IT pros who are quite passionate about their products, and who would surely benefit from a program like this.

Apparently, from what I understand, VMware had a program similar to Technet at one time called VMTN subscriptions. While I was cruising the interwebs last night, I ran across this article on Duncan Epping’s Yellow-Bricks blog. A thread in the VMTN forum posted by Mike Laverick started the ball rolling, and according to the article on Yellow-Bricks, VMware is looking into reinstating the program.

This would be HUGE for the hordes of dedicated VMware fans, who, truly are the driving force behind what makes VMware so successful. We need this! Plus, for those starting out in virtualization, the benefit of being able to affordably get their hands on the product, and extensively explore everything it has to offer would be immeasurable. Not to mention, the countless blog posts (can we say free advertisement?) this would spawn since now we would have adequate time to be able really to refine our lab environments. Quite often, I try not to get too far with my lab because I know I’ll have to start over or kill it soon.

If VMware can bring back the VMTN subscription service, it will only further prove what we already know – VMware cares about and listens to its customers. I, for one, support this whole-heartedly. Who’s with me?

There’s more to virtual networking than can be covered in a single blog post, so this will be the first of several. Bear in mind, that I am certainly not an expert (hence the name of my blog) at virtual network design. Also, since my focus here is, as always, small business, I will try to focus on implementation of virtual networking in what I’ve found to be typical small business environments. In this first post, I shall attempt to de-mystify virtual networking concepts, and give sort of a broad overview. For the purposes of this article, we will focus on virtual networking on a single ESXi host rather than vSphere as a whole.

A Virtual World

Often, to explain a difficult concept, it is best to use a metaphor. I can think of no better metaphor than to compare virtual environments to the environments you might find in an online role-playing game. In these games, you have virtual people, virtual shops, virtual forests, virtual towns – virtual versions of many things you would find in real life. A virtual networking environment is no different. Inside every ESXi host, you’ll find virtual versions of just about everything you’d find in a physical network – virtual servers, virtual switches, and perhaps even virtual firewalls and routers. It is like an entire datacenter contained inside a single server. Let’s examine some of these components more closely:

Virtual Switches

In any network, the device that glues the whole thing together is the switch. Physical switches allow you to connect all of your PCs, servers, printers, etc. together using wires. A virtual switch is no different in that it allows all of your virtual servers and PCs to be connected together, sans the wires, of course. Just as you connect the NIC on a physical machine to a physical switch, in the same way, you connect the virtual NIC on your virtual machine to a virtual switch.

If you take a look at the network adapter settings under the virtual machine properties for one of your virtual machines, this is where you connect the virtual NIC to a virtual switch. Here, you have check boxes to connect or disconnect the virtual NIC and a drop down box that lets you select the virtual switch to which you wish to connect the virtual NIC. Any virtual switch that contains a virtual machine port group can be connected to by the virtual NICs of virtual machines (more about port groups later).

Uplinks

In order to connect your virtual switches to the rest of your LAN, you must specify an uplink. This is done by adding one of your ESXi host’s physical NICs to a virtual switch. In doing this, all traffic that flows back and forth between your virtual servers and your physical network will go through the physical NIC you specify as your uplink. Basically, in the same way that you would connect two physical switches together with a wire, you are using a wire to connect your virtual switch to a physical switch on your network. You can have many virtual machines attached to the same vSwitch, using the same uplink to the physical network.

The picture below illustrates how virtual machines (VMs) are connected to virtual switches (vSwitches), and how physical NICs are used to uplink the vSwitch to a physical network.

Port groups

In ESXi, port groups specify what type of traffic is handled by a vSwitch. There are two basic types of port groups – virtual machine and VMkernel. A virtual machine port group does as its name suggests – it handles LAN traffic for virtual machines. VMkernel ports are used to handle traffic other than virtual machine traffic, such as management traffic, vMotion traffic, and iSCSI and NFS. In fact, when creating a VMkernel port group, you can specify which of these types of traffic is handled by each particular VMkernel port group. Additionally, you can specify active and stand-by uplink NICs for each of your port groups, which is vital in being able to segregate the various types of traffic, as well as providing a method for failover in the event one of the NICs goes bad.

Below is an example of a very simple setup. This is by no means a good way to configure your NICs – I’m only using it for demonstration purposes. This is one of the hosts in my lab with no external or shared storage. The ESXi host has twoNICs. I have one vSwitch configured with two port groups – one for virtual machines, and one for VMkernel. As we can see, I have both NICs assigned to this vSwitch. If we were to dig in further we would see that I have one NIC set as the active NIC for the virtual machine port group, and the other NIC assigned to the VMkernel, using eachother as fail overs. My next article will have more on use of port groups and effective use of multiple NICs.

Conclusion (for now)

As I mentioned before, virtual networking can be extremely complicated. It was my hope, with this article, to lay the ground work for better understanding of virtual networking. I believe that understanding anything on a broad level is important before diving into the details. I sincerely hope these articles will be helpful to someone. After all, it was seeing folks who are new to virtualization trying to grasp these concepts that prompted me to write this.

In the next article, I will attempt to explain how to effectively utilize port groups based on the number of physical NICs available.

Anyway, if you are new to virtualization, what are some hang-ups you have run across? How can I help? If you are not new to virtualization, did I explain this well? I could always use some sage-like advice from those who’ve been around a while!

Apparently, just one day before I wrote my article entitled “Virtual Desktops are Not Ready for Us”, it was announced at VMworld in Copenhagen that nVidia and VMware are teaming up to provide a way for virtual desktops to leverage nVidia’s quadro graphics processors installed as cards in the physical ESXi host. The technology is being called “Quadro Virtual Graphics Platform”.

I have not seen many details as to when the technology will be available, pricing, or which servers are supported for the Quadro Virtual Graphics Platform. Although, I do know that it will require one card for each VM that will be using the  technology. This will limit the number of “Virtual Workstations” that can run on a particular host to the number of expansion slots available in the host server.

This is exciting news to those of us who are IT admins for civil engineering firms (or maybe just me?). Ever since the first time I learned about virtual desktop infrastructure, I have been saying that there needed to be some way to leverage graphics hardware from within a VM in order to make it a viable option for graphics and CAD professionals. I though that perhaps in the future this would become a reality, but it looks as though the future is closer than I thought!

Links

An article on vmguru.nl with some good information about the Quadro Virtual Graphics Platform – this is where I first read about it. Thanks, vmguru!

nVidia’s blog post regarding the Quadro Virtual Graphics Platform

A Press Release from VMware about the Quadro Virtual Graphics Platform

What I Hoped to Accomplish

I sincerely hoped to revolutionize the way in which we do business. Particularly, I was enticed by the idea of being able to have locally hosted desktops brokered by VMware View, over the public internet, thus doing away with the need for our costly T1 WAN connections. Additionally, I had hoped to make life easier for my users in our remote offices by making slow data access over the WAN a thing of the past. Ideally, if I could have all desktops local, sending only screen refreshes over the internet to my users in the other offices, it would allow them to enjoy the same data access speeds that local users in our main office have come to expect. At the same time I could justify the cost of implementation by saving my company literally thousands of dollars a month on out T1 WAN links that my remote users currently use to access their data. In just about any other type of business, this would be the way to go, but in civil engineering there are challanges that make desktop virtualization somewhat less attractive.

The Challanges

By far, the biggest challange we faced during our experiment (and I knew this would be an issue up front) can be summed up by one name and three syllables: AutoCAD. More specifically, the version of AutoCAD we use is called AutoCAD Civil 3D, and it is a hog. In order to effectively run Civil 3D, an ordinary business class desktop won’t do. You need a workstation class machine. My typical configuration for a CAD workstation is a quad core Xeon processor, 8GB of RAM, and an nVidia Quadro FX graphics card. The price of such workstation often approaches that of a server.

In order to get a virtual desktop to run Civil 3D at even a somewhat acceptable level of performance, I had to create a monster VM. I started out with 4 vCPUs, and 4GB of RAM. The user who was using the desktop complained that Civil 3D was performing sluggishly, so I increased the resources. The configuration that was even bearable for AutoCAD use was a VM with 6 vCPUs, and 6GB of RAM, 3D turned on, and 128Mb of video memory. On a physical host with dual quad core processors and 8GB of RAM (it’s all I have for testing), this ate up nearly all of the system resources.

To my mind, one of the advantages of desktop virtualization (or server virtualization for that matter) is consolidation ratio – running many VMs on few peices of physical hardware. Since our typical desktop workload necessitates running very large VMs, unless we purchased very big, expensive servers on which to run the desktops, consolitation ratios go out the window. Even with a powerful server I wouldn’t imagine we would be able to run very many AutoCAD workloads on the same server. All hope was not lost, however, since I had another trick up my sleeve.

Plan “B”

It was apparent that I wasn’t going to get what I needed out of a virtual desktop, but that was no reason to give up just yet. VMware View can also broker connections to physical PCs. After a bit of research, I discovered that in order to get the desired desktop experience using VMware View to connect to a physical desktop, I would need to purchase a PCoIP host card. This would allow me to use the PCoIP (PC over IP) protocol to connect to my physical workstation, and let it do all of the video rendering. In this way, even though I couldn’t get the consolidation that virtual desktops offer, I could still re-locate my users PCs to our data center, and hopefully give them the same benefits that my local users enjoy. Apparently, not so.

I ordered the PCoIP host card – an EVGA HD02. I installed the card into a Dell Precision Workstation T5500, installed the host driver that View needs to connect to it, and added it to my pool in VMware View. Now, I try not to strongly criticize any product when I write, but the video performance, on a local gigabit network, was horrid. Sure, I could tell that the machine was actually performing better than its VM counterpart, but the video streaming to my VMware View client was quite choppy (for lack of a better word). You can opt to use Windows’ cursor, or one provided by the PCoIP driver. I chose the latter since the Windows one was unbearably laggy. Even worse, the large crosshairs in AutoCAD that my users like to use were so slow that they were nearly unusable. I let a couple of my CAD power users, who had tried my VM earlier, try it, and, to put it bluntly, they hated it. The video from the VM actually performed BETTER.

I do recall reading that just one or two versions ago, hardware PCoIP through VMware View was “experimental” – perhaps it still is. I haven’t put this issue to rest yet, though. I have tried a firmware update to my PCoIP card. I’ve tried different types of encryption. I’ve tried turning off SSL. I’ve tried everything I could find that even remotely sounded like it might work. At the time of this writing, I have a ticket in with Teradici, the manufacturer of the PCoIP chipset on this card, in hopes that they may have a solution for me. If I find out anything helpful, I will post an update here. Still, this is a bit disappointing since the card wasn’t cheap, and Teradici’s target audience is users like…well…mine!

Other Challanges

We deal with a large amount of printed material such as engineering plans and contract documents. It is a very frequent occurrence for us to have to scan something. In fact, we scan thousands of pages a month. Many of my users have Fujitsu ScanSnap desktop scanners. Using these scanners through VMware View over the internet is painful to say the least. We ran into some other smaller things that, like the scanning issue could be overcome with a little creativity, but the big issue mentioned above really makes the smaller ones superfluous.

Conclusion/Other thoughts

If you work for an accounting firm, an insurance company, or any other business that doesn’t require $2500.00 machines to run your desktop applications, then run, don’t walk to go virtualize your desktops. It will change the way you do business. For that matter, there are even use cases in our business where virtual desktops might be beneficial – I may still give it a serious look for our secretaries, receptionists, accountants, materials testing lab workers…IT managers. However, the vast majority of my users need more power that we can squeeze out of virtual desktops in a cost effective manner. Virtual desktops are simply not ready for the civil engineering world!

As is my custom now, I must ask… have any of you tried this? Have you been successful at virtualizing AutoCAD workloads? I’d love to hear about it if you have!

In my previous article on Acronis vmProtect 6, I wrote about some issues I had with the software. Particularly, I expierenced the problem described here: http://kb.acronis.com/content/25536. Essentially, the problem is said to occur when change block tracking is enabled when backing up VMs with certain file systems – to be more specific, Linux file systems (the KB article says “certain file systems”, but Acronis told me Linux). I found that, at least in my situation, this is not the case.

I removed all of my Linux machines from my backups, split my backups into groups, and created new backup archives. All but one of my jobs succeeded. I watched the job that failed while it was running, and even though it got to 100%, it still logged a failure. I checked the logs, and lo and behold, there was the same set of errors from before. Since my VMs were in smaller groups, I was able to easily narrow down the offending VMs – both were Windows VMs. One of these servers is running Filemaker server,  a database server, on Windows 2008 R2. The other VM is running ArcGIS server, a server that provides maps and associated data, whose data is kept in a SQL express database. This server is running Windows Server 2008 R2 as well. In either case, neither Linux nor a different type of file system was the culprit (just NTFS!).

I’m still not sure what about these VMs was causing the backups to fail. However, I was able to work around the issue in order to get these VMs backed up. In the above referenced KB article from Acronis, it is suggested that change block tracking (CBT) is causing the failures. To test this, I created a separate backup job containing only these two VMs backing up to their own acrhive. The initial full backup was successful, but the incremental with CBT turned on failed. I turned off CBT, and the incremental backup succeeded.

Now, all of my backups are humming along quite nicely!

On the way out of Acronis’ party at VMworld was a table full of gift bags, and everyone who attended the party recieved one. “All right!”, I thought, “more swag”. In the bag was 2 items – a stopwatch (which I actually used this past weekend to ensure I passed my PT test at my other job) and a credit card sized flash drive. I thought perhaps it was trial software, but upon further inspection (and verification from Acronis), it was a full copy of Acronis vmProtect 6. A couple of weeks ago, I began having trouble with VMware Data Recovery (trouble that is 100% related to my choice of  backup storage), and so I decided that it would be a good time to take a serious look at vmProtect as a replacement. I’ve experimented with a few different methods of backing up my virtual infrastructure, but thus far Acronis vmProtect 6 is the most elegant, simple, and flexible solution I have come across. That isn’t to say it couldn’t use improvement, but since I first installed it, I’ve been thoroughly impressed with Acronis vmProtect 6. Let’s take a closer look:

Installation and Configuration

vmProtect 6 can be installed in one of two ways – as a virtual appliance or as an agent running on a Windows server. I opted for the virtual appliance, which is deployed by running the vmProtect installer from a workstation. The applicane is Linux based, and has a very simple graphical console where basic settings such as IP address and local storage can be configured. After IP settings have been configured, all interaction with the appliance is done via a very easy-to-navigate web interface. Before you can begin creating backups, you must first provide the vmProtect software with your license keys, and point it at either your ESXi hosts or your vCenter server – the latter of which is preferred so vmProtect can keep track of VMs that might vMotion to other hosts. After this initial configuration, you’re ready to get started backing up VMs!

Creating Backup Jobs

Backing up VMs with vmProtect 6 is the most intuitive process I have ever seen in a backup solution of any kind. Essentially, to back up a VM, you must answer 4 simple questions:

1. What do you want to back up? – This is where you choose which VMs, hosts, or clusters you want to back up.

2. Where do you want to back it up? – This is where you tell vmProtect where your backup storage is. You can use a network share, a locally attached vmdk (virtual appliance), or a local disk (WIndows agent). In particular, I like the fact that, unlike VDR, which has a 500GB limit for CIFS destinations, vmProtect doesn’t discriminate in this area. My destination is a Drobo Pro attached to a physical Windows server.

3. When do you want to back up? – This is where you provide a schedule for your backups.

4. How do you want to back up? – This is where you set the cleanup and retention options for your backup job.

It’s that simple. Follow these four easy steps, and you’re ready to go!

Restoration

The process of restoring a VM with vmProtect 6 is essentially the same as the backup process – what? and where? Since, to my mind, virtualization backup solutions should be a reliable means of disaster recovery, the only restore task I performed was to simulater a disaster recovery scenario. vmProtect performed flawlessly in this regard. I was able to deploy the vmProtect virtual appliance to my lab environment, point it at a backup archive containing the VM I wanted to restore, and restore the VM to a completely foreign environment from it’s original home.

In addition to a typical whole-VM restore, you can also perform recovery of individual files from you backed up VMs, making vmProtect an ideal replacement for a traditional file backup solution. Also, vmProtect allows you to very easily run a VM from one of your backups. Another product I’ve seen has similar functionality, but Acronis’ approach is much easier to execute.

Performance

Considering my backup hardware setup which, in my opinion, can be quite slow sometimes, Acronis vmProtect 6 performed very well (and dare I say.. fast?). When backing up my smaller application server VMs, I saw speeds that ranged from 12MBps to 20MBps. However, for whatever reason, larger VMs, like my file servers and my Exchange server backed up much more slowly – around 5-6 MBps. Relative to the speed at which vmProtect was able to back up my application servers, 5-6 MBps may seem slow, however, this is actually quite a bit faster than file backup solutions I have used with this same hardware backing up this same data. That being said, even though the initial backup of my file server may take a whole day, using the change block tracking mechanism, all subsequent backups are “incrimental forever”. Past the first backup, the backups will be tiny, and will not take long to complete.

Also worth noting, while I was experimenting with vmProtect 6, I was leery of performing backups during work hours because I was unsure of how it might affect performance. However, waiting until the night time to see what my backup jobs would do got old in a hurry, so I decided to let the jobs run during the day. I am happy to report that running backups with vmProtect during business hours did not cause any noticeable performance degradation in my environment.

De-duplication

The backups Acronis vmProtect creates are tiny! I looked through all of my VMs,  added up all of the disk usage, then compared that to the size of the backups on disk. The size of all of the VMs I backed up was 966.34 GB, compared with a backup size of 587.85. That’s a substantial reduction!

Pain Points

Did I just write “pain points”? Oh no… I’m starting to sound like one of those corporate sales people. I digress. My experience with Acronis vmProtect 6 was not without problems. In particular, I ran into this issue quite a few times. This is apparently a known issue with backing up Linux file systems using change block tracking, which according to Acronis will be resolved in the next version. Even after following Acronis’ guidance on the issue, I still had trouble getting backup jobs to complete – especially the incremental backups. After one of these failures, I could never get that same job to complete again.  It seemed that the failures were most prevalent  when I was trying to back up all of my VMs to the same archive with the same job, so yesterday I split them up into groups. All of my backups last night succeeded, but the real test will be tonight when the first incremental backups run (I will give an update afterwards).

Features that would improve the product

I would like to see some more advanced scheduling options. For example, it would be very helpful if I could schedule one job, then have the other jobs execute after the first one completes. This would be very helpful in the aforementioned situation where someone might need to have multiple backup jobs. Also, there is no way to specify an order in which VMs get backed up. This functionality would be useful for someone who wanted to prioritize which VMs get backed up – so you could schedule the most important VMs to back up first. Ideally, to overcome this, I could create individual jobs for individual VMs, but this approach would be difficult to orchestrate since I would have to estimate the amount of time the jobs would take to complete so they don’t overlap.

Conclusion/Other Thoughts

First, I would like to thank Jerome Boutaud from Acronis, who has been very helpful to me during my testing of vmProtect 6. If his enthusiasm and dedication is in any way representative of Acronis as a company, then rest assured you won’t go wrong with Acronis.

As mentioned before, even with the issues I ran into, Acronis vmProtect 6 is a very compelling product. From the moment I began using it, I said to myself, “this is the VM backup product I’ve been waiting for”. I can confidently say that this will be my backup solution of choice. What about you? Ever used vmProtect? What do you think? Like something else? I’d love to see some comments!

A little background about why I (or anyone for that matter) would want to do such a thing:

The vCenter Server virtual appliance simplifies the deployment process for vCenter, and drastically reduces the amount of time it takes to deploy and configure vCenter. Plus – and this is a big one for me – it runs as a Linux virtual appliance, so there is no need to use up a Windows license.

The initial answer to my question was that there is no easy way. I thought that if I wanted to migrate to the appliance that I would have to start fresh, but then one of the presenters told me about a “fling” that is available from VMware labs (I will link to the fling at the bottom of this article) that will migrate your clusters, datacenters, resource pools, configuration settings, and such from one vCenter to another. The fling is called InventorySnapshot. The only thing it does not migrate is historical and performance data, but if you are not concerned with that, this is a very cool way to migrate to the appliance.

I won’t go into details on the actual usage of the InventorySnapshot fling since the authors have already done that. I will, however, briefly describe my expierence using the fling in my lab.

My lab at work was running vSphere 4.1 with vCenter running on Windows 2003. The fling, which is basically a Java app that takes information about your existing vCenter configuration, and generates a PowerCLI script to migrate all of your settings from a source vCenter to a target vCenter, was very simple and straightforward to use. I deployed the new vCenter virtual appliance into my existing lab environment, configured it, and using the InventorySnapshot fling, I was able to migrate all of my inventory and settings from my old vCenter server to my new vCenter appliance in just minutes!

The Bigger Picture

The ultimate goal is to eventually upgrade my production environment to vSphere 5. VMware gives a general overview here on how to do just that. Using their steps as a guide coupled with this tool, the upgrade process for someone who also wants to migrate to the vCenter Server Virtual Applicance might look something like this:

1. Deploy the vCenter appliance
2. Migrate your inventory using the InventorySnapshot fling
3. Shutdown the old vCenter server
4. If update manager was installed on the old vCenter (as mine is), install the new version of update manager on another Windows box somewhere *
5. Use update manager to update the hosts (with the VMs vMotioned off to other hosts, of course)
6. Upgrade VMware tools on the guest OSes
7. Upgrade virtual Machine hardware on VMs to verion 8
8. Upgrade datastores to VMFS 5

Obviously, some considerations should be made, like making sure all your hardware is on the HCL for vSphere 5 and ensuring any custom VIBs you are using are available for ESXi 5.

The Asterisk *

Wondering what the asterisk was for on step 4? Well, in the Q and A part of the aforementioned VMworld session, I asked another question, “Is update manager included with the vCenter appliance?” For you see, up until that point, I was under the impression, for whatever reason, that VMware update manager has to be installed on the same server as vCenter. Sitting next to me in that session was Forbes Guthrie, one of the authors of the vSphere Design book (I promise I’m not trying to name drop to make myself look cool – I want to give credit where it is due). After I asked my question about update manager, he took a moment and explained to me that update manager does not have to be installed on the vCenter server – that it is just a windows application, so I could still use it with the vCenter appliance.

My Point?

This story only serves to further illustrate my claim that attending VMworld is a must for anyone using VMware’s products. After asking only two questions, my idea of how to upgrade to vSphere 5 went from clear as mud to clear as day!

I’m still waiting before I upgrade to vSphere 5 until Dell releases their custom ESXi bits because of an issue I ran into in my lab on a Dell server – but that is a different post for a different day. I want to upgrade so bad I can taste it (and it tastes yummy!). What about you? Have you performed an in-place upgrade to vSphere 5? I’d love to hear about it!

Link to the InventorySnapshot Fling from VMware Labs

http://labs.vmware.com/flings/inventorysnapshot

Me and the Monster VM

My Friend Ian Selling Out for a Solarwinds Polo Shirt

My View Upon Entry to the VMworld Party

The Big Screens Used in the VMworld Party and Keynotes. These Things were massive!

Shot During the Killers Concert

Picture of the VMworld Labs Dashboard. The big fish are datacenters, the little fish are vApps.

Far off shot of the VMworld labs. Hundreds of thin clients talking to VMs in the public cloud. Very Impressive

A Shot of the Solutions Exchange before opening time on Thursday

Ian Wearing one of the Fezes they were giving out at the #VMunderground WuPaaS

Shot right before Paul Maritz Keynote