SuSE 12.1 VM on MS Hyper-v (2012 R2) hangs at the same time every night.


I have an ongoing issue where my Virtual Machines running OpenSUSE 12.1 hangs at the same time every night - regardless of what time the VM thinks it is. So, I think it is something to do with the host, but I am at a loss as to how to identify.

The symptoms are that the VM, at 23:30 every night, starts running at 24% CPU from 0%, the filesystems become read-only, and I have to “turn-off” the VM via the Hyper-V management console. I restart the VM and it is fine for another 24 hours.

I’ve tried turning off all integration services. I’ve turned off all update services in YaST. I don’t think that it is a SuSE problem in itself, but the problem seems to only be happening on SuSE VMs.

I have to continue using 12.1 for the time being as the application binaries cannot compile or run on later versions.

I’m running Hyper-V on Win server 2012 R2 Standard. I’ve tried reducing and increasing the RAM, reducing and increasing number of virtual CPUs, running on dynamically expanding or fixed size virtual hard drives. Still the problem persists.

Any help / advice will be greatly appreciated.



First we (and maybe you ) need some clarification.

In your title you mention : SuSE 12.1. In your post you mention: OpenSUSE 12.1

In real life there exist(ed) SUSE Linux Enterprise 12 Service Pack 1 and openSUSE 12.1.

Can you please try to find out what the real name and version of your operating system is?

When it is SUSE Linux Enterprise (SLES/SLED) you are in the incorrect place here. The correct forums are at : (same username/password as here).

When it is openSUSE 12.1, then it is very, very old and it may be that it is difficult for people to help you because they will not have it themselves running to see if they can re-create problems.

Apologies. It is OpenSUSE I am using.

Because of application binaires used and their complilation, I am pretty stuck with 12.1 at present.

Of course the “better” solution would be to update your app code, but once it’s been compiled it’s unlikely tied to the system it’s built. If the binary has no further dependencies, you should be able to transfer it to a current, supported system and “just run.”

The usual troubleshooting steps should be taken.

  1. Collect information.
    You’re skipping this step which is why your shotgun tries have little chance for success.
    If you believe the problem is in the HostOS, then you should start with inspecting the Windows System logs (Event Viewer).
    If you believe the problem is in the Guest, then you can parse the syslog which is the /var/log/messages file.
    For both of the above, if you believe your problem happens at exactly the same time each day, then inspect events starting about 15 minutes or so before that… Maybe some nightly maintenance is being run. So, for instance especially on Windows, if some kind of backup is being created, then files will need to be locked during the time the backup is being made.

  2. Consider Mitigation options.
    Based on the above, <now> you can formulate best practice to address the problem.

  3. Fix the problem
    Consider whether your chosen “fix” is risky, and whether you will need to undo. Prepare so you experience less pain later if your result is unsatisfactory and you need to try again.