Suse 11 sp 4 to Azure
Suse 11 is pretty dated but it is still in production in many I.T. shops. I haven’t worked much with Suse in the past, I’m mainly a Debian/Ubuntu guy, but when I received a request to figure out how to get Suse 11 to Azure I figured it might be a good challenge.
It turns out it actually pretty simple once you have prepped a RedHat machine. Two basic problems exist on Suse just like Redhat: 1.) Drivers 2.) Network configuration.
This guide is much more basic, because again I’m not a Suse expert, and will focus on the bare minimum to get Suse migrated to Azure.
Step 0 – SSHD and Firewall Config
This is critical! Make sure that SSHd is enabled and that your firewall settings allow SSH traffic into the machine.
Step 1 – Install Kernel Sources
sudo zypper insatll kernel-source kernel-syms
Step 2 – Add Azure Drivers to the Kernel Ram Disk
We will need to edit /etc/sysconfig/kernel
Find the line that starts with INITRD_MODULES and add the following drivers to it.
hv_storvsc hv_netvsc hv_vmbus
The line should look something like this when your done.
INITRD_MODULES=”vmw_pvscsi hv_storvsc hv_netvsc hv_vmbus ata_piix ata_generic”
Step 3 – Create an ifcfg file for eth1
When you boot in Azure, the nic will register as eth1 and we will need a configuration file configured to receive its address via DHCP.
Add the following to it:
BOOTPROTO='dhcp' NAME='eth1' STARTMODE='auto' USERCONTROL='no'
Step 4 – Rebuild the Ram Disk
cd /boot sudo mkinitrd
Step 5 – Test Failover
Once these steps are complete wait for all the changes to sync over to Azure. Then do a failover test to confirm that the VM is reachable in Azure.
Step 6 – Future Considerations
This article is very barebones. Normally I would have included more steps that would enable more functionality, but I had issues getting Suse to reliably output kernel boot messages to both the console and the serial console. So I left that part out.
It would also be advisable to enable a login terminal from serial console ttyS0 as well. But again, this caused a lot of kernel messages while the VM was in VMware, so I chose to leave it out of the article.
Compared to the Microsoft How To guide, I also left out the part where they disable presistant network names. I did this so that we could keep our eth0 configuration in place with its static IP (most likely) and have things continue to work normally after a reboot in VMware… this is critical if you are just using Azure as a DR location.