SnapVault is more or less a tool to make it easier for users to create specific snapshots and do several tasks that are manually very hard or impossible to do, but in essence, it transfers data as if you would do it by hand, then makes snapshot's as if you would also do them by hand. SnapVault is a tool, using SnapMirror as basis to make things easier for the user. You can perhaps compare it with a map and a navi system for a car. Both show you streets and paths to your destination but the navi system builds on the normal map and adds additional features to make it easier for the driver.
On top of SnapVault, OnCommand is yet another layer of management software, personally I think one that can be very cumbersome and often buggy. SnapVault snapshots and normal Snapshots while basically the same, are differentiated in OnCommand mostly for ease of use for the end user, as this often includes people who do not have the know how to use the command line or access the filer directly for different reasons, it splits these snapshots so they do not get confused. Sometimes this has also to do with access rights and permissions. in some big corporations and environments, the user that is responsible for snapvault backups, might not have access to other normal snapshots.
Also Snapvault snapshots are for the most part incremental snapshots, while the technology behind them is the same, you will not be able to do anything with a snapvault snapshot without the baseline, while "normal" snapshots are for the most part standalone snaps that can be used on their own.
SnapVault uses the same engine as qtree snapmirror to replicate snapshot data with some differences, like the per volume basis instead of a per relationship basis for schedules.
As for your initial question, I'd go with the way Riley already mentioned. Set the tries to 0, this prevents the schedule to run automatically, then you can go on with manually starting the update and depending on your personal preferences on the snapshots continue with snapvault snap.
***
In normal operation, qtree updates and snapshot creation proceed automatically according to the snapshot schedule. However, SnapVault also supports manual operation. The snapvault update command on the secondary initiates an update transfer from the primary to the secondary for an individual qtree. The snapvault snap create command begins snapshot creation just as if the scheduled time had arrived. On the secondary, if the -x option for the snapshot schedule is set, the secondary will contact the primaries to begin update transfers for all the qtrees in the volume, just as it would if the scheduled time had arrived.
***
The whole point of a schedule in the first place, as the word itself aleady says, is to have an automated trigger mechanism that regularly does the snapvault update and snap create for you.
You mentioned the missing option nodes in ZExplorer, but I didn't get the issue for this question, would you mind to elaborate here so we get a better idea of what you feel is missing?
#
Whe I create SnapVault schedule with tries count specifies to 0 (or any other parameter):
create vol_sv_target sv_manually2 6@- preserve=default,warn=0,tries=0
#
Are you talking about a snap create? a snap schedule?
