Yes, I'm still alive. It's been over three months now without blogging, and yes it's crazy!

Apart from being a Sr.Consultant and a TAM at VMware with 100% utilization in this huge and active region, I've been also doing lots of reading and studying lately to prepare for the VCAP exams. Not to mention my growing obsession with the Redwood project whether through testing and evaluating it, or following its daily discussions on our developers & PMs mailing lists. Add all that to the frequent traveling and you won't find a time to scratch your head!

I won't take much time in this introduction, so straight to the point: I decided to start a newsletter (or whatever they call it these days). I have to admit though that this is not my most original idea. Firstly I was inspired by one of my colleagues in VMware (Michael White – who's also one of the SRM legends out there). He has an internal weekly newsletter with lots of invaluable information and I really enjoy reading it! I thought of doing the same on my blog, but I wasn't sure about this idea until I started receiving another mind-blowing weekly newsletter written by our CTO, Steve Herrod. At that point I realized that I'm a newsletter person and I do like the idea of having everything consolidated in one place at a time. I won't do this letter however on weekly basis, at least at the beginning. Let's make it casual every two weeks or so until I see my readers feedback.

At least I get to blog, and that's all what it matters. Here we go.

News flash: vSphere 4.1 is released!

Yes the debate around the numbering (4.1 Vs. 4.5) is finally over. Most of this debate was driven mainly by the fact that it's a quite powerful release with major enhancements and rich features normally found only in major releases. There is no point of copying and pasting the release notes here if you can read it directly on VMware's website. Here you go:

• For ESX Classic : http://www.vmware.com/support/vsphere4/doc/vsp_esx41_vc41_rel_notes.html
• For ESXi : http://www.vmware.com/support/vsphere4/doc/vsp_esxi41_vc41_rel_notes.html

The password issue with ESX/i 4.1

You've probably heard about the 8-char password issue with ESX/i 4.1, but in case you haven't heard yet about its solution, you can find the details here in this KB article:
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1024500

VCB Support in vSphere 4.1

I had a couple of customers asking me about the VCB support and whether it has been removed, and the answer is no. VMware extended the support in 4.1, but I personally recommend moving to the vStorage API for Data Protection (VADP) in case you are upgrading or starting a new vSphere environment.

From our internal mailing list I also quote this: "Several backup vendors have released VADP based backup solutions. These include VMware Data Recovery 1.x, Symantec NetBackup 7.0, Symantec Backup Exec 2010, CA ArcServe 12.5, EMC Avamar 5.0, IBM TSM 6.2, Veeam 4.0 and VizionCore 4.5"

vSphere on IBM BladeCenter H Part II

I've been getting many questions about the second part of the BCH, and when I will release it. I actually finished nearly all the Visio diagramming, but the problem is simpler than this. The HX5 and Virtual Fabric expansion card from IBM are not been certified yet by VMware! I was really hoping that both will be on our HCL by the release of vSphere 4.1, but nothing so far. I see no point to publish my article if you won't be able to use it. Besides, it can cause lots of unnecessary confusions to the partners and customers. I won't leave you disappointed however, and I'll direct you to an awesome new redpaper written by IBM on the Virtual Fabric.

http://www.redbooks.ibm.com/redpapers/pdfs/redp4673.pdf

Mobile Noter for iPad!

Every day I find more value for the iPad! I'm not really into games or apps in general, and my main reason for buying an iPad was PDF reading and web surfing while traveling, but I have to admit that it has a lot more value than that. A couple of weeks ago I came to know about this cool App called "Mobile Noter" and it was like a dream came true! I used to take notes and document things on OneNote since it was released back in 2003, and till this moment I still do. The MN simply allows you to synchronize your iPad with either you desktop over a WiFi network, or to the cloud over 3G or WiFi. I can now have all my notes on the go with me either on the iPhone or iPad, and also keep them all synchronized.

New books:

Interesting 2 books talking about the forensic investigations in our virtualization and cloud computing worlds.

• A Digital Forensic Investigator's Guide to Virtual Environments
  http://www.amazon.com/exec/obidos/ASIN/1597495573
  
• Digital Forensics for Network, Internet, and Cloud Computing
  http://www.amazon.com/Digital-Forensics-Network-Internet-Computing/dp/1597495379/
  

To the partners

