Migrate VMs from vSphere to Acropolis Hypervisor – AHV

When it comes to building out a new Acropolis (AHV) cluster you are either starting out with new VMs or looking to migrate existing VMs from a vSphere environment. I have covered the process of creating new VMs in the “Creating VMs on AHV” post in this series. But if you are moving from vSphere to AHV, then there are two challenges that must be planned for. The first one is what will the conversion process look like and second, what will the migration process look like. With each of these are multiple choices and it will be up to the project team to decide which is the best choice for the project. There are likely other options that I might not mention here either.

Converting vSphere VMs

The task of converting a vSphere VM to a VM that runs on AHV is not that different than other hypervisors or even the P2V days when you were moving from physical servers. You have a VM that is in a vSphere format and must be converted to a different format. It will also have VMware tools and drivers installed into the operating system. After the conversion these will need to be cleaned up, just like they would be when migrating to other platforms.

For this there potentially two viable candidates. The first would be grabbing the virtual disk file (VMDK) from a datastore and using the image management feature in AHV to import and convert the disk. There would still be cleanup to be done, but it’s a simple one-off way. This method would not be ideal for doing a bunch of VMs, it however might be a simple method if you just have a hand full of template VMs that you want to populate on the new cluster.

The second and leading choice is to use the following method. In short with this method you are installing the VirtIO drivers in advance, think of them as the drivers that VMware tools install. Storage vMotion the VMs to a shared Nutanix datastore, power off the VM and create a new VM on AHV using the vDisks that were moved over. A fellow Nutant and VCDX has already created a detailed blog post about converting a vSphere VM to run on AHV. You can read the full details here as written by Artur Krzywdzinski.

In the future I would like to see something like Double-Take offer a solution that would offer help with these cross-platform conversions and migrations. This is something they have working for cloud migrations today. I see this becoming a common task in the future and demand is only going to increase for organizations wanting to move workloads between different resource pools whether they are on-premises or off-premises and very few of these moves will support a single VM format.

 

Migrating the VMs

The conversion process was just covered for what is available at the time this was published. I also touched on the option of sharing out a datastore from the AHV cluster to an existing vSphere cluster. This would allow you to Storage vMotion any VMs to that shared datastore before shutting them down to complete the conversion process. This method will likely be the most heavily used, since its familiar for other legacy types of migrations between old and new infrastructure.

A second option is available if both the vSphere and AHV clusters are running on Nutanix gear. You can create a Protection Domain (PD) on the vSphere cluster to replicate all of the VMs to the AHV cluster. This will get the data over to the AHV cluster in an efficient manner, this would be a great option if moving between sites also.

 

About Brian Suhr

Brian is a VCDX5-DCV and a Sr. Tech Marketing Engineer at Nutanix and owner of this website. He is active in the VMware community and helps lead the Chicago VMUG group. Specializing in VDI and Cloud project designs. Awarded VMware vExpert status 6 years for 2016 - 2011. VCP3, VCP5, VCP5-Iaas, VCP-Cloud, VCAP-DTD, VCAP5-DCD, VCAP5-DCA, VCA-DT, VCP5-DT, Cisco UCS Design

Read More

Live Migration on Acropolis Hypervisor – AHV

Live migration is the ability to move a running VM from one host (node) to another without any downtime or loss of connectivity. Some vendors call this live migration, if your a VMware person this is known as a vMotion. Live migration is supported on an Acropolis Hypervisor (AHV) cluster, whether it is initiated manually or through an automatic process.

There are several ways for VMs to be live migrated to other hosts, the most common is for someone to use Prism to select the VM and choose to migrate it. They can also occur when a host is placed in maintenance mode which evacuates all VMs, from the Acropolis CLI or via the REST API.

 

How to live migrate an AHV VM

Acropolis managed virtual machines can be manually migrated to other hosts within the cluster through the VM portion of the Prism interface. First you select VM option from the top menu. Then choose the table view,  then select VM to be moved and click the migrate option.

