Red Hat Enterprise Virtualisation: RHEV 3.0 Release

Red Hat Enterprise Virtualisation platform V.3

Red Hat has announced version 3 of its Red Hat Enterprise Virtualization (RHEV) server and desktop virtualisation software family. RHEV for Servers is the main product in the range that was introduced in autumn 2009 and updated in summer 2010. It includes a hypervisor, sometimes called RHEV-H, for hosting guest systems. Hosts are managed using management software (RHEV-M) which is another part of the server variant of RHEV and which also manages systems that are virtualised using Red Hat Enterprise Linux (RHEL). The RHEV for Desktops RHEV server "add-on" implements Virtual Desktop Infrastructures (VDIs) – sometimes called Hosted Virtual Desktop (HVD) – this technology involves running desktop operating systems on a server as guests; users then access these remote systems via (thin) clients.

As before, the RHEV hypervisor, which is only a few hundred megabytes in size, virtualises using KVM (Kernel-based Virtual Machine) and integrates many RHEL core components – however, the new RHEV uses components from the current RHEL version 6.2 rather than RHEL series 5. Consequently, the new RHEV-V offers many improvements that have been available in RHEL 6 for some time – for example, guest systems can now access up to 64 virtual CPU cores and up to 2 TB of working memory. Technologies such as vhost-net, Transparent Huge Pages (THP), x2apic and KSM (Kernel Shared Memory) are designed to improve performance and increase efficiency.

Red Hat says that it has incorporated more than a thousand new features into the management server software, which now includes a RESTful API. However, the most important change is that the code has been ported from C# to Java. This has had an important effect on the system requirements for running RHEV-M. Instead of the Microsoft Windows Server that RHEV-M 2.2 required, the new version relies on RHEL 6 server, with the Java code running on Red Hat's JBoss Enterprise Application Platform. However, Red Hat hasn't fully lost the Windows dependency it acquired with Qumranet, because the management server software's "Administrator Console" web front-end can only be operated from a Windows computer running a version of Internet Explorer 7 with .NET Framework 4. Red Hat plans to fix this issue in the next version of RHEV.

RHEV for Desktops continues to use Spice – developed by Qumranet – for communication between clients and virtualised desktop operating systems. Red Hat says that it has improved Spice in several ways, for example, users can now connect almost any USB 1.1/2.0 device to Spice clients which can pass the connections through to the remote virtualised desktop operating system. Apparently, even resource-hungry applications can be operated remotely this way.

According to Red Hat, the various RHEV products are based on open source software. Last autumn, Red Hat handed the management software it acquired when purchasing Qumranet, as well as a variety of other RHEV-specific components, over to the oVirt project, where the company has continued to develop them together with contributors such as Canonical, Cisco, IBM, Intel, NetApp and SUSE. Some background information on the oVirt components is available from one of the project's blog posts.

Like Red Hat's RHEL, RHEV is distributed using a subscription model. The server product's annual subscription fee depends on the number of host system processor sockets and on the chosen support option; options include the "Standard" and "Premium" versions that Red Hat customers will already know from RHEL. Red Hat has repeatedly emphasised that it considers this approach far simpler and more cost-effective than the licensing models of comparable products. Red Hat's remarks appear to be mainly aimed at market dominating virtualisation specialist VMware.

Original link: http://www.h-online.com/open/news/item/Red-Hat-releases-third-version-of-its-Enterprise-Virtualisation-platform-1416749.html

Configuring a Microsoft SQL database for vCloud Director 1.5

This articles outlines the steps for creating a Microsoft SQL database for use with vCloud Director 1.5. It is essential that these steps are followed exactly for your database to function correctly.

Cause

SQL Server databases have specific configuration requirements when you use them with vCloud Director. Install and configure a database instance, and create the vCloud Director database user account before you install vCloud Director.

