Sichuanren's Blog

November 20, 2014

Compress vmdk image for virtualbox

Filed under: Cloud, Virtualization — sichuanren @ 8:28 pm

We have a need to reuse qcow2 image for VirutalBox. With qemu-img convert we can get vmdk image but the size jump from 11G to 30G. Using vBoxManager tool option –compact (e.g., vdi) does not work. Also vBox boot the qcow2 image directly doesn’t work.

Solution: vmware-vdiskmanager -r /opt/vDisks/main1.vmdk -t 5 /opt/vDisks/main2.vmdk

November 12, 2014

Hugepages for KVM

Filed under: KVM, Virtualization — sichuanren @ 8:52 pm
1) teach MAKEDEV how to “create the directory” /dev/hugepages on boot. Actually it is creating an additional /dev/null device at /dev/hugepages/null, but it should be harmless to have multiple “null” (major 1, minor 3) devices and also harmless to mount on top of it.
echo 'c $ALLWRITE 1 3 1 1 hugepages/null' > /etc/makedev.d/01hugepages
2) tell udev to create it on boot if needed:
echo 'hugepages/null' > /etc/udev/makedev.d/52-hugepages.nodes
3) tell udev what the right permissions are for it:
echo 'KERNEL=="hugepages*", OWNER="root", GROUP="root", MODE="0775"' > /etc/udev/rules.d/52-hugepages.rules
4) Under CentOS/RHEL run “huge_page_setup_helper.py” to get your hugepages setup
5) Set the hugetlbfs to be mounted on boot:
echo 'hugetlbfs /dev/hugepages hugetlbfs defaults 0 0' >> /etc/fstab
That’s it! After a reboot, you can check that hugepages are setup with “sysctl vm.nr_hugepages” and “grep -i huge /proc/meminfo” and check that hugetlbfs is mounted with “mount | grep huge“.

Check /proc/meminfo once your KVM guests start to make sure the number of free pages decreases. If not confirm your guest’s XML file has “<memoryBacking><hugepages/></memoryBacking>” below the “<currentmemory>” section and that they have “-mem-prealloc -mem-path /dev/hugepages/libvirt/qemu” in the qemu-kvm command line (it should be auto-set by libvirt).

(from http://blog.tonns.org/2010/08/hugepages-and-kvm.html)

November 6, 2014

5个解决Docker网络问题的项目

Filed under: Docker, Virtualization — sichuanren @ 6:47 pm

Docker 是一个开源的应用容器引擎,它可以让开发者将自己的应用以及应用所依赖的内容打包到一个可移植的容器中,然后将该容器发布到任何流行的 Linux 机器上,也可以实现虚拟化。Docker 彻底释放了虚拟化的威力,它让应用的分发、部署和管理都变得前所未有的高效和轻松,凭借着自己出众的能力,Docker现在已经成为目前IT界创业者和创 新者的宠儿。那么Docker是否已经足够完美了呢?答案当然是否定的,对于管理者和开发人员来说网络依然是Docker的一个痛点,如何管理 Docker容器之间的交互和网络一直都充满了挑战。

为了解决网络的问题,有很多公司都开发了各自的产品以帮助开发者更方便地使用Docker。Serdar Yegulalp最近在InfoWorld上分享了一篇文章,介绍了这些项目中最重要的5个,包括Weave、Kubernetes、CoreOS, Flannel、Pipework以及SocketPlane,同时他认为这其中的部分项目将来可能会成为Docker的组成部分。下面就让我们来了解一下这5个项目。

Weave是由Zett.io公司开发的,它能够创建一个虚拟网络来连接部署在多台主机上的Docker容器。通过Weave所有的 容器就像被接入了同一个网络交换机,那些使用网络的应用程序不必去配置端口映射和链接等信息。外部设备能够访问Weave网络上的应用程序容器所提供的服 务,同时已有的内部系统也能够暴露到应用程序容器上。Weave能够穿透防火墙并运行在部分连接的网络上。另外,Weave的通信支持加密,所以用户可以 从一个不受信任的网络连接到主机。如果你想了解更多与Weave相关的信息,或者查看相关源码,那么可以点击这里

Kubernetes是由Google推出的针对容器管理和编排的开源项目,它让用户能够在跨容器主机集群的情况下轻松地管理、监 测、控制容器化应用部署。Kubernete有一个特殊的与SDN非常相似的网络化概念:通过一个服务代理创建一个可以分配给任意数目容器的IP地址,前 端的应用程序或使用该服务的用户仅通过这一IP地址调用服务,不需要关心其他的细节。这种代理方案有点SDN的味道,但是它并不是构建在典型的SDN的第 2-3层机制之上。如果对此感兴趣可以阅读一下Craig Matsumoto在sdncentral上发表的这篇文章,或者点此查看源码。

Flannel之前的名字是Rudder, 它是由CoreOS团队针对Kubernetes设计的一个覆盖网络工具,其目的在于帮助每一个使用 Kuberentes 的 CoreOS 主机拥有一个完整的子网。Kubernetes 会为每一个 POD 分配一个独立的 IP 地址,这样便于同一个 POD 中的Containers 彼此连接,而之前的 CoreOS 并不具备这种能力。为了解决这一问题,Flannel 通过在集群中创建一个覆盖网络为主机设定一个子网。点此查看该项目的源码。

Pipework是由Docker的一个工程师设计的解决方案,它让容器能够在“任意复杂的场景”下进行连接。PipeworkDocker的一个网络功能增强插件,它使用了cgroups和namespacpace。点此查看该项目的源码。

SocketPlane目前仅停留在将“SDN带给Docker”的口号上,基本上没有实质性的工作。该项目的想法是使用和部署 Docker一样的devops工具管理容器的虚拟化网络,同时为Docker构建一个相当于OpenDaylight/Open vSwitch的产品。听起来非常有前途,但是在2015年一季度之前我们无法看到任何产品。

对于以上项目,Serdar Yegulalp在自己的文章中也发表了针对性的观点,他认为Weave是最好的起点,因为它通过一种直截了当的方法解决了当前大部分的问题。 Kubernetes也是一个比较好的起点,但是真要用起来可能并不是那么简单。而Flannel则最好是和CoreOS一起使用,同时它依赖于 Kubernetes。对于Pipework,Serdar Yegulalp认为它是一个临时的设计方案,很有可能会被抛弃。最后的SocketPlane则基本上是看看就行了,不要期望太高。

Blog at WordPress.com.