vNEX's Posts

sorry I missed the license info in your initial post... So first if you have a two separate SSO domains  "Connect to a remote site" is the correct option exactly as it is on your screen shot. ... See more...
sorry I missed the license info in your initial post... So first if you have a two separate SSO domains  "Connect to a remote site" is the correct option exactly as it is on your screen shot. Next step is to type correctly IP/FQDN of the server on the target site where PSC is running...for successful registration with target PSC you need credentials of the DR site SSO domain user who has VRM remote.Manage VRM priviledge assigned (i.e. -> VRM administrator User Role). The last but not least step is to verify that traffic between ESXi host (its VR agent) on primary site  to VR Appliance at DR site is routed properly ... By default vSphere Replication is using ESXi management interface to send replication traffic to the VReplication appliance on the DR site. (its also possible to separate VR traffic from mgmt network) Please post hbrsrv.log and hms.log In addition to the HBR ports you need also: Default Port Protocol or Description Source Target Endpoints or Consumers 80 TCP vSphere Replication appliance Remote vCenter Server All management traffic to the vSphere Replication appliance goes to port 80 on the vCenter Server proxy system. 80 HTTP vSphere Replication appliance Remote ESXi host Used to establish the connection before initial replication starts
you have a several options to upgrade your host... If you have vSphere Update Manager in your environment you will need an ISO file. Same applies for interactive install/upgrade using bootable ... See more...
you have a several options to upgrade your host... If you have vSphere Update Manager in your environment you will need an ISO file. Same applies for interactive install/upgrade using bootable ISO/CD/DVD ... If you want to upgrade your host via ESXCLI you have to download and use ESXi offline/patch bundle which is available in form of ZIP archive and includes all the VIBs needed for an upgrade. Take note that in the opposite to ISO installer esxcli method  doesn't  perform any pre-upgrade checks for potential problems like unsupported HW etc. so double-check you server hardware for compatibility with ESXi 5.5U2 release before you start. For an upgrade from 5.0 to 5.5 use image profile option as follows: Determine profile name available in the downloaded bundle: esxcli software sources profile list --depot=file:///<path_to_profile_ZIP_file>/<profile_ZIP_file> Run upgrade: esxcli software profile update --depot=file:///<path_to_profile_ZIP_file>/<profile_ZIP_file> --profile= profile_name Download the latest relese below: https://my.vmware.com/group/vmware/patch#search
Hi, just to be sure have you verified that administrator@vsphere.local account have proper permissions on VC object (by default it has administrator rights on VC) and not for some reason just... See more...
Hi, just to be sure have you verified that administrator@vsphere.local account have proper permissions on VC object (by default it has administrator rights on VC) and not for some reason just a SSO admin rights ... If you are able to login via  vSphere C# client and not only via Web client it could be caused by wrong registration to the lookup service. Web client can see only vCenter server instances that are registered to the same lookup service. (you can made some typo during installation...) As a workaround you can try to reregister Web client and vCenter with SSO/lookup service: for vCenter: repoint.cmd configure-vc --lookup-server lookup_service_url --user single_sign_on_admin_user --password single_sign_on_admin_password --openssl-path "path_to_OpenSSL_bin_directory/" Example: repoint.cmd configure-vc --lookup-server https://Your-VC-FQDN:7444/lookupservice/sdk --user "administrator@vSphere.local" --password "account-password" --openssl-path "C:\Program Files\VMware\Infrastructure\Inventory Service\bin/" for Webclient: client-repoint.bat https://machinename.corp.com:7444/lookupservice/sdk "administrator@vSphere.local" "SSO_pw1@" after these steps restart following services: - VMware VirtualCenter Server - VMware VirtualCenter Management Webservices Good luck!
Hi, was your server installed using standard ESXi image made by VMware or comes as pre-installed from hardware vendor (i.e. DELL custom image) That determines which installation ISO you have ... See more...
Hi, was your server installed using standard ESXi image made by VMware or comes as pre-installed from hardware vendor (i.e. DELL custom image) That determines which installation ISO you have to use for an upgrade. If its a standard VMware image you can download installation iso here: VMware vSphere 5: Private Cloud Computing, Server and Data Center Virtualization (chose - ESXi 5.5 Update 1 ISO image (Includes VMware Tools)) If its a custom Dell image you must download iso directly from DELL: VMware ESXi 5.5 Update 1 Image Driver Details | Dell US In addition here is the complete list of Dell custom images available: http://downloads.dell.com/Manuals/all-products/esuprt_software/esuprt_virt_solutions/vmware-esxi-5_Reference%20Guide4_en… Download page: http://www.dell.com/Search/al/en/aldhs1/support/drivers/results?filters=categoryidnavigator~EC%2Cdriversoscodenavigator~… I would recommend you to go for the latest release i.e. 5.5 U2: VMware ESXi 5.5 Update 2 Driver Details | Dell US VMware vSphere 5: Private Cloud Computing, Server and Data Center Virtualization
Hi, if both sites uses the same SSO domain you should chose "Connect to a local site" option  at the Target sites connection ... If above is your case please post VR and VRMS logs they are ... See more...
Hi, if both sites uses the same SSO domain you should chose "Connect to a local site" option  at the Target sites connection ... If above is your case please post VR and VRMS logs they are located here: VRMS  logs (hms*.log ) are located at /opt/vmware/hms/logs VR logs (hbrsrv*.log ) are located at /var/log/vmware Double check: 1. That  you have all required ports open between both sites on  firewall especially port 31031 which is used for the initial replication traffic, for complete list of required ports see: VMware KB: Port Numbers that must be open for vSphere Replication 5.8.x and 6.0 2. That there is no DNS resolution issues with the  FQDN of vCenter servers and verify CN and SAN on VC certificates ...
Hello Pete, however direct migration from Windows vCenter Server to VCSA is not supported there is a fling available on VMware Labs. VCS to VCVA Converter – VMware Labs Take note that it i... See more...
Hello Pete, however direct migration from Windows vCenter Server to VCSA is not supported there is a fling available on VMware Labs. VCS to VCVA Converter – VMware Labs Take note that it is an experimental tool so use it carefully on production systems: VCS to VCVA Converter – TERMS The steps should be in following order: 1. convert VCS 5.5 to VCSA 5.5 2. upgrade VCSA to 6.0 Regarding SSO transition above steps will end with internal PSC. With use of external PSC you can have a mixed environment (only) during time of transition ... Mixed-Version Transitional Environments in vCenter Server for Windows Upgrades
Hi, SSL session always start with SSL handshake where both sides via client/server HELLO messages (RFC 3546) negotiates the SSL protocol version, cipher suites and other parameters used to es... See more...
Hi, SSL session always start with SSL handshake where both sides via client/server HELLO messages (RFC 3546) negotiates the SSL protocol version, cipher suites and other parameters used to establish secured communication. In this phase the server also sends to the client its certificate so the client can authenticate the server and his identity. (It verifies certificate validity, issuing CA trust/signature, CN on cert match to server hostname ...etc.)  If the server for some reason cannot be authenticated session will then close. If the server authentication succeeds SSL handshake continues to exchange the master secret which will be then used by both sides to create symetric sessions keys used for encyption/decryption of any consequent communication. Once this is done both send each other a message that all future communication between them will be encrypted with created session key. At this moment SSL handshake ends and all consequent messages/communication between them is encrypted. Until then NO passwords or "application data" are interchanged between these two sources in clear text....
Hi, there should be no difference in available ESXi shell commands between vSphere Hypervisor and paid vSphere editions. The main difference is that "free ESXi" -> vSphere Hypervisor have i... See more...
Hi, there should be no difference in available ESXi shell commands between vSphere Hypervisor and paid vSphere editions. The main difference is that "free ESXi" -> vSphere Hypervisor have its API only for read only access which limits/prevents remote management of that hypervisor using vCLI, PowerShell, Perl ... (including vCenter and vMA) Can you please post what commands you missing in ESXi shell? For list of available command line interfaces refer to this list: http://pubs.vmware.com/vsphere-60/topic/com.vmware.vcli.getstart.doc/cli_jumpstart.3.2.html For list of available vCLI commands go here: vSphere Command-Line Interface Reference Entire vCLI documentation: https://www.vmware.com/support/developer/vcli/
its quite obvious from the backtrace that the PF 14 was invoked by the i40e driver while "it sends buffer on TX ring" result was --> TX driver issue detected, PF reset issued for some reaso... See more...
its quite obvious from the backtrace that the PF 14 was invoked by the i40e driver while "it sends buffer on TX ring" result was --> TX driver issue detected, PF reset issued for some reason the requested page wasn't successfully loaded into the memory so next you have to distinguish between hardware/software fault you will need to compare few samples of consecutive PSOD screens. Then its quite simple if the error message (stack info 0x4123c...) information vary between vmkernel errors (PSOD) its likely a hardware issue. If error messages  between failures remains the same its likely a software issue. In addition for both scenarios please check if there is always the same CPU or world involved across these failures. Please post vmkernel.log from the time before the fault and right after the fault. (if its reproducible, hope it is on heavy load) Also try to reproduce the issue with TSO or LRO (or both) disabled on that host. # esxcli system settings advanced set -o /Net/UseHwTSO -i 0 # esxcli system settings advanced set -o /Net/TcpipDefLROEnabled -i 0 to verify its disabled run: esxcli system settings advanced list -o /Net/UseHwTSO esxcli system settings advanced list -o /Net/TcpipDefLROEnabled For additional info about these setting refer to this KB: VMware KB: Understanding TCP Segmentation Offload (TSO) and Large Receive Offload (LRO) in a VMware environment As a last resort if you have proper SnS you can file a SR to VMware Support they will need your core dump. VMware - How to File a Support Request Online | VMware | &amp;#268;esk&amp;#225; republika VMware KB: Extracting a core dump file from the VMKCore diagnostic partition following a purple diagnostic screen er…
Hi, have you checked your firmware version with the latest NVM Update Utility: https://downloadcenter.intel.com/download/24769
update for those with Windows 2012 R2 VMs with E1000/E1000e adapters >>> VMware KB: Windows 2012 virtual machines using E1000/E1000e driver experience loss of network connectivity
Hi, regarding your confusion about Preconfigured/Non-preconfigured environments and other options please have look to this document I wrote on that topic... hope it helps you to understand IB... See more...
Hi, regarding your confusion about Preconfigured/Non-preconfigured environments and other options please have look to this document I wrote on that topic... hope it helps you to understand IBM terminology and logic behind... (I have also found that IBM documentation is a bit confusing which was the reason that push me to make up this "hopefully" comprehensible guide) https://communities.vmware.com/docs/DOC-28310 Regarding to your connection issue doublecheck that you are able to successfully connect from your vCenter server (SRM server) to Storwize web management (https://10.1.30.243/login) ; (https://10.1.30.247/login) with "superuser" username and password. Also verify that "superuser" account has sufficient privileges granted in IBM Storwize web management.
Hello, first check which files consumes most of the /var space ... navigate to /var folder and run: #: du -h  | less Ping back with results ....
Hello, Yes you can mix different (supported) hardware even from different HW vendors in one cluster. You can also have hosts with different HW configuration (in terms of CPU family used, numb... See more...
Hello, Yes you can mix different (supported) hardware even from different HW vendors in one cluster. You can also have hosts with different HW configuration (in terms of CPU family used, number of CPU/RAM installed, HBA/NICs used ...etc.) Ideally is best to have identical server hardware which has similar HW configuration and comes from the same HW vendor. Every single difference or heterogeneity in the VMware HA cluster hardware makes things more complex which will lower cluster manageability and increase demands on administrators when you have to troubleshoot some issues or just configure the cluster. Mixing two HP Proliant G7/8 servers is absolutely OK just be careful about RAM size if its just two-node HA cluster you will not be able to failover all the VMs in case of HW failure of the first host (160GB)... which will result in much less availability of your VMs. In addition such configuration will also lead to an unbalanced cluster (and possible waste of the resources) in terms of HA Admission Control (used to reserve resources in the cluster for possible failover events) and reduce DRS considerations/lower possible vMotion initiated by DRS. I would recommend you to add some RAM to the second host to balance resources if its possible.
Hi, just in addition to already mentioned ... Cisco have introduced on some UCS systems a feature called Cluster on Die (COD). Cisco Unified Computing System BIOS Settings - Cisco Cluster ... See more...
Hi, just in addition to already mentioned ... Cisco have introduced on some UCS systems a feature called Cluster on Die (COD). Cisco Unified Computing System BIOS Settings - Cisco Cluster on Die (CoD) snoop is available on Intel Xeon processor E5-2600 v3 CPUs that have 10 or more cores. Note that some software packages do not support this setting: for example, at the time of writing, VMware vSphere does not support this setting. CoD snoop is the best setting to use when NUMA is enabled and the system is running a well-behaved NUMA application. A well-behaved NUMA application is one that generally accesses only memory attached to the local CPU. CoD snoop provides the best overall latency and bandwidth performance for memory access to the local CPU. For access to remote CPUs, however, this setting results in higher latency and lower bandwidth. This snoop mode is not advised when NUMA is disabled. This feature is nicely clarified in this article: http://www.enterprisetech.com/2014/09/08/intel-ups-performance-ante-haswell-xeon-chips/ New feature called Cluster On Die, or COD, that breaks the Haswell Xeon E5 chips with 10 or more cores into different NUMA regions to make sure the data doesn’t drift too far from the cores in these beasts. It essentially breaks the chip at the interconnect switch and treats it like two chips as far as the software is concerned, and for many workloads, this actually boosts performance significantly. Important part is that this feature is not supported by VMware ... below is support statement: VMware KB:     Known limitations of the Intel® Xeon® processor E5 v3 series with ESXi 5.1.x and ESXi 5.5 Update 2 ESXi 5.1 with patch ESXi510-201407001 and ESXi 5.5 Update 2 do not support the Cluster-On-Die feature on Intel Xeon processor E5 v3 series vSphere does not support the Cluster-On-Die feature on Intel Xeon processor E5 v3 series. Workaround: ESXi 5.1 with patch ESXi510-201407001 and ESXi 5.5 Update 2 systems must have the Cluster-On-Die feature on Intel Xeon processor E5 v3 series disabled because it is currently not supported by vSphere.   From USC Release 2.2(3c) you should be able to suppress COD feature by changing CPU Snoop settings in UCSManager via Service Profile and BIOS policy. Release Notes for Cisco UCS Software, Release 2.2 - Cisco Change it to one of these settings: - Early Snoop (ES) is available on all Intel Xeon processor E5-2600 v3 CPUs. It provides good local memory latency and bandwidth, but with a severe penalty in bandwidth for remote CPU access. ES should be used for latency-sensitive applications that do not require high remote bandwidth: for example, certain online transaction processing (OLTP) database workloads. - Home Snoop (HS) is also available on all Intel Xeon processor E5-2600 v3 CPUs and is excellent for NUMA applications that need to access a remote CPU on a regular basis. Of the snoop modes, HS provides the best remote CPU bandwidth and latency, but with the penalty of slightly higher local latency, and is the best choice for memory and bandwidth-intensive applications: for example, certain decision support system (DSS) database workloads.
Hello Martin, Oracle Database/Client at version 12.1.0.2 isn't listed as supported solution for vCenter server (5.5U2)  and SRM (5.8) databases. Only one listed as supported for vCenter 5.5U2... See more...
Hello Martin, Oracle Database/Client at version 12.1.0.2 isn't listed as supported solution for vCenter server (5.5U2)  and SRM (5.8) databases. Only one listed as supported for vCenter 5.5U2 and SRM 5.8 is Oracle 12c R1 at version 12.1.0.1. All later patchsets/releases aren't listed as supported ... So you have two options ask VMware support for confirmation and also some hint for this KB article: VMware KB: vCenter Server installed on Windows with Oracle database crashes Second just try use SRM with Oracle 12.1.0.1 release. See Interoperability Matrixes for reference: http://partnerweb.vmware.com/comp_guide2/sim/interop_matrix.php?
Hi, below are described both methods one for vCenter 6.0 and second for vCSA 6.0: VMware KB: Back up and restore the embedded PostgreSQL database
I don't know with which licensing you operate assuming it is Server 2012 licensing model which is completely different from previous on 2008 Servers... First Datacenter license is only worth i... See more...
I don't know with which licensing you operate assuming it is Server 2012 licensing model which is completely different from previous on 2008 Servers... First Datacenter license is only worth if your environment has plenty of VMs and gradually increase in numbers ... For low density virtual environments for example 50 VMs/on 8+ blades or an absurd scenario of 10VMs per 8 blades your choice is definitely Standard licensing. One Standard edition license entitles up to two VOSEs on up to two processors (2 socket server) = 8x Standard license enables you to run up to 16 VOSEs on 8 blades... For detailed and precise licensing info see this document: http://download.microsoft.com/download/F/3/9/F39124F7-0177-463C-8A08-582463F96C9D/Windows_Server_2012_R2_Licensing_Datas… So lets say you only had 10 VM's and 8 Physically servers, yes this does seem unrealistic, but just for the sake of argument, If I had one HA cluster with 8 physical servers then i would have to buy 5 Microsoft licenses for each physical server.  So 40 licenses total.  Or buy 8 Datacenter licenses.  In this case buying individual licenses would probably be cheaper then the datacenter licenses. Why 5 MS licenses for 1 physical server ??? With Server 2012 licensing model you only need 1MS Standard license per Blade for example above. But if I split it up into two HA clusters, so 5 VM in each HA cluster, and say 4 physical servers in each Cluster (yes that's allot of physically servers for so little VM's, just an example), so then I would need allot less Microsoft individual licenses as long as the VM's never get moved over to the other physical hosts. Is that allowed, I just don't want to break any Microsoft Licensing.  Im assuming its just on me to make sure the VM's never get migrated to the other hosts. Yes you can use DRS affinity rules to restrain VMs only to licensed hosts but regarding this I would ask some MS licensing specialist or license supplier. For more on that read "Q: What are my licensing options for the recovery server as part of disaster recovery planning?" section of document above.
Hi, as others already point out your best option is to buy Microsoft Datacenter license  ... one per hypervisor CPU/Socket allows you to run an unlimited number of instances of Windows Servers... See more...
Hi, as others already point out your best option is to buy Microsoft Datacenter license  ... one per hypervisor CPU/Socket allows you to run an unlimited number of instances of Windows Servers simultaneously in virtual OSEs (ESXi servers) Any additional info about that topic is here: Microsoft Licensing with VMware | Licensing Articles Microsoft Volume Licensing Brief - Licensing Microsoft Server Products in Virtual Environments http://download.microsoft.com/download/3/D/4/3D42BDC2-6725-4B29-B75A-A5B04179958B/WindowsServer2012VirtualTech_VLBrief.p… Once you have all the necessary CPU licenses you have to activate deployed MS servers via MAK key or KMS server with appropriate keys given by MS/DELL. With MAK you have to manually enter this key on every server separately ... with KMS you will need to install KMS server into your environment and activate him with given key. Once its done your servers should find KMS server on network and activate automatically...for more details see: Deploying KMS Activation Using MAK Activation
Hi, definitely go for the latest release (5.5 U2) [only HW or SW limitations of your current environment can push you to 5.1] before you start with upgrade check that your actual environmen... See more...
Hi, definitely go for the latest release (5.5 U2) [only HW or SW limitations of your current environment can push you to 5.1] before you start with upgrade check that your actual environment meet all the requirements (including VMware HCL) for vSphere 5.5 use these links: VMware KB: Upgrading to vCenter Server 5.5 best practices VMware Compatibility Guide: System Search Upgrade steps with correct order: Upgrading Environments with Host Clusters VMFS3 datastores can be upgraded to VMFS5 once all of your hosts will be on 5.x release or non of the legacy (4.1) hosts are accessing the datastore... For more info about VMFS5 upgrade see: VMware KB: Frequently Asked Questions on VMware vSphere 5.x for VMFS-5 In addition have a look at these sources: VMware KB: Block size limitations of a VMFS datastore VMware KB: Methods of upgrading to vCenter Server 5.5 VMware KB: Methods for upgrading to ESXi 5.5