Sorry for the rudimentary question, but what are the contents of my Kxx file supposed to be to stop a VM under v6b3? Is it by replacing "vmware" with the "DomID" or the "hostname" in the following?

 

[ -x /etc/rc.d/init.d/vmware  ] && /etc/rc.d/init.d/vmware stop

 

Thanks.

Sorry for the rudimentary question, but what are the contents of my Kxx file supposed to be to stop a VM under v6b3? Is it by replacing "vmware" with the "DomID" or the "hostname" in the following?

 

[ -x /etc/rc.d/init.d/vmware  ] && /etc/rc.d/init.d/vmware stop

 

Thanks.

 

xl shutdown -a -w

@dlandon, great job, thanks for the script. I discovered, that this is a very nice way to start and stop all VM's and the entire system in one single step. I saw the stop script for unRAID/XEN, so I just wanted to know if it's really that easy to define a start script:

 

S00:

xl create /mnt/cache/.VMs/ArchVM/arch.cfg 

 

S01

xl create /mnt/cache/.VMs/Debian/debcloud.cfg

 

Is anyone using it for a Windows VM as well? My experience is that it is shutting down only from Windows and not via xl shutdown windows

Is anyone using it for a Windows VM as well? My experience is that it is shutting down only from Windows and not via xl shutdown windows

 

if you install gplpv drivers in your windows vm you can then run the following to allow xl shutdown to work:-

 

run

"C:\Program Files\Xen PV Drivers\ShutdownMon.exe -i"

 

this will install shutdownmon as a service (in a command prompt if you want to get feedback that it succeeds).

 

hope this helps 

 

Of course 

 

Thanks a lot. The gplpv drivers are installed but I missed this piece of information.

it was a post from somebody else that i noted down a while ago, this is untested by myself (waiting for b4) but it looks like it should work, please let me know if it does work as i will also be requiring this 

Excellent !! Here is the link you might have the information from: http://wiki.xen.org/wiki/Xen_Windows_GplPv/Installing

 

Only a minor amendment of the command:

c:\program files\xen pv drivers\bin\shutdownmon.exe -i

 

Windows need to be rebooted - afterwards you can shut it down like any other (LINUX) VM.

 

The same command with -u (instead of -i) is uninstalling the service.

Thanks @dlandon

 

 

Sent from my iPhone using Tapatalk

Great thanks for confirming it works EdgarWallace

this works for shutting down machines with XEN servers running   at least in initial testing.

I was using the script on my second server after the great experience on my other unRAID machine (this is the server in my signature).

 

This server is always coming up with a parity check...I must have overlooked something. Syslog is attached, maybe someone can see that the issue is.

FAT-fs (sda1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.

Looks like it didn't shut down correctly. Let the parity check finish if its still running.

Then use POWERDOWN or stop cleanly through the webGUI.

Then remove the flash, put it in your PC and

Then Run chkdsk on your flash drive. (run Disk Utility on a Mac) 

 

That should fix the flash drive's flag which wasn't cleared by a previous bad shutdown.

 

 

Got DaleWilliams, so a corrupt flash drive can couse issues with the powerdown script? My issue is, that I will run another unclean powerdown after the actual parity check. Powerdown was working well until I installed the new powerdown script 2.06.

 

 

Sent from my iPad using Tapatalk

I was using the script on my second server after the great experience on my other unRAID machine (this is the server in my signature).

 

This server is always coming up with a parity check...I must have overlooked something. Syslog is attached, maybe someone can see that the issue is.

 

If you read back up this thread, you'll see that your symptoms are very similar to those I was experiencing.

 

The new Powerdown is trying to be less forceful when shutting down.  This is all well and good but it does mean that if the rest of the system doesn't cooperate you will experience unclean powerdowns.  The new Powerdown relies on using the '/etc/rc.d/rc.* stop' scripts to stop any running processes - in my case, the script didn't always succeed in stopping the process.

 

In your case, there is no evidence that any rc.* scripts are being run - either you have no plugins, or they don't provide an rc.* script.

 

However, you clearly have one, or more, open files on a user share which has files on disk1.  I suspect that it may be a VM with open file(s) on disk1, and your K00 script isn't succeeding in closing it down.

Thanks PeterB. I Do not have any plugins/addons etc. Disk1 is reserved  for Timemachine, no other process is accessing this drive.

I was using the script on my second server after the great experience on my other unRAID machine (this is the server in my signature).

 

This server is always coming up with a parity check...I must have overlooked something. Syslog is attached, maybe someone can see that the issue is.

 

There is an issue here with the K00.sh script.

Mar 22 22:18:09 Tower rc.unRAID[23152][23153]: Processing /etc/rc.d/rc.unRAID.d/ kill scripts.
Mar 22 22:18:09 Tower rc.unRAID[23152][23157]: Running: "/etc/rc.d/rc.unRAID.d/K00.sh"
Mar 22 22:18:09 Tower rc.unRAID[23152][23160]: Waiting for 0 domains

 

It appears that you are shutting down a VM and it is not working?  What is the content of your K00.sh script?

The new Powerdown is trying to be less forceful when shutting down.  This is all well and good but it does mean that if the rest of the system doesn't cooperate you will experience unclean powerdowns.  The new Powerdown relies on using the '/etc/rc.d/rc.* stop' scripts to stop any running processes - in my case, the script didn't always succeed in stopping the process.

 

Powerdown expects that plugins will shut down properly with supplied .rc scripts and it will no longer force plugins to shut down.  Plugins are expected to behave.  Being forceful in the past caused hang ups when shutting down.

Hmmm...last lines of your syslog:

Mar 22 22:18:16 Tower rc.unRAID[23194][23247]: Active pids left on the array drives

Mar 22 22:18:16 Tower rc.unRAID[23194][23250]:                      USER        PID ACCESS COMMAND

Mar 22 22:18:16 Tower rc.unRAID[23194][23250]: /dev/md1:            root    kernel mount /mnt/disk1

Mar 22 22:18:16 Tower rc.unRAID[23194][23250]:                      root      2027 F.... shfs

Mar 22 22:18:16 Tower rc.unRAID[23194][23251]: Stopping the Array

Mar 22 22:18:16 Tower rc.unRAID[23194][23257]: /root/mdcmd: line 11: echo: write error: Device or resource busy

Mar 22 22:18:16 Tower kernel: mdcmd (107): stop

Mar 22 22:18:16 Tower kernel: md: 2 devices still in use.

Your disk1 is JUST TimeMachine? Do your other share definitions EXCLUDE disk1?

 

I don't understand XEN, but could the answer be in your (EdgarWallace's) Post #206 above?  ...something about a -u flag being needed?

