Convert a Hyper-V VM with StarWind V2V

You can download StarWind V2V Converter from this link. Once you have downloaded and installed the product, you can launch it. To convert a Hyper-V VM, select Microsoft Hyper-V Server.

Then specify the name of the Hyper-V Host and credentials. Unfortunately, you can’t specify a cluster name.

Then select the virtual hard drive you want to convert and click on Next.

Next, select VMware direct conversion to ESXi. The description sysa that only ESXi 5.0, 5.5 and 6.0 are supported. But I have successfully converted a VHDX to an ESXi 6.7.

In the next window, specify the IP address and credentials of the target ESXi server.

Next select the datastore where you want to store the converted virtual hard drive.

When the VM is converting, you can get a progress bar.

When the migration is finished, you can connect to your ESXi and create a new VM with the same features. Remove the default hard disk Then add an existing hard disk and select the disk you’ve just converted.

Now you can start the VM. As you can see the VM is working (The VM I have converted was also on License terms). Once you are logged into operating system, you can install the VMware Tools.

Convert VMware VM to Hyper-V VM.

This time we want to convert a VMware VM to a Hyper-V VM. So I choose VMware ESXi Server.

Then specify the IP address and credentials of the source VMware ESXi server.

N.B: The migration from a VMware ESXi 6.7 doesn’t work with StarWind V2V Converter. I had to use a VMware ESXi 6.5 to make the screenshot.

Next select the VMDK you want to convert and click on Next. As you can see in the following screenshot, you can’t convert two VMDK in the same time. It’s a shame.

In the next window, choose Microsoft VHDX image.

Specify the hostname and credentials of the Hyper-V host. You can’t specify a cluster.

To finish choose the destination folder and click on next to start the convert process.

Conclusion

StarWind V2V is not the smartest converter product on the market. Some features are missing. But if you have a small amount of VM and you don’t want to pay a converter product, StarWind V2V can help you. You can migrate VM per VM from a lot of hypervisor. Thanks to this tool you can plan to migrate from Hyper-V to VMware or vice versa. However if you have hundred of VMs, don’t use this tool, it is not made for that.

The post Convert VMs with StarWind V2V converter appeared first on Tech-Coffee.

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.

Check the overall health of VMware vSAN

Many information are available from the vSAN cluster pane. VMware has added a dedicated tab for vSAN and some performance counters. In the below screenshot, I show the overall vSAN Health. VMware has included several tests to validate the cluster health such as the hardware compatibility, the network, the physical disk, the cluster and so on.

The hardware compatibility list is downloaded from VMware to validate if vSAN is supported on your hardware. If you take a look at the below screenshot, you can see that my lab is not really supported because my HBA are not referenced by VMware. Regarding the network, several tests are also validated such as the good IP configuration, the MTU, if ping is working and so on. Thanks to this single pane, we are able to check if the cluster is healthy or not.

In the capacity section, you get information about the storage consumption and how the deduplication ratio.

In the same pane you get also a charts which give you the storage usage by object types (before deduplication and compression).

The next pane is useful when a node was down because of an outage or for updates. When you restart a node in vSAN cluster, this last must resync information from its buddy. When the node was down, lot of data were change on the storage and the node must resync these data. This pane indicates which vSAN objects must be resynced to support the chosen RAID level and the FTT (Failure To Tolerate). In case of resync, this pane indicates of many components to resync, the remaining bytes to resync and an estimated time for this process. You can also manage the resync throttling.

In Virtual Objects pane, you can get for each vSAN object the health state. You can check also if the object is compliant with the VM storage policy that you have defined (FTT, RAID Level, Cache pining etc.). Moreovoer, in the physical disk placement tab, you get also the component placement and which are active or not. In my lab, I have a two-node vSAN cluster and I have defined in my storage policy RAID 1 with FTT=1. So for each object, I have three components: two times the data and witness.

In physical disks pane, you can list the physical disks involved in vSAN for each node. You can know also which components are store on which physical disks.

In the proactive tests, you can test a VM creation to validate that everything is working. For example, this test helped me one time to troubleshoot MTU issue between hosts and switches.

vSAN performance counters

Sometime you get poor performance and you expect better. So, you need to find the performance bottleneck. The performance counters can help you to troubleshoot the issue. In performance tab you get the classical performance counters about CPU memory and so on.

