Ok, so I got the task to install the Linux Integration Service for Hyper-V R2 on a RedHat Enterprise Server 5. Something that turned out to be a bit more to handle than I would have thought. So here’s a little How-To.
Preparations
Read the documentation provided in the Linux Integration Services download. Much of the information in this article is in there, but some parts are not. Otherwise I would not have bothered writing about it. 
I’m not going to go through the OS installation process here, but make sure to select the “Software Development” packages since you will be needing it. In case you missed it, you can install them later by running these commands.
# yum groupinstall "Development Tools"
# yum install kernel-headers
I’m not actually sure that you need to run the kernel-headers install manually or if it’s included in the “Development Tools” package.
The first gotcha i ran into was the fact that the link to the Linux Integration Services–previously known as Linux Integration Components or LinuxIC–on RedHat’s information pages gave me a 404 and a redirect to a bing-search that returned the exact same 404. The page have simply been removed by Microsoft without any form of redirection to the new page. Anyway, a search on http://download.microsoft.com for “Linux Integration Components” do return the new page, and that’s where I learned about the new name.
Thank you for making it easy for us Microsoft!
Here’s a direct link to the search on the current name: http://www.microsoft.com/downloads/en/results.aspx?freetext=linux+integration+services&displaylang=en&stype=s_basic
And here’s a direct link to the actual download page: http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=eee39325-898b-4522-9b4c-f4b5b9b64551
This download contains an ISO file that you can mount using the Hyper-V- or VMM-console, or you can do as I did and download the ISO to the virtual machine, mount it locally, copy the files and unmount it. Like this.
# mkdir /mnt/ISO
# mount -o loop /root/LinuxIC\ v21.iso /mnt/ISO
# mkdir /opt/linux_ic_v21_rtm
# cp /mnt/ISO/* -R /opt/linux_ic_v21_rtm/
# umount /mnt/ISO
You probably have to be root to do this by the way.
With that done, let’s get to the installation.
Installation
As root, do the following:
# export PATH=$PATH:/sbin
# cd /opt/linux_ic_v21_rtm/
# make
# make install
# reboot
Why the export PATH command? Apparently, on RHES5, /sbin is not in the PATH by default and this is something that the make scripts are completely unaware of. The “make install” will try to run “depmod” which will fail since it’s not in the default path. You could also add “PATH=$PATH/sbin” to the root users ~/.bashrc which will put it back in the PATH but only for the root user, but I don’t know if that’s recommended.
And, yes. You DO have to reboot after the install.
If you are running RHES5 64bit you also have to install the “adjtimex” package. It is in the RHN repository but also on the RHES5 Installation CD in case you have no internet connection. Install it with yum like this:
# yum install adjtimex
And from the CD (mount it first) like this:
# rpm –ivh /mnt/cdrom/Server/adjtimex-1.20-2.1.x86_64.rpm
And that’s basically it for the installation.
Verification
How do you know that the driver are installed?
After the reboot, try running “modinfo vmbus” which should return something like this:
# modinfo vmbus
filename: /lib/modules/2.6.18-194.11.1.el5/kernel/drivers/vmbus/vmbus.ko
version: 2.1.25
license: GPL
srcversion: 3C1899C419665CB2514F2D0
depends:
vermagic: 2.6.18-194.11.1.el5 SMP mod_unload gcc-4.1
parm: vmbus_irq:int
parm: vmbus_loglevel:int
Try that with netvsc, storvsc and blkvsc too (replace the vmbus part) and you should get something similar. If you don’t, the installation did not succeed.
The documentation also tells us to check that the components are running with “/sbin/lsmod | grep vsc” which should return:
# /sbin/lsmod | grep vsc
blkvsc 70184 3
storvsc 64264 0
netvsc 73504 0
vmbus 88304 3 blkvsc,storvsc,netvsc
scsi_mod 196953 6 scsi_dh,sg,blkvsc,storvsc,libata,sd_mod
The numbers will probably differ from installation to installation depending on blocksizes and allocation.
Configuration
Configuration is pretty straight-forward so I’ll keep this short.
When you install the drivers you will get a new network card called seth0, which I presume stands for Synthetic ETHernet. There’s nothing magic about it regarding configuration and “system-configuration-network” will work just fine.
The drivers will also give you a couple of SCSI-devices (if you have one attached) with the regular /dev/sd* naming. Simply configure these using fdisk or whatever GUI you might prefer.
There is also a note in the documentation about changing the grub configuration in the “Additional Information…” section. Do read that section.
Additional Comments
One thing I tend to do now that disk space is dirt cheap is to copy all ISO-files I use locally instead of mounting them when needed through Hyper-V. Simply because you can bet your insert-shorter-word-for-buttocks that the day you need it again, someone has been kind enough to have done som spring-cleaning or it’s locked by another machine in the cluster. If you have it locally and followed my instructions in the “Preparation” section, you will allready have a /mnt/ISO directory. Only thing you’ll have to do is
# mount -o loop /path/to/your.iso /mnt/ISO
And there you have it. Just remember to unmount it when you’re done.
I also almost never use the Hyper-V remote connection interface thingy since it will give you a GUI and the mouse just won’t work. If you haven’t configured a network card yet though, you could connect through Hyper-V and hit Ctrl+Alt+F1 to get a command prompt. Unfortunatly cut/paste don’t work here, but you could run system-configuration-network, assign an IP-address and then connect with an SSH client. I prefer PuTTY to a degree that I usually install the ported version on my Linux desktops aswell.
And I never logon using root. People should know this, but it should be stressed anyway. Always logon as regular user and su or sudo when needed. I can’t understand why RHES has root-login enabled by default in the SSH-server config.
Good luck!
Here’s a little trouble-shooting guide for discovering Linux systems from OpsMgr R2 when getting the following error from the wizard:
<stdout>Generating certificate with hostname="COMPUTERNAME"
[/home/serviceb/TfsCoreWrkSpcRedhat/source/code/tools/scx_ssl_config/scxsslcert.cpp:198]
Failed to allocate resource of type random data: Failed to get random data - not enough entropy
</stdout><stderr>error: %post(scx-1.0.4-248.i386) scriptlet failed, exit status 1
</stderr><returnCode>1</returnCode>
<DataItem type="Microsoft.SSH.SSHCommandData" time="2009-08-05T11:15:01.5800358-04:00" sourceHealthServiceId="0EB1D6DA-202C-7FC5-3D46-BDBB9208547D"><SSHCommandData><stdout>Generating certificate with hostname="COMPUTERNAME"
[/home/serviceb/TfsCoreWrkSpcRedhat/source/code/tools/scx_ssl_config/scxsslcert.cpp:198]
Failed to allocate resource of type random data: Failed to get random data - not enough entropy
</stdout><stderr>error: %post(scx-1.0.4-248.i386) scriptlet failed, exit status 1
</stderr><returnCode>1</returnCode></SSHCommandData></DataItem>
But first, a little background on the actual “problem”. To generate the certificate, the entropy needs to be high enough to generate random data for the certificate creation. Without the certificate, the OpsMgr agent won’t be able to open up communications with the MS. So, what creates this entropy we need? Bluntly put, a selection of hardware components that are likely to produce non-predictable data. Like a keyboard, mouse and a monitor or videocard. Of course, there’s a lot more to it, but we really don’t need to know this. What we need to know is that there has to be a “bit bucket” of more than 256bytes of entropy for the certificate creation process to succeed. We also need to know that more enterprise-ish servers, like rack- or blade-servers tend to be void of things like directly attached keyboards, mouses and monitors that the linux kernel needs to be able to generate entropy. And herein lies the problem. If you have a new server that is not in full service (likely since we are trying to deploy the monitoring on it) which means that there’s not much random data flowing through the hardware and there’s no keyboard or mouse or monitor connected to it there is quite the risk that the system entropy is going to be very low. Of the linux systems that I have been deploying OpsMgr agents to, about half have failed because of “Not enough entropy”. So, here’s the steps I usually takes to ensure that discovery works. I use PuTTY to connect to the soon-to-be-monitored servers. This guide also assumes that you have SU rights on the system since all of these steps (except #1) needs it.
- Check you current entropy
cat /proc/sys/kernel/random/entropy_avail
Is it less than, or close to, 256? It probably is. If you don’t feel like connecting a mouse and start wiggling it around—not really feasible in a data center—and see if the entropy increases, you can generate your own random data.
- Generate you own random data.
Be advised that this forced entropy will not be as random as the system-created on and thus not as secure. How much more insecure it is, I don’t know, and quite frankly I prefer to have my systems monitored yet slightly less secure than not monitored at all. Anyway, you can force your own random data by running:
dd if=/dev/urandom of=~/.rnd bs=1 count=1024
This creates a .rnd file with 1024B of random data that the certificate creation process will use instead of the system entropy if the file exists.
- Uninstall and re-discover
The first failed attempt of discovery will most likely leave a non-working agent installation that we have to remove. Otherwise we will just be stuck with an “Access Denied” error. Run:
rpm –e scx
Now, try to discover the system again.
- Failed again?
Try generating the certificate manually by running:
/opt/microsoft/scx/bin/tools/scxsslconfig -f –v
/opt/microsoft/scx/bin/tools/scxadmin –restart
Retry discovery again.
- Still fails?
Uninstall the agent once more as instructed in step 3.
Stese steps have solved my problems 100% on both SUSE and RedHat and hopefully they will help you too.
Interestingely enough, these problems seems to be connected to some changes in the 2.6 kernel and basically everything that uses SSL-ish certificates will be affected. Even though the symptoms may be a bit more subtle, like time-outs and disconnects. For “headless” servers like those I usually to administer where the random data tend to be much lower, there’s even specialised hardware whose sole purpose is to generate random data, like the Entropy Key. I have also been told that new servers is likely to be equipped with entropy chipsets to make sure that there’s chaos enough to avoid these new-found oddities.
Sources:
http://social.technet.microsoft.com/Forums/en-US/crossplatformsles/thread/f94ec905-23ac-4444-b9f8-644fec3ae357
http://www.askrenzo.com/oracle/SCOM/SCOM_discovering_nodes.html
Ok, so I reinstalled my linux partition with Ubuntu 9.04 x64 and decided to try EXT4 on the root partition. Like, yesterday.
Managed to get the Citrix client running (way more easy on Ubuntu than Fedora, I’ll be back on that) and all without too much fuzz.
First reboot gave me a “let’s FSCK!”. So I FSCK-ed and booted up to the desktop.
Second reboot gave me a “let’s FSCK!”. And I did. Booted to the desktop.
Third boot went smoothly, but all of a sudden all the icons decided to go AWOL. Rebooted again.
Fourth boot gave me a “let’s FSCK!”. I replied with “Well FSCK You!”
Fifth boot gave me a “let’s FSCK!”. I rebooted back to Windows 7.
Tonight I am reinstalling Ubuntu 9.04 x64 with EXT3.
Well, I wouldn’t really call this a fix and I don’t really know if I’ve got all facts for a decent how-too but this little manoeuvre helped me getting sound from the internal speakers on my Lenovo T61 in Fedora 11. Yah, that’s AMD64/x64 by the way.
I found out after a bit of googling that sound really is working, but only when using the head-phone jack. So i tried it out and much to my amusement it was true. This means that the sound-card has been discovered and enabled.
Anyway. Opening a terminal and running alsamixer -c0 will enable you to turn on the internal speakers.
In the mixer, step right until you get to “speaker” and you might find that it is muted by the MM above it. Press M and it will turn to 00. Now check your master volume and start enjoying the sound… i hope.
If this doesn’t work, you probably need to apply some patches and stuff found by… eh… google.
Good luck!