I know there are a quite big number of VMware partners subscribed to my blog (as I see from the email domains), so I'll try to keep you updated with any important news whenever applicable.

A new version of the HealthAnalayzer appliance has been released with strong support for the vSphere best practices. Make sure to download, test and patch this appliance to the latest updates before going to the customers. Great tool as it has always been!

Important: In case you haven't done that already, please take a moment to read the first post of this series.

Due to the insane number of expansion modules/options available in the IBM BladeCenter H, I had to split this post into two parts. In fact, I was initially planning to have around 12 different designs for vSphere on BladeCenter H (yes twelve) but I then I started to shrink and skip some designs to fit as many scenarios as possible in a reasonable two-part article. With that said, the following is by no mean a list of all the possible design scenarios you can achieve with this hardware platform. If you started the "mix and match" game, you may literally end-up with uncountable possibilities!

The Diagram

Here is some important notes before using the diagram:

• You will see different configurations in this post and the relevant architecture of each configuration in the diagram. This is done through the PDF layers, which basically means than you should *not* activate more that more layer in the same time.
• By default, "Configuration 1" is the first active layer when you open the PDF file. You can show/hide the other layers by simply clicking on them. Again, you should only show one layer/configuration at a time.
• You will always see two boxes on the right side of the diagram, the upper one will show you the current vSphere configuration, and the lower one will show you the relevant hardware configuration. You should typically start looking at those two boxes before scanning through the diagram to understand the "ingredients" of the design.
• At the time of writing this post, you will see four configurations only in this diagram, however, when I publish the second part, there will be additional configurations that I will add to the existing ones. In other words, the diagram will be updated later on to have those additional configurations so keep that also in mind.

The common design and configurations

You will find in most of the configurations a common design, unless I explicitly state otherwise. I will list them here in details:

The Clusters:

You will see two type of clusters:

• Management Cluster: it is typically a two node cluster running the management and infrastructure services. For example, if you want to virtualize the vCenter Server, the VM should be running on this cluster rather than the actual production clusters. Same thing holds true for other vCenter products like: AppSpeed, CapacityIQ, SRM and so forth. There are two reasons for doing that: the first, we don't want to run into the problem where vCenter Server is not accessible (there are some examples published in the community but my favorites are Jason Boche's Catch22s!). The second reason, we don't want to either affect our workloads' performance with our management virtual appliances or vice versa.
• Production Clusters: You can see here two production clusters (Cluster A and Cluster B). The take away from that is the following:
  • You don't have to stick with that number of hosts per cluster, it depends on what you want to achieve, and also on some configuration maximums that may or may not limit you.
  • The nodes have to be spanned across the two chassis as numbered and illustrated in (Config 1). There are two reasons for that: Firstly, you don't want your whole cluster to fail in an unluckily event when a whole chassis fails. Secondly, you have to keep in mind that VMware HA selects the first 5 hosts in the cluster and promote them as a "Primary" nodes, if they fail, your HA cluster fails.

The Blades:

You will see two consistent blades throughout the first four configurations, the HS22 and the HS22V. Both blade servers share the same IO expansion capabilities, however, there are a some differences between them. For example, the HS22V has no hot swappable HDD but it is superior in the memory capacity (144GB compared to 96GB in the HS22). In part-two of this article, I'll talk in details about the new HX5 and what it can bring to the table in terms of scalability.

The Expansion cards:

