Tag: Linux

Hyper-V Linux Integration Components V2.0 With RedHat Support

Microsoft released version 2.0 of the Linux Integration Components for Hyper-V on the 29th of January.  They include support for installing on not only SUSE Enterprise Linux (10 SP1 and 10 SP2) but also RedHat Enterprise Linux 5.

Now I’ve got to expand the possible Linux OS’s I would run on my Hyper-V farm.  Remember, I’m monitoring using Operations Manager 2007 R2.  It can support RHEL 4 and RHEL 5.  Hyper-V now has supported integration components for RHEL 5.

That means I can now run SLES 10 SP1 or RHEL 5 on my Hyper-V farm and be able to monitor the internal goings-on of those VM’s using Operations Manager 2007 R2.  I’m more likely to go with RHEL.  It appears to me to be more accepted and has more documentation in the blog-o-sphere that SLES.

Using VMM 2008 R2 For V2V

It is possible using Virtual Machine Manager 2008 R2 to migrate virtual machines from one hardware virtualisation platform to another.  This is known as Virtual to Virtual or V2V.  The possible migrations you can do are:

  • Migrate from Virtual Server 2005 R2 SP1 to Hyper-V
  • Migrate a VMware Virtual Machine from the VMM Library to Virtual Server 2005 R2 SP1 or to Hyper-V
  • Migrate a VMware Virtual Machine from a VMware host to Virtual Server 2005 R2 SP1 or to Hyper-V

This is a one-way process.  You cannot go from Hyper-V back to the original host platform.

Supported V2V VM Operating Systems

Just like with P2V, there is a matrix of supported operating systems:

Operating System

VMM 2008

VMM 2008 R2

Microsoft Windows 2000 Server with Service Pack 4 (SP4) or later

Yes

Yes

Microsoft Windows 2000 Advanced Server SP4 or later

Yes

Yes

Windows XP Professional with Service Pack 2 (SP2) or later

Yes

Yes

Windows XP 64-Bit Edition SP2 or later

Yes

Yes

Windows Server 2003 Standard Edition (32-bit x86)

Yes (Requires SP1 or later.)

Yes (Requires SP2 or later.)

Windows Server 2003 Enterprise Edition (32-bit x86)

Yes (Requires SP1 or later.)

Yes (Requires SP2 or later.)

Windows Server 2003 Datacenter Edition (32-bit x86)

Yes (Requires SP1 or later.)

Yes (Requires SP2 or later.)

Windows Server 2003 x64 Standard Edition

Yes (Requires SP1 or later.)

Yes (Requires SP2 or later.)

Windows Server 2003 Enterprise x64 Edition

Yes (Requires SP1 or later.)

Yes (Requires SP2 or later.)

Windows Server 2003 Datacenter x64 Edition

Yes (Requires SP1 or later.)

Yes (Requires SP2 or later.)

Windows Server 2003 Web Edition

Yes

Yes

Windows Small Business Server 2003

Yes

Yes

Windows Vista with Service Pack 1 (SP1)

Yes

Yes

64-bit edition of Windows Vista with Service Pack 1 (SP1)

Yes

Yes

Windows Server 2008 Standard 32-Bit

Yes

Yes

Windows Server 2008 Enterprise 32-Bit

Yes

Yes

Windows Server 2008 Datacenter 32-Bit

Yes

Yes

64-bit edition of Windows Server 2008 Standard

Yes

Yes

64-bit edition of Windows Server 2008 Enterprise

Yes

Yes

64-bit edition of Windows Server 2008 Datacenter

Yes

Yes

Windows Web Server 2008

Yes

Yes

Windows 7

No

Yes

64-bit edition of Windows 7

No

Yes

64-bit edition of Windows Server 2008 R2 Standard

No

Yes

64-bit edition of Windows Server 2008 R2 Enterprise

No

Yes

64-bit edition of Windows Server 2008 R2 Datacenter

