Shutdownproblem, Eisfair mit VMware-Tools

[sambu]

Hi,

es wird mir Build 768111 angezeigt und somit müsste der Juli-Patch korrekt installiert sein, incl. dem Patch für das Shutdown-Problem.
Das Runterfahren funktioniert auch bei diversen Windows-Maschinen, doch nicht bei einer Linux-Maschine. Es wird angezeigt, dass die Tools laufen. Im Client wird bei "kürzlich bearbeitete Aufgaben" auch der Shutdownbefehl ausgeführt. Wie komme ich der Fehlerursache auf die Spur?

Gruß
Sambu

[McStarfighter]

Wie wäre es mal mit mehr Infos zum Linux, zu deiner vSphere-Umgebung, zu deinen anderen VMs und so?! Kristallkugeln haben in letzter Zeit so ne enorme Preissteigerung, kaum noch bezahlbar ...

[Dayworker]

Ein "vmware.log" der betreffenden VM bis zum Shutdown wäre wirklich nicht verkehrt.
Am einfachsten wäre es, wenn du dieses auf eigenem Webspace verlinken würdest. Anscheinend gibt es kaum noch Freehoster ohne Zwangsanmeldung zum Download...

[sambu]

Hi,

stimmt natürlich, sorry. Es geht um einen einzelnen ESXi5. Die nicht runterfahrenwollende VM ist ein Eisfair Linuxserver mit 2.6er Kernel. Im vSphere Client sind die Tools bei der VM als laufend und grün markiert.
Die Meldung spricht auch dafür, dass dort was ankommt, oder?
Muss ich nach Installation der Tools was von Hand anpassen?
Gruß
Sambu


In vmware-log steht:
2012-08-31T09:15:49.287Z| vmx| TOOLS sending 'OS_Halt' (state=1 callback=A22BDB0 clientData=AFA8E90) state change request
2012-08-31T09:15:49.287Z| vmx| Vix: [3541 vmxCommands.c:541]: VMAutomation_InitiatePowerOff. Tried to soft halt. Success = 1
2012-08-31T09:15:49.388Z| vcpu-0| TOOLS state change 1 returned status 0
2012-08-31T09:15:49.388Z| vcpu-0| Msg_Post: Error
2012-08-31T09:15:49.388Z| vcpu-0| [msg.tools.haltFailed] The request to Power off this virtual machine failed because the corresponding VMware Tools script did not run successfully. If you have configured a custom power-off script in this virtual machine, make sure that it contains no errors. Attempting the operation again will ignore the script failure. You can also submit a support request to report this issue.
2012-08-31T09:15:49.388Z| vcpu-0|
2012-08-31T09:15:49.388Z| vcpu-0| ----------------------------------------

[continuum]

Kannst du das script von Hand ausfuehren ?

[sambu]

nein, über Button Gast herunterfahren am vSphere Client
Gleiche Meldung kommt, wenns Ghetto Backup Skript probiert.

[Dayworker]

Was listet das Linux-Log an dieser Stelle?
Ich tippe mal auf ein Rechteproblem zum Shutdown.

[sambu]

Wo finde ich die?
Im Handbuch steht:
To obtain diagnostic information in Linux based operating systems:
Open this file using any text editor for editing
/etc/vmware-tools/tools.conf
Find the entries below:
log = true
log.file = /tmp/vmtools.log

Es gibt aber keine vmtools.log dort, auch keine /tmp/vmtools.log. Die Tools-Installation lief fehlerlos durch. Auch zeigt der vSphere Client ja an, dass die Tools korrekt laufen. Zusatzfrage: "Tools beim Aus- und erneuten Einschalten prüfen und aktualisieren" aktivieren?

Danke für Deine Hilfe!
Gruß
Alex

[Dayworker]

Ich hab keine Ahnung, wo Eisfair sein System-Log hinschreibt.
Vermutlich aber nach "/var/log".

[sambu]

