NFS Mount Error on OEL

NFS Mount Error on OEL

Category : How-to

Get Social!

oelI have been using an Oracle Enterprise Linux (OEL) OpenVZ container in Proxmox for installing some Oracle software. The easiest and least interfering way I have found is to mount an NFS share which contains the binaries directly to the container. See my NFS blog post for more information on setting up an OpenVZ container for NFS.

After the service and container was set up for NFS I tried to mount the NFS share. I received the below error after running the mount command.

[root@localhost ~]# mount -a
mount.nfs: rpc.statd is not running but is required for remote locking.
mount.nfs: Either use '-o nolock' to keep locks local, or start statd.
mount.nfs: an incorrect mount option was specified

This was because the rpcbind daemon was not running. Run the below command to start the rpcbind daemon.

service rpcbind start

The service will display that the daemon is now running.

Starting rpcbind: [ OK ]

You can set rpcbind to start automatically by adding it to the startup group.

chkconfig rpcbind on

Retry the mount command and your NFS share should be mounted.

mount -a

You may need to check that you have the NFS client packages installed.

yum install nfs-utils

Proxmox OpenVZ SWAP and Performance

Get Social!

openvz-logo-150px_new_3 I have been having trouble with a Proxmox node which is only running OpenVZ containers however it is at the upper limit of its RAM resources. Over time, I noticed that Proxmox used SWAP (virtual memory, page file, etc), quite aggressively, to make sure there was always some RAM free. That sounds fantastic, and is just what I would expect the Proxmox server to be doing, except it does it all too well. Proxmox made sure that around 40% of the RAM on the host machine was free at the expense of moving many running processes across all the running containers to SWAP. This is how Linux works, by design, and is expected behaviour. Running processes which have memory which hasn’t been touched in a while have their memory moved to SWAP. This allows other applications which need the memory right now to use it and anything left over can be used as cache by the kernel. When a process with memory in SWAP needs to use that memory, it needs to be read from SWAP and back into memory so that it can be used. There is a huge overhead with this process and will often be noticed when you use a container which has not been used in a while – at the start everything will be slow until all the required memory items have been read from SWAP and put back into RAM. To help with this situation we can do two things:

  • Make sure SWAP is always on a fast disk with plenty of free IO bandwidth. On a small installation, this should not be on the same disk as your container file systems. SSDs can also bring a huge performance benefit over conventional mechanical drives.
  • Reduce the amount of RAM which Proxmox keeps free by making the algorithm which moves memory to SWAP less aggressive.

Move SWAP to fast storage

Generally, and when installing Proxmox for the first time a SWAP partition will be created on your hard disk. By default, this will be the same partition as your Proxmox operating system and your container storage. On a slow mechanical disk, this will result in far too much IO concurrency – that is different processes trying to read or write to a disk at the same time – which will massively affect server performance. One thing we can move to another disk is system wide swap.

You can either use a new file, disk, partition or block device for your new swap location. You will then need to turn your old SWAP device off to stop it from being used. Use the below examples to move your SWAP device.

See this post for a quick script to automatically create a SWAP file.

Make a new SWAP device as a file

Create a file on your file system and enable it to be used as a SWAP device. The below example uses the mount /mnt/swapdrive and the file swapfile to use as your new swap device with a size of 4096 MB.

dd if=/dev/zero of=/mnt/swapdrive/swapfile bs=1M count=4096

You will then need to format the file as SWAP with the below command.

mkswap /mnt/swapdrive/swapfile

Make a new SWAP device as a partition

Use the below command to use a drive partition as your new SWAP device. The below example uses /dev/sdc3 as your SWAP partition. You must have precreated this partition for it to be available.

mkswap /dev/sdc3
swapon /dev/sdc3

Turn a new SWAP device on

Once you have a new SWAP device created, either a file or a disk or partition you will need to enable it. Use the swapon command. The below shows an example of a file and disk partition command:

swapon /mnt/swapdrive/swapfile
swapon /dev/sdc3

Turn off the old SWAP device

To turn off the old SWAP device, first identify it using swapon -s.

swapon -s

Then, use the swapoff command to turn the device off. The below example is the default Proxmox SWAP device location.

swapoff /dev/mapper/pve-swap

Clear SWAP space without rebooting

You can clear your SWAP memory by turning the system wide SWAP memory off and then back on again. Run the below commands to turn off your system wide SWAP space forcing all the SWAP to be read back into RAM. You must have enough RAM for available on your system for this to work correctly. Once this has completed, run the second command to turn SWAP back on again. You can also use this to make your SWAP memory changes take effect.

swapoff -a 
swapon -a

Make the SWAP file persist after rebooting

To make sure your SWAP file is mounted the next time your machine reboots you’ll need to add an entry to the fstab file.

Open the fstab file with your text editor:

vi /etc/fstab

And add a line, similar to the below making sure the first attribute is the location of your newly created SWAP file.

/mnt/swapdrive/swapfile  swap  swap  defaults  0  0

Change the ‘swapiness’ setting

To change how aggressively Proxmox, or other Linux distribution, moves process memory to SWAP we have a swapiness attribute. The swapiness setting is a kernel setting which is permanently set in the /etc/sysctl.conf file, or temporarily using sysctl.

