Virtualization

The virtualization layer is implemented by the VMM and is software that runs in a layer between the VMkernel and one or more VMs. It provides the VM abstraction to the guest operating systems.

It is through the VMM that the VM leverages key technologies in the VMkernel. The VMM is part of the VMkernel and is provided for each VM.

The vSphere VMM manages CPU, memory, and input/output, or I/O, device virtualization by implementing software virtualization, hardware virtualization, or paravirtualization techniques.

Software virtualization is an approach in which the hypervisor uses binary translation technology to provide virtualization of CPU and memory for the guest operating systems.

Hardware virtualization is a technique in which hardware capabilities of current CPUs are exploited to provide virtualization of CPU and memory.

Paravirtualization is a virtualization approach that exports a modified hardware abstraction that requires operating systems to be explicitly modified and ported to run. VMware uses paravirtualization to optimize the performance of certain drivers, for example, Small Computer Systems Interface, or SCSI, and network drivers.

New Features in Linux Kernel 3.9

Ten weeks to the day after the arrival of version 3.8, Linux creator Linus Torvalds on Monday released version 3.9 of the Linux kernel.
“This week has been very quiet, which makes me much more comfortable doing the final 3.9 release, so I guess the last -rc8 ended up working,” wrote Torvalds in the announcement email early Monday. “Because not only aren't there very many commits here, even the ones that made it really are tiny and not pretty obscure and not very interesting.”

Linus Torvalds on Monday released version 3.9 of the Linux kernel.

That's certainly not to say that this new kernel release doesn't include a number of interesting features overall, however – quite the contrary, in fact. Here's a quick look at some of the highlights. 1. SSD Caching
It's always nice to see new features that enable faster performance, and one such example is Linux 3.9's addition of a device mapper target (dm-cache) that enables the use of speedy devices such as solid-state drives (SSDs) as a cache for slower devices such as rotating hard disks.  “Different 'policy' plugins can be used to change the algorithms used to select which blocks are promoted, demoted, cleaned etc.,” explains the changelog on KernelNewbies.org. “It supports writeback and writethrough modes.”
2. Expanded Architecture Support
Broadened support is another change that's pretty much always welcome, and Linux 3.9 actually adds two new architectures to the list of those supported. Specifically, this new release brings the Linux kernel port to the ARC700 processor family (750D and 770D) from Synopsys as well as the Meta ATP (Meta 1) and HTP (Meta 2) processor cores from Imagination. Meta cores can be found in many digital radios, while the ARC700 family is commonly embedded in SoCs in TV set-top boxes and digital media players.
3. Better Power Efficiency
Thanks to the inclusion of the Intel PowerClamp driver, which performs synchronized idle injection across all online CPUs, Linux 3.9 also offers improved power efficiency in terms of performance per watt.
4. Chromebook Support
Particularly useful for Chromebook owners yearning to get their favorite distro up and running on their machine, meanwhile, is that Linux 3.9 adds full support for “all the devices present in the Chrome laptops sold by many companies,” as KernelNewbies puts it.
5. Another Boost for ARM
Linux's support for ARM has improved considerably over the past few releases, and kernel 3.9 brings a key improvement in the form of support for the KVM virtualization system in the ARM architecture port. As KernelNewbies notes, “this brings virtualization capabilities to the Linux ARM ecosystem.”
6. Android Developer Support
Finally, targeting Android developers this time, Linux 3.9 adds support for the “Goldfish” virtualized platform that's part of the Android development environment. Essentially, that means it's now possible to develop for Android with “out-of-the-box” kernels.

How to write Redhat cloned distro initialization scripts with Upstart