migrate steps

 

The migration action window will present the admin with the option to let the system automatically select the target host based on resource utilization or via the drop down option, allow the admin to manually select the target host from the list of nodes in the cluster.

migrate VM

 

The following image shows that you can easily select the target host to move the VM to, if you do not want to let the system make the selection for you. Click the Migrate button and the VM is on its way to the new host.

migrate options

 

API Migrate Option

I still have very little experience with API’s but wanted to show that the option is available.

migrate api

 

ACLI Migrate Option

The ACLI option offers the ability to specify a max bandwidth for the move along with the expect destination options.

migrate cli

 

Conclusion

I know that live migrating a VM is pretty boring these days as it should be. But educating the community that this feature is available and showing how easy and flexible it is to use is also need.

 

About Brian Suhr

Brian is a VCDX5-DCV and a Sr. Tech Marketing Engineer at Nutanix and owner of this website. He is active in the VMware community and helps lead the Chicago VMUG group. Specializing in VDI and Cloud project designs. Awarded VMware vExpert status 6 years for 2016 - 2011. VCP3, VCP5, VCP5-Iaas, VCP-Cloud, VCAP-DTD, VCAP5-DCD, VCAP5-DCA, VCA-DT, VCP5-DT, Cisco UCS Design

Read More

Nutanix Acropolis Hypervisor for beginners series – AHV

I started my life in IT with MS-DOS and then moved into Windows when that became a thing. Then the wonders of VMware were introduced to me about a decade ago and I never looked back. Along the way, I have had limited exposure to Linux and related systems and it was always something that I wanted to learn more about, but other things always came first.

Since joining Nutanix recently, I will be learning a lot more about the Acropolis Hypervisor (AHV) offering that is built from KVM roots. This will be a new challenge for someone with my background and I’m looking forward to it. To help others with a similar background, I thought that a series of blog posts covering topics on getting started and operational tasks would be a good place to begin. These posts should help others that are new to virtualization or are experienced with VMware vSphere or Hyper-V already.

In the upper right margin of each post is an index of the posts in this series for easier access.

 

Creating networks on AHV

Configuring HA on AHV

Live Migration on AHV

Migrate VMs from vSphere to AHV

Managing VMs on AHV

Monitoring VMs on AHV

Image Service

Creating VMs on AHV

Using the Acropolis CLI (ACLI)

Upgrading AHV Hosts to new version

 

If there are other topics that you would like to see, drop me a note in the comments or via another method and I’ll consider it. If this series is well received I may do an Advanced AHV series at a later date.

 

 

About Brian Suhr

Brian is a VCDX5-DCV and a Sr. Tech Marketing Engineer at Nutanix and owner of this website. He is active in the VMware community and helps lead the Chicago VMUG group. Specializing in VDI and Cloud project designs. Awarded VMware vExpert status 6 years for 2016 - 2011. VCP3, VCP5, VCP5-Iaas, VCP-Cloud, VCAP-DTD, VCAP5-DCD, VCAP5-DCA, VCA-DT, VCP5-DT, Cisco UCS Design

Read More

Creating VM networks on Acropolis hypervisor – AHV

If you are building a new Acropolis Hypervisor (AHV) cluster there will likely be several networks that will need to be configured for VMs to consume. Also for existing AHV clusters, we all know that as environments mature and grow, typically additional networks are introduced. For these reasons a walkthrough on how to configure these networks on AHV is part of these series.

The Acropolis Hypervisor (AHV) leverages Open vSwitch (OVS) for all VM networking. When creating a new AHV cluster the management and Nutanix CVM networking paths are configured automatically. On a newly created AHV cluster there are no VM networks created automatically, VM networks are configured through Prism or the Acropolis CLI (ACLI). When networks are created within Prism they are automatically configured on all AHV hosts within the cluster to ensure compliance.

 

Creating VM networks in Prism

