Memory Dumping - Cause for concern in Virtualization?

Is this possible?
Yes, it's possible. The VM's memory is accessible by the host system, which allows the host to read anything inside the VM, including kernel-mode memory. Quite a few VM solutions allow guest instances to be dumped to file, or suspended (i.e. a VM version of hibernate).

Is this a threat?
Note that the VM's memory won't entirely be stored in the host's physical memory, but rather will likely be partially stored in a swapfile. This means that part of the guest OS's memory is stored on the host's disk, making slack space analysis a potential attack, even after the guest OS terminates. Images of suspended VMs may also be accessible to an attacker if he steals the disk or gets file read privileges on the host. If the attacker can compromise the host, he may also be able to issue arbitrary memory reads and writes on the VM process, allowing theft and manipulation of data.

Can the VM grab the memory of the host?
It shouldn't be able to. VMs work by creating virtualised versions of processors and memory controllers. This virtual hardware takes normal memory access interrupts and translates them into a virtual address space. For example, the guest OS's kernel might wish to access the physical memory at 7a22d6aa, but the VM actually translates that address to vm.swap+0x7a22d6aa instead, such that the VM is completely unaware of the translation.

Such an attack would require violation of the isolation mechanisms built into the VM. These isolation mechanisms are very strong, since they have to contain an entire OS and any software / drivers it might run. Isolation is often implemented at hardware level using CPU extensions such as VT-x. However, VM systems are software, and software always has bugs. There have been vulnerabilities in the past where software on a VM was able to attack the host, usually via inter-OS communication mechanisms used for sharing files and clipboard functionality.

The host can certainly grab a copy of the complete state of a VM, including what the VM sees as RAM. This is called a "snapshot" and it is a desirable feature.

You can imagine the host system as the kernel's kernel. A VM cannot be protected from its host, anymore than an operating system can protect from a malicious, corrupted CPU. If your security model calls from protection of the VM from the hosting system, then your security model is doomed from start.

(Although such a thing could exist in the context of fully homomorphic encryption, but current state of research is quite far from providing anything usable in that area, let alone efficient.)

In the other direction: the VM is supposed to be contained by the host, and not to be able to escape it, to reach either other VM, or the host itself. Now, of course, that's the theory, but in practice security holes occur.