Orly,
A "shared" disk group has nothing at all to do with VCS itself. A disk group is considered shared if more than one host has access to the disks that comprise the disk group.
In our environment, the disks for the NBU master server are visible on both systems via the SAN setup that we have (fiber based - the disks that comprise the disk group are mapped to be visible to both hosts). Once you have the disks visible on both servers, you can import them on one server at a time. This is what VCS does in the cluster framework...as your service group fails from one node to the other, VCS will deport the disk group, then import on the gaining node.
As far as your Oracle disk group goes, it just needs to be seen (format shows the disks that contain the disk group) on both nodes for VCS to be able to move it from one node to the other in a failover situation.
I've no practical experience with Oracle RAC, so hopefully someone who does can correct me if I'm wrong, but the only reason you would need to enable CFS/CVM functionality would be if you were trying to run Oracle as a parallel service group using Oracle RAC. I'm not sure what the setup would be in that case, but there is an Oracle agent add-on for VCS that might be helpful for you in either setup.
Here's a glimpse of what the resource hierarchy looks like in our NBU cluster:
app_NBU (NBU add-on agent resource type)
mount_NBU (Stock VCS Mount resource - ufs or vxfs are available options here)
volume_NBU (Stock VCS volume resource)
diskgrp_NBU (Stock VCS Disk Group resource)
The ordering here is: import the disk group, start the volume(s), mount the volumes on their mountpoints, then start the app.
There are many other things that need to be considered for the setup, but hope that gives you a starting place for what you were looking for.
Robert