Requirements

The VMs with the following configurations are not supported by Nutanix Xtract.

• Guest OSes not supported by AHV (see Supported Guest VM Types for AHV in the Nutanix Support Portal)
• VM names with non-English characters
• Custom vCenter ports
• Selecting individual ESXi hosts as source of VMs
• PCIE pass-through (only certain devices)
• Independent disks
• Physical RDM based disks
• VMs with multi-writer disks attached
• VMs with 2 GB sparse disk attached
• VMs with SCSI controllers with a SCSI bus sharing attached

Following operating system are fully supported:

• Windows 2016 Standard, 2016 Datacenter
• Windows 7, 8, 8.1, 10
• Windows Server 2008 R2, 2012, 2012 R2, 2016
• CentOS 6.4, 6.5, 6.6, 6.7, 6.8, 7.0, 7.1, 7.2, 7.3
• Ubuntu 12.04.5, 14.04.x, 16.04.x, 16.10, Server, Desktop (32-bit and 64-bit)
• FreeBSD 9.3, 10.0, 10.1,10.2, 10.3, 11.0
• SUSE Linux Enterprise Server 11 SP3 / SP4
• SUSE Linux Enterprise Server 12 Oracle Linux 6.x, 7.x
• RHEL 6.4, 6.5, 6.6, 6.7, 6.8, 7.0, 7.1, 7.2, 7.3

Following operating system are partially supported:

• Windows 32-bit operating systems
• Windows with UAC enabled
• RHEL 4.0, 5.x
• CentOS Linux 4.0, 5.x
• Ubuntu 12.x or lower
• VMs using UEFI-VMs requiring PCI or IDE bus

The following configurations are required by Nutanix Xtract:

• Supported browsers: Google Chrome
• VMware Tools must be installed and up to date on the guest VMs for migration
• Virtual hardware version running on a VM must be 7.0 minimum.
• Source VMs must support Changed Block Tracking (CBT). See https://kb.vmware.com/kb/1020128
• CBT-based snapshots are supported for certain VMs.
• Disks must be either sparse or flat format and must have a minimum version of 2.
• ESXi version must be 5.5 minimum.
• Hosts must not be in maintenance mode.
• vCenter reachable from Xtract appliance on Port TCP 443.
• ESXi hosts reachable from Xtract appliance on Ports TCP 443 and TCP 902.
• Every VM must have a UUID.
• ESXi hosts must be have complete configuration details of the VMs.
• Complete VM configuration details in ESXi.
• VMs must have multiple compatible snapshots.
• Allow port 2049 and port 111 between the Xtract for VM network and the AHV cluster network (CVMs).
• Accounts used for performing in-guest operations require Login as Batch Job rights in the local security policy on Windows or within the group policy, see https://technet.microsoft.com/en-us/library/cc957131.aspx. Administrator users do not have sufficient rights.

Before a migration, the VMware tools must be started and running and the snapshots must be deleted

Deploy Nutanix Xtract

First of all, download the appliance image from the Nutanix portal. Then log on Nutanix Xtract and navigate to Home |VM.

Next click on the wheel and select Image Configuration.

Then click on Create Image, specify a name and an annotation. Choose Disk image type and upload the qcow2 file from the Nutanix Xtract that you have previously downloaded.

The image upload take a moment and you can check the progression in task menu.

Then create a VM with the following settings:

• 2 vCPUs
• 2 Cores per vCPU
• 4GB of Memory

If you scroll down to Disks setting, you’ll get this message. Click on Add New Disk.

Configure the disk as the following and select the Nutanix Xtract image you’ve just uploaded. Then click on Add.

In Network Adapters section, specify the VLAN where will be connected Nutanix Xtract.

To finish, enable Custom Script and upload the script called xtract-vm-cloudinit-script located in the Nutanix Xtract archival that you have previously downloaded from Nutanix portal.

Then start the VM, connect to the console and wait a while. From my side, the appliance was ready after 30 minutes.

