Work

As I wrote some time ago, I was trying to utilize Nagios 3.x’s neat feature of " nested" hostgroups. Well, as it turned out I thought it worked differently; basically like this: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 define hostgroup { hostgroup_name a-parent-hostgroup alias Our toplevel parent hostgroup } define service { use generic-service check_command check_dummy!0! service_description SSH hostgroup_name a-parent-hostgroup } define hostgroup { hostgroup_name a-child-hostgroup hostgroup_members a-parent-hostgroup alias Our child hostgroup } define service { use generic-service check_command check_dummy!0! service_description LOAD hostgroup_name a-child-hostgroup } As you can cleary see on line 14, I thought you define the relation between two hostgroups in the child hostgroup. The problem with it was basically (as I said in the earlier posts), that all the services defined for the child hostgroups are handed on upwards to the parent hostgroup(s). ...

Recently we purchased a MessPC station for our server room, and my co-worker and myself had the wish it to be integrated within Nagios. Well, so far so good. The first I did was put both keywords into Google. That pretty fast brought up the manufacturer’s page (sorry it’s German only) about the device supporting Nagios by means of either SNMP or a specific plugin called pcmeasure. So I went ahead and tried both ways. ...

Well, today the support request came back. Seems one of the originally linked VMTN dicussions really is the only way: Export the customization specification Edit the XML file Import it again The related part inside the customization specification should then look like this: 1 2 3 4 <type>vim.vm.customization.Password</type> <plainText>true</plainText> <value>Password01</value> </password> So if you ever think about switching the default VirtualCenter certificate (for whatever reason), make sure you use the above workaround. Otherwise VirtualCenter is gonna fail miserably during the customization phase of the cloning process.

As I pointed out in my past posts, I was having some weird errors with SLES10 regarding mounting CD images inside the guest (as well, as it turned out, on the physical hardware). Now, finally, after about a week or so Novell finally released an updated kernel package today. So the error per se is fixed, I can use my CD drives again, as well as update my virtual machines by means of virtual center, without the trickery of copying the linux.iso from /vmimages/tools to the guest and mount it by means of mount -o loop.

Today I was moving a pretty standard SLES10 virtual machine to another host, when the migration dialog showed me this: fault.MemorySizeNotRecommended And if you now think, the virtual machine is something special take a look at those settings: Virtual machine configuration I don’t know what to think about that error message. Googling for it doesn’t reveal that much about it. If anyone out there got an idea, I’m open for suggestions.

Since I do happen to be in the situation pretty often where the kernel inside a VM is newer than what VMware currently has in their tools (as in the SUSE kernel is newer than the binary modules built by VMware), here’s a quick reminder for myself on how to to fix the .ko symlinks. 1 2 3 4 5 for file in /lib/modules/$( uname -r )/misc/*.ko ; do rm $file && ln -s /lib/modules/$( uname -r )/misc/${file/.ko/.o} $file done

If you think back, I talked about my problems with MSCS while utilizing the IBM RDAC Multipath driver for Windows. Everyone I talked to about this, including our IBM business partner and it’s systems engineers; as well as some IBM systems engineer (who in fact was an freelance guy hired by IBM), told me it had to do with how we did the zoning (stuffing every controller into a single zone), and that would be the reason why the x3650 was seeing that many drives. ...

Well, as one can read in about every damn post you can find for that topic, the /console switch is now silently ignored, as well as the rdp file option " connect to console:i:1". Now, what you don’t find anywhere (only in some scenario explanation), that it is allowed to specify the mode (ie /console previously and now /admin) within the full address parameter. Scenario: In the RDC client UI, you specify Computer_name /console in the Computer box (where Computer_name represents the name of the remote computer to which you want to connect), and then click Connect. ...

Well, it turns out that my thought was ultimativly flawed. When defining the hostgroup_members in the lower tiers, nagios is association the checks from the lower tier with the upper tiers. Thus propagandating all checks upwards, and me ending up with ~250 checks instead of ~150. Gonna have to try to define the dependency backwards, maybe that’ll help. But that’s a topic for Monday. Guess I’ll finish viewing Ghost in the Shell - Stand Alone Complex first.

Remember my last post about cpu masking ? Well, turns out that you can do it to a “template”. The only point you don’t need to do, is to mark the VM as a " template". You still can clone it and move it around and all that other stuff, but the good part is, that the cloned VM keeps the cpu mask set to the " template" 🤷 ...