There are many occasions when you may need to produce a report showing some aspect of your VM environment.
Many companies have various types of inventory databases which grab information from various sources to provide tracking and reporting of the various IT assets.
An example of a database could be one which pulls information from the software inventory system, patch management system, anti-virus console showing latest file update, AD etc. which could show a dashboard view of the workstations and highlight where they are not in compliance to company standards.
As a virtual workstation environment grows there is plently of information from vCenter that would be very useful to gather.
Grouping VMs by VDI groups in vCenter folders so you know how many VMs x department has would be useful to have. For the dashboard view it may be usedful having the VM Tools status. It’s could also be useful knowing which VMs are in which cluster and datastore, what virtual CPU and RAM they have and how big their disks are which can be used for capacity planning, performance analysis and reporting on what is deployed where.
Read more…
Here are some handy script lines for working out what CDs you have connected which can cause Vmotion to fail.
You don’t always want to disconnect all CDs. If you have .ISOs on shared storage Vmotion will be fine as long as the hosts can both see the .ISO files.
Get the names of VMs with connected CD drives:
get-vm | where { $_ | get-cddrive | where { $_.ConnectionState.Connected -eq "true" } } | select Name
Get the names of VMs with connected .ISOs
get-vm | where { $_ | get-cddrive | where { $_.ConnectionState.Connected -eq "true" -and $_.ISOPath -like "*.ISO*"} } | select Name, @{Name=".ISO Path";Expression={(Get-CDDrive $_).isopath }}
Disconnect all VMs where the CD Drive is connected and it is not an .ISO
$VMs = Get-VM
$CDConnected = Get-CDDrive $VMs | where { ($_.ConnectionState.Connected -eq "true") -and ($_.ISOPath -notlike "*.ISO*")}
If ($CDConnected -ne $null) {Set-CDDrive -connected 0 -StartConnected 0 $CDConnected -Confirm:$false }
or another slightly quicker and dirtier way thanks to commenter José de Alonso
Get-VM | Get-CDDrive | Where {$_.ISOPath -ne $null} | Set-CDDrive -NoMedia -Confirm:$false
My previous post talked about the design of BR and how to script a simple and scalable recovery process for getting as many VMs as you need from a primary site to a BR site when using NFS storage.
When using iSCSI storage it is slightly more complicated as you can’t use one of the benefits of NFS in presenting a read only datastore to ESX hosts in your BR site and having your VMs in the inventory and ready to just power on.
The manual steps would be:
Break the storage mirror.
Rescan the storage on the ESX hosts in the recovery site to pick up the now-visible LUN.
Browse the LUN for all .vmx files and add them into the inventory
Power on the VMs and answer the UUID question that they have moved.
Thanks LucD who has two great versions of a function for importing .VMX files, much better than the old community extension method.
http://communities.vmware.com/message/1317271#1317271
http://communities.vmware.com/message/1270822#1270822
The function is very powerful so it’s worth keeping as a link for using elsewhere.
Read more…
Also see SRM for free with PowerCLI – Part 2: iSCSI
Working in an enterprise company DR, BR, BCP, whatever you want to call it, is everything. With potentially many thousands of people around the globe, being able to get people working again as soon as possible after a disaster can mean the difference between being in business and going bust.
The best way to do business recovery is to design it from the ground up and make it part of every architecture design you put together. Thinking about the what-if of a disaster after everything is up and running often means you have to start again.
One of the great things about virtual worlds is you can easily (not necessarily cheaply though!) have a separate virtual infrastructure in both locations with shared storage. Simply by mirroring the storage from Site A to Site B you can recover VMs from Site A in Site B very easily without having to have a separate VM in Site B that you need to keep up to date.
This is where VMware’s SRM comes into play. SRM is a fairly powerful piece of software for running and testing your BR. It talks to your back-end storage and can automate the different steps required such as breaking the storage mirror, presenting the storage to your ESX hosts, adding the VMs to your inventory and powering them on.
Sounds great but firstly it is a product you need to pay for and secondly when it came out it didn’t support NFS so PowerCLI (it wasn’t called PowerCLI when we did it) came to the rescue.
Read more…
Recent Comments