Saturday, February 28, 2015

Using XenStore in Oracle VM

When you are developing a private cloud based upon the Oracle portfolio you will most likely make use of Oracle VM for your non-Sparc deployments. It is good to know that Oracle VM is based upon the opensource Xen Hypervisor developed by the Xen project.

The Xen Project hypervisor is an open-source type-1 or baremetal hypervisor, which makes it possible to run many instances of an operating system or indeed different operating systems in parallel on a single machine (or host). The Xen Project hypervisor is the only type-1 hypervisor that is available as open source. It is used as the basis for a number of different commercial and open source applications, such as: server virtualization, Infrastructure as a Service (IaaS), desktop virtualization, security applications, embedded and hardware appliances. The Xen Project hypervisor is powering the largest clouds in production today.

The above statement from the Xen project makes the statement that it is powering some of the largest clouds in production today which is a good thing to know if you are using Oracle VM. This means that the code adopted within Oracle VM is also empowering numerous other clouds and very large clouds for that matter.

To be able to make full use of the Xen part that makes Oracle VM it is advisable to start understanding how Xen by itself works. Reason for this is that Oracle has not adopted, or documented all features from Xen in its full extend while they are still largely available for you to use.

Even though Oracle has provided a great implementation of the Xen hypervisor and the tooling provided, especially with the integration of Oracle Enterprise Manager, is making life easy there are moments you want to do more than the standard implementation allows you. One of my recent experiences where this was the case was in relation to communication to XenStore. In basics XenStore is a shared storage space between the different domains running on the hypervisor. XenStore is maintained by the xentstored deamon in Dom0 and the operating systems running on the DomU’s can communicate with it via the XenBus.

Even though the default way of communicating to the XenStore is via a number of commands which do not require that you need to know the exact location of the XenStore data the data is actually located in a file. You can find the XenStore data file /var/lib/xenstored where the file is located and named tdb on Dom0. The name TDB stands for Tree Database.

One of the things that enables XenStore you to do is to retrieve information from the XenStore. When you are building more advanced deployment models you can, for example, store information in the XenStore and read this when you boot a guest for the first time and use this input in the configuration process. Also, having access to the XenStore from your guest VM can help you build better reports from the Guest point of view. Gregory Guillou wrote a great blogpost on this subject, the reason he was interested in using the XenStore was to be able to find the relation of a disk presented to a VM and the underlying storage from a VM guest point of view. This could help him to write additional code to do a snapshot from storage for which he needs to have the information about the underlying storage.

Compiling the XenStore tools
Oracle is not providing a RPM for the XenStore tools however you are able to download the Oracle VM sourcecode which contains the source code of the XenStore tools that you can then compile yourself. Or, when you need to do this often you can create a RPM yourself so you can easily distribute the XenStore tools to your guest VM’s.

Once you have downloaded the Oracle VM source code from the Oracle Download site you should open the .iso file and locate the correct source RPM in the SRPMS directory. For the version I am currently running this is xen-4.1.3-25.el5.94.src.rpm however naming can differ per version. Upload the .rpm file to the guest VM and install it.

[root@test1 ~]# rpm -ivh xen-4.1.3-25.el5.94.src.rpm
warning: xen-4.1.3-25.el5.94.src.rpm: Header V3 DSA/SHA1 Signature, key ID 1e5e0159: NOKEY
   1:xen                    ########################################### [100%]
[root@test1 ~]#

This should have provided you a new directory under your account named /rpmbuild/SOURCES in our case this is /root/rpmbuild/SOURCES which contains a large set of files. The only file we are interested in is the file that contains the source code to be used to compile the XenStore tools. In our case this is xen-4.1.3-ovs.tar.gz

[root@test1 SOURCES]# cd /root/rpmbuild/SOURCES/
[root@test1 SOURCES]#
[root@test1 SOURCES]# tar -zxvf xen-4.1.3-ovs.tar.gz