hab mal in /etc/vmware-tools/ eine tools.conf angelegt. finde allerdings kein Log. Auch nicht in /var/log, wo die anderen Logfiles stecken.

Rechteproblem? Welche datei wird da angestoßen? Soll ich der mal testweise 777 geben?

[Dayworker]

Also der Shutdown meines Ubuntu11.10-Rechners gelingt ohne Anpassung nur als "root" und den gibt es bei vielen Distros nicht mehr.
Stattdessen wird meist einfach "su" oder "sudo" davor geschrieben.

Welches Log-File du durchsuchen mußt, kann ich dir aufgrund fehlender Kenntnis von Eisfair nicht sagen.
Ich würds aber mit "syslog" und "auth.log" oder "messages" probieren.

[sambu]

wenn ich händisch versuche:
cd /etc/vmware-tools
/bin/sh power-vm-default
erhalte ich:
- Executing poweroff-vm-default
- Executing ./scripts/vmware/network
- network: Cannot find system networking script

Das Script network enthält:
#!/bin/sh
# network (Linux)
# Using a combination of a system networking script, ifconfig, and ifup,
# attempt to release and renew DHCP leases upon receipt of suspend and resume
# events, respectively.
echo `date` ": Executing '$0'"
echo
. `dirname "$0"`/../../statechange.subr
# find_networking_script --
# Searches common Linux distro init/rc paths to find a singular network
# services script.
# Result:
# Returns a valid networking script path on success or "error" on failure.
# Side effects:
# None.
find_networking_script() {
local script="error"
for dir in "/etc/init.d" "/sbin/init.d" "/etc" "/etc/rc.d" ; do
if [ -d "$dir/rc0.d" ] &&
[ -d "$dir/rc1.d" ] &&
[ -d "$dir/rc2.d" ] &&
[ -d "$dir/rc3.d" ] &&
[ -d "$dir/rc4.d" ] &&
[ -d "$dir/rc5.d" ] &&
[ -d "$dir/rc6.d" ]; then
# Now find the appropriate networking script.
if [ -d "$dir/init.d" ]; then
if [ -x "$dir/init.d/network" ]; then
script="$dir/init.d/network"
elif [ -x "$dir/init.d/networking" ]; then
script="$dir/init.d/networking"
fi
else
if [ -x "$dir/network" ]; then
script="$dir/network"
elif [ -x "$dir/networking" ]; then
script="$dir/networking"
fi
fi
fi
done

echo "$script"
}
# save_active_NIC_list --
# Records a list of every active NIC to /var/run/vmware-active-nics.
# XXX What's the story on aliases? Should they still be included, or will
# they be recreated automatically upon resume?
# Results:
# $activeList has, one per line, a list of all active NICs.
# Side effects:
# None.
save_active_NIC_list() {
>$activeList
for nic in `ifconfig | awk '/^eth/ { print $1 }'`; do
ifconfig $nic | egrep -q '\bUP\b' && echo $nic >> $activeList
exitCode=`expr $exitCode \| $?`
done
}

# rescue_NIC --
# For each NIC recorded in $activeList that is not currently "up", run
# "ifup $nic".
# Results:
# All downed NICs should be active.