VMware has also added two sections dedicated for vSAN performance counters: vSAN – Virtual Machine Consumption and vSAN – Backend. The below screenshot shows you the first section. It is useful because this section indicates you the throughput, the latency and the congestion.

The other section presents performance counters related to backend. You can get the throughput taken by resync job, the IOPS ad latency of vSAN.

The post Monitor and troubleshoot VMware vSAN performance issue appeared first on Tech-Coffee.

The following procedure regards Nutanix blocks. If you have a branded block (such as Dell), the procedure may change especially about network adapter to plug.

I’m sorry, the screenshots are blurred. I promise, I’ll do better next time

Requirements

To re-image Nutanix nodes, you need Nutanix foundation that you can download from Nutanix portal. This is a VM provided by Nutanix which contains tools to re-image node. This VM should be run on your laptop so you need a hypervisor which can run this VM such as VMware Workstation or VirtualBox.

I heavily recommend you to bring a simple switch (no manageable, 8 ports) to plug your laptop and Nutanix nodes. In this way nothing will trouble the deployment. The node discovering is based on IPv6LL.

You need also the lastest AOS release (5.1.3 at the time of writing this topic) and the VMware ESXi 6.5u1 ISO. To summary you need:

• A laptop with VMware Workstation/Fusion, VirtualBox
• Download the Foundation VM, add it to the hypervisor you chose and start it
• A non-manageable switch 8 ports
• Download the last AOS from the Nutanix Portal
• Download VMware ESXi 6.5u1

About foundation VM

Once you have downloaded the foundation VM, you can unzip it and add it to the hypervisor on your laptop. The VM must be connected to a bridge network. Be sure about this configuration. The default credentials are Nutanix / nutanix/4u.

About Nutanix nodes

The Nutanix nodes must be connected to the switch where your laptop is plugged. From my side, I have plugged the lower integrated network adapter port (Nutanix brand block). This configuration can change depending on the block brand. For example, for Lenovo blocks, I read that 1GB and 10GB network adapter must be plugged. For other, you need to plug also the IPMI. Please read the documentation for branded block about the right connection for re-imaging.

About network

Each Nutanix node requires four (three mandatory) IP addresses:

• One for IPMI
• One for Hypervisor (management)
• One for Controller VM (CVM)
• vMotion (Optional but recommended)

It is recommended that the CVM network and the Hypervisor network were on the same subnet. An additional IP is required for the cluster address.

Re-image Nutanix Node

Once the Foundation VM is started and you are authenticated to the system, you should get the following desktop. Run the script set_foundation_ip_address.

Choose Device configuration. Then set an IP address which will be on the hypervisor network to reach the cluster and the nodes.

Next I use a tool like PSCP to copy inside the VM the AOS and VMware image. To copy files, run the following command:

Pscp.exe c:\path\to\my\file nutanix@<foundation VM IP address>:/tmp

Then run the Foundation Applet to open the following GUI. The interface shows you the discovered nodes. In this example, only two nodes are discovered instead of three, I don’t know why. I chose to click on a node and launch foundation.

By magic in foundation, the three nodes are well discovered. If your nodes are not discovered, you can specify the IPMI MAC address to discover nodes manually. A label is stuck on back of each node with the IPMI MAC address.

On the next screen, specify the cluster information: cluster name and IP address, NTP server, DNS server and time zone. I activate the checkbox Configure IPMI IP to configure IPMI of each node. Next, I choose a netmask and a gateway for CVM and hypervisor network. Finally, I changed the CVM memory to 32GB which is a recommended value when you enable deduplication.

Next for each node, specify the node name and an IP for each network.

In this example, I choose Single Hypervisor because I want to deploy the same hypervisor in each node.

On the next screen, click on manage in AOS section and upload the AOS image that you have copied previously in /tmp. Do the same thing for ESXi.

After upload is finished, you should have something like that:

PS: You can upgrade the hypervisor whitelist to install latest VMware ESXi version. For that, you need to connect to Nutanix portal and download the last ISO_WhiteList.json. Then use PSCP to copy the file in the Foundation VM. Next click on View Whitelist and update the whitelist with the file that you have just copied.

Then the re-imaging process is running. It took 2h to finish the re-imaging.

Once th re-imaging process is finished, the cluster is creating.

