This blog contains experience gained over the years of implementing (and de-implementing) large scale IT applications/software.

Recovery From: Operation start is not allowed on VM since the VM is generalized – Linux

Scenario: In Azure you had a Linux virtual machine.  In the Azure portal you clicked the “Capture” button in the Portal view of your Linux virtual machine, now you are unable to start the virtual machine as you get the Azure error: “Operation ‘start’ is not allowed on VM ‘abcd’ since the VM is generalized.“.

What this error/information prompt is telling you, is that the “Capture” button actually creates a generic image of your virtual machine, which means it is effectively a template that can be used to create a new VM.
Because the process that is applied to your original VM modifies it in such a way, it is now unable to boot up normally.  The process is called “sysprep”.

Can you recover your original VM?  no.  It’s not possible to recover it properly using the Azure Portal capabilities.  You could do it if you downloaded the disk image, but there’s no need.
Plus, there is no telling what changes have been made to the O/S that might affect your applications that have been installed.

It’s possible for you to create a new VM from your captured image, or even to use your old VM’s O/S disk to create a new VM.
However, both of the above mean you will have a new VM.  Like I said, who knows what changes could have been introduced from the sysprep process.  Maybe it’s better to rebuild…

Because the disk files are still present you can rescue your data and look at the original O/S disk files.
Here’s how I did it.

I’m starting from the point of holding my head in my hands after clicking “Capture“!
The next steps I took were:

– Delete your original VM (just the VM).  The disk files will remain, but at least you can create a new VM of the same name (I liked the original name).

– Create a new Linux VM, same as you did for the one you’ve just lost.
Use the same install image if possible.

– Within the properties of your new VM, go to the “Disks” area.

– Click to add a new data disk.
We will then be able to attach the existing O/S disk to the virtual machine (you will need to find itin the list).
You can add other data disks from the old VM if you need to.

Once your disks are attached to your new Linux VM, you just need to mount them up.
For my specific scenario, I could see that the root partition “/” on my new Linux VM, was of type “ext4” (check the output of ‘df -h’ command).
This means that my old VM’s root partition format would have also been ext4.
Therefore I just needed to find and mount the new disk in the O/S of my new VM.

As root on the new Linux VM find the last disk device added:

# ls -ltr /dev/sd*

The last line is your old VM disk.  Mine was device /dev/sdc and specifically, I needed partition 2 (the whole disk), so I would choose /dev/sdc2.

Mount the disk:

# mkdir /old_vm
# mount -t ext4 /dev/sdc2 /old_vm

I could then access the disk and copy any required files/settings:

# cd /old_vm

Once completed, I unmounted the old O/S disk in the new Linux VM:

# umount /old_vm

Then, back in the Azure Portal in the disks area of the new VM (in Edit mode), I detatched the old disk:

 

Once those disks are not owned by a VM anymore (you can see in the properties for the specific disk), then it’s safe to delete them.

When SLES for SAP is not SLES for SAP

I recently downloaded and installed “SUSE Enterprise Linux for SAP 12 SP3” into a local virtual machine.
It seemed to contain everything that I thought it would contain with regards to included SAP Linux packages.

Noteable were the following in my local VM:

# which saptune
/usr/sbin/saptune
# rpm -qa | grep sap
cyrus-sasl-gssapi-32bit-2.1.26-7.1.x86_64
sap-netscape-link-0.1-1.2.noarch
sap-installation-wizard-3.1.81-3.1.x86_64
yast2-sap-scp-1.0.3-11.2.noarch
saptune-1.1.3-1.1.x86_64
saprouter-systemd-0.2-1.1.noarch
cyrus-sasl-gssapi-2.1.26-7.1.x86_64
patterns-sles-sap_server-12-77.8.x86_64
patterns-sles-sap_server-32bit-12-77.8.x86_64
yast2-saptune-1.2-1.5.noarch
sap-locale-32bit-1.0-92.4.x86_64
sapconf-4.1.8-1.18.noarch
sap-locale-1.0-92.4.x86_64
yast2-sap-scp-prodlist-1.0.2-4.2.noarch
# cat /etc/os-release
NAME=”SLES”
VERSION=”12-SP3″
VERSION_ID=”12.3″
PRETTY_NAME=”SUSE Linux Enterprise Server 12 SP3″
ID=”sles”
ANSI_COLOR=”0;32″
CPE_NAME=”cpe:/o:suse:sles_sap:12:sp3″
# uname -a
Linux hana01 4.4.73-7-default #1 SMP Fri Jul 21 13:26:40 UTC 2017 (6beeafd) x86_64 x86_64 x86_64 GNU/Linux