The above extracts the sources we need (and others) and we can go into the location where the sourcecode for the XenStore tools is located and make the code. However before you can make it you have to ensure you have some prerequisites completed that will have to be there before you can compile.  The below yum install command will install all required prerequisites if they are not installed yet. The below has been tested on Oracle Linux 6 and has been extended with gettext and patch based upon the information from the blog written by Gregory Guillou on this subject.

yum install oracle-rdbms-server-11gR2-preinstall libuuid-devel openssl-devel ncurses-devel dev86 iasl python-devel SDL-devel gettext patch

As soon as you have ensured that the prerequisites are all in place you can start the make command in the right directory.

[root@test1 tools]# cd /root/rpmbuild/SOURCES/xen-4.1.3-ovs/tools
[root@test1 tools]# make 

When done without any errors or warnings you can now use this to install the XenStore tools onto your guest VM.

[root@test1 tools]# cd /root/rpmbuild/SOURCES/xen-4.1.3-ovs/tools/misc
[root@test1 tools]#
[root@test1 misc]# install xen-detect /usr/local/bin
[root@test1 xenstore]# cd /root/rpmbuild/SOURCES/xen-4.1.3-ovs/tools/xenstore
[root@test1 xenstore]#
[root@test1 xenstore]# install libxenstore.so.3.0 /usr/local/lib
[root@test1 xenstore]# install xenstore xenstore-control /usr/local/bin
[root@test1 xenstore]#
[root@test1 xenstore]# cd /usr/local/bin
[root@test1 bin]#
[root@test1 bin]# ln -f xenstore xenstore-chmod
[root@test1 bin]# ln -f xenstore xenstore-exists
[root@test1 bin]# ln -f xenstore xenstore-list
[root@test1 bin]# ln -f xenstore xenstore-ls
[root@test1 bin]# ln -f xenstore xenstore-read
[root@test1 bin]# ln -f xenstore xenstore-rm
[root@test1 bin]# ln -f xenstore xenstore-write
[root@test1 bin]#

This in basics should have compiled and installed the XenStore tooling into your Guest VM. As you can see, there is a reason why you should want to create your own RPM in case you need to install this on more than one machine. However, the above gives you a good insight and starting point to build your own RPM.

Using the XenStore tools
Before you can use the XenStore tools you will have to set the correct path for LD_LIBRARY_PATH and you will have to mount Xen File System.

[root@test1 local]# export LD_LIBRARY_PATH=/usr/local/lib:$LD_LIBRARY_PATH
[root@test1 local]# mount -t xenfs none /proc/xen

Once you have done this you can use the XenStore tools. In basics you have xenstore-chmod, xenstore-exists, xenstore-list, xenstore-ls, xenstore-read, xenstore-rm and xenstore-write to your exposal.

Oracle Linux disable selinux

Security-Enhanced Linux (SELinux) is a Linux kernel security module that provides a mechanism for supporting access control security policies, including United States Department of Defense–style mandatory access controls (MAC). In some cases running SELinux is a good idea and should certainly be included in server builds for certain customers. However, in some cases it can also be a very big and troublesome security feature you  do not want to be active.

One of the cases where you do not want to have SELinux active is a development or research box. In this case I use the term research box for the machine you might have for yourself to play with and try new things. I do, as most people working with Oracle Linux a lot, have a large set of research boxes in a virtualized manner as well as development machines. All used for a specific task of project and when the project is done the installation is removed.

When you use a machine for this you do most likely do not want to have SELinux in place. Disabling SELinux is a small task.

SELinux is enabled via the configuration file: /etc/selinux/config to disable it simply ensure SELINUX=disabled is set in this file. This should turn of SELinux completely for your Oracle Linux installation.

As stated, SELinux is not a bad choice in secure environments, it can only be a hinder when you are testing new functionality. Understanding SELinux and using it in the right way can be a learning curve, to understand the benefits of SELinux it is good to have a look at the below video which provides an introduction.