If the cluster is well created, you should get the following screen:

Connect to Prism from a web browser (https://<Cluster IP>) and complete requested information. You have to change the default password also.

Next choose to activate or not Pulse.

After the wizard, you should get the Prism dashboard with cluster information. Now you can configure Prism and deploy vCenter. Have fun

The post Re-image Nutanix nodes to VMware ESXi 6.5u1 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.

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.

A 2-node cluster requires a Witness Appliance provided by VMware freely while the appliance is virtual. The Witness Appliance is based on ESXi. This is the first time that VMware supports a scenario in production with a nested ESXi. This topic describes how to deploy a 2-node vSAN cluster and its witness appliance.

Why you need a witness appliance

vSAN is something like a RAID over the network. vSAN currently supports RAID 1 and RAID 5/6. When you deploy a 2-node vSAN cluster, only the RAID 1 is available. When a VM objects such as VMDK is stored in vSAN, the data is written to a node and replicated to another (such as classical RAID 1 across two physical disks). So, two components will be created: the original data and the replica.

In vSAN environment, a storage object such as VMDK need more than half its components alive to be ready. So, in the above vSAN cluster, if a node is down, you lose half of the VMDK components and so the VMDK is not ready anymore. Not really a resilient solution :).

To solve this issue, VMware has introduced the vSAN Witness Appliance. Thanks to this appliance, in addition of these two components, a witness will be created. So even if you lose a node or the witness appliance, more than half of the components are available.

The Witness Appliance must not be located in the 2-node vSAN Cluster. It is not supported by VMware. You can deploy a third ESXi and deploy the Witness Appliance inside this ESXi. But the witness appliance must have access to the vSAN network.

The witness appliance is provided by VMware from an OVA file. It is free and a special license is provided with the appliance. So, it is really easy to deploy.

Requirements

To deploy this infrastructure, you need two nodes (physical or virtual) and at least a storage device for the cache and a storage device for the capacity. If you deploy a full flash solution, a 10Gb/s network is recommended for vSAN traffic. On my side, I have deployed the 2-node vSAN on this hardware for each node:

• 1x Asrock D1520D4i (Xeon 1520) (NIC: 2x 1GB Intel i210 for VM and management)
• 4x16GB DDR4 ECC Unregistered
• 1x Intel NVMe 600T 128GB (Operating System)
• 1x Intel S3610 400GB (Cache)
• 1x Samsung SM863 480GB (Capacity)
• 1x Intel x520-DA2 for the vSAN traffic and vMotion

These both nodes are already in a cluster and connected to a Synology NAS. Currently all VMs are stored on Synology NAS. Both nodes are direct connected via 10Gb adapters.

The storage adapter provided by the D1520D4i motherboard is not in the vSAN HCL. I strongly recommend you to check HCL before buying hardware for production.

To compute the memory resource needed for vSAN you can use this formula provided by VMware:

BaseConsumption + (NumDiskGroups x ( DiskGroupBaseConsumption + (SSDMemOverheadPerGB x SSDSize)))

• BaseConsumption: This is the fixed amount of memory consumed by vSAN per ESXi host. This is currently 3 GB. This memory is mostly used to house the vSAN directory, per host metadata, and memory caches.
• NumDiskGroups: This is the number of disk groups in the host, should range from 1 to 5.
• DiskGroupBaseConsumption: This is the fixed amount of memory consumed by each individual disk group in the host. This is currently 500 MB. This is mainly used to allocate resources used to support inflight operations on a per disk group level.
• SSDMemOverheadPerGB: This is the fixed amount of memory we allocate for each GB of SSD capacity. This is currently 2 MB in hybrid systems and is 7 MB for all flash systems. Most of this memory is used for keeping track of blocks in the SSD used for write buffer and read cache.
• SSDSize: The size of the SSD in GB. (cache)

So, in my case:

3GB + (1 x (0,5GB + (0,007GB x 400GB)))= 6,3GB

My node requires at least 6,3GB of free memory for vSAN.

Regarding the vSAN witness appliance (version 6.2), you can download the OVA here. In my deployment, I will do something not supported. I will place the witness appliance in the 2-node vSAN Cluster. It is absolutely not supported in production so, don’t reproduce this for your production environment. Deploy the witness appliance inside a third ESXi node.

I also recommend you the following PDF:

