spravtek's Accepted Solutions

Is your DNS working correctly in your environment? Maybe try adding 127.0.0.1 in your host file during setup... Something like this: %pre --interpreter=busybox Echo > /etc/resolv.conf Echo “127.0.0.1 localhost  ... ..." Failing that, you could go through some troubleshooting tips here (you might already have tried them all though): http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1002849

Sorry, had to delete previous comment, wasn't the correct way to go I think ... Maybe, if following doesn't work. From: VMware KB: Creating a local VMFS datastore after a fresh installation of ESXi 5.x fails with the error: Error during… Type over ssh: fdisk -u /vmfs/devices/disks/naa.690b11c049b2a600194a4c871a10b492 Then following: The number of cylinders for this disk is set to 36404. There is nothing wrong with that, but this is larger than 1024, and could in certain setups cause problems with: 1) software that runs at boot time (e.g., old versions of LILO) 2) booting and partitioning software from other OSs    (e.g., DOS FDISK, OS/2 FDISK) Command (m for help): d Partition number (1-4): 1 Command (m for help): d Selected partition 2 Command (m for help): w The partition table has been altered! Calling ioctl() to re-read partition table ~ # Then Type following again for confirmation fdisk -lu

Hi, Did you make sure that the manually created users are using SQL Server authentication? From the release notes: Connection to the MSSQL database fails during vCenter Single Sign On installation The error message Database connection has failed appears when  you install vCenter Single Sign On and you are using manually created  MSSQL database users. For MSSQL databases, you must use SQL Server  Authentication database users. Windows Authentication users are not  supported.

Yes, when we perform UPS tests, we take the whole environment down, let the UPS shut down completely and everything ... Besides that, I also take down the hosts when performing maintenance on the blade chassis as well ... Haven't had issues ... Knock on wood If you're not changing anything fundamental on the chassis or the hosts, you should be ok ... And when the hosts are down (if) then it won't matter if the uplinks are gone ... If you leave them in maintenance you'll obviously will see some, if not a lot, of alarms

Is management needed for both networks separately? Because if not, you can move the management port-group to the internal network on vmnic1.. Create a vmkernel port and enable it for management, give it an IP-address and it should be possible to connect to the internal network.

I was going to post the same as vGuy above ... So I will give you the option to do it through the console/ssh ... You can find the guidelines in this KB: http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1029513

You should probably use VLANs with different port groups for the perimeter network ... I think your physical NICs will not be abundant since it's a blade server. You'd need to configure something like this, this is just an example: Each leg of the firewall will be in its own VLAN, the problem with this is, that you'll need a switch which has this VLAN setup as well... In your case that will probably be the blade switch in the enclosure ... So you'll need to configure 1 VLAN per perimeter (eg: 100 for red, 101 for orange, 201 for green) ... If you do have 4 network cards in your server/blade, you could separate all perimeters per physical NIC and create separate vSwitches for each physical NIC, where 1 vSwitch will be red, 1 vSwitch will be orange and 1 vSwitch will be green. The management network will stay separate where possible ... As in, don't connect it with your Firewall or anything else.

If you go to the Host Profiles section in vCenter, right click on your reference profile, you can choose "Enable/Disable Profile Configuration" ... Here you can disable sections of the profile you don't want to get checked for compliance ...

Maybe this: http://adminotes.blogspot.be/2012/12/vsphere-general-system-error-occurred.html Can help you along ... Seems they had the same issue regarding an old DC... Though maybe you've tried all these things already.

Yes you can configure the Virtual Machines to start-up/suspend/shutdown automatically in vCenter. ref. http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=850

Hi ... Since your hardware isn't on the VMware HCL (http://www.vmware.com/go/hcl) it probably has to do with the onboard network card of your motherboard. The onboard network card of your motherboard is a Realtek RTL8111E and is known to have these issues (ref: http://communities.vmware.com/message/2123117 - last post is interesting) Easiest way to resolve this is to get an extra supported network card like Intel PRO/1000

Well ... Normally this isn't for your build .. But the purple screen you have does look remarkably similar to this: http://kb.vmware.com/selfservice/search.do?cmd=displayKC&docType=kc&externalId=2038767&sliceId=1&docTypeID=DT_KB_1_1&dialogID=547930176&stateId=1%200%20547936335 Does your ESXi come up/stay up at all or is it completely down? ... If you can access it, you could test with this setting ... Though as I said, normally if your build is higher than this it should be solved.

Sorry, I'm not an Oracle licensing expert This Oracle licensing FAQ may help you though: http://www.orafaq.com/wiki/Oracle_licensing I think you could take the Oracle Standard One maybe? Though it is restricted to only 2 CPU sockets, so if you ever want more CPUs, you'll need to buy another license.

This KB is for configuring syslog on ESXi 4.x: http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1016621 ESXi 4.x syslogging is different from 5.1, so options may vary ... Basically, as long as the syslogs are comming in your defined folders on your syslog server then your server is configured correctly, as you already found the xml-file you know you can change folders there ... That's about it.

Hi, This is mentioned in the vSphere 5.1 release notes: Network policy compliance failures continue for host profiles created from ESXi 4.1  or ESXi 4.0 hosts applied to ESXi 5.1 hosts After applying a host profile created from an ESXi 4.1 or ESXi 4.0 host to an ESXi 5.1 host, the  following host profile compliance failures might continue: For port group [PORT GROUP NAME] network policy property spec.policy.nicTeaming.failureCriteria doesn't match For port group [PORT GROUP NAME] network policy property spec.policy.nicTeaming.reversePolicy doesn't match The above network settings are not supported on ESXi 5.1 hosts and are no longer configured when  applying a host profile containing those settings. Workaround: Two possible remedies are available: After applying the host profile originally created from an ESXi 4.1 host to an ESXi 5.1 host, create  a new host profile from the ESXi 5.1 host and attach that to that ESXi 5.1 host and other affected  ESXi 5.1 hosts. Modify the NIC Teaming policy in the host profile to the User must explicitly choose the policy  option option instead of the Apply specified NIC teaming policy. Now I know iyour profiles are originally from 5.0 but thought to mention it anyway