No

Yes

Windows Web Server 2008 R2

No

Yes

Not Got VMM?

There is a manual process to convert Virtual Server 2005 R2 SP1 VM’s to Hyper-V if you do not have VMM.  There are 3rd party and free tools for this.  There are also 3rd party and free tools you can use to V2V from VMware to Hyper-V without VMM.  However, these would be very manual processes and VMM makes that all the much easier through it’s job process.

Destination Host Requirements

The destination machine should have the disk and the RAM to cater for the VM.  MS actually recommends RAM of the VM + 256MB for the conversion process.  The host should also be in a network that allows all necessary communications with the VMM server.

Original VM Requirements

Before you migrate any VMware machine to a Microsoft platform you must uninstall the VMware additions/tools.  That’s the VMware equivalent of the Microsoft integration components/services.  You also need to remove any checkpoints.

Library V2V

There are then two possible ways to do the conversion.  As I stated earlier, you can copy a VMware VM into the library and V2V the VM from there.  To do this in VMM, choose to use the Convert Virtual Machine Wizard.  You cannot V2V a VMware VM that uses raw disks (same idea as pass through disks).  You need access to the .VMX file (describes the VM) and the VMDK file(s) (the virtual hard disks).  Each VMDK will be converted into a VHD.

Host V2V

If your VM is on another host, e.g. Virtual Server 2005 R2 SP1 or VMware, then make sure the source host is being managed by VMM.  You can then use an offline migration, i.e. power off the VM, right-click the VM and Migrate it.  Make sure the hosts filter is adjusted to show your destination Microsoft virtualisation host.

Integration Components

When the job is completing, you’ll see that VMM will install the integration components/services for Hyper-V.  That will optimise the performance of the VM and cuts down on the manual labour.

Linux VM’s

Interestingly, Microsoft says you can V2V a Linux VM.  However, any OS not in the above table will not get the integration components.  And remember, only certain enterprise versions of SUSE (no IC’s) and RedHat (no IC’s) are supported.  If you V2V a supported SLES VM you will have to manually install the Linux integration components.

Hyper-V Live Migration and Linux VM’s

Let’s get this out of the way quickly.  Yes, you can run Linux virtual machines on a Hyper-V cluster and you can Live Migrate them.  I have SUSE Enterprise Linux 10 SP1 VM’s running on our cluster.  I can live migrate them from one host to another and not lose a ping packet during the move.

There’s a configuration that you must to to ensure this stability.  I first read about it online and it is in the Microsoft documentation for the Linux integration components.

You need to set the MAC (Ethernet) address of the virtual machine to be static.  VMM makes that quite easy. 

image

Above you can see the properties of a SLES VM on our Hyper-V cluster.  You can see that I’ve put the VM into a VLAN so I can firewall it.  I’ve also set the NIC to have a static MAC address.  Unlike most controls for networking, this must be set while the VM is powered off.  There’s a button on the right which allows you to generate a MAC address.  This is created from a pool of MAC addresses.

image

VMM allows you to specify what that pool of MAC addresses is.  It must be a range that does not exist on any hardware – there’s always the chance that you could otherwise accidentally set a MAC address for a VM that clashes with that of an actual Ethernet network card and cause all sorts of ARP issues.

Once you have that setting configured, boot up your VM, install the OS, install the IC’s and test.  Here I have run a ping from within the VM to the default gateway while running a live migration from VMM:

64 bytes from 192.168.100.31: icmp_seq=15 ttl=64 time=0.469 ms
64 bytes from 192.168.100.31: icmp_seq=16 ttl=64 time=0.052 ms

— 192.168.100.31 ping statistics —
107 packets transmitted, 107 received, 0% packet loss, time 106053ms
rtt min/avg/max/mdev = 0.030/0.090/0.469/0.083 ms

