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.

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.

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.

The NAS model used for this topic is a Synology RS815 NAS. But from vSphere perspective, this is the same configuration for others NAS/SAN model.

Understand type of iSCSI adapters

Before deploying an iSCSI solution, it is important to understand that several types of iSCSI network adapters exist:

• Software iSCSI adapters
• Hardware iSCSI adapters

Software iSCSI adapter is managed by the VMkernel. This solution enables to bind to standard network adapters without buying additional network adapters dedicated for iSCSI. However, because this model of iSCSI adapters is handled by the VMkernel, you can have an increase of CPU overhead on the host.

In the other hand, hardware iSCSI adapters are dedicated physical iSCSI adapters that can offload the iSCSI and related network workloads from the host. There are two kind of hardware iSCSI adapters:

• Independent hardware iSCSI adapters
• Dependent hardware iSCSI adapters

The independent hardware iSCSI adapter is a third-party adapter that don’t depend on vSphere network. It implements its own networking and iSCSI configuration and management interfaces. This kind of adapter is able to offload the iSCSI workloads from the host. In another word, this is a Host Bus Adapter (HBA).

The dependent hardware iSCSI adapter is a third-party adapter that depends on vSphere network and management interfaces. This kind of adapter is able to offload the iSCSI workloads from the host. In another word, this is a hardware-accelerated adapter.

For this topic, I’ll implement a Software iSCSI adapter.

Architecture overview

Before writing this topic, I have created a vNetwork Distributed Switch (vDS). You can review the vDS implementation from this topic. The NAS is connected to two switches with Vlan 10 and Vlan 52 (Vlan 10 is also used for SMB, NFS for vacation movies but it is a lab right :)). From vSphere perspective, I’ll create one software iSCSI adapter with two iSCSI paths.

The vSphere environment is composed of two ESXi nodes in a cluster and vCenter (VCSA) 6.5. Each host has two standard network adapters where all traffics is converged. From the NAS perspective, there are three LUNs: two for datastores and one for content library.

NAS configuration

In the Synology NAS, I have created three LUNs called VMStorage01, VMStorage02 and vSphereLibrary.

Then I have created four iSCSI targets (two for each ESXi host). This ensures that each node connects to NAS with two iSCSI paths. Each iSCSI target is mapped to all LUNs previously created.

Connect vSphere to iSCSI storage

Below you can find the vDS schema of my configuration. At this time, I have one port group dedicated for iSCSI. A create also a second port group for iSCSI.

Configure iSCSI port group

Once you have created your port group, we need to change teaming and failover configuration. In the above configuration, each node has two network adapters. Each network adapter is attached to an uplink.

Edit the settings of the port group and navigate to Teaming and failover. In the Failover order list, set an uplink to unused. From the first port group and set Uplink 2 to unused uplinks.

From the second port group, I set Uplink 1 to unused.

Add VMKernel adapters

From the vDS summary pane, click on Add and Manage Hosts. Then edit the VMKernel network adapters for all hosts. Next, click on new adapter.

Next, select the first iSCSI network and click on next.

On the next screen, just click on next.

Then specify the IP address of the VMKernel adapter.

Repeat these steps for the other nodes.

You can repeat this section for the second VMKernel iSCSI adapter. When you have finished your configuration, you should have something like that:

Add and configure the software iSCSI adapter

Then select the storage iSCSI adapter and navigate to Network Port Binding. Click on the “add” button and select both VMKernel network adapter.

Next, navigate to Targets, and select dynamic or static discovery regarding your needs. I choose Static Discovery and I click on add. Create one entry for each path with the right IP and target name.

When the configuration is finished, I have two targets as below. Run a rescan before to continue.

If you come back to Network Port Binding, both VMKernel network adapters should be marked as Active.

In Paths tab, you should have two paths for each LUN.

Create a datastore

Now that hosts have visibility on LUNs, we can create datastore. In vCenter navigate to storage tab and right click on the datacenter (or folder). Then select New datastore.

Select the datastore type. I create a VMFS datastore.

Then specify a name for the datastore and select the right LUN.

Next, choose the VMFS version. I choose VMFS 6.

Next specify the partition configuration as the datastore size, the block size and so on.

Once the wizard is finished, you should have your first datastore to store VM files.

Change the multipath algorithm

By default, the multipath algorithm is set to last used. So, only the last used VMKernel will be used. To leverage both VMKernel simultaneously, you have to change the multipath policy. To change the policy, click on the datastore, select the host and choose Edit multipathing.

Then select Round Robin to use both link. Once it is done, all paths should be marked as Active (I/O).

Repeat this step for each datastore.

Create a datastore cluster

To get access to Storage DRS feature, you can create a datastore cluster. If you have several datastore dedicated for VM, you can add them to datastore cluster and use Storage DRS to optimize resource usage. In the below screenshot, I have two datastore for VM (VMStorage01 and VMStorage02) and the content library. So, I’m going to create a datastore cluster where VMStorage01 & VMStorage02 are used.

Navigate to Datastore Clusters pane and click on New Datastore Cluster.

Give a name to the datastore cluster and choose if you want to enable the Storage DRS.

Choose the Storage DRS automation level and options.

In the next screen, you can enable I/O metric for SDRS recommendation to take into consideration the I/O workloads for recommendations. Then you set threshold to leave some space on datastore and latency.

Next select ESXi hosts that need access to the datastore cluster.

Choose the datastore that will be used in the datastore cluster.

Once the datastore cluster is created, you should have something like that:

Now, when you create a virtual machine, you can choose the datastore cluster and automatically, vSphere store the VM files on the least used datastore (regarding the Storage DRS policy).

The post Connect vSphere 6.5 to iSCSI storage NAS appeared first on Tech-Coffee.

Network configuration overview

To write this topic, I’ve worked on two VMware ESXi 6.5 nodes. Each node has two network adapters (1Gb/s). Each network adapter is plugged on a separate switch. The switch ports are configured in trunk mode where VLAN 50, 51, 52, 53 and 54 are allowed. The VLAN 50 is untagged. I’ve not set any LACP configuration.

The following network will be configured:

• Management – VLAN 50 (untagged) – 10.10.50.0/24: will be used to manage ESXi nodes
• vMotion – VLAN 51 – 10.10.51.0/24: used for vMotion traffic
• iSCSI – VLAN 52 – 10.10.52.0/24: network dedicated for iSCSI
• DEV – VLAN 53 – 10.10.53.0/24: testing VM will be connected to this network
• PROD – VLAN 54 – 10.10.54.0/24: production VM will be connected to this network

I’ll call the vNetwork Distributed Switch (vDS) with the following name: vDS-CAN-1G. To implement the following design I will need:

• 1x vNetwork Distributed Switch
• 2x Uplinks
• 5x distributed port groups

So, let’s go

vNetwork Distributed Switch creation

To create a distributed switch, open vSphere Web Client and navigate to network menu (in navigator). Right click on your datacenter and select Distributed Switch | New Distributed Switch

Then specify a name for the distributed switch. I call mine vDS-CNA-1G.

Next choose a distributed switch version. Depending on the version, you can access to more features. I choose the last version Distributed switch: 6.5.0.

Next you can specify the number of uplinks. In this example, only two uplinks are required. But I leave the default number of uplinks value to 4. You can choose to enable or not the Network I/O Control (NIOC). This feature provides QoS management. Then I choose to create a default port group called Management. This port group will contain VMKernel adapters to manage ESXi nodes.

Once you have reviewed the settings, you can click on finish to create the vNetwork distributed switch.

Now that vDS is created, we can add host to it.

Add hosts to vNetwork distributed switch

To add hosts to vDS, click on Add and Manage Hosts icon (on top of vDS summary page). Next choose Add hosts.

Next click on New hosts and add each host you want.

Check the following tasks:

• Manage physical adapters: association of physical network adapters to uplinks
  
• Manage VMKernel adapters: manage VMKernel adapters (host virtual NICs).

In the next screen, for each node, add physical network adapters to uplink. In this example, I have added each vmnic0 of both node to Uplink 1 and vmnic1 to Uplink 2.

When you deploy ESXi, by default a vSwitch0 is created with one VMKernel for management. This vSwitch is a standard switch. To move the VMKernel to vDS without connection lost, we can reassign the VMKernel to the vDS. To make this operation, select the VMkernels and click on Assign port group. Then select the Management port group.

The next screen presents the impact of the network configuration. When you have reviewed the impacts, you can click on next to add and assign hosts to vDS.

Add additional distributed port group

Now that hosts are associated to vDS, we can add more distributed port group. In this section, I add a distributed port group for vMotion. From the vDS summary pane, click on New Distributed Port Group icon (on top of the pane). Give a name to the distributed port group.

In the next screen, you can configure the port binding and port allocation. You can have more information about port binding in this topic. The recommended port binding for general use is Static binding. I set the number of ports to 8 but because I configure the port allocation to Elastic, the ports are increased or decreased as needed. To finish, I set the VLAN ID to 51.

Add additional VMKernel adapters

Now that the distributed port group is created, we can add VMKernel to this port group. Click on Add and Manage Hosts from vDS summary pane. Then select Manage host networking.

Next click on Attached hosts and select hosts you want.

In the next screen, just check Manage VMKernel adapters.

Then click on New adapter.

In Select an existing network area, click on Browse and choose vMotion.

In the next screen, choose vMotion services. In this way, the vMotion traffic will use this VMKernel.

To finish, specify TCP/IP settings and click on finish.

When this configuration is finished, the vDS schema looks like this:

So we have two port groups and two uplinks. In this configuration we have converged the management and vMotion traffics. Note that Management network has no VLAN ID because I’ve set the VLAN 50 to untagged from switches perspective.

Final result

By repeating the above steps, I have created more distributed port groups. I have not yet created VMkernel iSCSI adapters (for a next topic about storage :)) but I think you know what I’m saying. If you compare the below schema and the one of network overview, they are very similar.

The final job concerns QoS to leave enough bandwidth to specific traffic as vMotion. You can set the QoS thanks to Network I/O Control (NIOC).

The post Deploy a converged network with vSphere 6.5 appeared first on Tech-Coffee.

This topic shows you how to prepare a USB stick and an unattend file to deploy nearly automatically ESXi 6.5.

Architecture overview

In order that the following deployment works, I have done some configurations from a network perspective. I have configured the following:

• DHCP Server
• DNS Server (forward and reverse lookup zone)

The network address space is 10.10.50.0/24. In the DHCP server configuration, I have set a static IP for both ESXi:

Below you can find the forward lookup zone configuration in the Synology:

And below, you can find the reverse lookup zone:

Thanks to this configuration, the ESXi will obtain its production IP address (in DHCP) and its hostname from the reverse lookup zone during deployment. Then by using a script, the IP address has just to be set from DHCP to static.

Requirements

To follow this topic, you need the following:

• An USB stick with 8GB at least
• Rufus to prepare the USB stick
• ISO of VMware ESXi 6.5

Prepare the USB stick

To prepare the USB stick, plug it into your computer and run Rufus. This software is portable. Select the ISO image of ESXi 6.5 and set Rufus as the following screenshot:

If you have the following message when you start the format, just click on Yes.

Build the unattend file

To deploy my ESXi, I have used the following script. You can find an explanation in the comments. This script can be used for each ESXi to deploy while the static IP in DHCP and DNS are set.

#Accept VMware License agreement

accepteula


# Set the root password

rootpw MyPassword


# Install ESXi on the first disk (Local first, then remote then USB)

install --firstdisk --overwritevmfs


# Set the keyboard

keyboard French


# Set the network

network --bootproto=dhcp


# reboot the host after installation is completed

reboot


# run the following command only on the firstboot

%firstboot --interpreter=busybox


# enable & start remote ESXi Shell (SSH)

vim-cmd hostsvc/enable_ssh

vim-cmd hostsvc/start_ssh


# enable & start ESXi Shell (TSM)

vim-cmd hostsvc/enable_esx_shell

vim-cmd hostsvc/start_esx_shell


# supress ESXi Shell shell warning - Thanks to Duncan (https://www.yellow-bricks.com/2011/07/21/esxi-5-suppressing-the-localremote-shell-warning/)

esxcli system settings advanced set -o /UserVars/SuppressShellWarning -i 1


# Get Network adapter information

NetName="vmk0"


# Get the IP address assigned by DHCP

IPAddress=$(localcli network ip interface ipv4 get | grep "${NetName}" | awk '{print $2}')


#Get the netmask assigned by DHCP

NetMask=$(localcli network ip interface ipv4 get | grep "${NetName}" | awk '{print $3}')


# Get the gateway provided by DHCP

Gateway=$(localcli network ip interface ipv4 get | grep "${NetName}" | awk '{print $6}')

DNS="10.10.0.229"

VlanID="50"


# Get the hostname assigned thanks to reverse lookup zone

HostName=$(hostname -s)

SuffixDNS="vsphere.lab"

FQDN="${HostName}.${SuffixDNS}"


# set static IP + default route + DNS

esxcli network ip interface ipv4 set --interface-name=vmk0 --ipv4=${IPAddress} --netmask=${NetMask} --type=static --gateway=${Gateway}

esxcli network ip dns server add --server ${DNS}


# Set VLAN ID

esxcli network vswitch standard portgroup set --portgroup-name "Management Network" --vlan-id 50


#Disable ipv6

esxcli network ip set --ipv6-enabled=0


# set suffix and FQDN host configuration

esxcli system hostname set --fqdn=${FQDN}

esxcli network ip dns search add --domain=${SuffixDNS}


# NTP Configuration (thanks to https://www.virtuallyghetto.com)

cat > /etc/ntp.conf << __NTP_CONFIG__

restrict default kod nomodify notrap noquerynopeer

restrict 127.0.0.1

server 0.fr.pool.ntp.org

server 1.fr.pool.ntp.org

__NTP_CONFIG__

/sbin/chkconfig ntpd on


# rename local datastore to something more meaningful

vim-cmd hostsvc/datastore/rename datastore1 "Local - $(hostname -s)"


# restart a last time

reboot

Save the file and name it ks.cfg. Copy the file in the root of the USB stick.

Use the unattend file during deployment

Now we have to configure the boot the load the ks.cfg automatically for the deployment. Open the USB stick and edit Boot.cfg. Replace the following line kernelopt=runweasel by kernelopt=ks=usb:/ks.cfg.

Unplug the USB Stick and plug it on the server. You can boot the USB key to run the installer.

Deployment

During deployment, the installer will load the ks.cfg config file.

It starts by check if the config file is correct.

After the first reboot, the installer configures the ESXi as specified in the config file.

Once the system has rebooted for a second time, the configuration is finished.

For example, the SSH and the ESXi Shell are well enabled.

Conclusion

VMware provides a way to deploy quickly standard ESXi. If your infrastructure is not ready and you have not yet Auto Deploy, the deployment with unattended file can be a good option.

The post Deploy ESXi 6.5 from USB stick and unattended file 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.