Hi Mark,
unfortunately that is not possible (not in an official way at least) - since CloudStack is keeping tons of meta-data (info about VM hardware and such) in DB.
For simpler VMs, you could *experiment* with deploying brand new VM with (empty) appropriate disk sizes, shutdown VM, then go and replace QCOW2 files on your NFS storage with original volumes, but again this is all hacking and is not really guarantied to work - MAC and IP address would certainly change etc, perhaps underlying hardware for VM and you would need to play with drivers potentially (for sure if Windows VMs) - not the best approach - but is possible to work.
Normal way would be to export original ROOT (system/OS, say, /dev/vda) volume of your VM as qcow2 files to some web server (optionally RAW format, but that is both inefficient and might have its issues) and then register it as template inside CloudStack and finally deploy new VM in regular way - still some play with drivers etc might be needed, possible mount points (if not used UUID of volume in /etc/fstab), change MAC address of VM (i.e. delete udev rules for network, reboot VM), etc.
For data volumes (i.e. vdb and onwards) you would just upload qcow2 file as Volume to CloudStack - and attach it to your VM (this "attach" is "lazy" attach - meaning when you power on VM very first time (or you hot-plugged the volume during VM running...) CloudStack will move the qcow2 data file that you uploaded, from Secondary NFS to Primary Storage - and this move (qemu-img convert) takes time obviously...so you are not confused why it's so long for the first time.
Just in case you have some Windows VMs - you would probably need to initialize HAL again (google this or ping me if needed) - especially if changing from emulated/IDE stuff to VirtIO (otherwise you will get nice BSOD as usual with driver issues)
CloudStack is an awesome stuff, just give it a try.
Hope that helps
Andrija