Every HSxx blade comes with two onboard 1Gbps Ethernet ports for basic networking. They will always show in vSphere as vmnic0, and vmnic1. These ports are in turn mapped to Bay 1 and Bay 2 in the chassis. Of course no one recommends implementing vSphere using 2 x 1GbE ports in an enterprise environment (although it will technically work), so we will use here what we call: expansion cards. There are two slots for expansion cards in any HS22/V blade, the first one is called CIOv (for vertical expansion modules) and CFFh (for the horizontal fast IO modules). The CIOv is usually used with the FC HBAs (although we will see later how we will utilize it for iSCSI connectivity), and they are mapped to Bay 3 and Bay 4 in the chassis. The CFFh on the other hand is mapped to four fast expansion modules (7, 8, 9 and 10). I say fast because this is the only card that can leverage the 10GbE connectivity (or Infinibad but it's not relevant to our series). Depending on the configuration, you will see how we will use different cards to support our designs, however, the onboard 2 x 1GbE port will be always common, and always there.

Now that we've talked about the common stuff, let's start talking about the unique configurations. Oh yes, we were just warming up!

CONFIGURATION (1):

We have in this configuration 6 x 1GbE pNICs per blade to support our MGMT, VMkernel and Virtual Machine networks. We teamed three pNICs here in a vNetwork Standard Switch (vSS) to serve the SC, vMotion and FT. The other three pNICs are teamed in a vNetwork Distributed Switch (vDS) to serve the VM networks. Let's dig litter deeper on how this is done.

As mentioned earlier, we have three type of IO ports on the blades: the onboard ports, the CIOv, and the CFFh. In order to achieve the maximum availability, we teamed one onboard port with a couple of ports from the CFFh card. In this case, if we had a failure in any IO port (on board or expansion card) we will be able to tolerate that failure.

The second consideration here is to distribute the load and bandwidth for our networks. For example, the SC network will be active on vmnic0 and standby on vmnic1. The vMotion will be active on vmnic1 and standby on vmnic0 and so forth.

You may have noticed also that we grouped the SC + VMkernel network on a vSS, while we grouped the VM networks on a vDS. The reason behind that is to ensure that you would still be able to control your SC network even if your vCenter fails. For the VM networks, you would still leverage the great enhancements and features of the vDS. This is *not* a best practice from VMware, and as far as I know there is no documentation recommending that. It is up to you whether you would go with that setup or simply have everything on a single vDS.

CONFIGURATION (2):

This is nearly identical configuration except for the IP SAN. In Config1 we were running on a FibreChannel SAN, while in this configuration we have an iSCSI. The thing to note here is that you will need to install your Ethernet expansion modules in Bay 3 & 4. We will swap also the CIOv card from being a FC HBAs to a traditional 2 x 1GbE card. Of course you will use in this case the vSphere iSCSI initiator for doing your storage networking. This is fine in nearly most cases, except the one where you will actually need to boot your ESX server from SAN.

Please also note there that you can use NFS with the same layout. Your 2 x 1GbE blade ports + the 2 x expansion modules (bay 3 & 4) will all serve your NFS requirement in a high availability design.

CONFIGURATION (3):

What you will see in this configuration is something a bit different. We are using here a 2 x 10GbE ports through the CFFh expansion card to serve "all" our networks. This card is mapped to two 10GbE expansion modules sitting in Bay 7 and Bay 9.

The trick here is this: how can you have a proper network segmentation if you are using two pNICs only? The answer, of course, is VLANS. As you see in the diagram, we have two production networks and one lab network. All these networks are tagged with a VLAN ID to flow the traffic through the vmnics to pNICS all the way to your enterprise/core switches. The ports on your core switches need to be of course in trunk mode.

Now, the second question here would be this: how can you ensure that no network will saturate the whole link and affect the performance of the others. The solution for that is to use the vSphere traffic shipping. You can simply dedicate the bandwidth to each "port group" per your requirement. Example, for SC you normally don't need more than 1Gbps. For vMotion and FT you would definitely require more bandwidth. To keep things simple, I illustrated in the diagram how the segmentation and bandwidth allocation can be distributed across the two links in an Active/Standby approach.

You will notice here also that we are utilizing the two on board Ethernet ports to have an additional iSCSI SAN (for the Lab environment for example) along with the FC SAN for your production workloads.

CONFIGURATION (4):

In the previous configuration we saw how we leveraged the VLANs to do our network segmentation and how that was quite easy and flexible. But what if the customer has a policy not to use VLANs to consolidate the networks (for a security reason as an example)? Easy, we would still be able to comply with that. Basically we will need to swap here the 2 x 10GbE CFFh card with a 4 x 10GbE card and of course add additional two 10GbE expansion modules to Bay 8 and Bay 10.

Now, what did we achieve by doing that? Two things:

1 – We are compliant with the customer requirement to have a physical segmentation between the Management/FT/vMotion networks and the production networks.
2 – We are using the vSS for our management network while leveraging the vDS for our Virtual Machine networks.

You have also here another two options that were not included in the diagram. You can make use of the two onboard ports to have an additional iSCSI SAN as we did in the previous configuration, or, you can use them as a standby ports for your Management/VM networks in case of a CFFh card failure. Do you see now what I meant above by the "mix and match game"?

Coming Soon – Part 2:

I'll talk about the new HX5 and how you can have a lot more memory or extended IOs to support special workloads or strict design requirements. I will talk about FCoE and CNAs. I will also talk about the new & promising Virtual Fabric from IBM, and how you can basically slice your pNics into almost any protocol or speed you want.

Stay tuned!

This is going to be a quite long series of posts, so I'd better make this introduction as short and compact as possible. Here is a Q/A approach, just pick up the part you are interested in, and then jump straight to the first vendor in our series.

Why I decided to start this series?

Everyone already knows the revolution the blades had brought to our industry. I'm not going to repeat here what you already know. I'm not going also to promote the blades over the traditional rack servers, or try to answer the eternity question: "scale up or scale out?". You might have already made you decision to go with blades, or still considering that, in both cases this series should help you to take your next step. My main and only focus here is vSphere. I'll never try to promote a vendor over another, and I will never try to influence your decision to go with a specific design. Go to the next Q/A to see how can you benefit from this series, or at least how I think you might do.

Who might be interested in this series?

• Consultants or Customers: if you want to have an over whole idea on designing and/or implementing vSphere on specific blade vendors.
• VMware partners: if you are a partner, you may find this series useful to support your presentations to customers. I've seen many partners who can talk fluently about their hardware products, however, they can struggle to answer very simple VMware related questions like: how should I map the vSwitches' uplinks to the blades nics, or how can I have redundancy for my networks, and soon and so forth!
• Knowledge seekers: anyone, like myself, who's fascinated by VMware and willing to understand how these incredible software technologies can run on different hardware vendors with the same level of flexibility.

What vendors will be covered here, and in which order?

Any blade vendor that is listed in the VMware HCL might be included. I say "might" because it also depends on how fast I'll be able to learn about this specific vendor technologies given the highly complex and variant architectures from one vendor to another. You should know also that I work on my own here, no help from anyone what so ever. It really takes a lot of blood, sweat and tears to understand each vendor's approach in doing things.

There is no specific order in this series, I started with IBM because it's simply the hardware platform that I have worked the most on. If you like the series/concept let me know your thoughts and feedback and based on that I'll try to prioritize vendors over others. There is no preferences for me personally.

Are you a hardware vendor?

If you work for a blade vendor and stumbled through this series, please take a moment to read the following:

• If you'd like to comment, you are most welcome to add, correct, or amend any details in my posts that are related to your hardware. However, you are not welcome – under any way, shape or form – to bash your competitors in this series.
• I can work with you to highlight anything that can make the vSphere implementation more solid, unique or innovative on your hardware. On the other hand, I will not allow on my blog any vendor to criticize the design and/or implementation options of the other vendors. In short, no FUD please.

Alright then, enough introduction and scary thoughts and let's get to it. I'll keep the following list up-to-date to always reflect the new posts of this series.

• vSphere on IBM BladeCenter H

Announcement:

Effective March 1st 2010, I am joining the PSO team at VMware as the first Senior Consultant covering the Middle-east region.

Now that the word is out, I guess everyone reading these lines will say something like: “Here we go again, another blogger joining another vendor. The trend continues.”

Well, you might be right at some level. I am a blogger. VMware is a vendor. What else would be different?

What is different here, at least in my opinion, is the timeline and circumstances that this whole story developed through. My original plan was to write a pretty huge post and tell you everything about it. How the dream started when I was watching the VMworld 2008 opening keynote. How the opportunity represented itself from the least expected way. How I went through the longest, most challenging and exciting interview process I have ever experienced throughout my career.

I said “my original plan” because I had to come up with an alternative. Unfortunately I’m just being hyper-sensitive now towards anything that I want to say or disclose about VMware. You know this feeling when you start in a new place, where you don’t know initially what you can and can’t talk about in public? Hopefully it will be a short period before I start getting the essence of the VMware internal culture and be more comfortable to share with you my experience in this great place. Until then, all what I can tell you is that I was approached by Duncan Epping back in July 2009 for an opportunity in the PSO team.

Yes, it was July 2009, before there was even a trend in the first place. This huge gap between now and then wasn’t really up to me or to VMware. It’s the complicated system of sponsorship that we have in this part of the world and all its related formalities. I was crazy patient, and they were very determined to have me. But I’m not here to bore you about these details. What I want to do instead is to acknowledge the huge efforts by Duncan throughout the process. I would have loved to talk in details about that, but again, I find myself in the same situation where I don’t know if I can elaborate more or not. Regardless of all that, let me take a quick moment here to tell you about this true legend, and why I pride myself on being referred to VMware by him.

I don’t look at Duncan as the number one blogger in the community (three times in a row and counting), or as someone who has an unmatchable visibility and influence (check his IOPS post for example), or even as someone who has a great deal of respect and admiration from everyone I’ve known in (and outside) the community. It’s something completely different than all that. It is simply his “passion” for the technology that really differentiate him from the crowd. This is the one thing that always stands out to me about Duncan.

I know brilliant people, I mean literally “brilliant” people in our community with an incredible experience and knowledge that I might never even achieve any time in my future career. But I have never (I repeat: never) saw someone among those people whom I thought for one second to have more passion than me for the virtualization technology in general or VMware in particular. Duncan was (and still) the only exception to that. Every little blog post, email or even tweet I see from him, I always see someone who has passion and dedication for what he does more than anyone I have ever known.

That is why I will always look up to him for inspiration, and that is why he will always be my number one in VMware.

Now that I’m approaching the end of my post, I’d like to take this chance to thank Deepak Narain for his continued support and for sticking up for me. I wouldn’t have reached this place without all your help, even for the very little logistic things that you were voluntarily taking care of to get me on board as soon as possible. I’d like also to thank Vegard Sagbakken, Frank Denneman and Aaron White. They were among the people in VMware who knew about my delayed recruitment process, and were very kind to follow up with me on its progress.

Lastly, and most importantly, to my dear blog readers: it was through your encouragement and positive feedback that I was able to keep this blog running, and it was through this blog that I got the visibility and exposure for VMware to hire me. With that said, I will always do my very best to keep my content here as unique, informative and educational as possible. Everything you’ve seen and liked on this blog up till this moment was completely gathered on my own, I didn’t even have a partner access or any source of information other than what was available to the public. Imagine the giant leap that I’m taking now where I get to read, learn, try and witness everything directly from the source. I am so excited to start this new journey, and I promise you that I’ll always deliver higher quality posts to you.

Oh, and in case you didn’t get the joke in the subject, the VMware employees are not entitled to the vExpert award!

P.S. This was a last minute thing, and it’s just for fun: (click here)

Motivation

I was having a discussion with one of the large enterprises here in Qatar lately, and I was quite surprised to know from them that they are hesitated to migrate their VI3.5 environment to vSphere because of the associated downtime. What surprised me was not the fact that they can't afford a downtime, I've spent 6 years of my career working in the Telecom sector and I know for a fact that 1 second of downtime could mean a disaster, or even translate to a loss of thousand of $$. What surprised me was that they didn't know that it is possible to do this migration without any downtime!

In this blog post, I will not only show you (and them) how I was able to perform my upgrade without even this single second of downtime, but I will also show how we were able to migrate our storage from one array to another without any service interruption whatsoever in our equally critical environment. To make things even more exciting, what I'm about to show you here is completely achievable using vSphere's built-in features like VMware Converter, EVC, vMotion and Storage vMotion. There was no third-party tools used in this entire migration.

A brief environment overview

There is nothing better than diagramming this for easier follow-up. In the diagram below I'm illustrating a small portion of the environment showing the main components of the old ESX 3.5 hosts as well as the ESX 4.0 hosts. In our case, we decided not to go with in-place upgrade, and preferred to have a fresh install for the ESX hosts in the new vSphere environment.

You might have noticed that I included a video inside the diagram, and probably wondering why on earth would someone do something like that? The answer is simple: I'm showing-off! No seriously, I know many people (from VMware and specific storage vendors) who use my diagrams in their internal meetings with customers (really I'm not showing-off), and I thought it would be nice to have such small clip in the diagram that shows both the vMotion & SvMotion easy point-and-click approach.

