My little Information Technology blog
I found it quite risky to connect to a vCloud instance as a SysAdmin and perform calls to a specific Org and ensure not to touch other orgs by a simple typo in my commands.
Use the following command to connect via PowerCLi direct to an org in vCD.
Connect-CIServer -Org WWW -Server XXX -Username YYY -password ‘ZZZ’
The Virtual Machine Message I’m faced with deals with the relocation of the VM. Via the vSphere Client, my possible choices to answer the question are “Cancel”, “I moved it”, or “I copied it”. I don’t have the patience or desire to mouse through this hundreds of times.
I want to provide the same answer, “I moved it”, for every VM in inventory which has this question. The script to accomplish this is fairly simple, even by my standards. Once the PowerCLI connection is established to the vCenter Server or ESX(i) host, it’s a one-liner. Following is the PowerShell script which gets the job done for my situation:
Connect-VIServer vc501.boche.lab
Get-VM | Get-VMQuestion | Set-VMQuestion -Option “I moved it” -Confirm:$false
Note that there are different types of Virtual Machine Message questions which will yield a different set of possible answers. Be sure to query a VM having a question via PowerCLI for the possible answers to that question. Get-VM | Get-VMQuestion -full should do it. Once the possible answers are revealed, use Set-VMQuestion -Option to provide an answer.
Also note the script above will cycle through all VMs in inventory, and for those having a question, it will provide the same response for each VM. Thus the assumption is made that all VMs with pending questions have the same question being asked. To respond to explicit question types or to filter the VMs being looped through, the script would need to be refined.
For more information on the Get-VMQuestion or Set-VMQuestion PowerCLI cmdlets, use Get-Help Get-VMQuestion -full or Set-Help Get-VMQuestion -full respectively.
Thank you to Jason Boche for this article
On January 10, 2014 a vulnerability in ntpd, the Network Time Protocol daemon, was made public (US CERT VU#348126):
UDP protocols such as NTP can be abused to amplify denial-of-service attack traffic. Servers running the network time protocol (NTP) based on implementations of ntpd prior to version 4.2.7p26 that use the default unrestricted query configuration are susceptible to a reflected denial-of-service (DRDoS) attack. Other proprietary NTP implementations may also be affected.
I have encountered several vCenter Server Appliances, version 5.5.0 build 1476327 and older, that were exposed to the general Internet, and have been found to have this vulnerability. In these cases they were participating in DDoS attacks.
Yesterday I looked to the VMware KB to see if there were any security updates for these vCSAs, or mitigation approaches. Despite the vulnerability being over a month old there is no mention of it from VMware, nor is there a fix of any sort. The vulnerability probably extends to older versions of VMware ESX, too, if you are using NTP on them (as per best practices).
If you are running a vCenter Server Appliance I strongly suggest that you open a case with VMware Support regarding this problem. They have internal KB information about mitigating this. Ask them to search for CVE-2013-5211.
If you want to mitigate this problem on your own there are two ways to do it. First, VMware actually has public KB information in 1006427. It’s just buried (search that KB for CVE-2013-5211). Follow my steps below to edit the file and add their information.
If you want to mitigate the problem in a completely unsupported manner, but the one recommended by SANS and other organizations, you can SSH into the vCSA as root, and add “disable monitor” to /etc/ntp.conf. You can do this with the following steps:
SPECIAL THANKS for this article: http://lonesysadmin.net/2014/02/13/vmware-vcenter-server-appliance-5-5-0-insecure-ntp-server/
After some hunting I found that modification of an AutoDeploy rule wasn’t as simple as Edit-DeployRule 🙂 My coworker Joe Keegan, the God of AutoDeploy walked me through the simple steps to modify existing rules rather that deleting and replacing.
NOTE: You do NOT need to use “” or other characters around the <VALUE> EXCEPT for the Pattern Value. Otherwise, the object is found when it checks the name against the GetType.
To replace the Pattern of an existing rule:
Get-DeployRule -name <RULENAME> | Copy-DeployRule -ReplacePattern “<NEW PATTERN>”
To replace the Image, Location, or Profile of an existing rule:
Get-DeployRule -name <RULENAME> | Copy-DeployRule -ReplaceItem <NEW PROFILE NAME>