System logs on host are stored on non-persistent storage

I tested a brand new DELL PowerEdge R620 as a cloud hypervisor with an ESXi 5.0 installer. The new servers have only a dual SD cards as internal storage, instead of a SAS or SSD disc. If you try something new, you should have trouble configuring it in an old way. I got a new warning message after the hypervisor installation: System logs for host [hostname] are stored on non-persistent storage.
Continue reading “System logs on host are stored on non-persistent storage”

How-To create backups of running vApps in VMware vCloud version 5.1 and earlier

With vCloud version 5.5 the Director (web GUI) got a bunch of useful features. One of them is Cloning Running vApps: http://www.vmware.com/files/pdf/products/vCloud/Whats-New-VMware-vCloud-Director-55-Technical-Whitepaper.pdf page 9 – 2.2.3 Clone vApp with Memory State

With older deployments of vCloud administrators still have to use the REST API to create these hot-clones. From the vCloud Director the only option to clone a vApp is to stop that first, which method is simply unacceptable in production environments.

When developing automated backups, or auto deploying vApps/networks the REST API-based scripts come handy even with newer versions.

Let’s take a look at the API through a few simple examples.

Continue reading “How-To create backups of running vApps in VMware vCloud version 5.1 and earlier”

More is not always better – CPU ready in VMware vSphere

You might have a situation, when your 2 vCPU webserver is having a high load (although CPU usage in MHz is normal).

In this situation most administrators would add extra vCPUs to the server, and expect to have an enhanced performance.

Unfortunately the additional vCPU can actually degrade performance. Let me explain why.

Continue reading “More is not always better – CPU ready in VMware vSphere”

Configuring vSwitch ports

When people use standard vSwitches in vSphere it is always a problem, at least for me how

to configure switch security policies like promiscuous mode, or mac address changes just

for a few ports where these required. Using the standard vSwitch I always created a new

portgroup just for the few VMs which require special policies, but this is not the best

way, and really not a perfect solution.

If people change to use distributed vSwitches, and yes, if people has money for such

license this prblem could be solved much easier.

By default with a distributed vSwitch the same settings are defined at the portgroup

level, and the settings are inherited by all the ports. But this can be overridden if

required. To do so at first the override of the security settings at port level must be

enabled in the portgroup advanced settings tab.

2

After this, the inherited port settings can be changed.

3

Now, we have a port with custom port security policy. πŸ™‚

The Fairy Tale of the vSphere Update Manager and the DRS Policies

I’ve recently created a two node vSphere5 cluster in my test environment just for

testing, and playing around, with properly configured HA, and also DRS. I’ve created

various DRS policies, and tested a lot the cluster features throug a lot of scenario.

After that I started playing with VMware Update Manager. After configuration I ran into a

problem at the very beginning of the process when the Update Manager tried to place the

first ESX host into maintanance mode. The process were in stuck, and no error message at

all…

After a while (I am usually patient when trying something new πŸ™‚ ) I started

investigating, what the problem could be. I found quiet quickly that I hadn’t turned off

all the DRS policies, and one was active which forced 2 of my VMs running on different

hosts. This caused Update Manager not to be able to take the host into maintanace mode.

Turning off the DRS policy solved my problem, and Update Manager did the update

successfully.