Note: This is just an illustration not an S/vMotion architecture diagram! Wait for my A3 if you are interested to see the technology behind this…magic!

The Process

Step 1: We are running here vCenter on a physical server, and we want to utilize the same hardware for the new upgrade. The easiest way to achieve that is to P2V the existing vCenter 2.5 to another standalone ESX host in our environment. After the VM is migrated successfully and all the clean-up is done, the switch over from the physical to virtual can happen in a matter of seconds by disconnecting the physical server from the network, and connecting the VM (which has the same IP address of course) to the same subnet.

Step 2: Now that we have the vCenter 2.5 migrated, the next step is to perform a clean install on the freed physical server. Starting with the OS deployment, all the way to the vCenter 4.0 installation, initial configuration and licensing.

Step 3: The third step is to connect the new vCenter 4.0 to the old vCenter 2.5 licensing server. This part is important because the ESX 3.5 hosts do not leverage the new and improved licensing model that was introduced in the 4.0 release. This step is quite easy: you go to the "Administration" menu on your vSphere client, select the "vCenter Server Settings", and then enter your old vCenter 2.5 hostname into the field as shown in the example below.

Step 4: Now we are ready to create a new cluster for the existing ESX 3.5 hosts on the left side of the diagram. The thing to note here is to create the cluster with the EVC mode enabled as shown below because we will be migrating the VMs between two deferent hardware/CPU generations:

