suse Leap 43.2 - kernel panic on Hyper-V host

ivugrinec · December 11, 2017, 9:16am

I have an issue with Suse LEAP 42.3
Linux vanessa 4.4.76-1-default #1 SMP Fri Jul 14 08:48:13 UTC 2017 (9a2885c) x86_64 x86_64 x86_64 GNU/Linux


openSUSE 42.3 (x86_64)
VERSION = 42.3
CODENAME = Malachite

Vanessa is a VM under Hyper-V server 2012 R2. I have an issue with VM. It hangs from time to time with kernel panic. Last time happend 7 days ago.
I’ve tried to detect the reason and it looks like it happens when trying to backup the VM from Hyper-V Host.

This are the last log lines before reboot.

vanessa:/pg_backup # journalctl | tail -n 800 |more
Dec 10 20:00:57 vanessa hv_vss_daemon[835]: Hyper-V VSS: Illegal op:2
Dec 10 20:02:35 vanessa hv_vss_daemon[835]: Hyper-V VSS: Illegal op:2
Dec 10 20:02:39 vanessa hv_vss_daemon[835]: Hyper-V VSS: Illegal op:2
Dec 10 20:15:01 vanessa cron[21178]: pam_unix(crond:session): session opened for user root by (uid=0)
Dec 10 20:15:01 vanessa systemd[1]: Started Session 19 of user root.
Dec 10 20:15:01 vanessa CRON[21178]: pam_unix(crond:session): session closed for user root
Dec 10 20:17:55 vanessa hv_vss_daemon[835]: Hyper-V VSS: Illegal op:2
Dec 10 20:18:01 vanessa hv_vss_daemon[835]: Hyper-V VSS: Illegal op:2
Dec 10 20:20:20 vanessa hv_vss_daemon[835]: Hyper-V VSS: Illegal op:2
Dec 10 20:20:24 vanessa hv_vss_daemon[835]: Hyper-V VSS: Illegal op:2
Dec 10 20:23:49 vanessa hv_vss_daemon[835]: Hyper-V VSS: Illegal op:2
Dec 10 20:23:53 vanessa hv_vss_daemon[835]: Hyper-V VSS: Illegal op:2
Dec 10 20:23:55 vanessa hv_vss_daemon[835]: Hyper-V VSS: Illegal op:2
Dec 10 20:23:58 vanessa hv_vss_daemon[835]: Hyper-V VSS: Illegal op:2
Dec 10 20:23:59 vanessa hv_vss_daemon[835]: Hyper-V VSS: VSS: op=FREEZE: succeeded
Dec 10 20:23:59 vanessa kernel: sd 2:0:0:0: [storvsc] Sense Key : Unit Attention [current]
Dec 10 20:23:59 vanessa kernel: sd 2:0:0:0: [storvsc] Add. Sense: Changed operating definition
Dec 10 20:23:59 vanessa kernel: sd 2:0:0:0: Warning! Received an indication that the operating parameters on this target have changed. The Linux SCSI layer does not automa
Dec 10 20:23:59 vanessa hv_vss_daemon[835]: Hyper-V VSS: VSS: op=THAW: succeeded
Dec 10 20:23:59 vanessa kernel: scsi 4:0:1:0: Direct-Access     Msft     Virtual Disk     1.0  PQ: 0 ANSI: 4
Dec 10 20:23:59 vanessa kernel: sd 4:0:1:0: Attached scsi generic sg3 type 0
Dec 10 20:23:59 vanessa kernel: scsi 4:0:1:1: Direct-Access     Msft     Virtual Disk     1.0  PQ: 0 ANSI: 4
Dec 10 20:23:59 vanessa kernel: sd 4:0:1:0: [sdc] 266338304 512-byte logical blocks: (136 GB/127 GiB)
Dec 10 20:23:59 vanessa kernel: sd 4:0:1:0: [sdc] 4096-byte physical blocks
Dec 10 20:23:59 vanessa kernel: sd 4:0:1:1: Attached scsi generic sg4 type 0
Dec 10 20:23:59 vanessa kernel: sd 4:0:1:0: [sdc] Write Protect is off
Dec 10 20:23:59 vanessa kernel: sd 4:0:1:0: [sdc] Mode Sense: 00 00 00 00
Dec 10 20:23:59 vanessa kernel: sd 4:0:1:0: [sdc] Asking for cache data failed
Dec 10 20:23:59 vanessa kernel: sd 4:0:1:1: [sdd] Sector size 0 reported, assuming 512.
Dec 10 20:23:59 vanessa kernel: sd 4:0:1:0: [sdc] Assuming drive cache: write through
Dec 10 20:23:59 vanessa kernel: sd 4:0:1:1: [sdd] 1 512-byte logical blocks: (512 B/512 B)
Dec 10 20:23:59 vanessa kernel: sd 4:0:1:1: [sdd] 0-byte physical blocks
Dec 10 20:23:59 vanessa kernel: sd 4:0:1:0: [sdc] Sector size 0 reported, assuming 512.
Dec 10 20:23:59 vanessa kernel: sd 4:0:1:1: [sdd] Write Protect is off
Dec 10 20:23:59 vanessa kernel: sd 4:0:1:1: [sdd] Mode Sense: 00 00 00 00
Dec 10 20:23:59 vanessa kernel: sd 4:0:1:1: [sdd] Asking for cache data failed
Dec 10 20:23:59 vanessa kernel: sd 4:0:1:1: [sdd] Assuming drive cache: write through
Dec 10 20:23:59 vanessa kernel: sd 4:0:1:0: [sdc] 1 512-byte logical blocks: (512 B/512 B)
Dec 10 20:23:59 vanessa kernel: sd 4:0:1:0: [sdc] 0-byte physical blocks
Dec 10 20:23:59 vanessa kernel: sd 4:0:1:1: [sdd] Sector size 0 reported, assuming 512.
Dec 10 20:23:59 vanessa kernel: sdc: detected capacity change from 136365211648 to 512
Dec 10 20:23:59 vanessa kernel: ldm_validate_partition_table(): Disk read failed.
Dec 10 20:23:59 vanessa kernel:  sdd: unable to read partition table
Dec 10 20:23:59 vanessa kernel: sdd: partition table beyond EOD, enabling native capacity
Dec 10 20:30:02 vanessa cron[22693]: pam_unix(crond:session): session opened for user root by (uid=0)
Dec 10 20:30:03 vanessa systemd[1]: Started Session 20 of user root.
Dec 10 20:30:04 vanessa CRON[22693]: pam_unix(crond:session): session closed for user root
-- Reboot --
vanessa:/pg_backup #
vanessa:/pg_backup #
vanessa:/pg_backup #
vanessa:/pg_backup # df
Filesystem     1K-blocks    Used Available Use% Mounted on
devtmpfs          495392       0    495392   0% /dev
tmpfs             501820       4    501816   1% /dev/shm
tmpfs             501820    1624    500196   1% /run
tmpfs             501820       0    501820   0% /sys/fs/cgroup
/dev/sda2      129138324 3296200 124775100   3% /
tmpfs             100364       0    100364   0% /run/user/0
/dev/sdb1      515929528  172068 489526728   1% /pg_backup
vanessa:/pg_backup # nano /dev/sd
sda   sda1  sda2  sdb   sdb1
vanessa:/pg_backup # nano /dev/sd
sda   sda1  sda2  sdb   sdb1
vanessa:/pg_backup # nano /dev/sd

Why do i see the /dev/sdd and /dev/sdc. I’dont even have this devices.

Any help? Any idea?

tsu2 · December 11, 2017, 4:52pm

VSS normally refers to Volume Shadow Copy.

I haven’t read Microsoft’s documentation related to whether VSS should be enabled on the volume where your machine images are stored, but in general and on Linux similar tools are disabled.

So,
It probably comes down to what your backup strategy and tools are.
Are you really using VSS to snapshot this volume?
And, are you storing your images on the same volume as your Windows folder?

By default,
VSS when enabled is configured similar to how Snapper is enabled on openSUSE… the volume where your operating system is protected, and anything else that happens to be on that Volume. On a Windows Desktop (not server), the User personal files are typically on the same valume, but on openSUSE is not (unless you configure your entire system as a single volume, similar to how Windows is set up).

Without someone suggesting a really good reason to use VSS (or Snapper) to snapshot your image storage volume, I’d recommend against it.
Instead, I’d recommend some combination or choice of the following

Regular, conventional backups within the machine and/or on the HostOS
Copying or cloning the virtual machines periodically.
Only rarely, using the virtualization technology’s own snapshotting, but only sparingly and for special occasions. Downside is this creates multiple disk images, which both increases the complexity of creating and restoring backups, and could also put extra pressure on disk I/O. Yes, I typically always opt to create single disk images although many virtualization technologies default to creating multiple 2GB disk files, which would could be required on 32-bit OS.

TSU