00:34:08 jayjwa: "staff" is generally set aside for people, if you don't have a better option 00:45:23 I added a "users". I think that's how I have it on Solaris, and that's how I have it on Linux. I'm trying to do things the "Omni OS way". 09:27:32 I am trying to automatically delete snapshots after x days. Most of the guides shows solutions using date from gnu coreutils, but I'd like to came up with a solution using the tools available in the standard install. 09:27:38 I found a solution like this: 09:27:43 /usr/sbin/zfs destroy -r tank@`TZ=$TZ+167 date +'%Y-%m-%d'` 2>> /var/log/zfs.destroy 09:28:23 With this I can pass an offset to the TZ, in this example 167 hours offset is used, which gives me a date 7 days back from today. 09:29:23 I'd like to increase the offset, to keep snapshots from the last 30 days, but the date command silently ignores offsets greater than 167. For any offset greater than that it just returns the current date. 09:30:02 This behaviour seems to be incorrect from my point of view. 09:31:04 Considering possibly tons of scripts relying on this I don't expect my use-case to get any quick fix, so I am interested how do you guys delete automatically the old snapshots? 09:39:56 szilard: if all that is missing is formatting the date "30 days ago" to do this without GNU date, then 'date -r $(expr $(date -u +%s) - 30 \* 24 \* 3600) +%Y-%m-%d' should do the trick 09:41:16 Yep, this definetely works, thanks for the hint. 09:42:01 probably can be done much nicer doing ksh arithmetic, if that's what you're scripting in 09:42:38 I plan to add this to the root crontab, and AFAIR it runs everything in sh, but correct me if I am wrong. 09:43:58 I could adopt this command with the solution you proposed : /usr/sbin/zfs destroy -r tank@`date -r $(expr $(date -u +%s) - 30 \* 24 \* 3600) +%Y-%m-%d'` 2>> /var/log/zfs.destroy 09:44:47 But this feels dangerous. If the machine was not powered on for a long time, this could delete the last intact snapshot. 09:45:36 So I am interested how do you delete old, unnecessary snapshots. 09:47:03 on the systems where I do this, i use timeslider. but those systems run OI, not omnios :) 10:14:23 question for a newbie. running linux/bsd in a zone, can one migrate(online or offline) that "vm" from one omnios system to another easily?  I know with like other virt(like kvm/vmd) it was as simple as copy the disk file across and starting in on the other side. 12:34:06 question for a newbie. running linux/bsd in a zone, can one 12:34:06 migrate(online or offline) that "vm" from one omnios system to another 12:34:07 easily?  I know with like other virt(like kvm/vmd) it was as simple as 12:34:07 copy the disk file across and starting in on the other side. 12:39:06 Assuming it's bhyve, then it'll be a zvol (zfs volume) and you just have to send that (with zfs send + zfs receive) 12:40:31 And normally I would have the zone configured at the destination, but shut down so the disk isn't changing under a running system 12:42:19 You can keep the source running and replicate with zfs at whatever frequency you need to satisfy your recovery objectives 12:44:14 With a regular or lx zone, same idea, but using zfs to replicate the zone's dataset(s) 13:03:13 hmm, ok, pretty cool. thanks ptribble 13:04:05 szilard: You can simplify your command a bit by replacing expr(1) with the $((...)) "arithmetic expansion" of the standard sh(1) (as mandated by POSIX): 13:04:09 date -r $(($(date -u +%s) - 30 * 24 * 3600)) 13:05:03 works fine without running into globbing the unquoted "*". 13:06:43 (You can also drop any spaces between operands and operators, and referring to shell vars doesn't even require "$"s.) 17:58:29 There's two qemus: one really old, and a new one. The new one only lists 'tcg' for -accel help. Can qemu use KVM? I have kvm driver v0.1 loaded. 18:02:56 Windows lists whpx and Linux lists kvm in addition to tcg. 20:32:51 The old one is the one that works with kvm. That's all old and replaced by bhyve these days.