Category Archives: OracleVM

Check_VM for Oracle VM and Nagios.

Personal backup…

Refinements might be added if bugs or improvements are found. So keep an eye out for newer versions ūüėČ

This script might also be compatible with other  Xen clones.

# Author : Chris Gralike
# Company: AMIS Services BV
# Simple but effective Oracle VM check command for use with nagios
# This command checks the state of any given VM machine using the XM command.
# It will try to match the friendly name as well as the system name.
# It will return OK - and usefull metadata on succes, NOK on failure.
# usage : check_xm vmname
# ########################

use strict;                     # Good practice
use warnings;                   # Good practice

my (@data, @values, @name, $vmname, $vmcheck, $i, $result);

# Get the command parameters
if( ($#ARGV + 1) == 1 ) {
$vmname = $ARGV['0'];
print "usage: ./check_xm vmname \n";
exit 1;

# Perform the actual test
open(XM, "xm list|");
$i = 0;
if($i > 0){
# Split the output in portions
@data = split(" ", $_);
# Get the human readable name
@name = split('_', $data['0']);
$name['1'] = 'dezeisnietingebruik!';
if(($vmname eq $name['1']) || ($vmname eq $data['0'])){
print "OK - $data['0'] is active with Id:$data['1'] $data['3']CPUs $data['2']M \n";
exit 0;
close XM;

# If the loop was finished without result, then there is a problem!
print "NOK - $vmname is not running on this server\n";
exit 2;

network issues with Dell Broadcom interfaces?

Experiencing “Copper Link Down” messages with increased network load on Dell R and M Series servers?

Then you might want to look into this thread.

There is a known issue with the bnx2 driver used on the Linux platform that might cause the network card to become inactive. The problem is caused by the drivers MSI (Message Signaled Interface) option.

The two suggested solutions to this problem are;

1. Disable the msi option in the modprobe.conf file by adding the following rule;
options bnx2 disable_msi=1 (Recommended)

2. Load the latest dell driver that disables the msi-x option in the driver itself.

Please read these threads carefully before you decide this problem is the one you might be experiencing.

How to detect the problem on OracleVM / OEL.

1. Make sure the Link-led is lid on the back op the physical machine.
2. Run the ethtool eth# -t to view its current state
3. Make sure the ethtool reports a Link-Down

Applying the fix use the following steps;

1. Logon to the OracleVM Dom0 / OEL / Other Linux box.
2. vi /etc/modprobe.conf
3. Add the following line below alias eth0 bnx2
options bnx2 disable_msi=1
4. Save and quit vi :sq
5. Reinit the module using the following command.
modprobe bnx2
6. Verify the setting using the following command.
modinfo bnx2
The following rule should be listed.
parm: disable_msi:Disable Message Signaled Interrupt (MSI) (int)

Hope this fix resolves the problem for you!


OracleVM & Oracle licensing….

Be aware of licensing, ‘soft’ partitioned virtualized guests with Oracle products installed are a financial RISK!

OracleVM supports ‘Hard’ partitioning.

In essence the OracleVM product is equal to any ‘soft’ partitioning solution. This is because in essence the Oracle (Xen) Hypervisor will also use¬†all of the resources in the¬†pool to spread the workload as efficiently as possible (para virtualized). In this scenario the licensing model will also require you to license all the available CPUs on the fysical box.

There¬†is a supported method to circumvent this. If you configure the domain¬†to map its¬†virtual¬†CPUs to Fysical CPUs, this setup is accepted by Oracle as ‘Hard’ partitioning. A special configuration entry needs to be set to the vm.cfg of each virtual machine¬†running¬†an Oracle Database as described in this Oracle Document.

Remember to set this configuration rule!
Else Oracle Licensing will identify your cool OracleVM infrastructure as just another Soft partitioned VM solution that requires¬†you to license each fysical CPU available to the virtual platform¬†ūüėČ

Additional reading :


Migrating a running OVS to a new OVM (howto)

What is this article about?

When reading the Oracle Documentation you might discover that the method of ‘migrating’ a running OVS-server into a new POOL is not very well documented. In this article I will explain in steps that allow you to add a running OVS-Server into a new POOL on a new OVS-Manager.

Setup used to write this article.

  1. two ovs-managers (ovs-manager1 / ovs-manager2).
    Both version 2.2.0
  2. one ovs-server (ovs-server1) that has two running domain ontop of it.
    version 2.2.1


In my setup I didnt create a OCFS cluster (shared storage) from which the domains are ran. Even though the domains use fysical paths to the actual domain components, even though the cluster file service service will not allow the cluster to be broken (service stopped) with running domains I cannot assume this article is applicable… You are adviced to ‘TEST’ a migration in a LAB situation first! This article might help you get an idea of the required steps.

This article will describe the steps taken to migrate the “ovs-server1” which was managed on “ovs-manager1” to the new manager “ovs-manager2”. Any reason to do this might be iron-replacement without a decent backup of the ovs-manager, ovs-manager1 was fysically destroyed and needs to be restored, etc…


  1. Make sure you have a backup of the ovs-managers database (see ovs-manager documentation no how a backup is created)
  2. Logon to ‘ovs-manager1’ in which the ovs-server is member of an¬†existing¬†pool.
  3. Select the ‘Server Pools’ tab.
  4. “!Make sure you have all the CIs if this server documented!”
  5. Select the pool in which the ‘ovs-server1’ ¬†is listed and select “Delete”
  6. In the delete form “ONLY SELECT FORCE REMOVE”. DO NOT¬†SELECT¬†¬†any other option!
  7. When the pool is succesfully deleted logon to the ovs-server1 using a ssh-client.
  8. verify that all the domains are still in the state we left them using the following command;
    xm list
  9. Document the root repository used by the ovs-agent. You need to document it because the repositories are part of the ovs-agents local database thats being cleaned in the next step. You can find the current repository by running the following command;
    /opt/ovs-agent-2.3/utils/ -l

    It should return a string simular to this one;
    [ * ] e3514a86-a763-4eee-84b5-0fedcc03416d => /dev/sdb1

    We need this string to verify the repository when we recreate it.

  10. The next step is to clean the ovs-agents local database in which the ovs-manager is registered. This entry prevents us from linking any other ovs-manager to this agent. The ovs-agent, version 2.3 contains a cleanup script located in /opt/ovs-agent-2.3/utils/ that is needed to perform this cleanup. If the cleanup script is not there, you are probably using ovs-server version 2.2.0. You can check the ovs-server release by issuing the following command;
    cat /etc/*-release

    Oracle VM server release 2.2.1

    In the situation you indeed using version 2.2.0, you might simply copy the script from a ovs-server version 2.2.1 and put it in the path mentioned above. (yeah, same ovs-agent versions but still minor differences ūüėČ ).

  11. If the is in place, run it;
    Confirm the question
  12. The result of this action is that the agents local database has been cleaned. As a result of this you might notice that the /OVS mapping is gone as well. Not to worry, using the xm list command you are able to verify that the various domains are still up and running. This is because they are being configured to use the fysical path to its template directory somewhere in the /var/ovs/mount/ which is still mounted.
  13. Before you add the ovs-server to the new manager we need to restore the agents entry for the root repository. For this we need the information documented in step 9. Use the information, specific the devices listed in step 9 to restore that config. Initially you need to add the various repositories, afterward (step 14) we need to assign the ‘root’ label to one of them, in our case the one created here.
    /opt/ovs-agent-2.3/utils/ -n /dev/sdb1
  14. As a result the previous command returned a rule that also contains the UUID for this repository. verify that the UUID is the same as the one listed in step 9. The recreated UUID should be the same!
  15. Assign the ‘root’ label to this repository (that might be a different one if you used multiple repositories)
    /opt/ovs-agent-2.3/utils/ -r e3514a86-a763-4eee-84b5-0fedcc03416d
  16. When you have are finished restoring the repo config you can start adding the server to a new POOL on ovs-manager2.
  17. Logon to ovs-manager2 (the new ovs-manager)
  18. Select the “Servers Pools” tab.
  19. Select “Create pool”.
  20. Fill out all the required fields and use the cleaned ovs-server1 machine as to be added server.
  21. Finish all the required steps so a new pool is created.
  22. You might notice you have a new pool with the ovs-server1 in it, but with no virtual machines. This is because we need to “discover / reimport” these from the ovs-server. This is done as followed.
  23. Select “Resources”
  24. Select “Virtual machine Images”
  25. Select “Import”
  26. Select “Select from server pool (discover and register)”
  27. Select the Server POOL you have just created.
  28. Select the “running?” Virtual machine image name in the pulldown and fill out all the fields required (It might be wise to match these with the initial configuration of the VM Image you are trying to register)
  29. Finish all the steps and repeat step 25 > 29 for each VM image you like to import.
  30. DONT FORGET TO “APPROVE” them ūüėČ

This should be all you need to do to restore the machine and all of its (running?) images into the new OVS-manager.

If all is well, after creating the new POOL in step 19 / 21 the /OVS share should be remounted by the ovs-agent / ovs-manager. You might want to verify this on the ovs-server box.

Hope this helps ūüôā
Rgrds, chris