I tend to use qtrees often for flexibility with repliction, quotas, security style, oplocks, etc., and even for vFilers. However, I never assign a qtree directly to a vFiler anymore (like Adam said...I did do this back in the tradvol days ontap 6.2-6.5 when multistore was new and we didn't have flexvols). I always assign a volume to a vFiler then create qtrees in those volumes. The vFiler owns the volume and qtrees in it. Even though dr and migrate will work with qtrees assigned to vFilers (by using qsm instead of vsm), the volume fsid will change if the vFiler doesn't own the underlying volume. So, all nfs mounts go stale and it won't work for non-disruptive migrations and won't meet data motion requirements with 7.3.3/ops mgr 4.0. If a host has a qtree mounted, even after migrate/dr/datamotion the mount does not go stale since the entire volume, fsid and file handles all migrated with the volume. Also, when qsm is used, any dedup has to be rerun on the target (although sis start is needed anyway with vsm to a new aggregate, but at least the data is still thin but with qsm it is rehydrated across the wire).
For vFiler root volume size... I often use a very small size, however there are some exceptions. If you are doing cifs auditing, then be careful to size to hold the logs and you might need a larger vfiler root. Most logging (messages, disk, etc.) go to vFiler0, but some specific events like cifs auditing go to the vFiler since it is specific to that vFiler.