On Linux systems, initialization (init) scripts manage the state of system services during system startup and shutdown. When the system goes through its runlevels, the System V init system starts and stops services as configured. While this tried-and-true technology has been around since the dawn of Unix, you can now create modern and efficient CentOS 6 init scripts by using Upstart, an event-based replacement for System V init.
Until its latest release, CentOS used the System V init system by default. SysV init scripts are simple and reliable, and guarantee a certain order of starting and stopping.
Starting with version 6, however, CentOS has turned to a new and better init system – Upstart. Upstart is faster than System V init because it starts services simultaneously rather than one by one in a certain order. Upstart is also more flexible and robust, because it is event-based. Upstart generates events at various times, including while going through the system runlevels, similar to the SysV init system. However, Upstart may also generate custom events. For example, with Upstart you can generate an event that requires certain services to be started, regardless of the runlevel. And Upstart not only generates events, it also handles them – so, for example, when it acknowledges the event for starting a service it will do so. This event-based behavior is robust and fast.
Upstart supports SysV init scripts for compatibility reasons; most service init scripts in CentOS 6 continue to be SysV-based. You might someday have to create an init script yourself if you write custom software. If you do, you should write your new init scripts with Upstart in mind so you can benefit from the new init system's faster performance and additional features.

Beginning the Upstart init script

Upstart keeps init scripts in the /etc/init/ directory. A script's name should correspond to the name of the service or job it controls, with a .conf extension. The init script for the Tomcat service, for example, should be named /etc/init/tomcat.conf.
Like SysV init scripts, Upstart init scripts are regular Bash scripts, but extended with some Upstart-specific directives, which are called stanzas in Upstart. In SysV init scripts you commonly see the line . /etc/init.d/functions, which provides access to additional necessary SysV functions. Upstart scripts are more sophisticated and complete; you don't have to include any additional functions or libraries.
Just as in any Bash script, comments in Upstart scripts start with #. Put descriptive comments at the beginning of each script to explain its purpose, and in other places where the code may need explanation. You can use two special stanzas, author and description, for documentation.

Defining when a service starts

After the introductory comments you can define when a service should start and stop using the special stanzas stop on and start on. These two stanzas can be used with a recognized Upstart event such as when the system enters a runlevel.
Usually administrators configure service jobs to start and stop with the server. By convention, in CentOS you should configure a service job to start at runlevels 2, 3, 4, and 5 and stop at runlevels 0, 1, and 6. In an Upstart init script this is written like this:

start on runlevel [2345]
stop on runlevel [06]

This instructs Upstart to start and stop the service whenever the system enters the runlevel in brackets.
Upstart also lets you start or stop services based on other types of events, such as the starting or stopping of other services. For example, suppose you have an Apache web server integrated with a Varnish caching web server, as described in the article Varnish improves web performance and security. In such a scenario you should make sure that Varnish starts whenever Apache starts, so the configuration stanza for Varnish should look like:

start on starting httpd
stop on stopped httpd

The latter stanza is an unique feature of Upstart; Upstart init scripts can stop services at the same time as other services are stopped, while SysV init scripts depend solely on runlevels.
Another difference is that you configure SysV init scripts when to start and stop by placing symlinks to them in the corresponding runlevels' directories in /etc/rcX.d/, where X is the runlevel number. The command chkconfig does this automatically for you in CentOS. While chkconfig continues to manage most of the init scripts in CentOS 6, it does not work with Upstart, and you cannot manage Upstart jobs with it.

Preparing for an Upstart job

To prepare and customize your environment for an Upstart service job you can use a few additional parameters, each on a new line in the job's .conf file:

• respawn – When you use this parameter the service process will be restarted if it dies unexpectedly. Without this Upstart parameter you might have to write a dedicated wrapper program to start a service and ensure its proper and constant operation, such as mysqld_safe for starting MySQL.
• expect fork – Every service job should be expected to fork in as a background process. When you specify this parameter Upstart obtains the new process's PID, which it can use later to send signals to it, such as to shut down or reload configuration.
• kill timeout [seconds] – This is the number of seconds before the process may be forcibly killed. You should specify enough time (say, 120 seconds) so that interruption-sensitive services such as MySQL are able to complete any pending operations and shut down safely.