The swapiness setting takes a value between 0 and 100. Using 0 will virtually turn off using SWAP, except to avoid an out of memory exception (oom). Using a value of 100 will cause the system to use SWAP as often as possible and will likely degrade system performance servilely. A value of 60 is the default for Proxmox.

Change the swapiness value for the current boot

To change your swapiness value for the current boot, use the below command. The value will be reset after rebooting. The following example will set the swapiness value to 20.

sysctl -w vm.swappiness=20

Permanently change the swapiness value

Use the below command to permanently change your swapiness value. Note that this will not affect the current boot.

vi  /etc/sysctl.conf

And add the following to give a swapiness of 20

vm.swappiness=20

Remove the Proxmox “No Valid Subscription” message

Category : How-to

Get Social!

proxmox logo gradProxmox 3.1 has implemented a new repository setup, as described in my recent blog post.

Each time you log into Proxmox 3.1 a dialogue box pops up with the message:

You do not have a valid subscription for this server. Please visit www.proxmox.com to get a list of available options.

One way to remove the message is to purchase a subscription from the Proxmox team. Remember that paying subscriptions keeps the development of Proxmox progressing. For the recent release, the subscription cost has been heavily reduced and is more affordable than ever.

The fact of the matter is, I started using Proxmox as a free and open source tool and expected it to stay that way. Had I known a subscription element would have been introduced, I would likely have chosen another toolset. As it is, I am too invested in Proxmox (time-wise) and changing to another technology is simply out of the question at this point. This brings me onto the other method; make a slight change to the code to remove the dialogue box from appearing. This is allowed under the License (aGPLv3) used for Proxmox however future updates may break your code and you may have to re-apply it or apply a different change.

You will need SSH access to the Proxmox host with the required access to edit the pvemanagerlib.js file.

First, take a backup of the file:

cp /usr/share/pve-manager/ext4/pvemanagerlib.js /usr/share/pve-manager/ext4/pvemanagerlib.js_BKP

Then open the file using a text editor, vi for example.

vi /usr/share/pve-manager/ext4/pvemanagerlib.js

Currently on line 519 of the file, however it may change with future updates, there is a line similar to below;