Zero packets lost and no massive spikes in latency.  Failing to set the MAC to be static can cause issues where the VM appears to go offline.  There is an example of this on the MS support site (KB976724).  In this scenario, SLES 10 SP2 live migrates, changes MAC address on the new host and then loses it’s IP configuration.  This is because the Linux distro binds the IP configuration to the MAC address.

By the way, there’s usually no reason to configure this setting for Windows guests.

Technorati Tags: ,,,

Setting Up Public Key Based SSH Access To SLES

I needed to set up key based, rather than password based, access to SUSE Linux Enterprise Server.  It’s more secure because it uses a public/private key pair rather than a password.  The user’s private key is stored on the client.  The private key for the user is stored on the Linux machines.  When they connect using an SSH client there is no need to enter a password.  You can optionally (and it’s recommended) store a passphrase with the private key so that it cannot be used without knowing the private key.

The solutions starts at the client.  I normally used Putty but I couldn’t get it to work properly with this type of solution.  Instead I turned to Poderosa.  Using it I create a public and private key pair.  From there I saved the public key in OpenSSH format and the private key.

Save the private key somewhere safe, e.g. a backed up location on your PC or on your home drive on a file server.  Make sure the location is secure.

Now you need to copy the text of the public key.  Note that it is a single line.  Log into the SLES machine and browse to your home directory.  For example:

  • For root browse to ~/.ssh
  • For any other user browse to /home/<username>/.ssh

Use a text editor (like vi) to create a file called authorized_keys in that home directory.  Copy the text from your private key and paste it into the file.  Save it.

You now need to enable SSH to allow logons using keys.  The configuration for SSH is stored in a text file: /etc/ssh/sshd_config.  Edit that and you’ll have a few entries to modify.  We’ll start by allowing public keys to be used for authentication.  This is done by setting PubkeyAuthentication to “yes”.  I had to remove the # (comment/remark) symbol from the start of the line.

PubkeyAuthentication yes

I restarted the SSH daemon or service by running rcsshd restart.  That’s required to load the new settings for authentication. 

I configured the SSH client to log in as my user to this server with my private copy of the key.  I started the connection and I was logged in without using a password.  It authenticated me using the private key (and the passphrase for the key if you set it).

Now it is possible to disable log via SSH on using passwords.  You’ll do this to force people to us their private key instead of a weaker password that could be subject to brute force attacks.

The first is to change PasswordAuthentication to have a value of “no”.  You may need to remove the comment/remark symbol of # from the start of the line.  I also found that I had to set UsePam to a value of “no”.  That meant these two lines were in the file in different locations:

PasswordAuthentication no

UsePam no

Again I restarted SSH using rcsshd restart.  Now I tested two things:

  1. I tried to login using Putty and my username and password.  The initial connection failed.
  2. I logged in using my private key.  That worked.

Perfect.  Now I can use SSH to log into the Linux box without the worry of weak passwords being used by users on the machine.  They are forced into using stronger public/private key pairs.  And I can sleep safe knowing that the machine is not vulnerable to brute force password attacks.

Technorati Tags: ,

Choosing a Linux to Run on Hyper-V

Become a Hyper-V administrator and sooner or later someone wants you to run Linux.  Hyper-V has support to run is SUSE Linux Enterprise Server (SLES) 10 SP1, 10 SP2 or 11, x86 or x64 as well as RedHat 5.2, and 5.3 with no IC’s.  Performance is important to me so I want my VM’s to have Integration Components.  That limits me to SLES 10 and 11.

If you are running Hyper-V then management is probably important to you.  You’re probably running some components of Microsoft System Center, even Operations Manager 2007 R2.  OpsMgr 2007 R2 has cross platform extensions, i.e. the ability to monitor Linux and UNIX physical and virtual machines using Microsoft written agents and management packs (optionally supplemented by 3rd party management packs).

