VMware Cloud Community
Mizzou_RobMan
Contributor
Contributor

Does anyone else notice after patching a red hat vm, there are errors?

from our linux admin after patching we have noticed, vmware tools adds a couple of lines to the /etc/udev/rules.d/99-vmware-scsi-udev.rules file

that are for debian or ubuntu. We have to comment those out because the cause errors

  1. Debian systems

#ACTION=="add", SUBSYSTEMS=="scsi", ATTRS=="VMware " , ATTRS

  1. SuSE / Ubuntu systems
=="Virtual disk ", RUN+="/bin/sh -c 'echo 180 >/sys$DEVPATH/device/timeout'" #ACTION=="add", SUBSYSTEMS=="scsi", ATTRS=="VMware, " , ATTRS=="VMware Virtual S", RUN+="/bin/sh -c 'echo 180 >/sys$DEVPATH/device/timeout'"

In the past we have been told to ignore them that they do no harm and I would agree that there is no harm in the errors that show up, we just don't want to see them since errors are scrutinized.

0 Kudos
2 Replies
RParker
Immortal
Immortal

we just don't want to see them since errors are scrutinized.

By whom, and how would they see them? VUM is not normally wide open, so who would see them?

I have found that Redhat and Windows are better served by their respective updates rather than VM ware. they work better, and easier to manage.

WSUS for Windows

Redhat Network for Redhat.

0 Kudos
alvserversuppor
Contributor
Contributor

In our case we are running Red Hat 5 and commented out Debian/Suse to eliminate the new ATTR error messages that show up during bootup, but we then discovered that the correct SCSI timeout is not set.

Use this command to verify (top one works in Red Hat 4):
for a in /sys/class/scsi_device/*/device/timeout; do echo -n "$a "; cat "$a" ; done;
or
for a in /sys/class/scsi_generic/*/device/timeout; do echo -n "$a "; cat "$a" ; done;
You should see results of 180

I was able to change the Red Hat line in 99-vmware-scsi-udev.rules to be:
# Redhat systems
ACTION=="add", BUS=="scsi", SYSFS{vendor}=="VMware" , SYSFS{model}=="Virtual disk",   RUN+="/bin/sh -c 'echo 180 >/sys$DEVPATH/device/timeout'"
No trailing spaces allowed for vendor or model and it is case sensitive.
And now it works for us with Debian/Suse commented out. Your mileage may vary, always reboot and test.

Apparently, even if you are running Red Hat and didn't touch the /etc/udev/rules.d/99-vmware-scsi-udev.rules file, that 180 would get set properly through

one of the other rules still matching somehow. This problem only effects those of us that commented out the other lines to eliminate that boot screen error.

Yes, if you ignore the boot messages you are fine, but this is still a bug. VMware is pattern matching on Debian or Suse for a Red Hat machine, that is just wrong (poor coding/testing). Of course a future update of vmware-tools will probably overwrite my changes to 99-vmware-scsi-udev.rules so I need to monitor that and also ask them to fix their script.

0 Kudos