![]() Here's the performance data that an appliance collects for a server running on VMware and sends to Azure: DataĬalculation for disk size, storage cost, server size Value generated using disk.UnitNumber, disk.Key, Vm.().FindAll(x => is VirtualEthernet).count Here's the full list of server metadata that the appliance collects and sends to Azure: DATA The appliance collects configuration, performance metadata, data about installed applications, roles and features (software inventory) and dependency data (if agentless dependency analysis is enabled) from servers running in your VMware environment. Microsoft doesn't use this data in any license compliance audit. Metadata discovered by the Azure Migrate appliance helps you to assess server readiness for migration to Azure, right-size servers and plans costs. ![]() The Azure Migrate appliance is a lightweight appliance that the Azure Migrate: Discovery and assessment tool uses to discover servers running in your environment and send server configuration and performance metadata to Azure. Needless to say I'm a bit confused right now.This article provides details of the metadata discovered by Azure Migrate appliance. Model name : Intel(R) Xeon(R) CPU E5620 2.40GHzįlags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid dca sse4_1 sse4_2 popcnt aes lahf_lm ida arat epb dtherm tpr_shadow vnmi flexpriority ept vpidĪddress sizes : 40 bits physical, 48 bits virtual ![]() At least that's what I see when looking at the CPUID flags reported by /proc/cpuinfo on two identical servers, one with CentOS 6 installed on bare metal and one with a virtualized CentOS 6 running atop of VMware ESX 5.5: Also, VMware doesn't pass through every single flag but only a limited subset thereof. My understanding is that the old operating systems are obviously not going to support the latest features and most likely ignore unknown CPUID flags but should still run just fine given their x86/x86_64 compatibility. I don't really expect any problems due to the fact that VMware has that entire virtual layer between the OS and the hardware, and the PowerEdge R7425 servers are fully supported and certified by VMware. On the other hand, our 32-bit SuSE 9 servers were once running on Pentium 4 based servers, virtualized a couple of years ago, and are now doing perfectly fine on Sandy Bridge with an old 2.6.19 kernel. In my understanding, the VMware hypervisor layer should take care of the hardware incompatibility issue, but there's that little bit of uncertainty in the back of my head mainly because VMware seems to be passing through most of the CPUID flags to the virtual operating system (as in: the virtual machines can see what exact CPU type and architecture the host has installed) which could cause potential problems with older kernels. The latest Xeon processors (Skylake-SP) are on the other hand supported but will require at least RHEL 6.9: Īs far as I was able to find out this only applies to RHEL installed directly on bare metal without any virtualization layers in-between the OS and the hardware. What worries me most are our production servers running CentOS 6 - according to RedHat, EPYC is not and will not be supported on RHEL6. Those aren't mission critical and we might be able to either replace them or keep one or two Westmere-Hosts around for these specific machines until we can get rid of them for good. We have several virtualized Linux servers running on these VMware clusters, among others some CentOS 5 and even SuSE 9 legacy servers. We need to replace our current VMware Servers with new ones, and are currently seriously considering switching from our current Xeon servers (Sandy Bridge and even Westmere) to Dell PowerEdge R7425 AMD EPYC-based servers that will be running VMware ESXi 6.5U1 due to their higher core count and support for up to 1 TB RAM per CPU (compared to only 768 GB for Intel's current line-up).
0 Comments
Leave a Reply. |