@dlandon & DaleWilliams, I'm back and ready to paying attention  So let me cover what you were asking:

 

1.) Disk 1 is just Time Machine....disk 1 is excluded for all shares.

2.) Here is my K00.sh script:

[ -f /var/run/xenstored.pid ] && xl shutdown -a -w

I'm convinced that, with powerdown v1.02, issuing the 'shutdown -P now' command would execute the powerdown script and then power the machine off - in the same way that a short push on the power button would do (and still does).

 

However, I have just tried to use 'shutdown -P now' and the machine shut down but failed to power down.  Is this something that can be easily fixed?

 

I've also discovered that if powerdown is invoked soon after the machine has booted up, an unclean powerdown can result, with a seemingly random drive failing to umount.  In my world of frequent powercuts, this is a very real problem - it has happened twice in the last month or so.  I suspect that it is associated with cache_dirs performing its initial scan - the active PID is a 'find' command.  I guess that the cache_dirs plugin requires some attention to the way rc.cache_dirs responds to the 'stop'.  I suspect that a "killall -9 find" is in order!

I'm convinced that, with powerdown v1.02, issuing the 'shutdown -P now' command would execute the powerdown script and then power the machine off - in the same way that a short push on the power button would do (and still does).

 

However, I have just tried to use 'shutdown -P now' and the machine shut down but failed to power down.  Is this something that can be easily fixed?

 

The 'shutdown -P now' should operate the same.  Run the command and post a log so I can take a look.

I'm convinced that, with powerdown v1.02, issuing the 'shutdown -P now' command would execute the powerdown script and then power the machine off - in the same way that a short push on the power button would do (and still does).

 

However, I have just tried to use 'shutdown -P now' and the machine shut down but failed to power down.  Is this something that can be easily fixed?

 

I've also discovered that if powerdown is invoked soon after the machine has booted up, an unclean powerdown can result, with a seemingly random drive failing to umount.  In my world of frequent powercuts, this is a very real problem - it has happened twice in the last month or so.  I suspect that it is associated with cache_dirs performing its initial scan - the active PID is a 'find' command.  I guess that the cache_dirs plugin requires some attention to the way rc.cache_dirs responds to the 'stop'.  I suspect that a "killall -9 find" is in order!

 

'shutdown -P now' is a maintenance mode and switches to a single user mode.  It won't shut off the computer.  Are you sure this is the command you used in the past?

'shutdown -P now' is a maintenance mode and switches to a single user mode.  It won't shut off the computer.  Are you sure this is the command you used in the past?

 

root@Tower:~# shutdown
Usage:	  shutdown [-akrhHPfnc] [-t secs] time [warning message]
	  -a:      use /etc/shutdown.allow
	  -k:      don't really shutdown, only warn.
	  -r:      reboot after shutdown.
	  -h:      halt after shutdown.
	  -P:      halt action is to turn off power.
	  -H:      halt action is to just halt.
	  -f:      do a 'fast' reboot (skip fsck).
	  -F:      Force fsck on reboot.
	  -n:      do not go through "init" but go down real fast.
	  -c:      cancel a running shutdown.
	  -t secs: delay between warning and kill signal.
	  ** the "time" argument is mandatory! (try "now") **
root@Tower:~#

 

Pretty sure, yes.

Not sure if this is something I have to edit in Dynamix or Powerdown but I set up K00.sh / S00.sh scripts which worked fine when I hit "start array" or "stop array" with the standard webGUI. However after I installed the Dynamix enhanced webGUI the K00.sh / S00.sh scripts stopped being executed when I hit start/stop array on the Dynamix webGUI.

Not sure if this is something I have to edit in Dynamix or Powerdown but I set up K00.sh / S00.sh scripts which worked fine when I hit "start array" or "stop array" with the standard webGUI. However after I installed the Dynamix enhanced webGUI the K00.sh / S00.sh scripts stopped being executed when I hit start/stop array on the Dynamix webGUI.

 

Make sure you have the latest version of Dynamix.  Also look at your log and check which version of powerdown is installed.  An older version of Dynamix will install powerdown 1.02 that does not support the K and S scripts.