The process to create a new VM network through Prism is a simple pop-up form to fill in with the network name and corresponding VLAN ID. Once a network is created, it will be available for assignment to existing and newly created virtual machines. To get started once in Prism there are two options for getting to the network config. The first is to click on the gear in the upper right and select Network Configuration. The other option is when you are on the VM screen in prism in the upper right there is a green button for Network Config. Both options are shown in the image below. 

network config

 

About Brian Suhr

Brian is a VCDX5-DCV and a Sr. Tech Marketing Engineer at Nutanix and owner of this website. He is active in the VMware community and helps lead the Chicago VMUG group. Specializing in VDI and Cloud project designs. Awarded VMware vExpert status 6 years for 2016 - 2011. VCP3, VCP5, VCP5-Iaas, VCP-Cloud, VCAP-DTD, VCAP5-DCD, VCAP5-DCA, VCA-DT, VCP5-DT, Cisco UCS Design

Read More

Configuring HA on Acropolis Hypervisor – AHV

With any new hypervisor or one that someone has not worked with previously, high availability will be one of the early questions. What happens to the VMs running on a host that crashes for one reason or another. Acropolis hypervisor (AHV) is built on CentOS KVM, which does not offer HA natively. Nutanix has built additional functionality as part of AHV to offer virtual machine High Availability (HA) as a feature to ensure virtual machine availability in the event of a host or block outage. In the event of a host failure the VMs previously running on that host will be restarted on other healthy nodes throughout the cluster. There are three HA configuration options available to account for different cluster configuration scenarios.

By default, all AHV clusters will provide a best effort level of HA even when the cluster was not specifically configured for HA. Best effort HA works without reserving any resources. Admission control is not enforced and hence there may not be sufficient capacity available to start all the VMs from the failed host. What this means is that even when AHV clusters have not been configured for HA, clusters are still protected. Depending on how many compute resources are available within the cluster all or a subset of the affected VMs may be restarted.

When an Acropolis cluster is configured for HA, the process is accomplished through Prism and is enabled with a single click. Prism will examine the cluster and will configure the cluster reservation for a specific number of host failures or segment reservations. The reservation method decision is based upon the uniformity of the hosts configuration within the cluster and selects the method with the least amount of overhead.

Host reservations – With this method an entire host is reserved for failover protection. The least used host in the cluster is selected as a reserve node, and all VMs on that node are migrated off to other nodes in the cluster so that the full capacity of that node is available for VM failover. This is the default HA method when all hosts within the cluster have the same amount of RAM. Prism will configure the number of failover hosts to match the number of failures the cluster will tolerate for the configured Replication Factor (RF).

Segment reservations – This method divides the cluster into fixed size segments of CPU and memory. Each segment corresponds to the largest VM that is guaranteed to be restarted in case the failure occurs. The other factor is the number of host failures that can be tolerated. Using these inputs, the scheduler implements admission control to always have enough resources reserved so that VMs can be restarted upon failure of any host in the cluster.  This is the default method used when hosts in the cluster have different amounts of RAM.

As you add more blocks and nodes to you AHV cluster as part of the expand cluster function, Prism will configure the new AHV hosts with the same profile settings as other hosts in the cluster. This ensures that the new resources are added to the HA calculations for the cluster and any changes are made to all hosts.

How to configure HA via Prism

Configuring HA on AHV in Prism is one-click, just like many other functions that Nutanix has built so far. Once you are logged into Prism you click on the gear in the upper right, find the Manage VM High Availability choice and select.

setting up HA

 

About Brian Suhr

Brian is a VCDX5-DCV and a Sr. Tech Marketing Engineer at Nutanix and owner of this website. He is active in the VMware community and helps lead the Chicago VMUG group. Specializing in VDI and Cloud project designs. Awarded VMware vExpert status 6 years for 2016 - 2011. VCP3, VCP5, VCP5-Iaas, VCP-Cloud, VCAP-DTD, VCAP5-DCD, VCAP5-DCA, VCA-DT, VCP5-DT, Cisco UCS Design

Read More
Page 1 of 212
%d bloggers like this: