Yes, to flash you would want an actual Jetson with a non-virtual machine Ubuntu 64-bit host PC. There are other steps where a VM wouldn’t matter, but flash itself is picky.
Yes, JetPack3.3 can set up and install packages to both an Ubuntu host and Jetson. By default JetPack install options will first flash, and then after flash completes and reboots, install software over the wired ethernet. If you don’t flash (you’d uncheck this in the options), and only install software, then you can leave out the USB cable and you can avoid putting the Jetson in recovery mode. If you are just flashing, and want to ignore adding any kind of package to the Jetson itself, then you could ignore the wired ethernet. If you just want to install packages to the host, then you could probably do so without having a Jetson present at all.
Yes, a clone of the rootfs gives you a 100% bit-for-bit exact match of the TX2’s root file system. If you had done package updates, and added devel packages for compiling software against, then your clone too would have that. Your cross-compile environment on the host PC could point at a loopback mounted clone and anything your Jetson could compile could then be cross compiled on your host PC. All linking would be against the exact library versions at the time of the clone.
At a later date a clone can be loopback mounted on a host and updated via rsync, e.g., after doing more package updates and/or additions to the Jetson. This would be quicker than a full clone.
If your virtual machine can run “sudo apt-get” commands, then you would need to add whatever dev packages you are interested in to do user space builds there.
To build a kernel or modules you do not need any sysroot (the user space libraries and linker tools). All you would need is the source code, a cross compiler, and the correct commands. JetPack can install the right tools. The “source_sync.sh” script from the driver package can download the correct kernel source. If you’ve flashed with JetPack, then this would act as a front end to the driver package, and thus you’d already have source_sync.sh. The “Linux_for_Tegra/” directory is from the driver package, and the content in “Linux_for_Tegra/rootfs/” is from the sample rootfs plus the “sudo apply_binaries.sh” step (and these steps will also be performed for you if you use JetPack to flash…but you can do this on command line as well).