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.

HowTo: Cancel Large Message Stuck in SAP PI/XI Queue

Scenario: You have a large message that is stuck in the INBOUND (XBTS*) queue of an integration server (maybe an ABAP proxy).
(This solution is based on SAP note 688147).

The message is visible in transaction SMQ2 (inbound queue) for a few hours/days/months:

and it’s consuming significant resources, visible in SM50:

You may also be blowing the ICM http buffer, visible in the SMICM log file:

But, you can’t cancel the message in SXMB_MONI, as it is still scheduled on the QUEUE (“still scheduled in queue XBTS*”):

SAP notes state that you should NEVER delete messages directly from SMQ1 or SMQ2 as this leaves the messaging system in an inconsistent state.

What to do? What to do?

Instead, in this exceptional case, you can delete the message in SMQ2. This will prevent it retrying.
Once you’ve done this, you can then use report RSXMB_CHECK_MSG_QUEUE to restore the messaging system integrity by resetting the original message status to cancel it.

Delete the entry from the queue:

Now execute the report RSXMB_CHECK_MSG_QUEUE:

Ensure that you enter the specific message ID, then enter the PIPELINE ID (same as that shown in column PIPELINE in SXMB_MONI), select all status to search for and then select TEST RUN:

The log should show that it will flag 1 message for archiving (“No QRFC entry found. Message flagged for archiving”):

Now go back and re-execute the program with “Test Run” un-checked:

You will be prompted to cancel selected messages:

The log will show:

SXMB_MONI now shows the message is “Cancelled Manually”: