Skip to main content

Posts

Showing posts from December, 2019

Project Pacific VMware

Project Pacific Project Pacific is a re-architecture of vSphere with Kubernetes as its control plane. To a developer, Project Pacific looks like a Kubernetes cluster where they can use Kubernetes declarative syntax to manage cloud resources like virtual machines, disks and networks. To the IT admin, Project Pacific looks like vSphere – but with the new ability to manage a whole application instead of always dealing with the individual VMs that make it up. Project Pacific will enable enterprises to accelerate development and operation of modern apps on  VMware vSphere  while continuing to take advantage of existing investments in technology, tools and skillsets. By leveraging Kubernetes as the control plane of vSphere, Project Pacific will enable developers and IT operators to build and manage apps comprised of containers and/or virtual machines. This approach will allow enterprises to leverage a single platform to operate existing and modern apps side-by-side. The

vMotion

vMotion VMware vMotion enables the live migration of running virtual machines from one physical server to another with zero downtime, continuous service availability, and complete transaction integrity. It is transparent to users. vMotion advantage: Automatically optimize and allocate entire pools of resources for maximum hardware utilization and availability. Perform hardware maintenance without any scheduled downtime. Proactively migrate virtual machines away from failing or underperforming servers. Virtual machine and its host must meet resource and configuration requirements for the virtual machine files and disks to be migrated with vMotion in the absence of shared storage. vMotion in an environment without shared storage is subject to the following requirements and limitations: The hosts must be licensed for vMotion. The hosts must be running  ESXi  5.1 or later. The hosts must meet the networking requirement for vMotion. See  vSphere vMotion Net

Enhanced vMotion

Enhanced vMotion (EVC) vSphere Enhanced vMotion is a feature through which workload can be live migrated from one ESXi host to another ESXi host which are running on different CPU generation but with same cpu vendor. EVC in vSphere was introduced in vSphere 5.1 using vMotion and Storage vMotion terminology. EVC can be enabled at the vSphere ESXi Cluster and on VM's. Figure 1 VMware EVC Mode works by masking unsupported processor having different generation of same vendor and presenting a homogeneous processor to all the vm's in a cluster. The benefit of EVC is that you can add ESXi host consist of latest processors to exising cluster without incurring any downtime. The VMware Compatibility Guide is the best way to determine which EVC modes are compatible with the processors used in your cluster.  Below in  figure 1 demonstrates how to determine which EVC mode to use given 3 types of Intel processors. https://www.vmware.com/resources/compatibility/s

Rolling Updates and Rollbacks in Kubernetes

Rolling Updates and Rollbacks in K8s In our environment everyone has several application deployed and running successfully. Each application comes with a version and time by time application vendor releases new version of it where new version consist of new features and previous bug fixes. Now, its become must task to update our applications to leverage new features. So, how will be make the strategy to upgrade our applications into production environment. Its quite difficult to update all the application at once as it would hamper the stability of the environment. In Kubernetes there is default strategy of deployment called Rolling updates where we do not destroy all the application at one, instead we bring down the application older version and bring back the new version of the application one by one. By doing this application never goes down and upgrade is seamless. It's require to specify the upgrade strategy into the deployment. If there is no suc

Monitoring & Logging in Kubernetes

Monitoring cluster components  of Kubernetes (K8s) There are various type of monitoring we can perform at the cluster, node level and pod level. At cluster level we can monitor like number nodes running, how many are healthy, performance status, network usage etc.   At the POD level we can monitor disk and cpu, memory utilisation, Performance metrics of each POD about its resources. To utilise the experience of monitoring on kubernetes cluster we can use “ Metrics server ”  We can have 1 metrics server per cluster. It's retrieves the information about Nodes , PODS aggregate them and store them into memory.  Matrics server is IN-MEMORY solution where the data or information which it fatch from nodes and pod will be in memory and does not store it in disk.  As Metrics server is " IN-MEMORY " where it's not possible to retrieve the historical data about the kubernetes resources. To get the historical data its require to use advance to

What Is Kubernetes.....

What Is Kubernetes..... Running a container on a laptop is relatively simple. But, connecting containers across multiple hosts, scaling them, deploying applications without downtime, and service discovery among several aspects, can be difficult.                                             Kubernetes is the one which addresses those challenges from the start with a set of primitives and a powerful open and extensible API. The ability to add new objects and controllers allows easy customization for various production needs.  According to the  kubernetes.io  website, Kubernetes is:  "an open-source system for automating deployment, scaling, and management of containerized applications".  Kubernetes is that it builds on 15 years of experience at Google in a project called borg.   Kubernetes is inspired by Borg - the internal system used by Google to manage its applications (e.g. Gmail, Apps, GCE). Methodology of Kubernetes Deploying c

Popular posts from this blog

Changing the FQDN of the vCenter appliance (VCSA)

This article states how to change the system name or the FQDN of the vCenter appliance 6.x You may not find any way to change the FQDN from the vCenter GUI either from VAMI page of from webclient as the option to change the hostname always be greyed out. Now the option left is from the command line of VCSA appliance. Below steps will make it possible to change the FQDN of the VCSA from the command line. Access the VCSA from console or from Putty session. Login with root permission Use above command in the command prompt of VCSA : /opt/vmware/share/vami/vami_config_net Opt for option 3 (Hostname) Change the hostname to new name Reboot the VCSA appliance.   After reboot you will be successfully manage to change the FQDN of the VCSA . Note: Above step is unsupported by VMware and may impact your SSL certificate and face problem while logging to vSphere Web Client. If you are using self-signed certificate, you can regenerate the certificate with the

VM Creation Date & Time from Powercli

Most of the times we have several requirement when we talk about IT environment like designing , deployment , compliance check or for Security auditing the environment. Somewhere during security auditing we require to provide several information to security team to get successful audit. One of them is the compliance of Virtual machine auditing of creation date and time. Here into this post we will explore how to get the creation date and time of virtual machine hosted into the vCenter or ESXi. To get the details we will use VMware Powercli to extract the details. By default there is no function added into Powercli to get such details, so here we will add a function of vm creation date. Below is the function which needed to be copy and paste into the Powercli. ======================================================================= function  Get-VMCreationTime  {     $vms  =  get-vm     $vmevts  = @()     $vmevt  =  new-object  PSObject     for

Unable to poweron the VM. (Failed to lock the file)

I have encountered may issues like where after some upgrade or migration we were unable to power on the VM. Figure 1 An error was received from the ESX host while powering on VM HSSVSQL01. Failed to start the virtual machine. Cannot open the disk '/vmfs/volumes/578d835c-18b2c97a-9b0d-0025b5f13920/SAMPLE1_cloud/000000.vmdk' or one of the snapshot disks it depends on. Failed to lock the file In above Figure:1, where while powering on the VM, its prompt for an error. Well, there are several reason for where the VM unable to poweron and you can find many article on this. Here in this article we will discuss to resolve this issue. Please use below step to resolve the disk lock issue  C hecked that VM is running on snapshot if its getting error " VM Consolidation required". Checked the snapshot manager if its showing any snapshot. If yes, try to delete the  snapshot. Verified the same from Esxi cl
google.com, pub-4920175566720914, DIRECT, f08c47fec0942fa0 google.com, pub-4920175566720914, DIRECT, f08c47fec0942fa0