4 ms·

Thanks. I remember a blog post that coined a term "virtualized container", but cannot find the link right now. I wouldn't use the word VM, as it reminds us of

Thanks. I remember a blog post that coined a term "virtualized container", but cannot find the link right now. I wouldn't use the word VM, as it reminds us of the heavy full-blown images. It is probably more misleading to say that HyperContainer launches your Docker image in VMs. But you are right, it is still new and requires efforts to get people understand.

Pyxl101 11y ago
I don't know if I would describe VMs as heavy. But to the extent that they are heavy, it's because they are an application and OS running on virtualized (i.e. partially or fully emulated) hardware rather than physical hardware. [Edit: Removed rest of comment to limit negativity. Thank you for responding to clarify.]
- gnepzhao 11y ago
  Let me be more clear. The problem of VM is not virtualization (or hypervisor), the problem is "Machine". For a long time, we try to emulate a complete machine with a complete "OS" running atop. What Docker really changed is to make us realize that all we need is the app, not a full OS. Therefore Docker image is an app-centric package, nothing specific to Linux container. Yes, it runs with Linux container, but you can also launch it with a hypervisor in 100ms. Shall we call hypervisor+kernel+Docker image VM? I don't think so. It never tries to give you a complete machine, neither a full OS. Personally I like "virtualized container". But the combination of these two words might be more confusing, given that whenever you see the word "container", you think of Linux container.
  - Pyxl101 11y ago
    Thank you for responding to clarify. What parts of a machine do traditional data center VMs emulate that Hyper avoids? What system functions normally supported by a guest OS will Hyper not need to support? (E.g., memory management, network stack?)
  - dap 11y ago
    OS size is just one problem with Virtual Machines. (Much of the OS is idle unless explicitly used anyway.) Other significant problems include: - inefficient use of resources resulting from functionality duplicated in both the hypervisor and the guest (e.g., two TCP stacks, two filesystem implementations, two schedulers, and so on). (That's why I asked about this in a separate comment.) - inefficient use of resources resulting from the inability to dynamically share resources between VMs (e.g., memory and disk typically have to be statically allocated to VMs, instead of sharing a common pool the way processes within a single Unix-like system typically do). - poor visibility from the hypervisor into the application (i.e., observability tools cannot typically cross the hardware-virtualization boundary). That's just a partial list. I think that's why you're seeing pushback from people insisting that these be called VMs rather than containers: they have all of the above downsides of VMs, even if the operating system surface area isn't that large. [edited for formatting]

Pyxl101 11y ago

I don't know if I would describe VMs as heavy. But to the extent that they are heavy, it's because they are an application and OS running on virtualized (i.e. partially or fully emulated) hardware rather than physical hardware. [Edit: Removed rest of comment to limit negativity. Thank you for responding to clarify.]

gnepzhao 11y ago
Let me be more clear. The problem of VM is not virtualization (or hypervisor), the problem is "Machine". For a long time, we try to emulate a complete machine with a complete "OS" running atop. What Docker really changed is to make us realize that all we need is the app, not a full OS. Therefore Docker image is an app-centric package, nothing specific to Linux container. Yes, it runs with Linux container, but you can also launch it with a hypervisor in 100ms. Shall we call hypervisor+kernel+Docker image VM? I don't think so. It never tries to give you a complete machine, neither a full OS. Personally I like "virtualized container". But the combination of these two words might be more confusing, given that whenever you see the word "container", you think of Linux container.
- Pyxl101 11y ago
  Thank you for responding to clarify. What parts of a machine do traditional data center VMs emulate that Hyper avoids? What system functions normally supported by a guest OS will Hyper not need to support? (E.g., memory management, network stack?)
- dap 11y ago
  OS size is just one problem with Virtual Machines. (Much of the OS is idle unless explicitly used anyway.) Other significant problems include: - inefficient use of resources resulting from functionality duplicated in both the hypervisor and the guest (e.g., two TCP stacks, two filesystem implementations, two schedulers, and so on). (That's why I asked about this in a separate comment.) - inefficient use of resources resulting from the inability to dynamically share resources between VMs (e.g., memory and disk typically have to be statically allocated to VMs, instead of sharing a common pool the way processes within a single Unix-like system typically do). - poor visibility from the hypervisor into the application (i.e., observability tools cannot typically cross the hardware-virtualization boundary). That's just a partial list. I think that's why you're seeing pushback from people insisting that these be called VMs rather than containers: they have all of the above downsides of VMs, even if the operating system surface area isn't that large. [edited for formatting]