I was setting up a new host the other day and I received a call from one of my admins letting me know that they could not copy/paste within the console; but they can copy/paste in RDP.
This is a simple fix found in KB1026437. You can make the change on an individual VM, but I think it is best to change it on the host (which applies to all VMs). I really wish the default would have this enabled.
Open a Putty session…if you don’t have putty then get it here.
1. Log into the ESXi host that you want to change.
2. Type vi /etc/vmware/config
3. Arrow down to the last line and type i which stands for “insert”.
4. Add the lines:
vmx.fullpath = “/bin/vmx”
5. Press the ESC key and then type :wq which stands for “write and quit”.
The next time each VM is power cycled it will enable the copy/paste functionality. Keep in mind that if you ever upgrade this host to a new ESXi version that this setting will go back to the default of disabled and you will have to add this line again.
I came in this morning only to be greeted by my web client telling me that I can’t login because it can’t create SAML 2.0. I am not sure that I really want it creating SAML 2.0….I don’t know SAML 1.0. Ok, bad joke. Here was the message…
I found KB2034798 at which point I remoted into my SSO server and checked the imsTrace.log for “NetUserGetLocalGroups”. I didn’t find it…so the KB didn’t apply to me…L
After some more googling I found this blog post that indicated that references KB2043070. The idea is that there is a local identity source within SSO that it is trying to authenticate the users to. You have to login with the admin@system-domain account and password. Hopefully you saved this when setting up your SSO server. The only problem I had was that I didn’t have this local identity source to remove.
I thought to myself, that there might be a stale identity source on the list that it is authenticating to. I was talking to a coworker and they mentioned that there was a domain that was deleted the day before. AHAH!! I clicked on the identity source of the domain that had been removed and then clicked “Test Connection”. There was an error that didn’t tell me much.
I cancelled out and was back at my list of identity sources. I selected the identity source that had been removed from AD and I hit the red X, “Delete Identity Source”. You will get a prompt asking for you to confirm. One thing to note is that the identity source that I deleted was not one of the default domains at the bottom. If you haven’t set a default domain up, I would do that now. I am wondering if there might be a bug that uses the identity source at the top of the list instead of the default at the bottom. After deleting the state Identity Source I was able to login again.
Posted in Server 2012, Templates, VMs, VMware Vcenter Server, VMware Vsphere 5, Windows Server 2012 R2
Tagged Server 2012, Server 2012 R2, Templates, VMware Vcenter Server, vSphere 5, vSphere 5.1
In Part 3 we are going to install Powerchute Network Shutdown on the OVA that we deployed, then we are going to configure it to shut down the VMs in case of a problem.
- See APC pdf FA159776. Open Putty.exe, insert the name or IP of the VMA you just deployed, and then click “Open“. Click “Yes” if you get a security alert. Login with vi-admin and your password that you set earlier.
- Create a temp directory in opt using the command (You will be prompted for the vi-admin password): sudo mkdir /opt/temp
- Next we need to change the permissions to this temp directory: sudo chmod 777 /opt/temp
- Now to check the permissions: ls -la /opt The permissions should now read drwxrwxrwx
- Now using WINSCP we need to transfer the .tar.gz file that we downloaded earlier up to the ESXi host. Enter the appropriate information and then click “Login“. Click “Yes” or “Proceed” if prompted with a security warning.
- Check the “Never show this banner again” box and then click “Continue“. You should now see a screen with two windows. The window on the left is your local computer and the screen on the right is the VMA. Navigate on the left window until you find the .tar.gz file.
- On the right window the drop down where it says “vi-admin“. Change this to /<root>. Then navigate to “opt–>temp“
- Drag the .tar.gz file from the left window to the right window. Click “Copy” when prompted.
- Verify that the file has been copied successfully.
- Now go back to Putty.exe and we are going to uncompress the file. The commands are: gunzip pcnsname.tar.gz then: tar -xvf pcnsname.tar
- Use the ls-la command and you should see a new ESXi folder. Use the command cd ESXi to change to this folder.
- List the contents of ESXi with the ls -la command. We need to change the permissions for the installation file: sudo chmod 777 install_en.sh
Now do another ls -la to see that the permissions have changed to rwxrwxrwx.
- Now we are ready to install PCNS. Use the command: sudo ./install_en.sh
Press “Enter” and then use the “z” key to scroll to the end of the agreement. If you agree then type “yes” and then press “Enter“.
- Accept the default installation path (or insert a different one if you prefer). Press “Enter“. Type “yes” and “Enter” that you are sure about the path.
- Take the default for the java directory. Press “Enter“.
- Next the installation looks for the ESXi host that will be shut down. First add the IP of the host and then it will ask for the username and password for the host to make this change. Update: Almost all of the deployments failed to add the ESXi host here, so I would choose “q” to skip and then at the command line do: sudo vifp addserver <hostname/ IP address of ESXi host>
- Verify that the server has been added with the command: vifp listservers
- To ensure Powerchute can shutdown the VMs on the host, we need to add the ESXi host to the fasspass. Use the command: vifptarget -s <server name or ipaddress>
Now type the command: vicfg-nics -l
You should see a list of nics on the ESXi host.
- One the server has been added you should be able to open a browser and go to the powerchute configuration wizard: https://vmahostnameorip:6547
- Click “Next” and you should see the Configuration Wizard: Security page. Insert the username and password and the authentication phrase. This must match the card in your APC device. By default this is apc/apc with the passphrase: “admin user phrase” then click “Next“.
- On the UPS Electrical Configuration page choose the correct configuration for your company and then click “Next“.
- On the UPS Details page choose the protocol, port, and IP for the APC network card.
- On the Miscellaneous page check the box for “Automatically check for updates to PCNS” and then click “Next“.
- Confirm the details and then click “Apply“.
- Hopefully you see that the computer is now protected. Click “Next“.
- You should now see that the wizard is complete, now click “Finish”.
- You will now see the main page for the Network Shutdown. Click “Configure Events” and then click the check box for “Shutdown System” on “UPS: On Battery“.
- The “Shut Down Operating System” page will display and input 300 into the “Shut down the PCNS operating system only when the event lasts this long (seconds)“
- Finally, we need to set up the virtual machine shutdown options on the ESXi host. Open the vSphere Client, select the host, and then choose the “Configuration” tab. Under the “Software” pane click on “Virtual Machine Startup/Shutdown“.
- In the top right corner click “Properties“. Click the box “Allow virtual machines to start and stop automatically with the system“. Set the shutdown delay (120 default) and then set the shutdown action to “Guest Shutdown“.
- Leaving VMs under the Manual startup will make it so when the host turns back on, the VMs will not start up by themselves. Usually you want to make sure power is restored and stable before bringing up VMs. You can change your VMs to start automatically if you really wanted to.
We had an issue the other day with our filers and because of it, some our machines orphaned themselves and VMware didn’t know what to do with them. If I tried to power off the machine I would get the error,
Basically, I don’t even think the machine was on, but my vCenter server showed it as being powered on. Luckily I found a KB article that deals with this. http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1014165.
SSH into the host that the VM is said to be running from. Then run the command:
esxcli vm process list
This gives you a list of all the running VMs, and the important piece you want is the World ID. Copy that, and then run the command:
esxcli vm process kill –type=[soft,hard,force] –world-id=WorldNumber
Note: Three power-off methods are available. Soft is the most graceful, hard performs an immediate shutdown, and force should be used as a last resort.
As you can see, I ran this command and it killed the VM. After doing this, I was able to power on the VM without issue. I used soft and it worked.
That’s all I have for today.
We have two vCenter servers that are in linked mode. After upgrading to Vsphere 5 I have been having problems deploying machines. I get this error:
Strange right… Well, I then decided to do a vStorage migration of a machine and got the same error:
Turns out that this is a bug with no fix right now when you link two vcenter servers together. To get around this, make sure that your VIC client is logging into the vCenter server that you are going to do the vStorage migration or deplate deployment from. If I have vCenter Server A and B and I want to deploy from a template on B; you would log into the B vCenter to deploy.
Here is the KB article http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2013516