All looks good to me.

I then created an Azure hosted virtual machine using the image “SLES for SAP 12 SP3 (BYOS)”:

 

The Azure VM seems to be missing a lot of the packages that I would expect to be in place:

# which saptune
which: no saptune in (/sbin:/usr/sbin:/usr/local/sbin:/root/bin:/usr/local/bin:/usr/bin:/bin:/usr/games:/usr/lib/mit/bin)
# rpm -qa | grep sap
patterns-sles-sap_server-12-77.8.x86_64
yast2-sap-scp-prodlist-1.0.2-4.2.noarch
yast2-sap-scp-1.0.3-11.2.noarch
cyrus-sasl-gssapi-2.1.26-7.1.x86_64
sapconf-4.1.10-40.37.1.noarch
# cat /etc/os-release
NAME=”SLES”
VERSION=”12-SP3″
VERSION_ID=”12.3″
PRETTY_NAME=”SUSE Linux Enterprise Server 12 SP3″
ID=”sles”
ANSI_COLOR=”0;32″
CPE_NAME=”cpe:/o:suse:sles_sap:12:sp3″
# uname -a
Linux hana01 4.4.82-6.3-default #1 SMP Mon Aug 14 14:14:02 UTC 2017 (4c72484) x86_64 x86_64 x86_64 GNU/Linux

Notice also that the Kernel release is slightly newer on the Azure image, plus the version of the sapconf package is slightly newer.
The most important point is that the Azure image is missing the saptune package.
This is important as it is a method presented in numerous SAP notes for automatically applying the recommended O/S settings (that’s right, they don’t all get applied out-of-the-box).

Downloading SAP Download Basket Contents in the Cloud on Linux

Scenario: You’ve made the move to the cloud.  You are about to install some SAP software on a new Linux server hosted in the cloud and you just need to get the installation media uploaded.
Except, you don’t want to have to start X-Windows or setup a specific Windows server just to do this.

You have two options to achieve this, you can either:
Upload the files from your local network using SFTP or SCP (maybe you have ExpressRoute or DirectConnect) and have a fast connection.

or

Why not just download them straight from your SAP download basket into the target server.
What’s the difference between the two?  Well, it depends on whether you’ve already got access to the installation media locally, or if you are intending to first download it locally from SAP, then upload it to your cloud hosted server.
This doesn’t make sense to download then re-upload to the cloud.
Therefore, here’s how you can download straight from your SAP download basket.

What you will need:
– A web browser on your local PC.
– A valid SAP S-user account.
– Disk space on a cloud hosted Linux server (I’m going to show you the Linux way).
– The cloud hosted server will need internet access.

Setup Download Basket:
Before we start downloading, you need to cleanup your download basket.
Go to https://launchpad.support.sap.com/#/downloadbasket
Remove everything already in there that is not the items you want to download to the cloud hosted server.
The reason we must do this is because it’s difficult to know which items relate to which files in the download basket (you’ll see in a moment).
Now you can add the specific items you wish to download, into your download basket.
I’ve got two items:

Export Download Basket:
In the download basket click the “Export Links to Text File” button:

This will generate a text document which you can open on your PC called myDownloadBasketFiles.txt.

Open the text file using notepad:

I have 2 lines for the two items in my download basket.  I don’t know which is which.  I can suppose they are in order, but I don’t really know for sure.
Take the first line and log onto your cloud hosted Linux server as your preferred user.
Ping the softwaredownload.sap.com server using the Linux utility wget to make sure you can see the server.

> wget https://softwaredownloads.sap.com

A successful ping will show a HTTP error 401 and “Authorization failed“:

We have confirmed that our cloud hosted Linux server can see the SAP download server.
Switch to your target download directory (somewhere with disk space):

> cd mydownloadsdirectory

We now call wget again and pass the first item to download:

> wget –http-user=”[your s-user]” –http-password=”[your password]” [the first url] –output-document=1file.SAR

Adjust the command line above to put in your S-user account name and password.
You should also change the last parameter to give your file a name.

We have to guess that it is a SAR file.  Once it’s downloaded you can always re-name and test the extraction using “SAPCAR -tvf thefile.SAR”.

The wget utility will save the file in the current directory.
Repeat the same command line, changing the URL and the output document file, for each of the remaining items in the notepad text file of your download basket.

As you can see, using wget will allow you to script the download process so that you could schedule an overnight download of software.