What are the best solutions for sandboxing and debugging?

Malware analysis involves sandboxing, debugging, and analysis tools. I'm hoping you guys can help me figure out the finer details in setting up my malware analysis rig.

I think I want to do nested VMs (like Qemu running within Virtualbox running within VMware, or something like that) for added security against VM breakout 0 days, but I want to know what you think. I have 32GB of RAM so I can afford to be inefficient.

I won't give the VMs network access just in case they have some self-propagating Cryptolocker-esque shit that tries to infect my network drives. Or maybe I should just set up a separate VLAN and make ACL rules so that my test rig can't interact with any other private addresses, meaning it can't touch my other local stuff. Then I could still monitor shit in Wireshark even if I can't into proper debugging forensics.

As far as debuggers go, I've heard that Ollydbg is good, but I have no experience with such things so I'm not sure if that's true or not.
Also how can I make a VM not appear to be a VM? And how can I get around some malware's anti-debugging features?

Also, aside from Wireshark and Process Explorer, what are some other good tools for analyzing what's happening within an OS? Windows or GNU/Linux, doesn't matter, since I'll be doing tests for malware and exploits for all kinds of systems.

Thanks in advance, cuties.

Okay, I think I have come up with an idea for what I want to do.
I will run Linux on a cheap(ish) computer (that will need a decent amount of RAM) that is dedicated solely to malware analysis. I will install Ganoo plus Linux as the primary OS and then run VMware running a Windows VM. Within the Windows VM, I will run Virtualbox, and run another Windows VM. The Linux machine will periodically reload the nested VM snapshots.
I won't use any network connection at all, unless you count VMs interacting with each other on the single host. I've actually done more research and come to the realization that many pieces of malware stay dormant until they've verified a connection to their C&C server, and there are ways to spoof it. You can add an entry to your hosts file to redirect malwarecontrolldomain.com to a private address (like 192.168.1.10) which is a fake server you've set up in another VM within the first VM. Sometimes they will attempt to send login credentials to an FTP server so they can upload log files containing information about the infected host machine.
The Linux host box will be running a Windows virtual machine, probably VMware, but I can always change the specific vendors later. The important thing is that they'd be different so VM escape exploits have limited scope. Within the Windows VM, which will have networking and shared folders disabled for no interaction with the host VM, it will have the nested Windows VM for actually running the malware and analysis tools, and a nested Linux VM which will be used for the dummy server. These 2nd layer VMs will have networking enabled for inter-VM communication only.
Instead of using an internet connection or whatever, I can always add more stuff to the airgapped malware computer using DVD-Rs or CD-Rs. Optical media like that is read-only, so that should be safe. And they're cheap enough that I can just throw them out afterwards. It could be risky to add files via a flash drive, because there is malware which can rewrite USB device firmware in ways that are transparent to most users.
I will reload the VM snapshots after every analysis session and I can also reflash the BIOS every now and then using some bios.bin file on a CD. If there is ever any malware that has a combination of VM escape and BIOS rootkit features, I can avoid it that way.
If I need any sort of information off of the airgapped malware analysis PC, I can use a video capture device, similar to the ones people use for recording video game console footage.
Does this sound better?
The only weakness I see in this setup is that some malware might detect that it's being run in a VM and then kill itself. But even without VMs, anti-debugging and anti-analysis features still exist, so I don't really think there would be that much use in running it on the native OS.