• VMware Virtual SAN stretched Cluster & 2 node guide
• vSAN Node Direct Connect setup checklist

Deploy the vSAN witness appliance

To deploy the witness appliance, navigate to vSphere web client and right click on the cluster or node where you want host the appliance. Select Deploy OVF template.

Next choose a host or a cluster to run the witness appliance.

In the next screen, you can review the details of the OVF that you deploy. As indicated in the below screenshot, the product is VMware Virtual SAN Witness Appliance.

Next accept the license agreements and click on next.

The model provides three deployment configurations. Choose one of them regarding your environment. In the description, you can review the supported environment for each deployment configuration.

Then choose a storage where you want to store the witness appliance files.

Next choose the network to connect the witness appliance.

To finish specify a root password. Then click on next and run the deployment.

Configure the witness appliance network

Once the witness appliance is deployed, you can start it. Then open a remote console.

When the appliance has started, you can configure the network like any ESXi nodes.

So, I set the network by configuring static IP. I also configure the name of the appliance and I disable IPv6.

When I have finished the settings, my appliance looks like this:

Add appliance to vCenter

The witness appliance can be added to vCenter like any ESXi nodes. Just right click on a datacenter or folder and select Add host.

Next provide connection settings and credentials. When you are in assign license screen, select the license related the the witness appliance.

When you have finished the wizard, the witness appliance should be added to vCenter.

Once you have added the witness appliance, navigate to Configure | VMKernel Adapters and check if vmk1 has vSAN traffic enabled.

Deploy 2-Node vSAN Cluster

Because my two nodes are already in a DRS cluster, I have to turn off the vSphere HA. You can’t enable vSAN in a cluster where vSphere HA is enabled. To turn off vSphere HA, select the cluster and select Configure | vSphere Availability.

Next navigate to Virtual SAN and select General. Then click on Configure.

Then I enable the Deduplication and Compression and I choose Configure two host Virtual SAN cluster.

Next the wizard check if vSAN adapters are available.

Then the wizard claims disk for cache tier and capacity tier.

Next choose the witness appliance and click on next.

Next, you should have a disk for the cache tier and another for the capacity tier. Just click on next.

To enable vSAN, just click on finish.

When vSAN is enabled successfully, you should have three servers and at least three diskgroups (2 nodes and the witness appliance).

In Fault Domains & Stretched Cluster you should have something like this screenshot. The witness host should be enabled. You can see that the 2-node configuration is the same as stretched cluster.

Now you can enable again the vSphere HA as below.

After moving a virtual machine to vSAN, you can see the below configuration. The VMDK has two components and a witness. Even if I lose one of the components or the witness, the VMDK will be ready.

Final configuration

In this section, you can find some recommendations provided by VMware for vSAN. These recommendations regard the configuration of the cluster, especially the vSphere Availability. First I change the heartbeat datastores setting to Use datastores only from the specified list and select no Datastore. This is a VMware recommendation for vSAN when vSAN nodes are also connected to another VMFS or NFS datastore. The heartbeat datastores is disabled to leave only the network heartbeat. If you leave heartbeat datastores enabled, if the network fails, the vSphere HA will not restart VM to another node. If you don’t want a VM restart to another node in case of network failure, keep this setting enabled.

To avoid warning because of datastore heartbeat is disabled (number of vSphere HA heartbeat datastore for this host is 0, which is less than required:2), you can add the following line in advanced options:

Das.ignoreInsufficientHbDatastore = True

For vSAN configuration, VMware recommends to enable Host Monitoring and change the response for host isolation to Power off and restart VMs. Thanks to Host Monitoring, the network will be used as heartbeating to determine the state of a host. The datastore with PDL (Permanent Device lost) and APD (All Path Down) should be disabled (for further information read this documentation). To finish, configure the VM Monitoring as you wish.

Conclusion

VMware vSAN provides an easy way for HA VM storage in branch office. If I compare with Microsoft Storage Spaces Direct, the 2-Node vSAN cluster is more complex to deploy because of the Witness Appliance. This appliance requires a third ESXi node in the same site or another datacenter. With Storage Spaces Direct, I can use a simple file share or Microsoft Azure as a Witness. Except this issue, vSAN is a great solution for your hyperconverged infrastructure.

The post Deploy a 2-node vSAN cluster 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.