My little Information Technology blog
WARNING!!! This will delete ALL VMs in your vCD!!!!!
Connect to your vCD with “Connect-CIServer
Stop-CIVApp * -Confirm:$false
Remove-CIVApp * -Confirm:$false
sleep 5
Remove-OrgNetwork * -Confirm:$false
Then manually delete any gateway devices and then run the following to clean up all the orgs:
Set-OrgVdc -Enabled:$false
remove-OrgVdc -Confirm:$false
Set-Org -Enabled:$false
remove-Org -Confirm:$false
Big thanks to my colleague Grant Voss for this awesome little cleanup script.
vmware=92963abd36c896b93a36b8e296ff3387
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>