Monday, 30 June 2014

Libxml error while compiling dual php - "make: *** [ext/dom/node.lo] Error 1"

Libxml error while compiling dual php - "make: *** [ext/dom/node.lo] Error 1"

ext/dom/node.c: In function 'dom_canonicalization':
ext/dom/node.c:1953:21: error: dereferencing pointer to incomplete type
ext/dom/node.c:1955:5: error: dereferencing pointer to incomplete type
make: *** [ext/dom/node.lo] Error 1

This is a PHP error when compile the older version when install libxml2 from bigger version 2.9.0.


Need to update patch.

+ vi libxml29_compat.patch

+ copy and paste below code in the file: 'libxml29_compat.patch'


--- ext/dom/node.c    2012-08-06 17:49:48.826716692 +0800
+++ ext/dom/node.c    2012-08-06 17:52:47.633484660 +0800
@@ -1895,9 +1895,17 @@ static void dom_canonicalization(INTERNA
     } else {
         if (mode == 0) {
+            ret = xmlOutputBufferGetSize(buf);
             ret = buf->buffer->use;
             if (ret > 0) {
+                RETVAL_STRINGL((char *) xmlOutputBufferGetContent(buf), ret, 1);
                 RETVAL_STRINGL((char *) buf->buffer->content, ret, 1);
             } else {
--- ext/dom/documenttype.c    2012-08-06 18:02:16.019640870 +0800
+++ ext/dom/documenttype.c    2012-08-06 18:06:16.612228905 +0800
@@ -205,7 +205,13 @@ int dom_documenttype_internal_subset_rea
         if (buff != NULL) {
             xmlNodeDumpOutput (buff, NULL, (xmlNodePtr) intsubset, 0, 0, NULL);
+            ZVAL_STRINGL(*retval, xmlOutputBufferGetContent(buff),
+                         xmlOutputBufferGetSize(buff), 1);
             ZVAL_STRINGL(*retval, buff->buffer->content, buff->buffer->use, 1);
             return SUCCESS;
--- ext/simplexml/simplexml.c    2012-08-06 18:10:44.621017026 +0800
+++ ext/simplexml/simplexml.c    2012-08-06 18:12:48.016270419 +0800
@@ -1417,7 +1417,12 @@ SXE_METHOD(asXML)

             xmlNodeDumpOutput(outbuf, (xmlDocPtr) sxe->document->ptr, node, 0, 0, ((xmlDocPtr) sxe->document->ptr)->encoding);
+            RETVAL_STRINGL((char *)xmlOutputBufferGetContent(outbuf),
+                           xmlOutputBufferGetSize(outbuf), 1);
             RETVAL_STRINGL((char *)outbuf->buffer->content, outbuf->buffer->use, 1);
     } else {


+ run the bleow commnad from php-source path:

# patch -p0 < libxml29_compat.patch

Am sure, Now you can go-ahead with # ./configure --your modules.......


Sunday, 29 June 2014

Boot Failure after Latest Kernel Update - "warning: selinux targeted policy relabel is required"

warning: selinux targeted policy relabel is required

When rebooting the server due to kernel upgrade we may face below error due to "SELinux is in permissive mode, the operation would have been denied but was permitted due to permissive mode."


Warning -- SELinux targeted policy relabel is required. Relabeling could take a very long time, depending on file system size and speed of hard drives.


SELinux is preventing access to files with the label, file_t.


We have done below steps to overcome the issue,

> Login the server through KVM

> Enter into single user mode.

> Edit the file: "/etc/selinux/config" as below




> exit from single user mode

Now the box will boot-up normally. :) !!!

Thursday, 12 June 2014

KVM disk performance: raw vs qcow2 & Steps to Convert raw to qcow2

Disk Format: Raw vs. Qcow2:

The libvirt(The virtualization API. libvirt is: A toolkit to interact with the virtualization capabilities of recent versions of Linux (and other OSes))  snapshots can only be performed on certain type of disk formats. There are several types of VM disk formats, but the most  common are raw and qcow2 (copy-on-write).

    * qcow2 [ "QEMU Copy-On-Write" ]

    * qcow2 is an updated version of the qcow format, intended to supersede it. The main difference with the original is that qcow2 supports multiple virtual machine snapshots through a new, flexible model for storing snapshots.

*   Users can easily convert qcow disk images to the qcow2 format. QEMU and Xen have retained the qcow format for backwards compatibility.

How qcow2 works:

*   Raw disks are presented as-is to the VM without any disk layering and do not support snapshots, whereas qcow2 disks support a range of special features including snapshots, compression and encryption.

*   Raw disks have better I/O performance than qcow2 because the VM disk space is pre-allocated before the VM is created, as opposed to qcow2, where VM disk space is thinly provisioned and allocated on-the-go as the VM requires it.

*   If you create a VM with a raw disk of 10 GB, you?ll see that the disk image size for the VM will be exactly 10 GB, whereas for a VM with a qcow2 disk the actual file size will be a fraction of 10 GB (say 2-3 GB) and it will grow as you occupy disk space inside the VM.

Verify VM disk format:

# file /vm-images/vm1.img
/vm-images/vm1.img: Qemu Image, Format: Qcow, Version: 2

# qemu-img info /vm-images/vm1.img
image: /vm-images/vm1.img
file format: qcow2
virtual size: 10G (10737418240 bytes)
disk size: 3.2G
cluster_size: 65536

Converting disk format from raw to qcow2:

It is easy to convert from a raw VM image (which doesn?t support libvirt snapshots) to qcow2 format. In this example, we convert an image file of size 10 GB for a VM called vm2.

1. Shut down the VM:

# virsh shutdown vm2

2. Let's take a look at the image file format:

# cd /vm-images

# qemu-img info vm2.img
image: vm2.img
file format: raw
virtual size: 10G (10737418240 bytes)
disk size: 10G

3. The conversion process actually makes a qcow2 copy of the raw image and leaves the raw image intact.

The command is:

# qemu-img convert -f raw vm2.img -O qcow2 vm2.qcow2

* The new image file extension is irrelevant; we use “qcow2” to help us identify the different image format.

* The conversion process will take a few minutes, depending on the size of the image file.

4. Let's take a look at the new image file format:

# qemu-img info vm2.qcow2
image: vm2.qcow2
file format: qcow2
virtual size: 10G (10737418240 bytes)
disk size: 3.2G
cluster_size: 65536

* Notice that the virtual size remains unchanged, it is still 10 GB.

* The disk size (as the OS sees it) will be less than 10 GB. In our case, it is 3.2 GB. If you run the „ls –l? command on the file, its reported size will match the “disk size” reported here. As you add files inside the VM disk, this file size will increase, up to a maximum of 10 GB.