In a perfect datacenter environment, we would all have an additional area for Dev/Test. This is not always the case and we don’t always have the resources readily available to us. Most of us get creative using what old equipment we have. Some carve out a section in their infrastructure, while others leverage the cloud. Currently I’ve been using Ravello as my Dev/Test area of my lab for VIO. A VIO production-ready deployment requires a significant amount of resources. These same resources may not be instantly available in some environments. The current deployment architecture of VIO requires 15 VMs with a total of 56CPUs and 192GB RAM; details can be found here. This doesn’t take into account if you’re using NSX. However, there are a few ways you can be conservative with VIO resources. Let me state up front: the following setup is not supported by VMware for production.
Changing VIO Configuration Settings
Open the VIO management-server console or use SSH. In the example below I’ll be using SSH to make configuration changes.
Login using the viouser account.
The file that needs to be modified is omjs.properties, located in /opt/vmware/vio/etc.
Important: Create a backup of the omjs.properties file prior to making any changes.
“cp omjs.properties bak-omjs.properties”
Edit omjs.properties, in this example I’m using the VI editor.
Here is the initial omjs.properties.
The changes made were to the CPU, Memory, and vSphere settings section.
Note: When doing the math only the first 8 entries count for CPU and Memory. The oms.vmsize.cpu.smoke and oms.vmsize.memory.smoke are currently not used. They could be place holders for future use.
Save the changes and restart the management-server.
Important: The omjs.properties settings will be reverted to its original state when applying a VIO update.
Using Ravello for my VIO lab (part 1 and part 2), I’ve been able to manage with this setup. Keep in mind the above configuration is not supported by VMware. This should only be for Dev/Test deployments with limited resources. If resources are available, I would recommend staying with the default setup. Another alternative is shutting down some of the highly available VIO VMs, this solution is also not supported in production. To save on resources use this alternative method in conjunction with editing the omjs.properties. There you have it: two ways to save on resources.