rescue_NIC() {
if [ -f "$activeList" ]; then
while read nic; do
if ifconfig $nic | egrep -q '\bUP\b'; then
echo `date` "[rescue_nic] $nic is already active."
else
echo `date` "[rescue_nic] activating $nic ..."

ifup $nic
exitCode=`expr $exitCode \| $?`
fi
done < $activeList

rm -f $activeList
fi
}
# TranquilizeNetworkManager --
# Put the NetworkManager daemon to sleep (maybe).
# See http://projects.gnome.org/NetworkManage ... /spec.html .
# Results:
# Sleep(true) request is sent to the NetworkManager D-Bus interface.
#
TranquilizeNetworkManager() {
# `which' may be a bit noisy, so we'll shush it.
dbusSend=`which dbus-send 2>/dev/null`
if [ $? -eq 0 ]; then
# NetworkManager 0.6
$dbusSend --system --dest=org.freedesktop.NetworkManager \
/org/freedesktop/NetworkManager \
org.freedesktop.NetworkManager.sleep
# NetworkManager 0.7.0
$dbusSend --system --dest=org.freedesktop.NetworkManager \
/org/freedesktop/NetworkManager \
org.freedesktop.NetworkManager.Sleep boolean:true
fi
}
# WakeNetworkManager --
# Wake the NetworkManager daemon (maybe).
# See http://projects.gnome.org/NetworkManage ... /spec.html .
# Results:
# Sleep(false)request is sent to the NetworkManager D-Bus interface.
WakeNetworkManager() {
# `which' may be a bit noisy, so we'll shush it.
dbusSend=`which dbus-send 2>/dev/null`
if [ $? -eq 0 ]; then
# NetworkManager 0.6
$dbusSend --system --dest=org.freedesktop.NetworkManager \
/org/freedesktop/NetworkManager \
org.freedesktop.NetworkManager.wake
# NetworkManager 0.7.0
$dbusSend --system --dest=org.freedesktop.NetworkManager \
/org/freedesktop/NetworkManager \
org.freedesktop.NetworkManager.Sleep boolean:false
fi
}
# main --
# Main entry point. Perform some sanity checking, then map state change
# events to relevant networking operations.
# Results:
# See comment at top of file.
main() {
exitCode=0
activeList=/var/run/vmware-active-nics

networkScript=`find_networking_script`
[ "$networkScript" != "error" ] || Panic "Cannot find system networking script."

# XXX Are these really necessary? If so, we should have seen customer
# complaints by now.
which ifup >/dev/null 2>&1 || Panic "ifup not in search path."
which ifconfig >/dev/null 2>&1 || Panic "ifconfig not in search path."

case "$1" in
poweron-vm)
rm -f $activeList
;;
suspend-vm)
save_active_NIC_list
"$networkScript" stop
TranquilizeNetworkManager
;;
resume-vm)
# According to hfu, "/etc/init.d/networking restart" on Debian 5.0
# may bring down ethernet interfaces tagged as "allow-hotplug" without
# bringing them back up.
#
# This is especially a problem when reverting to a live, running
# VM snapshot where an active NIC list hadn't yet been generated,
# resulting in sudden loss of an otherwise operational NIC.
#
# So, if the active list doesn't exist, assume we're coming back to
# a live snapshot and capture the current active list now for
# rescue later.
if [ ! -s $activeList ]; then
save_active_NIC_list
fi
WakeNetworkManager
# XXX Do we really want restart or is start sufficient? Like, would
# using start avoid the problem mentioned above?
"$networkScript" restart
rescue_NIC
;;
*) ;;
esac

return $exitCode
}

main "$@"
-------------------------------

hoffe ich bekomme jetzt keine Haue, weil ich so ein langes Skript poste....sorry, aber ich komme nicht weiter
Freue mich über Hilfe!

Viele Grüße
Sambu

[Dayworker]

Über welches Script verwaltet den Eisfair sein Netzwerk?

[sambu]

Hi,

ich war in der Newsgroup auf der Suche nach Antwort darauf.
/etc/init.d/ip-eth
Verschiedene Vorschläge hab ich bekommen:
Link nach /etc/init.d/network
oder Datei network anlegen mit:
halt

vmware-tools suchen nach dem Skript und starten dieses, um das Netzwerk herunterzufahren?

Gruß
Alex

[sambu]

Hi,
ist jetzt zwar ne Weile her, aber vielleicht ists noch für andere wichtig und interessant.

Das Eisfair-Skript /etc/init.d/halt habe ich nach /etc/vmware-Tools/ kopiert und dort (nach Wegsichern des Originals) poweroff-vm-default benannt. Rechte angepasst und fertig.


Viele Grüße
Sambu