OpsMgr 2007 R2 supports the following non-Microsoft operating systems:

  • AIX 5.3 (Power), 6.1 (Power)
  • HP-UX 11iv2 (PA-RISC and IA64), and 11iv3 (PA-RISC and IA64)
  • Red Hat Enterprise Server 4 (x64 and x86) and 5 (x64 and x86)
  • Solaris 8 (SPARC), 9 (SPARC) and 10 (SPARC and x86 versions later than 120012-14)
  • SUSE Linux Enterprise Server 9 (x86) and 10 SP1 (x86 and x64)

If you draw a Venn diagram then you’ll see your options for an optimal solution are starting to dwindle … rapidly.  The common MS supported operating systems for Hyper-V and Operations Manager 2007 R2 are:

  • 10 SP1 (x86 and x64)

Maybe I should have said “is” instead of “are”.

So, if you are running Windows Server 2008 R2 Hyper-V and System Center Operations Manager 2007 R2, then I’d recommend that you choose SUSE Linux Enterprise Server 10 SP1 as your Linux of choice.  Yes, it is a bit old.  Hyper-V has kept up to date but OpsMgr has lagged behind a little.

EDIT #1

Microsoft added support for running RHEL with integration components with the version 2 release of the IC’s for Hyper-V.

Installing Linux Integration Components on W2008 R2 Hyper-V VM’s

Microsoft has a set of version 2 Linux integration components for SUSE Enterprise Linux 10 and 11 virtual machines.  They support x86 and x64 architectures.

The download contains two files:

  • An ISO file containing the additions.  If you use VMM then go ahead and stick that in your library or libraries.
  • A PDF containing all the step-by-steps for installing the IC’s.

I’m not going to bother copying the steps from the PDF.  It’s a well written and clear document.  You can read as well from it as you can from here.

A few things to note:

  • After I’ve installed the IC’s I can no longer mount /dev/cdrom.  Instead I have to mount /dev/hdc.  That took me (a Windows admin) an hour to figure out.
  • If you installed a synthetic network card (not the legacy one) then it won’t be available until after you’ve installed the IC’s.  Then you need to run yast2 lan to configure the card and the IP set up.
  • SLES 10 is very quick and easy.  SLES 11 requires a few extra steps before and after the instructions for SLES 10.
  • You won’t be booting up from the XEN kernel anymore so there’s no need to install it.
  • You cannot do hot add/remove of storage with the SCSI controller like you can with Windows VM’s.
  • Jumbo frames and TCP offload for Linux VM’s is not supported.
  • The following Integration Services are not available to you: Operating System Shutdown, Time Synchronization, Data Exchange, Heartbeat, Volume Snapshot Backup.  I really miss that shutdown one.
  • There is support from MS for these IC’s on the supported SUSE platforms via email.

MOST IMPORTANTLY OF ALL

If there is any chance at all that you will migrate this VM in any way (live migration, offline migration, quick migration) then set the VM to have a static MAC or Ethernet address.  This is very easy in VMM; it’s just a tick box in the network card properties.  If you don’t then you will have network issues with the VM after migration.  MS states that “certain versions of Linux” are affected.  I’ve seen some people report the issue as well on Hyper-V clusters.  Just tick that box and you’re safe.

You cannot install the IC’s from VMM.  That’s a pity.  I’ve love to see that feature.  I know the IC’s are making their way into the kernels of new Linux distros but what about future upgrades?  Don’t bother telling Linux admins to upgrade their servers.  I can’t ever remember hearing of a Linux admin I’ve worked with ever doing an upgrade.

Can You P2V Linux?

Eek!  What a scary thought.  I was asked tonight if this was possible.  Not with VMM and not with VMware’s tools AFAIK.  I had no idea.  I did some searching.  Apparently PlateSpin can do it with PowerConvert.  There’s a messy solution for cloning Linux machines.  This process will probably get easier when the Linux distros are available with the Hyper-V integration components installed.  But most P2V operations will likely be on older distros so things won’t be easy. 

I’m not touching this one with a barge pole 🙂