I am going to do a couple of blogposts with “basic” workflows using the Web Client. Let me know if you find this useful or not… I will start with deploying the vCenter Server appliance and will assume you all know how to install ESXi. I prefer using the vCenter Server appliance in my lab as I can deploy it in minutes without the need to pre-install an OS etc. The following steps outline the import process of the vCenter Server appliance. Open the vSphere Client Click “File – Deploy OVF Template” Browse for the OVA file Provide a name for the to be imported virtual machine, in our case “vCenter-01” Select a datastore where this virtual machine should be stored Use the default Disk Format Provide the networking details like IP address, DNS, netmask etc. Finish the wizard During the reinstallation of my lab environment I ran in to this issue a couple of times. In my environment when I deploy the vCenter Server Virtual Appliance (VCVA) I always got the following error on the remote console: No Networking Detected This seems to happen when I point my vSphere Client directly to a host and import the OVA. When you point your vSphere Client directly at a host you do not have the option to fill out the networking details in the OVF wizard. (At least I don’t…) When I point my vSphere Client to a vCenter Server and import the OVA I get the option to fill out the networking details. Log In to the VMware vCenter Server…

vSphere 5.x does not allow operations to be performed directly on an ESX host managed by a virtual center. This error is given while connected directly to an ESXi server with vSphere client, attempting to resize a virtual disk on a VM (to add more capacity). However as this ESXi server and its virtual machines was managed by vCenter server, it would not let me modify its "resource settings" i.e. its disk size. There is a way to remove the host from thinking it was connected to vCenter. This is probably not supported by VMware and I do not support it but it works. 1. Connect to the ESXi server either on the console or via SSH 2. Edit /etc/vmware/vpxa/vpxa.cfg vi /etc/vmware/vpxa/vpxa.cfg Remove the whole vpxa section including <vpxa> and </vpxa> "d" <vpxa> <bundleVersion>1000000</bundleVersion> <datastorePrincipal>root</datastorePrincipal> <hostIp>123.123.123.123</hostIp> <hostKey>52e16e0d-07e4-366e-7bf6-73279af3c8f0</hostKey> <hostPort>443</hostPort> <licenseExpiryNotificationThreshold>15</licenseExpiryNotificationThreshold> <memoryCheckerTimeInSecs>30</memoryCheckerTimeInSecs> <serverIp>123.123.123.123</serverIp> <serverPort>902</serverPort> </vpxa> Save it ":wq!! 3. Restart the services /sbin/services.sh restart 4. Connect back to the ESXi server with vSphere client and it should now let you make the changes Note: I would very much assume at this point if the host was managed by vCenter you will have to disconnect and reconnect the host to push out the VPXA agent and config, otherwise you wont be able to manage the host via vCenter. As it happens the ESXi server I had this issue with was no longer managed by vCenter server as someone has rebuilt vCenter, but had not removed this host from vCenter before doing so. Before I did a fresh install of vCenter,I want to add some more…

Posted on October 2, 2013 by Mark Achtemichuk There is a lot of outdated information regarding the use of a vSphere feature that changes the presentation of logical processors for a virtual machine, into a specific socket and core configuration. This advanced setting is commonly known as corespersocket. It was originally intended to address licensing issues where some operating systems had limitations on the number of sockets that could be used, but did not limit core count. KB Reference: http://kb.vmware.com/kb/1010184 It’s often been said that this change of processor presentation does not affect performance, but it may impact performance by influencing the sizing and presentation of virtual NUMA to the guest operating system. Reference Performance Best Practices for VMware vSphere 5.5 (page 44):http://www.vmware.com/pdf/Perf_Best_Practices_vSphere5.5.pdf Recommended Practices #1 When creating a virtual machine, by default, vSphere will create as many virtual sockets as you’ve requested vCPUs and the cores per socket is equal to one. I think of this configuration as “wide” and “flat.” This will enable vNUMA to select and present the best virtual NUMA topology to the guest operating system, which will be optimal on the underlying physical topology. #2 When you must change the cores per socket though, commonly due to licensing constraints, ensure you mirror physical server’s NUMA topology. This is because when a virtual machine is no longer configured by default as “wide” and “flat,” vNUMA will not automatically pick the best NUMA configuration based on the physical server, but will instead honor your configuration – right or wrong – potentially leading to a topology mismatch that does affect performance. To…