Hey @jack0729 - Thanks for reaching out, sorry for the slow response here. I see you filed a RFE ticket with support just yesterday actually, I pinged the case owner as we already have an open enhancement request for this within engineering, so he will link your case with that ticket.
I've also linked this product idea thread to that backend ticket as well, so we're covered.
I'm actually the one who filed that enhancement request long ago, so this issue is near to my heart. We've been exploring a few ideas but haven't come to a conclusion yet. This is actually one of those issues that sounds really clear cut, but is actually incredibly nuanced. As an example, modern public cloud providers behave in the same way that we do when deleting instances last I checked, so there is precendence for both the "immediate delete" approach as well as the "only delete powered off VM's" approach.
First off, welcome to the Nutanix family! It's always nice to see new customers hit up the forums. Second, we sure can add a request for something like that into a newer release. I can take a look and see if we have anything similar to that potentially coming down the pipe, as well.
As a temporary workaround, you can set up a weekly schedule that takes a snapshot at your intervals. So, in this case, setting up 6 weekly schedules (M,T,W,T,F) at the specified times would look like this:
It's a little more manual to set it up that way, but it'll be a way right now to achieve what you are looking for.
i.e a "BS detector alert"
The challenge here is that, its possible for an application to spit out all zero content, so getting stargate (or anything else) to pick up when you're actually just running a BS storage test, or when the application is actually doing something that slightly resembles a BS test (rare, but it could happen), could be tricky.
I love the zero suppression technology that we have, its actually quite a huge strength, and in my mind, no amount of fancy alerting is going to undo the fundamental misunderstanding that people having around running performance test (i.e, not everyone knows that DISKSPD generally is a bunch of zeros)
Good point. We've got this on the short term roadmap in 2017. We can talk about it more over a beer if you want, I'm around all December in town.
Can you do me a solid, and submit a support ticket on portal.nutanix.com with priority RFE request for enhancement, and ask this same question, and ask them to associate the ticket to the these two tickets?
This will help us track real world volume for these requests.
Definitely leverage in-line compression for pretty much everything, it works really well.
Speaking of that, we've got a huge release (next release out), code named Asterix, where we've done work to make compression even better. Internal numbers are quite awesome that I've seen thusfar, but of course its subjective to workload and data types, BUT, comparing old compression vs new compression, we're seeing even better savings at same or better performance (and in-line already performed really well on existing code).
TLDR - Do in-line now, and keep an eye out for the next big release (you'll see it make a splash), and know that it's projected to be even better.
I agree with you, and we've actually demo'd a ton of concepts around this both at the .NEXT conference as well as our internal engineering "Hackathons", we've just never pushed it out as a product ... as, well, no one's ever asked us to.
Looks like you guys are a NX customer. Do me a favor, go to portal.nutanix.com and file a ticket with priority RFE Request for Enhancement, and mention both this thread as well as engineering ticket FEAT-1726
FEAT-1726 is our internal feature request that we've opened as a placeholder a while back, but we can link your request there, and it helps us track real user demand for such a feature.