Step 5: We create here a second cluster (EVC enabled as well) and add the new ESX 4.0 hosts to it as shown in the right side of the diagram.

Step6: Now, the trick here is to have one ESX 4.0 host in this cluster connected to both arrays in the environment – the EVA and the V-Max. We achieve that by connecting one HBA to the HP SAN fabric, and the second HBA to the EMC SAN fabric. Once this is done, and all the associated zoning and masking is configured, we can scan the HBAs and have all the datastores/LUNs available on this server that we will call it "Gateway".

Step7: The fun begins. Since the gateway server is having the same shared storage with the ESX 3.5 hosts, all what you need to do here is to drag and drop your VMs from the old cluster to the new one. The vMotion will kick-in and do it's magic to live migrate the VMs to the new gateway server. That's right! We are live migrating virtual machines from ESX 3.5 to ESX 4.0 on the fly.

Step 8: Now to my favorite part in the whole migration process. Here we get to experience one of the most amazing features in vSphere – the Storage vMotion. It has been actually re-written with significant performance improvements that made it one of the most powerful tools for any VMware administrator in my opinion, and the best part is that it's done now with a few mouse clicks through the GUI (checkout the diagram video, or this detailed post). As I mentioned above, we were migrating our workloads from the HP EVA to the EMC V-Max, and we felt quite confident (after intensively testing this in the lab for a week) that the SvMotion would be the best choice for our storage migration. The other reason for using SvMotion was the ability to thin-provision VMs on the fly. I'm not talking here about everything of course, but rather the development VMs that are hardly ever touched. We had so many VMs for our development department with quite huge space requirements, while in fact they are neither actively used all the time, nor they consume the disk space allocated to them. The thin-provisioning for these VMs saved us literally TBs of storage on the new expensive V-Max SAN.