vCloud Director database performance is an important factor in overall vCloud Director performance and scalability. vCloud Director uses the SQL Server tmpdb file when storing large result sets, sorting data, and managing data that is being concurrently read and modified. This file can grow significantly when vCloud Director is experiencing heavy concurrent load. It is a good practice to create the tmpdb file on a dedicated volume that has fast read and write performance. For more information about the tmpdb file and SQL Server performance, see http://msdn.microsoft.com/en-us/library/ms175527.aspx.

Resolution

Prerequisites

• You must be familiar with Microsoft SQL Server commands, scripting, and operation.
• To configure Microsoft SQL Server, log on to the SQL Server host computer using administrator credentials. You can configure SQL server to run with the LOCAL_SYSTEM identity, or any identity with the privilege to run a Windows service.

Configuring the Microsoft SQL Server Database

1. Configure the database server.
   
   A database server configured with 16GB of memory, 100GB storage, and 4 CPUs is adequate for most vCloud Director clusters.
2. Specify Mixed Mode authentication during SQL Server setup.
   
   Windows Authentication is not supported when using SQL Server with vCloud Director.
3. Create the database instance.
   
   This script creates the database and log files, specifying the proper collation sequence:
   
   USE [master]
   GO
   CREATE DATABASE [vcloud] ON PRIMARY
   (NAME = N'vcloud', FILENAME = N'C:\vcloud.mdf', SIZE = 100MB, FILEGROWTH = 10% )
   LOG ON
   (NAME = N'vcdb_log', FILENAME = N'C:\vcloud.ldf', SIZE = 1MB, FILEGROWTH = 10%)
   COLLATE Latin1_General_CS_AS
   GO
   
   The values shown for SIZE are suggestions. You might need to use larger values.
4. Set the transaction isolation level.
   
   This script sets the database isolation level to READ_COMMITTED_SNAPSHOT:
   
   USE [vcloud]
   GO
   ALTER DATABASE [vcloud] SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
   ALTER DATABASE [vcloud] SET ALLOW_SNAPSHOT_ISOLATION ON;
   ALTER DATABASE [vcloud] SET READ_COMMITTED_SNAPSHOT ON WITH NO_WAIT;
   ALTER DATABASE [vcloud] SET MULTI_USER;
   GO
   
   For more about transaction isolation, see http://msdn.microsoft.com/en-us/library/ms173763.aspx.
5. Create the vCloud Director database user account.
   
   This script creates the database user name vcloud with password vcloudpass:
   
   USE [vcloud]
   GO
   CREATE LOGIN [vcloud] WITH PASSWORD = 'vcloudpass', DEFAULT_DATABASE =[vcloud],
   DEFAULT_LANGUAGE =[us_english], CHECK_POLICY=OFF
   GO
   CREATE USER [vcloud] for LOGIN [vcloud]
   GO
6. Assign permissions to the vCloud Director database user account.
   
   This script assigns the db_owner role to the database user created in Step 5:
   
   USE [vcloud]
   GO
   sp_addrolemember [db_owner], [vcloud]
   GO

Making a bootable OpenBSD 5.0 CD

Here are the scripts on how to make the bootable OpenBSD v 5.0 CD

#!/usr/local/bin/bash
#
## Calomel.org -- Making a bootable OpenBSD CD
## calomel_make_boot_cd.sh
#
arch="amd64" # Architecture
version="5.0" # OS version
#
echo "building the environment"
mkdir -p /tmp/OpenBSD/$version/$arch
cd /tmp/OpenBSD/$version/$arch
#
echo "getting the release files"
wget --passive-ftp --reject "*iso" ftp://ftp.openbsd.org/pub/OpenBSD/$version/$arch/*
#
echo "building the ISO"
cd /tmp/OpenBSD
mkisofs -r -no-emul-boot -b $version/$arch/cdbr -c boot.catalog -o OpenBSD.iso /tmp/OpenBSD/
#
echo "burning the bootable cd"
nice -18 cdrecord -eject -v speed=32 dev=/dev/rcd0c:0,0,0 -data -pad /tmp/OpenBSD/OpenBSD.iso
#
echo "DONE."
#