VMware VDR licensing

Here I wrote about availability of VMware VDR in almost all the editions of vSphere - newly in Standard edition as well. VDR provides agent-less backups of  virtual machines and in-line block based destination deduplication.

This license change applies for all installations or upgrades to the latest release 4.1 update 1 of ESXi hypervisor. The  screenshot below shows the licensed features of one of my ESXi servers with  ESXi 4.1 update 1, build 348481, standard edition.

CentOS 6?

I'm a big fan of CentOS project. I use it in production and I recommend it to the others as an enterprise ready Linux distro. I have to admit that I was quite disappointed by the behaviour of  project developers who weren't able to tell the community the reasons why the upcoming releases were and are so overdue. I was used to downloading CentOS  images one or two months after the current RHEL release was announced. The situation has changed with RHEL 5.6 which is available since January, 2011 but the corresponding CentOS was released not before April, 2011. It took about 3 months to release it instead of one or two as usual. By the way, the main news in RHEL 5.6 are:

• full support for EXT4 filesystem (included in previous releases as technical preview)
•  new version 9.7 of BIND nameserver supporting NSEC3 resource records in DNSSEC and new cryptographic algorithms in DNSEC and TSIG
• new version 5.3 of PHP language
• SSSD daemon centralizing identity management and authentication

More details on RHEL 5.6 are officically available here.

The similar or perhaps worse situation was around the release date of CentOS 6. As you know, RHEL 6 is available since November, 2011. I considered CentOS 6 almost dead after I read about transitions to Scientific Linux or about purchasing support from Red Hat and migrating the CentOS installations to RHEL . But according to this schedule people around CentOS seem to be working hard again and the CentOS 6 should be available at the end of May. I hope the project will continue as I don't know about better alternative to RHEL (RHEL clone) than CentOS. The question is how the whole, IMO unnecessary situation, will influence the reputation of the project.

VMware Data Recovery

How do you backup your virtual infrastructure based on VMware platform? Do you still rely on VCB? Even if the VCB is still supported and it is compatible with the latest ESX/ESXi hypervisor at version 4.1u1 it should be discontinued from the next release. So what backup tool to use in the future? 

VMware vDR is considered to be its successor and in my opinion, the latest release is working pretty stable without any major issue. It's missing some features now like email reporting or GUI FLR restore tool but I think we can expect the future release will include them as the competing backup tools don't miss such basic things.

But what I consider the most important for better adoption of vDR in datacenters is that VMware corrected their licenses recently and vDR is now included in Standard edition as well. This means that vDR is available in all vSphere editions except vSphere Essentials kit.

DNS reverse mapping

Recently, I had to cope with configuring some reverse zones for subnets where the netmask is like 26 or 20 (IPv4). It's quite straightforward to do it with class C networks when it is sufficient to  reverse the order of network base of the address,  join the result with special domain in-addr.arpa and  create a reversed mapped zone file finally. If we had a network 192.168.1.0/24 then the reversed base of the network address would be 1.168.192 and the reversed zone 1.168.192.in-addr.arpa. 

The previous technique is well known for class C networks (B or A as well) when it is possible to split  it on its octet boundaries. If we have assigned a class C subnet which has less than 256 hosts we can't do it like this and we need to define the  network part and the host part of the address differently. The brute force way how to do it is to create a reversed zone for each host . The better way is to read through the RFC2317.

The RFC defines a classless allocation of subnets on non-octal boundaries with less than 256 hosts. Let's take a network 192.168.1.32/28 (subnet of network 192.168.1.0/24) where the network base is 192.168.1.32, the maximum number of host is 14 and the netmask is 255.255.255.240 (28 in CIDR notation). The next step is to reverse the network base which gives us 32.1.168.192 and join the result with the domain in-addr.arpa. It gives us a semi-reversed zone 32.1.168.192.in-addr.arpa. The final steps to construct the reversed zone are  not so clear. Take the first octet from the semi-reversed zone, substitute it with the netmask in CIDR notation and write it in the form first_octet/substituted_zone. In our example, we would get 32/28.1.168.192.in-addr.arpa (32 is the last octet and 28 is the netmask).

Why is the presented method useful? Even if the reverse zone creation is not so clear it helps to create only 1 zone file for 14 hosts in our example. If we had a network with netmask e.g. 25 we would be able to specify all 126 PTR records in one zone file. The method is obfuscated a bit but it eliminates  a creation of reversed zone file for each host.

It's important to realize the RFC2317 is for networks with 256 hosts or less  where  netmask  is from 24 to 32. For networks with more hosts there has to be used traditional delegation. If we have a network with netmask from 17 to 24 then we will have 1 zone file for each 256 hosts.  If we have a netmask from 9 to 16 then we can have 1 zone file per 65536 hosts.

Quickly - persistent modules loading on RHEL

The kernel modules required for booting the system up are part of an initial  ramdisk which is automatically loaded into the memory by a boot loader. The ramdisk contains enough modules to mount the root filesystem and to initialize essential devices like keyboard, console or   various expansion cards.  The boot process  then continues with running the init process.

During the next phase, the other modules referenced by the operating system  are loaded automatically.  The modules are called by their aliases specified and set in the /etc/modprobe.conf configuration file. The typical alias is e.g. eth0 for a network interface card or usb-controller for an USB controller.

If we need  to load some specific module during the system boot and there isn't a way to reference it we have a few choices how to do it.

• Place a particular modprobe command to the /etc/rc.d/rc.local script which is called at the end of the whole boot process. But it is likely to be late at this phase.
• Or better, place the command in the  /etc/rc.modules file which is read and executed by the /etc/rc.d/rc.sysinit initialization script during the system initialization phase. It may be better to load the modules as soon as possible.

The /etc/rc.modules does not exist by default, so at first create it and make it executable. I think the first method is commonly used by many of us but the second one is in my opinion more systematical.