After installing CloudPhysics, you will be able to gain insight into your environment which will help you .choose the right virtual machines to migrate. In this video you will learn how to run reports and choose the right virtual machines to migrate to the cloud. In this module you will learn strategies and considerations for choosing which virtual machines to migrate to the cloud. There are many different kinds of applications running inside virtual machines, for instance customer-facing applications, back office, developer tools, and experimental apps to name a few. There are three categories to keep in mind when choosing virtual machines to migrate. Apps that are easy to move. These have fewer dependencies, are usually newer, and are written internally so they have no licensing considerations and are also more tolerant to scaling and other cloud patterns. Apps that are difficult to move. These have dependencies and are less tolerant to scaling or have complex licensing requirements. Apps that won't be moved. Some apps that might not be good candidates to migrate, run on specialized or older hardware, have business or regulatory requirements that make it necessary for them to stay in your data center or even have complex licensing requirements that don't allow them to move to the cloud. One of the ways to sort VMs for migration is to tag them by the level of migration difficulty the application that runs on them imposes. When you install CloudPhysics, you can gain insight into the environment that runs your application and are then able to make data-driven decisions. This data can particularly help with selecting which workloads to migrate to the cloud. CloudPhysics introduces the concept of cards which are collections of data. For instance there's the host analysis card which provides you with hardware related reports or the guest operating system card which analyzes which systems within your infrastructure are running specific operating system types and versions. As we explore these cards the main goal is to identify and tag virtual machines that are suitable for migration, harder to migrate or should just remain on premises. The host analysis card provides an overview of the current hardware running in your VMware Vcenter environment as well as versions of deployed VMware ESXi hypervisors. This card is useful for identifying and tagging virtual machines that run on VMware ESXi hypervisor versions that are about to enter or have already reached their end of support. Identifying these hypervisors helps mitigate common stability and security risks within your environment. Another subset of virtual machines worth paying attention to is within the host analysis card. These are virtual machines supported by VMware hosts that run on hardware that is not supported by VMWare's Hardware Compatibility List also known as an HCL. Finally you can identify VMware hosts that are not compatible with your minimum desirable version of the ESXi hypervisor which can also be a good candidate for migration. For instance if your organization only allows VMware host running ESXi version 6.7 or higher the host analysis card can quickly identify hosts that are running older versions of ESXi, which do not comply with your corporate policy. Virtual machines running on top of these out of compliance hypervisors can be strong candidates for cloud migration. Each workload in your data center has an operating system, gaining insight into the operating system families and versions that are running in your data center can make you aware of the risks opportunities and general diversity within your organization's workloads. Each environment is different and the guest operating system analysis card can provide a filtering mechanism that will help you bulk tag or untag all virtual machines that run a specific version of an operating system. For example, if you have an operating system license agreement for a specific operating system that cannot be migrated to the cloud the guest operating system analysis card can help you easily tag the virtual machines running these operating systems and mark them as unsuitable for migration. I will show you how to do that in the upcoming demo video. Another useful filtering mechanism is tagging all machines that are currently powered off as not suitable for migration because they might not be needed in your Cloud environment. Knowing the estimated cost per workload for on-premises workloads is critical in order to make the business justification to move to the cloud which is the purpose of this on-premise IT cloud simulator card. Multiple variables can directly affect your cost per workload. Deep insight into hardware, software, management, environmental, and depreciation metrics is key to establishing an accurate total cost of ownership or TCO estimate the on-premise it Cloud simulator card will do just this so that you can easily build a proper business justification for moving to the cloud the gcp cloud simulator card will match your virtual machines to gcp compute engine virtual machine. Students types and will predict the total cost of ownership of running them in the cloud. The simulator card can include manually tagged virtual machines or all of the virtual machines that are compatible with GCP and also exclude virtual machines that cannot be migrated because of unsupported operating systems and other factors. When you run your infrastructure on premises, there's a tendency to be more generous with resource allocation. Most of your investment is paid up front when you buy the underlying hardware and therefore it is not uncommon to over-provision virtual machines as a result. In addition to the potential to create contention between virtual machines as your fleet grows, the over allocation of resources can balloon your cloud bill with no added benefit. When you lift and shift to the cloud you pay for what you allocate. Therefore the proper right-sizing of virtual machine resources based on actual use is critical. Right sizing is leveraging analytics based recommendations for how to map on-premises instances to cloud instance types with the ability to optimize for either performance or a control. You can configure the simulation to estimate how much the migrated virtual machines will cost based on the same configuration as on-premises or you can right size based on the virtual CPU parameters. Certain performance metrics like peak CPU usage can be misleading. Let's say for instance a software update might have caused a virtual CPU usage on a particular virtual machine to temporarily spike throughout the month. In a scenario like this the virtual CPU peak usage would not be the best indicator for how many virtual CPUs your machine may need. It is for this reason that peak usage metrics are often considered less desirable to determine actual virtual CPU utilization. Despite this, virtual CPU peak usage metric would ensure that your virtual machine has the necessary resources during those times of peak use, but remember there's a financial cost associated for allocating cloud resources that you rarely need. A better solution to properly right size your soon-to-be cloud environment is to leverage the 99th and 95th percentile performance metrics. 99th percentile refers to the maximum CPU utilization rate for 99% of the time a system is running filtering out any odd and infrequent CPU spikes which would have been represented in the previously mentioned peak usage metric. You can also think of it as 1% of the time the CPU was above that metric. 95th percentile works the same way but determines the maximum CPU utilization rate for 95% of the time a system is running. There's a contextual decision here to make between the applications tolerance for CPU spikes and desired billing optimization. One last thing to note is that the longer the CloudPhysics observer can collect data the more accurate the statistics will be. Once you migrate to the cloud, Google will provide you with right-sizing recommendations for compute engine virtual machines running in the cloud within 24 hours of their operation.
