Suse 11 SP4 Migration Tips - Justin's IT Blog

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.

Create /etc/sysconfig/network/ifcfg-eth1

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.

0 Shares