You can also adjust a few Bash variables in the job's .conf file. For example, you can configure the umask (permissions) with which new files will be created. A secure choice is umask 007, which means that new files will be created with restrictive permissions 770, which allow only the user itself and the members of its user group to manipulate the newly created files.
A special Upstart stanza pre-start allows you to specify a command or inline script to be run right before Upstart actually starts the job. This stanza is suitable for specifying any sanity checks, such the existence of a necessary file. You may also define prerequisite tasks, such as cleaning of the caching directory of a caching proxy. If the pre-start procedure fails – that is, if it exits with a code other than zero – then the whole job fails and the service is not started.
To see how this works, here's a pre-start directive to remove PHP accelerator eAccelerator's previously cached files, as you would want to do when eAccelerator is integrated with Apache: pre-start exec rm /var/cache/eaccelerator/* -rf. A longer example with a whole inline script looks like:

pre-start script
    # check if Apache's binary is executable or fail 
    [ -x /usr/sbin/httpd ]
    # clear the /tmp directory from old sessions
    rm /tmp/sess_*
end script

Several other stanzas are similar to the pre-start stanza:

• post-start – specifies a procedure to run after starting the service. This is usually useful for complex services that may need additional attention after startup, such as MySQL.
• pre-stop – specifies actions used in preparing for the service shutdown. It is rarely used.
• post-stop – may be regarded as an alternative to the pre-start stanza; in some cases it makes more sense to take some actions right after service shutdown instead of waiting for its next start.

Configuring the Upstart start command or script

Once you've configured your environment, the last thing you must do is define the job's command or script using the stanzas script ... end script to write a regular Bash script inline, or just exec to simply execute a command with arguments. Here's an example that uses the script stanza for the rsyslog service in the rsyslog.conf file:

script
    . /etc/default/rsyslog
    exec rsyslogd $SYSLOGD_OPTIONS
end script

The above directive first sources (includes) the content of the file /etc/sysconfig/rsyslog, where the variable SYSLOGD_OPTIONS is defined. This variable is then used to start the rsyslogd service. This is a convenient way to start a service that requires complex or custom configuration, and it's why such script stanzas are suitable for services such as MySQL or Apache.
Alternatively, the exec stanza lets you specify an executable file and any additional arguments it may need. It's suitable for simpler services; for example, you can start the CUPS daemon with the directive exec /usr/sbin/cupsd -F.

How Upstart stops and reloads services

If you're familiar with SysV init scripts, you may wonder how you configure the commands to stop a service or reload its configuration. The answer is that you don't have to; with Upstart you only configure the start command for a service. When Upstart starts a service it keeps track of its PID and the PIDs of the process forks. When Upstart later needs to shut down a service, it does so with the native Unix signals. Upstart first sends a PID the SIGTERM signal to gracefully shut it down. If the process ignores SIGTERM, Upstart sends SIGKILL to forcibly kill it. Similarly, when the configuration needs to be reloaded, Upstart sends the SIGHUP signal. Upstart's simple architecture removes the needs to specify procedures for stopping, restarting, and reloading a service, though if the shutdown procedure for a service requires more than just sending SIGHUP or SIGTERM signals, you can use the pre-stop and post-stop stanzas.
One last and important difference between Upstart and SysV inits is how you manually start and stop jobs. Upstart works with the command /sbin/initctl, the init daemon control tool. It accepts as a first argument stop, start, restart, or reload, and changes the state of the service correspondingly. The second argument is the name of the service. For example, to start MySQL's Upstart job manually you would run the command initctl start mysqld.

OpenStack 'Grizzly' 2013.1 release.

Roughly six months after the launch of its “Folsom” release last fall, OpenStack on Thursday unveiled version 2013.1 “Grizzly,” the seventh and latest release of the open source software for building public, private and hybrid clouds.

More than 500 contributors made 7,620 updates in the OpenStack "Grizzly" release.

More than 500 contributors made 7,620 updates in this new release, which, “more than any before it, was driven by users who have been running OpenStack in production for the past year (or more) and have asked for broader support for the compute, storage and networking technologies they trust and even greater scale and ease of operations,” explained Mark Collier, chief operating officer at the OpenStack Foundation, in a blog post announcing the new software. Best Buy, Bloomberg, NSA, Cisco WebEx, Comcast, CERN, HP, NeCTAR, PayPal, Rackspace and Samsung are among the companies using OpenStack in production.
Developers who contributed to this release came from more than 45 companies, including Red Hat, Rackspace, IBM, HP, Nebula, Intel, eNovance, Canonical, VMware, Cloudscaling, DreamHost and SINA.

'Support for Security Groups'

Seven integrated projects make up OpenStack, each with source code now publicly available: Compute ("Nova"), Object Storage ("Swift"), Image Service ("Glance"), Networking ("Quantum"), Block Storage ("Cinder"), Identity ("Keystone") and Dashboard ("Horizon").      
More than 200 new features are included in this Grizzly release, and some 1,900 bugs were fixed. In anticipation of the launch, Linux.com spoke earlier this week with Thierry Carrez, release manager for the project, to hear about some of the highlights.
“Personally, my favorite key features for this release would be in OpenStack Compute (Nova): introduction of the 'Cells' deployment model for massive scale, and isolation of the compute nodes from the rest of the system for better security ('no-db-compute'),” Carrez began. “I also like how OpenStack Networking introduced support for security groups, as well as a load-balancing-as-a-service feature.”
Meanwhile, “I would also mention how OpenStack Block Storage (Cinder) managed to add a large number of storage drivers from all of the storage industry,” he told Linux.com. Ten new drivers were added, in fact, including Ceph/RBD, Coraid, EMC, Hewlett-Packard, Huawei, IBM, NetApp, Red Hat/Gluster, SolidFire and Zadara.
Finally, “the general drive towards more reuse of code across the various OpenStack projects (through the introduction of the common 'Oslo' libraries) is also worth mentioning,” Carrez said.

Cross-Origin Resource Sharing 

Other highlights of the new release include significant improvements in virtualization management on the Compute side, with full support for ESX, KVM, XEN and Hyper-V. Quotas were added to the Object Storage system, meanwhile, as was cross-origin resource sharing (CORS), enabling browsers to “talk directly to back-end storage environments,” Collier noted.
For Networking, Grizzly aims to achieve greater scale and higher availability by distributing L3/L4 and dynamic host configuration protocol (DHCP) services across multiple servers. New plug-ins were also added from Big Switch, Hyper-V, PlumGrid, Brocade and Midonet.
The Grizzly Dashboard, meanwhile, is backwards-compatible with the Folsom release.

vCloud Director : vSphere enter to maintenance mode

• System-> Manage & Monitor
• vSphere Resources -> Hosts

1. Find the host you need to place in to maintenance mode, right click and select Disable Host.
2.  At that point, the status will turn from a green circle with a check, to a red circle.
3. Right click on the host again and select Redeploy All VMs.
4. The ESXi host will go in to maintenance mode in the vCenter server and evacuate all virtual machines as usual.
5. (Optional!) If you see vsla errors (such as the screenshot), issues with deleting vApps, Unprepare the host which removes the vCloud agent from ESXi
6. (Optional!) Prepare the host for vCloud by pushing the vCloud agent to ESXi
7. When maintenance is complete, right click and Enable Host.
8. And your work is complete!

Oracle Linux Vs RHEL

As one of the most widely deployed operating systems today, Linux is increasingly being adopted for cloud-based solutions. Oracle Linux is the most complete and integrated solution available—and delivers higher performance and better reliability at up to 7 times lower cost than Red Hat. Below, explore the top ten reasons why Oracle Linux provides more value than Red Hat Enterprise Linux.

Reason	Oracle Linux	Red Hat Enterprise Linux
Lower Cost	Oracle Linux is free to download and distribute Support subscription for Oracle Linux is simple and extremely affordable Support costs can be up to 7 times lower than Red Hat	Red Hat Enterprise Linux cannot be downloaded unless you buy a support subscription Very high-cost subscriptions and add-ons Complex licensing
Management Tools Included	Oracle Linux Support customers get access to free Oracle Linux server lifecycle management tools that are the equivalent of Red Hat Satellite Server and associated modules The same Oracle Enterprise Manager tool can also be licensed to manage the entire solution from application to disk.	Users have to license Red Hat Satellite Server and associated modules for each server; the extra cost can quickly add up
High Availability (HA) Included	Oracle Linux includes OCFS2 and Oracle Linux Basic and Premier Support subscribers have free access to Oracle Clusterware	Red Hat charges separately for add-ons that include clustering software for HA
XFS Support included	Oracle Linux Premier Support subscribers have free support for XFS	Red Hat charges separately for the XFS add-ons
Free Download of Binaries and Source	Oracle Linux installation media (DVD) are free to download, use and distribute All source code for Oracle Linux, including source code for patches and errata are freely, publicly available	Red Hat Enterprise Linux cannot be downloaded unless you buy a support subscription
Enterprise-Quality Support with Premier Backporting	Same level of 24/7 enterprise-class support as Oracle Database Backport bug fixes are available between update releases without forcing customers to upgrade to the entire update release Zero downtime updates with Ksplice	Various levels of support include business hours only Red Hat forces customers to upgrade to the latest update release in order to apply only a few bug fixes Need to re-boot for software updates and patches
Higher Performance	Oracle's Unbreakable Enterprise Kernel closely tracks the mainline kernel and offers customers access to the latest Linux innovations The Unbreakable Enterprise Kernel is fast, modern, and reliable New record-breaking TPC-C and SPECjEnterprise2010 benchmark results	Red Hat Enterprise Linux 5 (RHEL5) is using a four-year-old kernel, so customers using RHEL5 did not benefit from Linux innovations
Ease of Deployment	To enable faster time to market for customers, Oracle provides documented best practices with Oracle Validated Configurations for Linux, which include recommendations on deploying pretested stacks of server, storage, drivers, networking components, Oracle Linux, and Oracle software in a physical and virtual environment Oracle VM Templates offer pre-installed and pre-configured images of enterprise software running on Linux, eliminating the need to install and configure from scratch	Red Hat does not offer such a program Red Hat does not adequately test with Oracle software
Integrated with Systems	Oracle's Sun x86 servers come preinstalled with Oracle VM and Oracle Linux; support for Oracle Linux is already included with the Oracle Premier Support for Systems	Red Hat needs to partner with other hardware and software companies to offer full stack
Fully Tested and Ready for Data Center Deployments	Oracle makes significant investment in testing Linux internally, both in the development farm and Global IT More than 80,000 hours of QA is run on Oracle Linux servers each day in our development farm More than 42,000 servers run Oracle Linux supporting Oracle's Global IT	Red Hat does not test with Oracle Database and Oracle Applications
Complete Solution with a Single Point of Contact for Support	Only Oracle offers a complete and integrated, applications-to-disk Linux solution (servers, operating system, database, and applications), including a single point of support—eliminating finger pointing among various vendors	Need to deal with numerous vendors for the solution and for support

LMD : Linux Malware Detect

Linux Malware Detect (LMD) is a malware scanner for Linux released under the GNU GPLv2 license, that is designed around the threats faced in shared hosted environments. It uses threat data from network edge intrusion detection systems to extract malware that is actively being used in attacks and generates signatures for detection. In addition, threat data is also derived from user submissions with the LMD checkout feature and from malware community resources. The signatures that LMD uses are MD5 file hashes and HEX pattern matches, they are also easily exported to any number of detection tools such as ClamAV.

Linux Malware Detect (LMD) Features:
 * MD5 file hash detection for quick threat identification
 * HEX based pattern matching for identifying threat variants
 * statistical analysis component for detection of obfuscated threats (e.g: base64)
 * integrated detection of ClamAV to use as scanner engine for improved performance