You already got some excellent answers to your questions at hand but you might profit from a little "theory" behind all that, so here it goes:

Whenever we talk about virtualisation we need to keep in mind that there are to fundamentally different ways of doing so: "full virtualisation" and "para-virtualisation".

Full-virtualisation is what i.e. VMWare or the DOSbox emulator do: a program is started which emulates a certain hardware platform. On this emulated hardware an OS is installed and "runs" more or less independently from the host hardware. The advantage this has is that you can mix arbitrary platforms because it only depends on the availability of the emulator programs. You can install a PC-emulator onto Linux and run a WIndows guest in it, start it a second time and install another Linux to it, then start a third instance and install DOS onto that. Fully virtualised systems are not "aware" that they are virtualised. For the virtualised system it is like running on non-virtualised hardware.

Para-virtualisation on the other hand, does not work like this: hardware is only emulated up to a certain point. For instance, take the file system driver: if you work on a real disk you need to do all sorts of checks inside this driver because disk blocks could be failing, filesystems can get corrupted, etc.. The driver makes up for that to some extent by these checks. Now, a fully virtualised system has usually a fully virtualised disk which is in fact a file in the host systems filesystem. The driver of the virtualised machine wouldn't have to do all these checks because "under" it the disk driver of the host system (which really does the writing) will do it anyway. A para-virtualised disk driver is "aware" that it works on virtual hardware so it skips all these checks (and a lot of other unnecessary work) which makes the load the emulation places on the host system considerably lighter. The same goes for network drivers, etc.. The final development in this is to have not even a separate kernel for the guest OS but set aside some "space" in the host kernel where all the processes of the guest system go. At this point we usually do not call the guest systems "guest systems" any longer but call these "containers". The big advantage of paravirtualised systems is: the load produced by emulating the hardware itself is much lighter than in fully virtualised systems, so you get to run more guest systems from a given amount of host resources. On the downside, having only one kernel for all guests means that you can't have different OSes running but are limited to what the host system runs. Examples for para-virtualisation software are OpenVZ/Virtuozzo but also Docker.

What is chroot and how does it enter the picture: UNIX, since its earliest stages, has the chroot command, which creates a system environment limited to some separated part of the filesystem. Historically this was done to be able to safely operate FTP servers: in a certain directory a replica of the (important parts of the) main filesystem (like /usr/lib, /bin, etc.) was created and the absolute minimum of libs, commands, etc. were placed there. Then the FTP server process was started in a way so that this directory was the "root" of tis environment and it could not access any other file outside of this. This was done with the chroot command. This way users could access the FTP server and transfer files to ad from it - they might even mess up the FTP server itself, but this "chrooted" part only, not the "underlying" system. Para-virtualised guest systems - in specific containers - more or less resemble this and para-virtualisation is therefore sometimes regarded as "richly dressed up chroot environment".

I hope that connects a few loose ends.

bakunin