Things to note:

• After you complete this migration you are not quite done yet. You should typically have your VM tools updated, and also the VM hardware upgraded from v4 to v7. While you will still run fine without these upgrades, it's always recommended to be up-to-date in that regard, and to also leverage many of the new vSphere featuers like for example memory hot-add (my personal favorite!). The trick here is that you will need a VM reboot to perform that. In our case, for the less critical VMs we scheduled a planned reboots on weekly basis for the upgrades, and for the high-critical VMs, we just wait for the first possible OS reboot and we perform our upgrades along with it.
• Any storage vendor will tell you to do the thin-provisioning on the array directly, and I kinda agree with them on that, but this is not an option to everyone. Not all arrays come with this feature, or even if they do, not everyone can afford the licensing part. In our case, I simply couldn't rely on the SAN admins for monitoring and maintaining these thin-provisioned LUNs on the array side, and from the other hand, there were some technical limitations associated with that in terms of SRDF replication or FAST v1 (but that is something specific to EMC, and relevant only to the time of writing this post).

Conclusion:

I will finish this post from where I started. The VMware vSphere is a very powerful and a true enterprise class virtualization platform. You've seen here how I was able to migrate the entire VI3.5 environment without one single second of downtime, and also how it was an extremely easy process to migrate our complete storage from one array vendor to another without any interruption in the servers/services whatsoever. There is nothing extraordinary in this scenario (except maybe the embedded video in the diagram), and you've seen how easy the steps are, and how everything we've done here is built in vSphere itself. Just know your requirement, plan your migration ahead, and you will be just fine!