Generating Random Data in Linux

I’ve been fleshing out a proper Veeam Backup & Replication Demo lab at work, but doing demos on static VMs isn’t all that much fun and doesn’t really give us much. Doing scheduled backups of non-changing data is really boring.

So, in order to get some changes done on the file system on a few Linux VMs running in the environment, I came up with the following solution:

I set up a crontab entry that generates a file with random data in it a couple of times a day, just to make sure that there are some changes made to the VM. The crontab entry looks like this:

0 03,09,13,22 * * * head -c 1G </dev/urandom >/tmp/randomdata

This generates a 1 GB file called randomdata in /tmp filled with content from /dev/urandom at a couple of different times a day. This ensures that there are at least 1GB of changes for each backup cycle, and gives Veeam Backup & Replication something to work with.

#vDM30in30 progress:

Troubleshooting: Root Cause of Invalid memory setting: memory reservation (sched.mem.min) should be equal to memsize (memsize)

Screenshot 2014-07-12 20.04.31While working on reconfiguring my home lab setup, and migrating all the vSphere resources into a single cluster I ran into a problem powering on one of the VMs which used to run on a single host. The power on operation yielded the following error message:

Invalid memory setting: memory reservation (sched.mem.min) should be equal to memsize (memsize)
[showhide type=”errorstack” more_text=”Show error stack (%s More Words)”]

Task Details:
Status: Invalid memory setting: memory reservation (sched.mem.min) should be equal to memsize(4096).
Start Time: Jul 12, 2014 4:22:21 PM
Completed Time: Jul 12, 2014 4:22:23 PM
State: error
Error Stack:
An error was received from the ESX host while powering on VM MinecraftServer.
Failed to start the virtual machine.
Module MemSched power on failed.
An error occurred while parsing scheduler-specific configuration parameters.
Invalid memory setting: memory reservation (sched.mem.min) should be equal to memsize(4096).
Additional Task Details:
VC Build: 1476327
Error Type: GenericVmConfigFault
Task Id: Task
Cancelable: false
Canceled: false
Description Id: Datacenter.ExecuteVmPowerOnLRO
Event Chain Id: 20017

[/showhide]

Clearly there was an issue with memory reservations on the VM, but there was no memory reservation enabled on it at all, nor should there be. The only related errors I found while investigating the issue, was with regards to pass-through devices, which also did not apply in this case. It turns out that the problem was due to the VM was configured to use the latency sensitivity feature introduced in vSphere 5.5.

The Deploying Extremely Latency-Sensitive Applications in VMware vSphere 5.5 whitepaper from VMware clearly states that usage of this feature also demands a memory reservation being set on the VM, and this VM had no reservation.

Enabling the latency-sensitivity feature requires memory reservation.

In the end, the solution was a simple one, revert the latency Screenshot 2014-07-12 21.10.12sensitivity advanced option for the VM to the default value of Normal let me power-on the VM again without issues.

The error message received in vCenter could be a lot clearer though, and a knowledge base article with the exact error message and resolution paths might be in order. It was not immediately obvious that the lack of memory reservation error message was related to the latency sensitivity settings for the given VM. The vSphere Web Client shows a warning that you should check the CPU reservations, but does not mention memory reservations when you enable this feature.

Now I just need to figure out why my home MineCraft server had that setting enabled in the first place…