Configure the appliance

When the appliance is ready, you can enter admin credentials (admin / nutanix/4u).

When you are logged with admin user, run the rs command and type again the admin password.

Edit the file /etc/sysconfig/network-scripts/ifcfg-eth0 and specify a static IP as below configuration.

Then restart the service network by running service network restart.

Next edit the file /etc/resolv.conf and specify your suffix DNS and the DNS server(s):

• search mydomain.local
• nameserver 10.10.201.2

Restart the Nutanix Xtract appliance. Now connect through HTTPS to the appliance by using the static IP you have set previously. Accept the license agreement and click on Continue.

Next specify a password for the nutanix account.

Now you can log on Nutanix Xtract with the nutanix account.

Configure Nutanix Xtract

Now that you are connected to the appliance, you have to add the source and the target environment. First click on Add Source environment.

Then enter the source name, the vCenter Server address and admin credentials.

Next click on Add target environment and specify your Nutanix Prism.

Now you have the source and the target environment. You are ready to migrate VMware VM to Nutanix AHV.

Migrate a VMware VM to Nutanix AHV

Now to migrate VMs, we have to create a migration plan. To create it, click on Create a Migration Plan.

Provide a name for the migration plan and click on OK.

Next select the target environment and the target container where you want to store VMs.

Next you can look for VMs you want to migrate by using the search field. Then click on the “+” button to add VM into the migration plan.

The guest credentials are used if you run guest operations on source VMs such as install the VirtIO tools. I recommend to not bypass Guest Operations on Source VMs to install VirtIO automatically. Lot of VMs I have migrated without these operations didn’t boot. You can also make the mapping between the source network and the target network.

Next check the migration plan summary and click on Save And Start to run immediately the migration. The data will be copied but the cutover will be done manually later.

Then you can monitor the migration progression.

When you are ready to cutover the VM, you can click on Cutover. The source VMs will be shutdown and the target VMs will be started. I final incremental data copy is executed.

When the copy is finished, the migration status should be completed. Congratulation, you have migrated VMware VMs to Nutanix AHV easily :).

Conclusion

Nutanix provides a powerful tool to migrate VMware VM to Nutanix AHV. All is included to plan the migration and you can schedule the failover. I had some issue with Microsoft UAC but globally the tool works great.

The post Migrate VMs from VMware to Nutanix AHV with Nutanix Xtract appeared first on Tech-Coffee.

By replacing the certificate, your browser will not warn you anymore because of untrusty certificate and you get stronger security.

Requirements

To follow this topic, you need a working PKI based on AD CS. The root and intermediate certificates must be distributed on your computer. You need also a working vCSA 6.5u1 with SSH and bash enabled.

Generate a certificate request

First of all, connect to the vCSA by using SSH and launch the bash by typing Shell. Then run /usr/lib/vmware-vmca/bin/certificate-manager. On the first prompt, choose option 1.

Enter administrator credentials and choose again the number 1.

Then specify the following options:

• Output directory path: path where will be generated the private key and the request
• Country: your country in two letters
• Name: The FQDN of your vCSA
• Organization: an organization name
• OrgUnit: type the name of your unit
• State: country name
• Locality: your city
• IPAddess: provide the vCSA IP address
• Email: provide your E-mail address
• Hostname: the FQDN of your vCSA
• VMCA Name: the FQDN where is located your VMCA. Usually the vCSA FQDN

Once the private key and the request is generated, type the following command in order to connect with WinSCP to your vCSA.

Download WinSCP from this location and install it. Configure the connection as the following:

Once connected to your vCSA, download the vmca_issued_csr.csr file.

Sign the request with ADCS

Open the certification authority console and right click on the name of your CA. Select All Tasks | Submit new request…. Then select the CSR file you have downloaded from vCSA.

Then navigate to pending request and right click on the request. Select All Tasks | Issue.

Now navigate to issued certificate and double click on the certificate you just issued. Then navigate to Details | Copy to file.

