I'm a Systems Reliability and DevOps engineer for Netdata Inc. When not working, I enjoy studying linguistics and history, playing video games, and cooking all kinds of international cuisine.
The key difference is where the virtualization is happening. A virtual machine is virtualized at the hardware level (that is, it has virtual hardware), while a container is virutalized at the OS level (that is, the OS itself is virtualized).
This leads to a number of at times subtle, but often significant differences:
The lack of virtualized hardware means that containers always have to match the host CPU architecture (well, not always, but it's a serious pain to run containers for a different architecture than the host). It also means, however, that you have fewer layers of indirection, and thus generally better performance. This is almost always a favorable trade-off, as the practical uses for cross-architecture VM's are few and far between (pretty much, you only really need them for embedded software development and testing, and mobile app development and testing).
Similarly, because the OS itself is what's providing the virtualization, you can only run containers for the same OS as the host (though there are very specific exceptions to this). This is generally considered a fair trade-off because it's unusual to run truly heterogeneous infrastructure that would be impacted by this (most places run mostly one OS for their infrastructure).
From a security perspective, the attack surface is rather different. Containers are theoretically more secure than a type-1 (bare-metal) hypervisor (like Xen, Hyper-V, and VMWare ESXi) because compromising the container software does not get you access at a lower level than the host system, but less secure than a type-2 (hosted) hypervisor (like VirtualBox, Parallels, QEMU, or VMWare Workstation) because compromising the container software often means you have kernel-level access to the host. Regardless, the attack surface is smaller than a VM, because there is less being emulated/virtualized. This is the part where things get complicated (most advocated uses of containers would be using type-1 hypervisors, so they're usually better).
Because the OS itself is being virtualized, most of the contents of containers can be managed just like other processes on the host. This makes it easier to properly distribute resources when over-provisioning a system with containers than VM's, which is further helped by the (usually) improved performance.
The last point is probably the biggest contributor to the rise of containers over VM's. Most hypervisors make you commit a fixed amount of resources to each VM, so it's hard to reliably over-provision and not unusual to have large percentages of your system not being utilized to the fullest. Containers are more easily flexible in that respect, so it's easy to over-provision, and much easier to ensure that everything that can be used on your system is being used.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
The key difference is where the virtualization is happening. A virtual machine is virtualized at the hardware level (that is, it has virtual hardware), while a container is virutalized at the OS level (that is, the OS itself is virtualized).
This leads to a number of at times subtle, but often significant differences:
The last point is probably the biggest contributor to the rise of containers over VM's. Most hypervisors make you commit a fixed amount of resources to each VM, so it's hard to reliably over-provision and not unusual to have large percentages of your system not being utilized to the fullest. Containers are more easily flexible in that respect, so it's easy to over-provision, and much easier to ensure that everything that can be used on your system is being used.