TE
TechEcho
Home24h TopNewestBestAskShowJobs
GitHubTwitter
Home

TechEcho

A tech news platform built with Next.js, providing global tech news and discussions.

GitHubTwitter

Home

HomeNewestBestAskShowJobs

Resources

HackerNews APIOriginal HackerNewsNext.js

© 2025 TechEcho. All rights reserved.

Xen and Docker: Made for Each Other

77 pointsby ferrantimover 10 years ago

8 comments

markbnjover 10 years ago
I don&#x27;t disagree with this post, but neither do I see the point of it. Anyone who is deploying containers on EC2 is already using the two technologies side-by-side, not that it means anything earth shattering. Maybe I&#x27;m in the minority here but I continue to not get the constant comparisons between containers and VMs. They&#x27;re not the same thing, and they don&#x27;t solve the same problems.<p>I spin up a VM from Amazon and it lets me share an underlying hardware platform in controlled ways so that I pay only for what I need and can&#x27;t affect the other people sharing it. That&#x27;s the problem VMs solve.<p>But now that the VM is running I still have to configure it for my applications. It&#x27;s just a virtual server, with a potentially large gap between that state and the state I want it in. That&#x27;s the problem containers solve.
评论 #8286053 未加载
评论 #8286886 未加载
评论 #8287695 未加载
brendangreggover 10 years ago
Xen is a great technology, and the community has accomplished much in terms of features and performance improvements. But I doubt the long term future is Containers&#x2F;Docker inside Xen guests, instead of just bare-metal.<p>Reasons to pick bare-metal:<p>1. Price&#x2F;performance. For many CPU-bound workloads the Xen overheads are negligible, but for I&#x2F;O-bound workloads the overheads add up. The network code path, especially at 10 GbE speeds, is sensitive to any wasted cycles. For large sites with thousands of instances, these overheads mean less efficiency, and needing to run more instances, costing more for the business.<p>Can the future of Xen eliminate (or near eliminate) I&#x2F;O overheads, so that their resource cost is near bare-metal? Put differently: will there be a future where all I&#x2F;O paths in AWS EC2 access PCI passthrough, or some similar technology to bypass synchronous overheads? That would be great, but is this realistic? Bare-metal provides this level of performance today.<p>2. Debugability. Many environments are sensitive to latency outliers, and measure the 95th and higher latency percentiles. Root causing these is difficult on hardware virtualized environments, where latencies end at the hypercalls, but easier for bare-metal environments. Even with root access on both the host and guests, tracing I&#x2F;O between them can be painstaking work, as the host can&#x27;t see and trace inside the guest. (Is the Xen going to solve this problem? Eg, could I have a SystemTap script trace both guest application-level I&#x2F;O requests and associate them with host device level I&#x2F;O? I suppose it can be done, but will it?) On bare-metal with containers, the host can see all, and trace I&#x2F;O seamlessly from guest processes to bare-metal devices. Currently.<p>3. Density or efficiency. Resources can be shared at a finer level of granularity with cgroups, than is really practical with virtualized devices such as CPUs. Unless you are only running one big Xen guest on a host.<p>Xen (and KVM) are here to stay: there will always be the need for different kernel support for legacy applications. But for very large sites with thousands of instances, the future (although it may take a while) for sites with many instances and are performance sensitive, is likely bare-metal + Containers&#x2F;Docker.<p>If you&#x27;re a small site, or you care less about performance and debugging, then there may well be merit in the work this article covers.
评论 #8287136 未加载
评论 #8288253 未加载
PaulHouleover 10 years ago
I think of Xen as a dying technology.<p>Lately IBM passed around a paper aimed at Amazon that showed how badly paravirtual machines behave compared to bare metal.<p>What they didn&#x27;t note is that newer Intel chips have serious support for hardware virtualization, and that with hardware virtualizaton you get near bare metal performance. And they didn&#x27;t note that the new instance types on AWS support hardware virtualization.<p>Paravirtualization was an important technology for a while because it was the fastest sort of virtualization ten years ago, but now it is the slowest.
评论 #8285509 未加载
评论 #8285232 未加载
评论 #8285311 未加载
评论 #8285851 未加载
nickstinematesover 10 years ago
Always a good surprise to see new companies embracing Docker. I&#x27;d love to chat - nick@docker.com
评论 #8285398 未加载
评论 #8285492 未加载
评论 #8285422 未加载
RRRAover 10 years ago
We run each services in an LXC container. Containers are run inside a KVM that is connected to a bridged interface (one KVM per VLAN).<p>This setup is very clean and easy to partition, secure and maintain. So yes, light vs real virtualization can work well together!
click170over 10 years ago
Site down? It&#x27;s not loading for me on Desktop or Mobile. From the title it sounds like an interesting read, I&#x27;ll have to check back later.<p>Edit: Mwuhaha. <a href="http://webcache.googleusercontent.com/search?q=cache:upPfoeOZQacJ:blog.xen.org/index.php/2014/09/08/xen-docker-made-for-each-other/%3Futm_source%3Drss%26utm_medium%3Drss%26utm_campaign%3Dxen-docker-made-for-each-other%26utm_source%3Dtwitterfeed%26utm_medium%3Dtwitter+&amp;cd=1&amp;hl=en&amp;ct=clnk" rel="nofollow">http:&#x2F;&#x2F;webcache.googleusercontent.com&#x2F;search?q=cache:upPfoeO...</a>
评论 #8284970 未加载
zobzuover 10 years ago
It seems you could do most of the resource sharing, separation and dynamic allocation with cgroups in docker (should it be implemented)<p>XEN mainly provides a stronger separation (or, like, KVM does that, too)
评论 #8285057 未加载
labianchinover 10 years ago
Would that be simple as running a CoreOS image inside Xen? Does it make sense?