Export the certificate in Base-64 encoeded X.509 format.

With WinSCP, copy the signed certificate and the CA certificate to the vCSA.

N.B: If your PKI is based on a multi-tier (Root CA and Sub Cas), you need to concatenate each CA certificate of the certification chain in a .PEM file.

Replace vCSA 6.5u1 certificate

Run again /usr/lib/vmware-vmca/bin/certificate-manager and select option 1. Specify administrator credentials and this time select option 2.

Then specify the signed certificate, the private key and the CA certificate (or a concatenated PEM file with all CA certificates, in case of multi-tier PKI).

If the certificate is good, you should see that each service is updated. When all service is updated, the vCSA restart.

N.B: I have seen in production that the certificate replacement doesn’t work because of plugin. In this case, you’ll see which service make the issue. Disable the plugin and try again.

Once vCSA has restarted, connect to the Web Service by using a Browser. You should see your custom certificate as below:

The post Replace vCSA 6.5u1 certificate by an ADCS signed certificate appeared first on Tech-Coffee.

To follow this topic, you need a Windows vCenter Server 5.5 or 6.0 to migrate. You need also the latest VMware vCenter Server Appliance (at the time of writing this line, it is vCSA 6.5 update 1). You need also enough storage and compute resource.

Step 1: Run VMware migration assistant

Before beginning the migration, you must run the VMware Migration Assitant on the source vCenter server (I mean the Windows vCenter Server). You can find this tool in the vCSA ISO that you have previously downloaded in <Drive Letter>:\migration-assistant\VMware-Migration-Assistant.exe. This tool starts a web service on the Windows vCenter Server to communicate with the vCSA install program.

Step 2: Deploy the vCSA

Once you have executed the VMware Migration Assistant on the source, you can mount the vCSA ISO on your favorite Windows computer or server (it must have access to your vSphere infrastructure) and run <DriveLetter>:\vcsa-ui-installer\win32\installer.exe. You can also run the installer from Mac or Linux but I prefer Windows :). In the first window, just click on Migrate.

The next screen introduces the migration process. Just click on Next.

On the next screen, accept the license agreement and click on Next.

Then specify the source Windows server (by using an IP or FQDN). The VMware migration assistant must run otherwise you’ll have an error. Specify also the administrator’s credentials to connect to source vCenter.

Next, you have to specify the information about the target. Because I migrate the only one vCenter I have, I set credentials and FQDN of an ESXi node (be sure to disable DRS while migration).

Then provide the name of the new vCenter Appliance VM and its root password. Be sure to not indicate the same VM name than the source vCenter. You can rename the source VM name by adding suffix _old for example.

In the next window, choose a deployment and storage size. These settings depend on the vSphere infrastructure you have. The table indicates which deployment you should choose depending on the number of hosts and VMs to manage from the vCenter.

Next choose the datastore where you want to store the vCenter VM files. You can also deploy the vCSA VM in thin provisioning mode.

Then specify temporary network information. These settings will be used when the source Windows vCenter Server and target vCSA will be powered up at the same time.

To finish this step, please review the setting that you have specified and click on Finish to run the deployment.

A progress bar shows you the deployment status. It can take a while to deploy the target vCSA.

Once it is finished, you can click on continue to start the stage 2. If you close this window or if there is a network issue, you can connect later to the appliance to run the step 2 at https://<ip or vCSA FQDN>:5480.

Step 3: Configuration and data migration

The first screen of the stage 2 introduces what happen in this step. Just click on Next. Then the wizard runs a pre-migration check.

Next the pre-migration check shows warnings and issues. It can indicate which components cannot be migrated (such as plugin or Update Manager baseline).

If the source Windows vCenter Server is joined to Active Directory, the wizard asks you credentials to join the vCSA to the same Active Directory domain.

Next you can select the data to migrate: just the configuration or configuration, events, tasks and performance metrics.

In the next window, you can choose to join the CEIP or not.

