ASL in Microsoft CentOs based (Openlogic) Instances

[jruix]

Hi,
is ASL and ASL Kernel fully compatible with Azure centos based Linux version?

[scott]

Does that environment normally need some kind of custom kernel?

[jruix]

Does that environment normally need some kind of custom kernel?

It needs some tools installed in your virtual machine in order to deal with Azure, but as far as I know you can use the standard kernels with the exceptions of some kernel versions where NUMA has to be disabled to work properly.

update: I've been running ASL kernel in Azure without any problem a part from some alerts that appear with high frequency, not sure if they have something to do with azure and the way it handles swap or hard disk:

"hostname kernel: ata1.00:failed command:FLUSH CACHE "

[scott]

Im just speculating here since I havent seen that kind of message before. I suspect that is trying to dump cached data to disk, and the virtualization above it is stopping it (throttling perhaps, or some other limits based on the VM).

Swap is a good possibility, or maybe log files.

[jruix]

Im just speculating here since I havent seen that kind of message before. I suspect that is trying to dump cached data to disk, and the virtualization above it is stopping it (throttling perhaps, or some other limits based on the VM).

Swap is a good possibility, or maybe log files.

Azure is not mounting Swap partitions by default, and after mounting the swap partition the errors were reduced a lot but still there I think they are produced when the system tries to FLUSH CACHE from the root partition device.

The error is not present if I don't use the ASL kernel, I think that it has to be some security rule that Azure tools are breaking some way.
I've pasted below the whole log entries related with it:
PPGE-prd-02 kernel: ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
Aug 13 13:26:47 hostname kernel: ata1.00: failed command: FLUSH CACHE
Aug 13 13:26:47 hostname kernel: ata1.00: cmd e7/00:00:00:00:00/00:00:00:00:00/a0 tag 0
Aug 13 13:26:47 hostname2 kernel: res 51/04:00:20:00:00/00:00:00:00:00/a0 Emask 0x1 (device error)
Aug 13 13:26:47 hostname kernel: ata1.00: status: { DRDY ERR }
Aug 13 13:26:47 hostname kernel: ata1.00: error: { ABRT }
Aug 13 13:26:47 hostname kernel: ata1.00: configured for PIO0
Aug 13 13:26:47 hostname kernel: ata1.01: configured for MWDMA2
Aug 13 13:26:47 hostname kernel: ata1: EH complete

[scott]

well Im not sure whats going on there, thats the kind of error message the hard drive would pass up to the kernel if it was failing. So it sounds like either a problem with the abstraction layer, or the hardware.

[jruix]

After some investigation from Microsoft, they've point us that the HyperV drivers used by ASL are outdated, I've compared the Storage driver version in the Linux distribution provided by Azure(Patched with the latest drivers) with the driver in the ASL Kernel:

*** Driver info in ASL Kernel ***
description: Microsoft Hyper-V virtual storage driver
version: 3.1
srcversion: 242A1C8C412058814C3C389
vermagic: 3.2.60-71.art.x86_64 SMP mod_unload modversions KERNEXEC_BTS UDEREF REFCOUNT GRSEC
parm: storvsc_ringbuffer_size:Ring buffer size (bytes) (int)

*** Driver info in Azures Linux distribution***
description: Microsoft Hyper-V virtual storage driver
version: 3.1
srcversion: A385CD40B1893EAFB73538C
vermagic: 2.6.32-431.17.1.el6.x86_64 SMP mod_unload modversions
parm: storvsc_ringbuffer_size:Ring buffer size (bytes) (int)

As you can see the version in equal in both cases, but Microsoft told us that it wasn't relevant as they are using this version number for the drivers for long time, so I guess the code to check here would be the "srcversion" what is indeed different but not sure how could I say if one is older than the other.

Do you think that would be possible to update those drivers to get fully compatibility with Azure?

[scott]

Oh where did you get that patch? If I can see that I might be able to determine if it is compatible with the 3.2 branch.

[jruix]

Oh where did you get that patch? If I can see that I might be able to determine if it is compatible with the 3.2 branch.

Hi, I didn't patch it, it's the kernel version of the Openlogic Centos based Linux from Azure gallery, sorry.

[jruix]

Just for the record, the issue was solved by atomic and the error message is not being showed any more.

Thanks