if (data.status !== 'Active') {

This line is doing the check to see if your subscription status is not ‘Active’. This needs to be changed to return false to stop the subscription message from being shown.

if (false) {

And that annoying little popup will be a thing of the past!

Note: You may need to clear your web browser cache after applying this code change.

I have added this code to my Proxmox patch – see this blog post for more information.


GlusterFS storage mount in Proxmox

Category : How-to

Get Social!

proxmox logo gradProxmox 3.1 brings a new storage plugin; GlusterFS. Thanks to this storage technology we can use distributed and redundant network storage to drive OpenVZ containers, qemu disk images, backups, templates and iso’s – basically all the Proxmox storage types.

Proxmox 3.1 uses version 3.4 of the GlusterFS client tools and therefore a compatible GlusterFS server version is required. For the current version, please see this post for the latest PPA Ubuntu repository, and this post for setting up a 2 node GlusterFS server.

Adding a single GlusterFS share to Proxmox 3.1 is one of the easiest things you will do, providing the server is already set up. The trouble comes in when you are using GlusterFS in a redundant/ failover scenario as Proxmox only allows you to enter one GlusterFS server IP meaning that you are loosing all the benefits of having a redundant file system.

At this point it’s worth understanding something about the GlusterFS server setup. Let’s say you have two physical servers which replicate a single GlusterFS share. This gives you a level of redundancy as one server can fail without causing any issues. It also gives you load balancing but that is a separate point altogether. The client can then connect to one of these servers as it mounts the filesystem however because of the way GlusterFS works it needs access to both the GlusterFS servers. This is because the first connection the client makes is to one of the servers to get a list of servers available for the storage share it is going to mount. In our example here, there are two storage servers available and it is this list which is sent to the client. Then, as the mount point is used by the client, it can communicate with any server in the known list. So then, although using a single IP for a client is a single point of failure, it’s only a single point of failure on the initial communication when obtaining the list of servers available.

Add using Proxmox web GUI

proxmox add storage

To set up a single server mount point, click on the Storage tab which can be found on DataCenter. Click Add and then GlusterFS volume. You will then see the Add: GlusterFS Volume dialogue box.

proxmox add glusterfs volume

Enter your GlusterFS server information into the dialogue box along with the other required fields described below.

  • ID – the name to use for the storage mount point. This will be visible in your storage list.
  • Server – the GlusterFS server IP or hostname.
  • Volume name – the share name on the GlusterFS server.

Using the GlusterFS client you are able to specify multiple GlusterFS servers for a single volume. With the Proxmox web GUI, you can only add one IP address. To use multiple server IP addresses, create a mount point manually.


Proxmox bind mount for OpenVZ – mount storage in a container

Category : How-to

Get Social!

proxmox logo gradYou can allocate storage to an OpenVZ container during creation, when the container is offline and even when the container is active. The main problem with this is that it is not shared, and has to be on the same storage which the container was created on.

You can mount any folder which is available to the host operating system in any container. You can also mount the same storage in multiple containers.

Before you begin, make sure the storage is mounted and usable on the host file system. For this example, we are going to use a disk which is mounted on the host at /mnt/binaries.

On the host, locate where your OpenVZ container config files are stored. On a standard Proxmox installation, this is /etc/vz/conf/. 

cd /etc/vz/conf/

Create a file with the naming convention [VMID].mount. This will be the file which is executed each time the container is started as part of the boot process. This example will assume the container is using VMID 270.

vi 270.mount

Add the below content to this file making the two changes; [HOST FOLDER] should be replace with the location on the host to use for storage in the container and [GUEST FOLDER] which will be the folder on the guest container where the storage will be available. The location on both the physical host and virtual guest must exist when the container is started. 

#!/bin/bash
. /etc/vz/vz.conf
. ${VE_CONFFILE}
SRC1=[HOST FOLDER]
DST1=[GUEST FOLDER]

mount -n -t simfs ${SRC1} ${VE_ROOT}${DST1} -o ${SRC1}

The below example makes /mnt/binaries on the host available at /mnt/vm_binaries on the guest.

#!/bin/bash
. /etc/vz/vz.conf
. ${VE_CONFFILE}
SRC1=/mnt/binaries
DST1=/mnt/vz_binaries

mount -n -t simfs ${SRC1} ${VE_ROOT}${DST1} -o ${SRC1}

To create multiple bind mounts, edit the below example.

#!/bin/bash
. /etc/vz/vz.conf
. ${VE_CONFFILE}
SRC1=/mnt/binaries
DST1=/mnt/vz_binaries
SRC2=/mnt/homes
DST2=/homes
SRC3=/mnt/backups
DST3=/mnt/vz_backups

mount -n -t simfs ${SRC1} ${VE_ROOT}${DST1} -o ${SRC1}
mount -n -t simfs ${SRC2} ${VE_ROOT}${DST2} -o ${SRC2}
mount -n -t simfs ${SRC3} ${VE_ROOT}${DST3} -o ${SRC3}

If you have many mounts something more elegant could be created however, generally speaking, only a few mount points are required per guest meaning that this brutish script is perfectly adequate.

These settings will require a restart of your container as the scripts are only applied on container start up.


Proxmox 3.1 package/ updates manager

Get Social!

proxmox logo gradProxmox version 3.1 made a huge change to the way updates are managed. Prior to version 3.1, updates for the PVE software were managed from two main repositories – test and production – both of which were free and available. Generally the production repositories were used to ensure a stable and secure Proxmox host. These two repositories have now changed to the following:

Please note, this also works for version 4.x.

None subscription repository

This repository remains free, and all the code is still under AGPL v3. I believe this repository is similar to what the test repository used to be – containing test and potentially buggy packages. There is also the standard Debian repository for all other, non-Proxmox, updates. As these packages are potentially unstable, it is not recommended to use this repository for a production server.

Proxmox Version 3.x

Proxmox version 3.x is based on Debian Wheezy.

deb http://ftp.uk.debian.org/debian wheezy main contrib
deb http://download.proxmox.com/debian wheezy pve-no-subscription
Proxmox Version 4.x

If you run version 4.x of Proxmox, based on Debian Jessie then you’ll need to adjust the URL slightly as below:

deb http://ftp.uk.debian.org/debian jessie main contrib
deb http://download.proxmox.com/debian jessie pve-no-subscription

Enterprise repository

This repository requires a subscription license key to be added to Proxmox before you can access it. These packages are stable and are recommended for any production Proxmox server after version 3.1.

If you do not have a valid subscription, you will need to remove this repository otherwise apt-get will never complete it’s update. Without a valid subscription, you will see errors such as “You do not have a valid subscription for this server. Please visit www.proxmox.com to get a list of available options.

Proxmox valid subscription error

Proxmox valid subscription error teminal

To remove the repository, open the source list file in the apt-get sources folder

vi /etc/apt/sources.list.d/pve-enterprise.list

And comment out the line with a # as below.

#deb https://enterprise.proxmox.com/debian wheezy pve-enterprise

All updates will now come from the none subscription repository which are publicly available. Unfortunately, each time you click the Refresh button on the Updates tab you will receive the above message. You will also receive this message when you login to the web GUI.

What about the old updates repository?

The original updates repository should be removed once you have upgraded to Proxmox 3.1. No future updates will be available in this repository.

Edit the sources list and comment out the old repository:

vi /etc/apt/sources.list

If you used the test repository, you will need to comment that out too.

# PVE packages provided by proxmox.com
#deb http://download.proxmox.com/debian wheezy pve

How to remove the “No Valid Subscription” message

Each time you log into Proxmox 3.1 a dialogue box pops up reminding you that you have not purchased a valid subscription. One way to remove the message is to purchase a subscription from the Proxmox team. Another method is to make a slight change to the code to remove the dialogue box from appearing.

See my post on how to change the code to remove the dialogue box.


Visit our advertisers

Quick Poll

How many Proxmox servers do you work with?

Visit our advertisers