To finish, review your settings. If all is good, you can check the box saying that you have backed up the source vCenter Server and click on Finish.

A warning indicated you that the source vCenter Server will be powered off once the network configuration is set on the destination vCenter Server. If you are sure, just click on OK.

A progress bar indicates you the migration status. It can take a while depending on the data to migrate and the speed of your network and vSphere infrastructure. Once the data is migrated, you should be able to connect to the vCenter again and it should be converted into a vCSA :).

The post Step-by-step: Migrate Windows vCenter server to vCSA 6.5u1 appeared first on Tech-Coffee.

The VMware vCSA upgrade is done in 2 steps:

• The vCSA deployment
• The data migration from source to destination

Before beginning you need the following:

• A new name for the new VM or rename the old vCenter VM Name with _old prefix for example
• A temporary IP address
• Enough storage for the appliance
• Enough compute resources to run the appliance

Step 1: Deploy a new appliance

Once you have mounted the ISO, open <ISO Drive Letter>\vcsa-ui-installer\win32\installer.exe. Then choose Upgrade.

The next screen introduces the steps to follow to upgrade your appliance from vCSA 5.5 or 6.0 to vCSA 6.5u1. Just click on Next.

Once the next screen, just accept the license agreement and lick on Next.

In the next window, specify the vCenter FQDN or IP address and password to connect to. Then specify the ESXi name which hosts the vCenter Appliance. I specify the ESXi instead of the vCenter because I want to upgrade this vCenter server. When the upgrade will occur, the current vCSA will be shutdown.

Then choose the deployment type and click on next.

Then specify an ESXi or vCenter name. Because I migrate the only one vCenter I have, I choose to specify the ESXi name and credentials to connect to.

Next choose a destination VM folder and click on Next.

Then choose an ESXi in the list.

Next specify a VM name and the root password for the target vCSA.

In the next window, regarding your needs, choose the right appliance size. In the table, you have information about supported number of hosts and VMs.

Next choose the datastore where you want to store the vCSA VM file. You can also deploy the appliance in thin provisioning.

Next specify the temporary IP address. This IP is used only during the data migration step.

In the next screen, you can review the settings you apply previously. When you have reviewed the settings just click on Finish to run the vCSA deployment.

Once the appliance deployment is finished, you can click on continue to process the step 2.

Step 2: Migrate configuration for vCSA 5.5 to vCSA 6.5

The next screen introduces the step2 which consists of copying data from source vCenter Server Appliance to the new appliance.

The next step runs some verifications to check if the configuration can be migrated. For example, in the below screenshot is indicated that a plugin cannot be migrated and to check if DRS is not enabled on the ESXi which host the new appliance. If the DRS is enabled, the new appliance can be migrated and so the wizard will be not able to contact this VM anymore (we have specified the ESXi in step 1).

In the screen, the wizard asks you which data you want to migrate.

Then you can choose to join the CEIP or not.

Next you can review the settings before run the data copies. To run the migration, just click on Finish.

Once the migration is finished, you can connect to the vCenter by using the web client and enjoy the new web interface (either flash or html). The source appliance should be shutdown.

The post Step-by-Step: Upgrade VMware vCenter Server Appliance 5.5 to 6.5u1 appeared first on Tech-Coffee.

Step 1: upgrade your vCenter Server Appliance

