Configuring or modifying alarm notifications on vCenter can be time consuming because there are more than 80 pre-defined alarms (in vCenter 5.5) which need to be modified; and the point is that it’s not possible to apply a single change to all of them or a group of them at once. Via GUI (web client or native) alarms should be modified one by one. So, imagine that you want to add an email as recipient of some alarms, let’s say the ones which send email notification when status is changed from Yellow to Red and Yellow to Green. It’s difficult to go through all the alarms, find them and apply your changes. This kind of change is very common when a new administrator is added to the team or someone leaves.
It is one of the situations where using PowerCLI is really beneficial. You can customize and group the alarms as you want, change the variables whenever needed and run the script using PowerCLI. I found this template by Lauren Malhoit very useful but it was not compatible with vSphere 5.5. I modified the script for vSphere vCenter 5.5 and you can download it here. Using this script is easy by modifying email addresses and you can also change the groups (I mean for example adding to YRYG alarms) as you desired.
In VMware vSphere client (native and web client), sometimes you get this message in Summary tab of a host: “Configuration Issues: Quick stats on Host ‘xyz’ is not up-to-date”
Most of the times this message disappears after a while but sometimes it bothers for a long time. In those cases, a quick ‘Reconfigure for vSphere HA’ may clear the message.
Migrating and relocating VMs is a great feature in Virtualized environments. You can do migration and perform your maintenance without disrupting any service. Migration in VMware is easy by utilizing vMotion in vCenter. You right click on VM, then choose Migrate and follow the instructions. But how we can relocate (change datastore or storage vMotion) a VM in vCloud Director?
Actually I was expecting the procedure in vCloud Director to be similar to vCenter, but when I right-clicked on the VM, I couldn’t find a ‘Migrate’ option or something like that. And apparently it’s not a good practice to migrate a VM which is controlled by vCloud Director through vCenter. But fortunately storage vMotion is possible in vCloud Director if you have separate Storage Profiles. To do this kind of relocation, right-click on the VM, then choose ‘Properties’; in ‘General’ tab you will find a pulldown menu for changing Storage Profile. Simply change Storage Profile to the desired one and bingo! Storage will be changed. You can even see the progress of relocation in vCenter.
- As mentioned, changing datastore is possible if proper storage profiles are defined in the environment. That being said, it’s not possible to relocate to an individual, specific datastore. Actually, storage profile is another abstract layer over storage infrastructure that is being used by vCloud Director. To be honest, I didn’t have deeply realized what’s the main purpose of introducing storage profile and storage capability yet and why it doesn’t use datastore cluster instead. By the way, keep in mind that you need to create separate storage profiles if you have separate storages and you want more flexibility in vCloud. To get more information, look at this link: Using Storage Profiles with vCloud Director.
- I couldn’t find much resources on the effects of migrating a VM from one host to another in vCloud Director environment; it is possible to perform this in vCenter and I did it in some cases with no issues. I suppose vCloud Director is working on higher level and will be notified of the changes.
Remember to change default value of “Highest supported hardware version” from 7 to 9 when you create a Provider vDC in VMware vCloud Director 5 or you will face some issues later on when you want to import VM’s from vCenter to your Catalogs and will get this error message:
“The selected vdc does not support required virtual hardware version”
The interesting point is that VM’s in vCenter are created compatible to Hardware Version 8 by default! In fact, there are some inconsistencies between vCenter, vSphere and vCloud Director; it is just one of them.
VMware vCenter and VMware vCloud need a database to store important information (most importantly, configuration). Due to critical nature of data, database server needs to be an enterprise class one. Supported databases are Microsoft SQL, Oracle (for a full list, see here). Of course, high availability should be considered for database server, but you may wonder if it’s safe to restart database server for a short time? For example, say you still didn’t implement high availability and you need to do a Windows update. You want to reboot database server but you don’t intend to reboot the whole environment, I mean vCloud Director, vCenter itself, … So, the question would be: Is it possible that rebooting database server causes crash or any harm in other VMware components?
I decided to experience this in my Lab environment and the answer is: It’s generally safe to reboot! And it seems reasonable; as long as you are not changing configuration on your infrastructure.
Although, when I started some administration jobs in vCloud Director, like modifying a VM or adding a VM to a vApp, I got some weird error messages. In fact, vCloud Director complained: “Error while connecting to sphere profile driven storage service”. I never saw this before and actually I’m not sure what profile driven storage service is! So, I looked into my vCenter server. In Administration, Management, there was an icon, named ‘VM Storage Profiles’. It looked relevant, so I clicked on it. The error message appeared here too! Looking into the issue more, It turned out that there is a Windows Service named ‘VMware vSphere Profile-Driven Storage Service’ that was stopped, while it was ‘Automatic’ service. I started the service and everything got back to normal.
It means that we can’t say rebooting database server is completely safe and some unexpected issues may happen. If you have to reboot your database server, make sure to check the health of your other servers (vCloud Director and vCenter in specific) by looking into Logs, Services, …
p.s – My Lab environment included MS SQL 2008 R2, vCenter 5.1 (on Windows 2008 R2), vCloud Director 5.1.2 (on RedHat 6)