VMware vSphere 4.1 deep dive - part 1

Editor's Notes

• #5: Isn’t cluster supported in 4.0.1? Compared the 2 manuals closely.Design here can mean better design, or you can fix/propose things that you can’t before, or give you more options to take on larger or more complex design.Cost here can mean lower Product cost, Services cost (e.g. reduce effort from partner) or less effort (if internal IT is doing it).Scalability means you can do more, like do more VM per ESX. Performance means can do the same thing but faster. For example, backing up a VM is faster.Memory Compression reduces cost: more VM per ESX means less ESX host, or smaller RAM expense.Scripted install improves security as it reduces risk of variance among installation.ESXi SAN boot improves security as ESXi config are not stored in a hundred places.vSphere 4.1 introduces an FT-specific versioning-control mechanism that allows the Primary and Secondary VMs to run on FT-compatible hosts at different but compatible patch levels. vSphere 4.1 differentiates between events that are logged for a Primary VM and those that are logged for its Secondary VM, and reports why a host might not support FT. In addition, you can disable VMware HA when FT-enabled VMs are deployed in a cluster, allowing for cluster maintenance operations without turning off FT.Compare with 4.0. The VMware HA dashboard in the vSphere Client provides a new detailed window called Cluster Operational Status. This window displays more information about the current VMware HA operational status, including the specific status and errors for each host in the VMware HA cluster.
• #6: Hyper-V import: without it, it will be more complex and may require longer down time.ESX 4.1 takes advantage of deep sleep states to further reduce power consumption during idle periods. The vSphere Client has a simple user interface that allows you to choose one of four host power management policies. In addition, you can view the history of host power consumption and power cap information on the vSphere Client Performance tab on newer platforms with integrated power meters. Need screenshot and new machine.Faster vMotion improves management as you spend less time waiting for 10 VMs to complete vMotion as you prepare to do hardware maintenance.In some cases, you are given a fixed window to do your maintenance. And you want the 5 or 15 VMs in that host to vmotion as fast as possible.vSphere 4.1 reduces the amount of overhead memory required, especially when running large VMs on systems with CPUs that provide hardware MMU support (AMD RVI or Intel EPT).vSphere 4.1 includes an AMD Opteron Gen. 3 (no 3DNow!™) EVC mode that prepares clusters for vMotion compatibility with future AMD processors. EVC also provides numerous usability improvements, including the display of EVC modes for VMs, more timely error detection, better error messages, and the reduced need to restart VMsVmware Tools now have CLI, which
• #7: VMware Data Recovery is actually available in 4.0.1 too, as it’s compatibleVMFS enhancements: minor. Transparent to usersThere have been many algorithm changes between v3.33 and and 3.46 VMFS-3.46 driver uses hardware accelerated locking and hardware accelerated Storage VMotion, Virtual Machine provisioning, and cold migrate functions on such hardware. This improved the performance and scalability of workloads that require the above functions.Personally, there are those who are 100% convinced on the benefit of iSCSI boot. This is because it’s mixing storage and network, and can make troubleshooting/support complex.VADP: VSS on Win08NFS performance improvement. Quantified?NFS Performance Enhancements. Networking performance for NFS has been optimized to improve throughput and reduce CPU usage
• #8: Nexus is not released yet.vDS: scalabilityvNIC enhancements: E1000 vNIC supports jumbo frames
• #9: You can use Host Profiles to roll out administrator password changes in vSphere 4.1. Enhancements also include improved Cisco Nexus 1000V support and PCI device ordering configurationUnattended Authentication in vSphere Management Assistant (vMA). vMA 4.1 offers improved authentication capability, including integration with AD and commands to configure the connectionUpdate Manager 4.1 immediately sends critical notifications about recalled ESX and related patches. In addition, Update Manager prevents you from installing a recalled patch that you might have already downloaded. This feature also helps you identify hosts where recalled patches might already be installed.The License Reporting Manager provides a centralized interface for all license keys for vSphere 4.1 products in a virtual IT infrastructure and their respective usage. You can view and generate reports on license keys and usage for different time periods with the License Reporting Manager. A historical record of the utilization per license key is maintained in the vCenter database
• #14: an 8-vCPU SMP VM is considered wide on an Intel Xeon 55xx system because the processor has only four cores per NUMA node
• #15: ESXi was released around 2 years ago. Just sharing my experience as SE. In this short period of 2 years, the discussions that I have with customers or partners have progressed, from “what is ESXi” to “why should we use ESXi” to “we are using or planning to use ESXi”. For a platform software, it is doing very well since it needs to build its ecosystem.
• #16: We can say that vSphere 4.1 is the release for ESXi. In this release ESXi takes center stage. 4.1 is our strongest message that we are going toward ESXi as the sole hypervisor. A lot of customers, even some of the largest deployment, have decided to go ESXi going forward. If your customers have not, 4.1 is a good opportunity for you offer a migration services or hardware refresh.As SE, we also know that there are some features that we wish we have in the 4.0 release. For example, while the remote CLI helps, none of the Linux command works as the execution context is the VMA OS, not the ESXi kernel. And in some troubleshooting scenario, customers do need to issue linux command. Another thing we can’t do automatic installation and boot from network.
• #20: One of the most popular requests among customers is to improve the deployment and management of ESXi.First in the line is boot From SAN is now fully supported in ESXi 4.1. It was as only experimentally supported in ESXi 4.0. Boot from SAN will be supported for FC, iSCSI, and FCoE. For iSCSI and FCoE, it will depend upon hardware qualification, so please check the HCL and Release Notes when vSphere 4.1 is released.Dependent Hardware iSCSI means the card depends on VMware networking, and iSCSI configuration and management interfaces provided by VMware. So properties like IP, MAC, and other parameters used for the iSCSI sessions are configured from VMware GUI/CLI.http://www.vmware.com/resources/compatibility/info.php?deviceCategory=san&mode=san_introductionFor ESXi text installer we have a screen that warns if the user is trying to install image onto an existing data store. It will not prevent user from installing if he/she desires to do so. For scripted install, unless user specifies an override VMFS flag, scripted install will not proceed with installation when a user tries to install on an existing datastore. We will only support a booting of host on a unique LUN. This LUN *cannot be* shared by other hosts. User is expected to set proper LUN masking to avoid this scenario. If the luns were to be shared it could result in data corruption. ----------- copied from 3rd party site iSCSI SW boot: the only currently supported network card is the Broadcom 57711 10GBe NIC. When booting from software iSCSI the boot firmware on the network adapter logs into an iSCSI target. The firmware than saves the network and iSCSI boot parameters in the iBFT which is stored in the host’s memory. Before you can use iBFT you need to configure the boot order in your server’s BIOS so the iBFT NIC is first before all other devices. You than need to configure the iSCSI configuration and CHAP authentication in the BIOS of the NIC before you can use it to boot ESXi from. The ESXi installation media has special iSCSI initialization scripts that use iBFT to connect to the iSCSI target and present it to the BIOS. Once you select the iSCSI target as your boot device the installer copies the boot image to it. Once the media is removed and the host rebooted the iSCSI target is used to boot and the initialization script runs in first boot mode which configures the networking which afterwards is persistent.
• #21: Second features we have implemented is more choice during install. We can now do PXE boot, and we can script it too.Scripted Installation, the equivalent of Kickstart, is now available. The installer can boot over the network, and at that point you can also do an interactive installation, or else set it up to do a scripted installation. Both the installed image and the config file (called “ks.cfg”) can be obtained over the network using a variety of protocols. There is also an ability to specify preinstall, postinstall, and first-boot scripts. For example, the postinstall script can configure all the host settings, and the first boot script could join the host to vCenter. These three types of scripts run either in the context of the Tech Support Mode or in Python. The Tech Support Mode shell is a highly stripped down version of bash.You can start the scripted installation with a CD-ROM drive or over the network by using PXE booting. You cannot use scripted installation to install ESXi to a USB device
• #22: The media depot is a network-accessible location that contains the ESXi installation media. You can use HTTP/HTTPS, FTP, or NFS to access the depot. The depot must be populated with the entire contents of the ESXi installation DVD, preserving directory structure.If you are performing a scripted installation, you must point to the media depot in the script by including the install command with the nfs or url option.The following code snippet from an ESXi installation script demonstrates how to format the pointer to the media depot if you are using NFS:install nfs --server=example.com --dir=/nfs3/VMware/ESXi/41
• #23: The preboot execution environment (PXE) is an environment to boot computers using a network interfaceindependently of available data storage devices or installed OS. These topics discuss thePXELINUX and gPXE methods of PXE booting the ESXi installer.PXE uses DHCP and Trivial File Transfer Protocol (TFTP) to bootstrap an OS (OS) over a network.Network booting with PXE is similar to booting with a DVD, but it requires some network infrastructure anda machine with a PXE-capable network adapter. Once the ESXi installer is booted, it works like a DVD-based installation,except that the location of the ESXi installation media (the contents of the ESXi DVD) must be specified.A host first makes a DHCP request to configure its network adapter and then downloads and executes a kerneland support files. PXE booting the installer provides only the first step to installing ESXi. To complete theinstallation, you must provide the contents of the ESXi DVD either locally or on a networked server throughHTTP/HTTPS, FTP, or NFS.TFTP is a light-weight version of the FTP service, and is typically used only for network booting systems orloading firmware on network devices such as routers.If you do not use gPXE, you might experience issues while booting the ESXi installer on a heavily loadednetwork. This is because TFTP is not a robust protocol and is sometimes unreliable for transferring largeamounts of data. If you use gPXE, only the gpxelinux.0 binary and configuration file are transferred via TFTP.gPXE enables you to use a Web server for transferring the kernel and ramdisk required to boot the ESXi installer.If you use PXELINUX without gPXE, the pxelinux.0 binary, the configuration file, and the kernel and ramdiskare transferred via TFTP.Setting up a new DHCP server is not recommended if your network already has one. If multipleDHCP servers respond to DHCP requests, machines can obtain incorrect or conflicting IP addresses, or canfail to receive the proper boot information. Seek the guidance of a network administrator in your organizationbefore setting up a DHCP
• #24: Scripted Installation, the equivalent of Kickstart, will be supported on ESXi 4.1. The installer can boot over the network, and at that point you can also do an interactive installation, or else set it up to do a scripted installation. Both the installed image and the config file (called “ks.cfg”) can be obtained over the network using a variety of protocols. There is also an ability to specify preinstall, postinstall, and first-boot scripts. For example, the postinstall script can configure all the host settings, and the first boot script could join the host to vCenter. These three types of scripts run either in the context of the Tech Support Mode shell (which is a highly stripped down version of bash) or in Python.
• #25: The firstboot scripts are run as initscripts. All initscripts have a numerical part in their filenames. They are sorted by that numerical part to determine the order in which they are run. So a script with "90.1" would run after a script with "90.0" and before a script with "90.2"
• #26: Finally, the Tech Support Mode is fully supported. We support both the local, when you are in front of the server, or remote, when you are using SSH.In ESXi 4.0, Tech Support Mode usage was ambiguous. We stated that you should only use it with guidance from VMware Support, but VMware also issued several KBs telling customers how to use it. Getting into Tech Support Mode was also not very user-friendly.The warning not to use TSM has been removed from the login screen. However, anytime TSM is enabled (either local or remote), a warning banner will appear in vSphere Client for that host. This is meant to reinforce the recommendation that TSM only be used for fixing problems, not on a routine basis.The SysAdminTools URL in the message above will take you to vMA, PowerCLI, CLI, etc.
• #27: To enable or disable from the console, it’s pretty straight forward. By default, after you enable TSM (both local and remote), they will automatically become disabled after 10 minutes. This time is configurable, and the timeout can also be disabled entirely. When TSM times out, running sessions are not terminated, allowing you to continue a debugging session. All commands issued in TSM are logged by hostd and sent to syslog, allowing for an incontrovertible audit trail.When lockdown mode is enabled, DCUI access is restricted to the root user (so root can still go in), while access to Tech Support Mode is completely disabled for all users. With lockdown mode enabled, access to the host for management or monitoring using CIM is possible only through vCenter. Direct access to the host using the vSphere Client is not permitted.
• #28: As you know, the tech support mode is not for day to day use. So anytime it is enabled, we will flag it.
• #29: We can also enable it via the GUI. You select the ESXi you want to manage, then click on the “Configuration” tab. From here, click on the “Security Profile”. Clicking on the properties brings up this dialog box. From here, we can stop and start the relevant services.
• #30: Procedure:1 Log in to the host from the vSphere Client.2 From the Configuration tab, select Advanced Settings.3 From the Advanced Settings window, select Annotations.4 Enter a security message.The message is displayed on the direct console Welcome screen.
• #31: There is now an ability to totally lock down a host. Lockdown mode in ESXi 4.1 forces all remote access to go through vCenter. So Lockdown mode is only available on ESXi hosts that have been added to vCenter.
• #32: The only local access is for root to access the DCUI – this could be used, for example, to turn off lockdown mode in case vCenter is down. However, there is an option to disable DCUI in vCenter. In this case, with Lockdown mode turned on, there is no possible way to manage the host directly – everything must be done through vCenter. If vCenter is down, the only recourse in this case is to reimage the box.Of course, Lockdown Mode can be selectively disable for a host if there is a need to troubleshoot or fix it via TSM, and then enabled again.BTW,
• #33: Vscsistats has also been ported and now is available directly in the ESXi console.It is an advanced commands, and can be used to identify the IO patterns.
• #34: Other useful utilities for troubleshooting have been added to TSM
• #47: You can add multiple USB devices, such as security dongles and mass storage devices, to a VMthat resides on an ESX/ESXi host to which the devices are physically attached. Knowledge of devicecomponents and their behavior, VM requirements, feature support, and ways to avoid data losscan help make USB device passthrough from an ESX/ESXi host to a VM successful.When you attach a USB device to a physical host, the device is available only to VMs that resideon that host. Those VMs cannot connect to a device on another host in the datacenter.A USB device is available to only one VM at a time. When you remove a device from a virtualmachine, it becomes available to other VMs that reside on the host.USB Arbitrator Manages connection requests and routes USB device traffic. The arbitrator isinstalled and enabled by default on ESX/ESXi hosts. It scans the host for USBdevices and manages device connection among VMs that reside onthe host. It routes device traffic to the correct VM instance fordelivery to the guest OS. The arbitrator monitors the USB deviceand prevents other VMs from using it until you release it from theVM it is connected to.If vCenter polling is delayed, a device that is connected to one virtualmachine might appear as though it is available to add to another virtualmachine. In such cases, the arbitrator prevents the second VM fromaccessing the USB device.USB Controller The USB hardware chip that provides USB function to the USB ports that itmanages. The virtual USB Controller is the software virtualization of the USBhost controller function in the VM.USB controller hardware and modules that support USB 2.0 and USB 1.1devices must exist on the host. Only one virtual USB controller is available toeach VM. The controller supports multiple USB 2.0 and USB 1.1USB devices in the virtual computer. The controller must be present before youcan add USB devices to the virtual computer.The USB arbitrator can monitor a maximum of 15 USB controllers. Devicesconnected to controllers numbered 16 or greater are not available to the virtualMachineBefore you hot add memory, CPU, or PCI devices, you must remove any USB devices. Hot adding theseresources disconnects USB devices, which might result in data loss.n Before you suspend a VM, make sure that a data transfer is not in progress. During thesuspend/resume process, USB devices behave as if they have been disconnected, then reconnected. Also,if you use vMotion to migrate a VM away from the host that the USB device is attached to, itwon't be reconnected when the VM is resumedFor compound devices, the virtualization process filters out the USB hub so that it is not visible to the virtualmachine. The remaining USB devices in the compound appear to the VM as separate devices. Youcan add each device to the same VM or to different VMs if they reside on the samehost.
• #49: Another feature that was requested a lot is to integrate with MS AD. This further simplify the management of vSphere as we can now be consistent with vCenter.AD integration provides authentication for all local services. This means access via Admin Client, via the console, via remote console are all based on AD.ESX and ESXi should integrate with MS AD for all user authentication. This effectively removes static information from the ESX host and enables the "plug and play" and "stateless appliance" concepts. Customers do not want to manage user accounts on ESX or ESXi because it is additional work to what they would do in a physical environment. Lowers the Opex of managing a VI environment and also competitively positions our platform with Hyper-V which can do this today. Customers don’t want to rely on VC for these functions due to HA of VC.
• #51: So how do we do it? One way is to select the ESX that you want to add to AD, and choose the “Configuration” tab. From this page, choose the “authentication service” link. Click on the properties link, the dialog box shown on the next slide is shown.
• #52: From the dialog box that pops up, select “AD” from the drop down.Then specify the Domain name.Then click “Join Domain”. The next dialog box will pop up to let you enter the ID which can join a domain. Click on Join Domain button to join the domain. If there is an error, an error message will be prompted. If not, ESXi will join the domain.
• #53: I guess a question from customer will be how they can do this automatically, if they have a lot of ESXi and not enough Sys Admin to manage all these things.We have enhanced our host profile. Here is the screen where we can configure the same info in the host profiles.
• #60: The idea of memory compression is very straightforward: if the swapped out pages can be compressed and stored in a compression cache located in the main memory, the next access to the page only causes a page decompression which can be an order of magnitude faster than the disk access. With memory compression, only a few uncompressible pages need to be swapped out if the compression cache is not full. This means the number of future synchronous swap-in operations will be reduced. Hence, it may improve application performance significantly when the host is in heavy memory pressure. In ESX 4.1, only the swap candidate pages will be compressed. This means ESX will not proactively compress guest pages when host swapping is not necessary. In other words, memory compression does not affect workload performance when host memory is undercommitted. 3.5.1 Reclaiming Memory Through Compression Figure 8 illustrates how memory compression reclaims host memory compared to host swapping. Assuming ESX needs to reclaim two 4KB physical pages from a VM through host swapping, page A and B are the selected pages (Figure 8a). With host swapping only, these two pages will be directly swapped to disk and two physical pages are reclaimed (Figure 8b). However, with memory compression, each swap candidate page will be compressed and stored using 2KB of space in a per-VM compression cache. Note that page compression would be much faster than the normal page swap out operation which involves a disk I/O. Page compression will fail if the compression ratio is less than 50% and the uncompressible pages will be swapped out. As a result, every successful page compression is accounted for reclaiming 2KB of physical memory. As illustrated in Figure 8c, pages A and B are compressed and stored as half-pages in the compression cache. Although both pages are removed from VM guest memory, the actual reclaimed memory size is one page. If any of the subsequent memory access misses in the VM guest memory, the compression cache will be checked first using the host physical page number. If the page is found in the compression cache, it will be decompressed and push back to the guest memory. This page is then removed from the compression cache. Otherwise, the memory request is sent to the host swap device and the VM is blocked. The per-VM compression cache is accounted for by the VM’s guest memory usage, which means ESX will not allocate additional host physical memory to store the compressed pages. The compression cache is transparent to the guest OS. Its size starts with zero when host memory is undercommitted and grows when VM memory starts to be swapped out. If the compression cache is full, one compressed page must be replaced in order to make room for a new compressed page. An age-based replacement policy is used to choose the target page. The target page will be decompressed and swapped out. ESX will not swap out compressed pages. If the pages belonging to compression cache need to be swapped out under severe memory pressure, the compression cache size is reduced and the affected compressed pages are decompressed and swapped out. The maximum compression cache size is important for maintaining good VM performance. If the upper bound is too small, a lot of replaced compressed pages must be decompressed and swapped out. Any following swap-ins of those pages will hurt VM performance. However, since compression cache is accounted for by the VM’s guest memory usage, a very large compression cache may waste VM memory and unnecessarily create VM memory pressure especially when most compressed pages would not be touched in the future. In ESX 4.1, the default maximum compression cache size is conservatively set to 10% http://www.vmware.com/files/pdf/techpaper/vsp_41_perf_memory_mgmt.pdfNote that this paper is written based on ESX4.0 memory management paper. Besides the new content introduced in ESX4.1, e.g., memory compression, quite a few places have been updated to represent the state of the art of ESX memory management.
• #63: What does the counter _really_ mean as it’s an _average_ of a _rate_?
• #66: Esxtop also has a power view “p”
• #67: (2) The feature of displaying per-VM power consumption is experimentaland off by default. It can be turned on with an advanced config optionas the paragraph describes. The per-VM power consumption feature isdependent on the host power consumption feature
• #70: HA and DRS have always been the popular features among our customers. I have quite a number of customers who found that HA is good enough for their SLA and moved from MS clustering. In the 4.1, we have a couple of enhancements in these main features.
• #71: Give tips on HATypes of cluster: prod, dmz, tier 2, IT cluster, non prod, desktop, why min host is 4This slides give a summary of the new enhancements. As customers adopt more and more virtualisation, we are entering the phase where mission critical workloads are virtualised. With all these enhancements in 4.1, customers may be tempted to create large clusters and put everything there. By large I mean either large no of nodes, or a lot of VMs in single cluster. Personally, I still prefer the traditional approach, where a cluster is really the building block. So we have multiple clusters, with distinct purpose.From the list above, something that I think customers will appreciate is the
• #72: In the past, customers reported that they very occasionally saw DRS "get it wrong" in the sense that DRS would move VMs based on purely performance criteria with scant regard for the availability anxiety. What this means is, in the past it was possible (if somewhat unlikely) for DRS to place 20 VMs on an ESX host and only put 8 VMs on another. While that may have been a good idea from a performance standpoint, it could lead to scenarios where DRS itself created an "eggs in one basket" scenario, as DRS didn't distribute VMs to prevent one ESX host from becoming overpopulated (and with a bigger VM count) than another. In this scenario, DRS would have to carry out VMotions to free up resources so HA can power on a VM.
• #78: For Application Monitoring, developers would develop application monitoring agents using the Application Monitoring SDK for specific applications running in the VM. There is support added in VMware Tools for an application to report its heartbeat/status. This gets communicated to vCenter as an "AppHeartbeatStatus" (similar to the "GuestHeartbeatStatus"). HA can respond to that by going red, indicating that the application has died. Thus, Application monitoring would work for those applications that use the new VMware Tools capability along with an application monitoring agent to report application status. To enable Application MonitoringObtain the SDK from VMware (this is for the ISV, not end customers)Use it to set up customized heartbeats for the applications you want to monitor.
• #81: Since the hypervisor has full control over the execution of a VM, including delivery of all inputs, the hypervisoris able to capture all the necessary information about non-deterministic operations on theprimary VM and to replay these operations correctly on the backup VM.The tagging scheme doesn’t introduce any significant delay of the replaying VM, since the hypervisorof the recording (primary) VM guarantees that last log entry of each single instructionemulation or a device operation is marked as a go-live point. Since the backup VM cannotbe significantly delayed, the primary VM is also not affected by the use of go-live points
• #82: Patches can cause host build numbers to vary between ESX and ESXi installations. To ensure that your hosts are FT compatible, do not mix ESX and ESXi hosts in an FT pair.
• #84: FT with vSphere 4.1 still has some incompatibilities Thin Provisioning and Linked ClonesHot plug devices and USB PassthroughIPv6 (as HA does not support)vSMPN-Port ID Virtualization (NPIV)StorageVMotionSerial/ parallel portsPhysical and remote CD/ floppy
• #85: Business opportunity: migrate customer from clustering (running 2 instance) to FT, where we have higher up time
• #86: #1: If administrators wanted to move an ESX hosts from one vCenter instance to a new one (for whatever reasons) they usually did not bring the ESX host into maintenance mode.But adding the host to the new vCenter server without removing it from the previous one caused FT failures.Now the administrator will get a warning- which can be followed or ignored (yes/no) if he tries to add an ESX host which is managed by a different vCenter.#2: DRS will vMotion FT enabled VMs if needed and will place them according to DRS groups and other rules. Storage vMotion is not supported with FT, though.#3: If an administrator disabled HA he was forced to disable FT first. Now he gets a warning and he can decide to override and accept FT will not work as expected. Following this decision several operations re to FT will be disabled while HA is off.
• #95: So how do we do it? We can now create 2 types of group: groups of VM and groups of ESX.We then map the VM group to the ESX group
• #96: An ESX host can belong to multiple group?
• #102: The separate rules now include more than only two VMs.If you select a “Separate rule” and include 5 VMs you’ll need at least 5 ESX hosts to accommodate this rule as each of them must run on separate host.
• #105: vMotion is not a cluster feature. We can vMotion across cluster.? Can we vMotion from 2 clusters with different EVC? We can try this on the lab.We should be able to vMotion from 4.0 to 4.1, as we can do from 3.5 to 4.1
• #110: This sound quite complicated but is easy to understand.Assumimg a VM was powered on on an older EVC mode and migrated (without powering off) to a cluster with a newer mode (and newer feature).So in this case the VM is “part” of the new EVC mode, but does not use the new features- instead still the old ones.Previously if you tried to vMotion this VM to and ESX host with the older EVC mode vCenter complained about them not being compatible- as the ESX host was not compatible to the current EVC mode the VM is running.Now it checks which mode the VM itself uses and accepts vMotioning to an older mode- as the VM doesn’t care and is still not using the new features.
• #112: Earlier Add-Host Error detection: Host-specific incompatibilities are now displayed prior to the Add-Host work-flow when adding a host into an EVC cluster.
• #116: in the vSphere VM Administation Guide page 92 vmware writes: "You can verify the CPU settings for the VM on the Resource Allocation tab.“But in this menu you can see no indication to the multi core configuration. what do I have to look for? Is it already implemented in the vSphere 4.1 RC ?When you configure multicore virtual CPUs for a VM, CPU hot Add/remove is disabled.For more information about multicore CPUs, see the vSphere Resource Management Guide. You can also searchthe VMware KNOVA database for articles about multicore CPUshttp://www.cpuid.com/softwares/cpu-z.html provides a more detailed view within each Guest OS________________Need to see if we can use Orchestrator or PowerShell to check this
• #117: Need to see the PowerCLI and vSphere API to see if we can do this programmatically
• #118: Note that “Average Capacity” in the report refers to the average capacity of all license keys for that product. Products (e.g. vSphere Enterprise) can have multiple keysEach key has a capacity and usage associated with it.In the screen above:Current capacity is total capacity for all the keysAverage capacity is the average capacity for the keys. For example…Product: vSphere Enterprisekey | capacity | usagexxxx-xxxx—xxxx | 1000 | 500yyyy-xxxx—xxxx | 2000 | 100 For the product, vSphere Enterprise we would report:Total Capacity  - 3000Total Usage – 600Average Usage – 300Average Capacity – 1500