In my lab, I have deployed a vCenter Server Appliance. So, to update the VCSA I’m connecting the Appliance Management (https://<IP or DNS of VCSA>:5480). Then, I navigate to update. Click on check updates from repository.

Once the update is installed, click on summary tab and reboot the VCSA. You should have a new version.

Step 2: Update ESXi nodes

Manage patch baseline in Update Manager

My configuration consists of two ESXi 6.5 nodes and one vSAN witness appliance 6.5. To update these hosts, I use Update Manager. To create / edit a baseline open the Update Manager from “hamburger” menu.

I have created an update baseline called ESXi 6.5 updates.

This baseline is dynamic which means that patches are added automatically regarding criteria.

The criteria are any patches for the product VMware ESXi 6.5.0.

Update nodes

Once the baseline is created, you can attach it to the nodes. Navigate to Hosts and Clusters and select the cluster (or a node) and open the update manager tab. In this tab, you can attach the baseline. Then you can click on Scan for Updates to verify if the node is compliant with the baseline (in other words, if the node has the last patches).

My configuration is specific because it is a lab. I run a configuration which is absolutely not supported because the witness appliance is hosted on the same vSAN cluster. To avoid issues, I manually set to maintenance mode the node I want to update and I move VM to the other node. Then I click on Remediate in Update Manager tab.

Next I select the baseline and I click on next.

Then I select the target node.

Two patches are not installed on the node. These patches are related to vSAN 6.6.

I don’t want to schedule later this update so I just click on next.

In host remediation options tab, you can change the VM Power state. I prefer to not change the VM Power state and run a vMotion.

In the next screen, I choose to disable the HA admission control as recommended by the wizard.

Next you can run a Pre-check remediation. Once you have validated the options you can click on finish to install updates on the node.

The node will be rebooted and when the update is finished you can exit the maintenance mode. I do these steps again for the second node and the witness appliance.

Note: in a production infrastructure, you just have to run the update manager from the cluster and not for each node. I add the node to maintenance mode and I move manually the VM because my configuration is not supported and specific.

Step 3: Upgrade disk configurations

Now that nodes and vCenter are updated, we have to upgrade the disk format version. To upgrade these disks, select your cluster, navigate to configure and general. Then run a Pre-check Upgrade to validate the configuration.

If the Pre-Check is successful, you should have something as below. Then click on Upgrade.

Then the disks are upgrading …

Once all disks are upgraded, disks should be on version 5.0.

That’s all. Now you can enjoy VMware vSAN 6.6.

The post Upgrade VMware vSAN to 6.6 appeared first on Tech-Coffee.

• Deploy Veeam 9.5 Backup & Replication
• Connect Veeam to vCenter and add a backup repository
• Backup and restore your first VMware VM

The post Step-By-Step: Deploy Veeam 9.5 and backup VMware VM appeared first on Tech-Coffee.

Add identity source

To be able to authenticate to vCenter with Active Directory, you have to add an identity source. To add an identity source, navigate to Administration | Single Sign-On | Configuration. Click on the add button.

Then select Active Directory (Integrated Windows Authentication).

In the next screen, the wizard tells you that you cannot add this identity source because the vCenter Single Sign-On server is not joined to a domain. So, click on Go to Active Directory Management to join the vCenter SSO server to the domain.

Next, click on join.

Then specify a domain, an OU and credentials to join the vCenter to the domain.

Next restart the vCenter server. When it is online again, you should be joined to the Active Directory Domain.

Next go back to to Administration | Single Sign-On | Configuration. Click on the add button. Then select Active Directory (Integrated Windows Authentication). Now the wizard sets automatically the domain name. Just click on next.

After you have reviewed the settings, you can click on finish to add the identity source.

Once you have added the identity source, you should have its information in the table as below.

Use Active Directory users and groups in vCenter

Now that vCenter can use Active Directory accounts to authenticate, you can browser users and groups. Navigate to Users and Groups tab. In domain menu, select your domain. You should get all the user of the domain.

In the Active Directory console, I have created a group called GG-VMwareAdmins. The account Romain Serre is a member of this group.

Next go back to vCenter and select groups tab. Select the Administrators group and click on add member.

Then select your domain and specify the name of the group in search field. Once you have found your group, just click on Add and OK.

Now the GG-VMwareAdmins Active Directory group is member of Administrators vCenter group.

From the authentication page, specify an account member of the Active Directory group.

If the configuration is good, you should be logged into vCenter as below.

Activate Windows Session Authentication

VMware provides an authentication plugin to use the Windows session login to authenticate to vCenter. The below screenshots come from Firefox. Open the browser and navigate to the vCenter authentication page. Then in the footer of the page, click on Download Enhanced Authentication plugin.

Once you run the installer, you have a warning saying that all other plug-in instances will be stopped. Just click on OK.

Next the wizard says to you that two plug-ins will be installed: the VMware Enhanced Authentication Plug-in and VMware Plug-in Service installers. Click on OK.

Foreach plug-in, follow the process to install it.

When both plug-ins are installed, close and open the web browser. Next, open again the vCenter authentication page. You should have the below popup. Click on Remember my choice for vmware-plugin links and click on Open link.

Next, you are able to check Use Windows session authentication. When you check the box, the below pop-up appears. Click on Allow.

Now you can use the Windows session credentials to authenticate to vCenter.

Conclusion

The authentication from Active Directory brings a valuable way to manage and segregate rights. Almost all companies have an Active Directory to manage authentication and authorization centrally. Thanks to Active Directory, vCenter authentication and authorization can also be managed from this service. This enables to increase the security level because vCenter is not managed alone anymore and it is integrated into the overall company security policies (such as password length, expiration and so on).

The post Authenticate to vCenter from Active Directory credentials appeared first on Tech-Coffee.

• A Software to be deployed on a Windows Server (physical or virtual)
• A virtual appliance that is based on Linux (vCenter Server Appliance: VCSA)

Since vSphere 6, the VCSA can manage more hosts and more VM and is more robust and scalable. With vSphere 6.5, the VCSA support the simplified native vCenter High Availability which is available only for the VCSA (not for Windows).

The below table introduces the Windows versus VCSA scalability (vSphere 6.0 information):

As you can see, there is no advantage anymore to use Windows vCenter. Moreover, with vSphere 6.5, the update manager is integrated to vCenter. You don’t need Windows for that anymore. The VCSA is free where you have to pay a license for the Windows vCenter. The only con of VCSA is that it is a black box.

In this topic, I’ll show you how to deploy a standalone VCSA 6.5 from a client computer.

Requirements

To deploy your VCSA 6.5 you need the following:

• A running ESXi host reachable from the network
• The ISO of VCSA 6.5 (you can download it from here)
• At least 4GB on your host and 20GB on a datastore

Step 1: Deploy the VCSA on an ESXi

Once you have downloaded the VCSA 6.5 ISO, you can run vcsa-ui-installer\win32\installer.exe

When you have run the installer, you can see that you have several options:

• Install: to run the VCSA installation (I choose this option)
• Upgrade: if you want to upgrade an existing VCSA to 6.5 version
• Migrate: to migrate a Windows vCenter Server to vCenter Server Appliance
• Restore: to recover the VCSA from a previous backup

In the next screen, the wizard explains you there is two steps to deploy the VCSA. In the first step, we will deploy the appliance and in the second one, we will configure it.

Next you have to accept license agreement and click on next.

Then choose the deployment model. You can select to embed the Platform Services Controller (PSC) with the vCenter Server. Or you can separate the role as explain in the below schema. PSC manages SSO, certificate stores, licensing service and so on. The second deployment model is recommended when you want share these services between multiple vCenter Server instances. For this example, I choose the first one and I click on next.

Then specify the ESXi or the vCenter Server where the appliance will be deployed. I specify a running ESXi, the management port and the root credential.

Next I specify the VM Name and the root password for the VCSA.

In the next screen, you can choose the appliance size. More the virtual infrastructure is huge, more the VCSA needs vCPU, RAM and storage.

Then choose a datastore where the VM will be deployed and click on next.

In the next screen, specify the network configuration of the VCSA. If you specify a FQDN in system name, be sure that the entry exists (with the right IP address) in the DNS server. Otherwise you will have an error message.

To run the appliance deployment, click on finish in the below screen.

While the deployment occurs, a progress bar will show you where you are in the deployment process.

If you connect to the ESXi from the web interface, you can see that the VM is well deployed.

When the deployment is completed, you should have the below screen.

Click on continue to process in the step 2.

Step 2: Configure the appliance

In the step 2, we will configure the appliance. In the first screen, just click on next.

Then, specify some NTP server to synchronize the time.

In the next screen, provide SSO information to manage your vSphere infrastructure.

Next you can accept to join the VMWare’s Customer Experience Improvement Program (CEIP) or not.

To finish, click on finish to run the configuration.

During the configuration, you should have a progress bar to inform you where you are in the process.

Once the configuration is finished, you should have the below screen.

You can now connect to the vSphere Web Client. The URL is indicated in the above screenshot.

Appliance monitoring

The VCSA provides an interface for the monitoring. You can connect from https://<SystemName>:5480. You can use root credential.

As you can see in the below screenshot, you can have the overall health status from this interface.

You can also monitor the CPU and memory of the appliance.

And you can also update the appliance from this interface.

Conclusion

Since vSphere 6.0, the VCSA is really highlighted by VMware. Moreover, since vSphere 6.5, the Update Manager (VUM) is integrated in vCenter. In my point of view there is no advantage to use Windows vCenter Server anymore compared to VCSA. As you have seen in this topic, the VCSA deployment is really turnkey and easy.

The post Step-by-Step: Deploy vCenter Server Appliance (VCSA) 6.5 appeared first on Tech-Coffee.

In hybrid solution, you must have flash cache devices and mechanical cache devices (SAS or SATA). In full-flash solution you have only flash devices for cache and capacity. The disks either flash or capacity will be aggregated in disk groups. In each disk group, you can have 1 cache device and 7 capacity devices. Moreover, each host can handle 5 disk groups at maximum (35 capacity devices per host).

In this topic I will describe how to implement a hybrid solution in a three-nodes cluster. For the demonstration, ESXi nodes are located in virtual machines hosted by VMware Workstation. Unfortunately, Hyper-V under Windows Server 2016 handle not very well ESXi. Only IDE controllers and legacy network adapters are supported. So I can’t use my Storage Spaces Direct lab to host a vSAN cluster .

VMware vSAN lab overview

To run this lab, I have installed VMware Workstation 12.x pro on a traditional machine (gaming computer) running with Windows 10 version 1607. Each ESXi virtual machine is configured as below:

• ESXi 6.0 update 2
• 2x CPU with 2x Cores each
• 16GB of memories (6GB required and more than 8GB recommended)
• 1x OS disk (40GB)
• 15x hard disks (10GB each)

Then I have deployed the vCenter server 6.0 update 2 in a single Windows Server 2012 R2 virtual machine.

I have deployed the following networks:

• Management: 10.10.0.0/24 (VLAN ID: 10) – Native VLAN
• vSAN traffic: 10.10.101.0/24 (VLAN ID: 12)
• vMotion traffic: 10.10.102.0/24 (VLAN ID: 13)

In this topic, I assume that you have already installed your ESXi and vCenter server. I assume also that each server is reachable on the network and that you have created at least one datacenter in the inventory. All the screenshots have been taken from the vSphere Web Client.

Add ESXi host to the inventory

First of all, connect to your vSphere Web Client and navigate to Hosts and Clusters. As you can see in the following screenshot, I have already created several datacenters and folders. To add the host to the inventory, right click on a folder and select Add Host.

Next specify the host name or IP address of the ESXi node.

Then specify the credential to connect to the host. Once the connection is made, a permanent account is created and used for management and not anymore the specified account.

Then select the license to assign the the ESXi node.

 On the next screen, choose if you want to prevent a user to logging directly into this host or not.

 To finish, choose the VM location.

 Repeat these steps to add more ESXi node to inventory. For the vSAN usage, I will add two additional nodes.

Create and configure the distributed switch

When you buy a vSAN license, a single distributed switch support is included. To support the vSAN, vMotion and management traffic, I’m going to create a distributed switch with three VMKernels. To create the distributed switch, navigate to Networking and right click on VM Network in a datacenter and choose New Distributed Switch as below.

Specify a distributed switch name and click on Next.

Choose a distributed switch version. Because I have only ESXi version 6.0, I choose the last version of the distributed switch.

Next change the number of uplinks as needed and specify the name of the port group. This port group will contain VMKernel adapters for vMotion, vSAN and management traffic.

Once the distributed switch is created, click on it and navigate to Manage and Topology. Click on the button encircled in red in the below screenshot to add physical NICs to uplink port group and to create VMKernel adapters.

In the first screen of the wizard, select Add hosts.

Specify each host name and click on Next.

Leave the default selection and click on Next. By selecting the following tasks to perform, I’ll add physical adapters to uplink port group and I’ll create VMKernel adapters.

In the next screen, assign the physical adapter (vmnic0) to the uplink port group of the distributed switch which has just been created. Once you have assigned all physical adapters, click on Next.

On the next screen, I’ll create the VMKernel adapters. To create them, just click on New adapter.

Select the port group associated to the distributed switch and click on Next.

Then select the purpose of the VMKernel adapter. For this one I choose Virtual SAN traffic.

Then specify an IP address for this virtual adapter. Click on Next to finish the creation of VMKernel adapter.

I create again a new VMKernel adapter for vMotion traffic.

Repeat the creation of VMKernel adapters for each ESXi host. At the end, you should have something like below:

Before make the configuration, the wizard analyzes the impact. Once all is ok, click on Next.

When the distributed switch is configured, it looks like that:

Create the cluster

Now the distributed switch and virtual network adapters are set, we can create the cluster. Come back to Hosts and Clusters in the navigator. Right click on your folder and select New Cluster.

Give a name to your cluster and for the moment, just turn on virtual SAN. I choose a manual disk claiming because I have set to manually which disks are flash and which disks are HDD. This is because ESXi nodes are in VMs and hard disks are detected all in flash.

Next, move the node in the cluster (drag and drop). Once all nodes are in the cluster, you should have an alert saying that there is no capacity. This is because we have selected manual claiming and no disk are for the moment suitable for vSAN.

Claim storage devices into vSAN

To claim a disk, select the cluster where vSAN is enabled and navigate to Disk Management. Click on the button encircled in red in the below screenshot:

As you saw in the below screenshot, all the disks are marked in flash. In this topic I want to implement a hybrid solution. vSphere Web Client offers the opportunity to mark manually a disk as HDD. This is possible because in production, some hardware are not well detected. In this case, you can set it manually. For this lab, I leave three disks in flash and I set 12 disks as HDD for each node. With this configuration, I will create three disk groups composing of one cache device and four capacity device.

Then you have to claim disks. For each node, select the three flash disks and claim them for cache tier. All disks that you have marked as HDD can be claimed for capacity tier.

Once the claiming wizard is finished, you should have three disk groups per node.

If you want to assign the license to your vSAN, navigate to Licensing and select the license.

Final configuration

Now that vSAN is enabled, you can Turn On vSphare HA and vSphere DRS to distribute virtual machines across the nodes.

Some vSphere HA settings must be changed in vSAN environment. You can read these recommendations in this post.

VM Storage policy

vSAN is based on VM Storage policy to configure the storage capacity. This configuration is applied by VM per VM basis with the VM Storage policy. We will discuss about VM Storage policy in another topic. But for the moment, just verify that the Virtual SAN Default Storage policy exists in the VM Storage Policies store.

Conclusion

In this topic we have seen how to create a vSAN cluster. There is no challenge in this but it is just the beginning. To use the vSAN you have to create VM Storage Policy and some of the capacity concept are not easy. We will discuss later about VM Storage policy. If you are interested by the same Microsoft solution, you can read this whitepaper.

The post Create a VMware vSAN cluster step-by-step appeared first on Tech-Coffee.