phpor

10月 202017
 

rbd vs rbd-nbd

两者功能一样,效果也没啥差别,只是实现方式有所不同; 前者使用内核的rbd模块访问ceph存储,当ceph较新(内核较旧)时,可能会有一些image的feature内核不支持,就不能map;后者使用librbd来访问ceph存储,基本不会存在feature不支持的情况。

同一个rbd image可以同时在一台服务器上map多次;但是只能mount一次,因为多次挂载后设备的uuid是同一个,文件系统不允许同时挂载两个相同uuid的设备的

同一个rbd image可以同时挂载到多个服务器上;

也就是说,ceph的image是可以作为共享存储使用的。

注意:

  1. 即使在两个不同的mnt名字空间,也不能同时分别mount同一个设备,依然有uuid冲突的问题
  2. 即使分别在不同的mnt名字空间执行rbd map,设备的uuid也都是一样的
  3. 即使在不同的服务器上执行rbd map,设备的uuid也都是一样的

 

 Posted by at 下午 12:11
10月 202017
 

功能: 创建新的名字空间,并使得进程处于sleep状态,可以随时nsenter进来

测试 mnt 时发现,似乎并没有实现mount的隔离; 测试方法:

./new-namespace -m &

然后使用nsenter,分别在名字空间内外查看 /proc/self/mountinfo 的内容,发现如何操作,内外都是一致的。

注意: 需要和pid名字空间一起使用

 

参考: https://www.toptal.com/linux/separation-anxiety-isolating-your-system-with-linux-namespaces

 Posted by at 下午 12:08
10月 172017
 

有时候,我们为了安全,禁用root账号登录,需要root的话,在普通账号登录后再sudo;也有时候,我们期望vnc桌面的时候使用的是root账号,于是,我们在普通账号sudo(或sudo -s )后启动vncserver,于是问题来了,我们vnc看到的桌面是黑色的,而且里面的窗口是没有菜单的

解决办法:

  1. 要么直接root登录后启动vncserver
  2. 要么普通账号登录时,su后启动vncserver
 Posted by at 上午 10:29
10月 162017
 

 

kvm上安装windows虚拟机时,如果起初配置的磁盘就是virtio驱动的,则安装时会发现不到磁盘,需要使用virt-win.iso 来安装驱动; 如果起初使用的是IDE,则可以顺利安装windows,如果安装后才发现IDE其实没有virtio 高效,于是直接修改为virtio,则windows就会启动不了;解决办法:

先不要讲IDE修改为virtio,而是先挂一个virtio的磁盘,然后会在windows的设备管理器中发现缺少驱动,使用virtio-win.iso 安装驱动即可;然后删掉多余的virtio磁盘,并且将系统盘修改为virtio即可

参考: http://blog.chinaunix.net/uid-20776139-id-3481065.html

 

 Posted by at 下午 3:35
10月 162017
 

对于kvm虚拟机,由于宿主机和guest之间的独立性很大,当guest把很多内存用于系统cache的话,宿主机也没有办法识别这部分内存,也没有办法建议guest让出一部分内存。

kvm有个内存气球的概念,原以为可以在不改变guest已定义的内存大小的情况下可以让guest让出一部分非关键性的内存占用,而实际上balloon却是在修改(变大和变小)guest的总内存大小,而且在减小guest内存大小的时候,也是武断地减少内存大小,一点儿不考虑guest的感受,不惜杀死进程来满足宿主机的请求,下面是逐步balloon的过程:

  1. 先让出free部分
  2. free不够再让出cache部分(并非所有的buff/cache都是完全让出的)
  3. 实在还不够,杀进程

参考资料:

https://www.linux-kvm.org/page/Projects/auto-ballooning  这里有提到选项automatic=true

http://www.openstack.cn/?p=4540

 Posted by at 上午 11:26
10月 122017
 

现象:

乍一看, /proc/self/exe 文件找不见?

一般来讲,文件找不见并不奇怪,怪就怪在是 /proc/self/exe 找不见就不太应该了;

因为docker exec 最终是由libcontainerd进程来出来的,strace跟进发现,是chdir到 /root/data1/docker/devicemapper/mnt/4723e8178992b32b7284aa48c1c62f4011a6b785aca0c54e18d7ce5cc23b22dc/rootfs 时,找不到目标目录导致的,于是我就迅速地看了一下,该目录确实不存在,但是对于正常的能够exec的容器来讲,相应的rootfs目录也是不存在的

思考中。。。

docker玩的就是名字空间和cgroup,所以不能不想到这些;libcontainerd也有自己的(mnt)名字空间,我们进入libcontainerd进程的文件系统就可以查看到上面目录的存在了,而且,正常的容器存在相应的目录,异常的容器不存在相应的目录;

通过mount命令可以发现mount的规律,从容器的config.json (/var/run/docker/libcontainerd/c6176f37c4b67b03d4187edef6d1131cd44ab80bd0f0c20b24a7a20056967652/config.json) 中查看到对应的mount的位置,通过nsenter进入libcontainerd的mnt名字空间手动mount上去就好了,如下:

那么该mount点是如何丢掉的呢?重启dockerd能否自动修复该问题呢?稍后再研究

 Posted by at 下午 6:34
10月 122017
 

不严格地讲,内存各部分关系大致如下:

可用(60287) + 已用(37G) =  总数(96G)

已缓存(45913MB) + 空闲(14420MB) = 可用(60278MB)

所以:

  1. 已用 不包含 已缓存
  2. 空闲 不等于 可用
    1. 空闲意味着真的空闲
    2. 可用可能包含可以被随时踢掉的缓存
 Posted by at 下午 3:21
10月 122017
 

在openstack管理的虚拟机中启动vnc时,:1 是启动不了的,似乎是被kvm已某种方式给占用了,而这种占用方式似乎并不依赖虚拟机中的vnc软件。

浏览器中的vnc性能和体验都不如vnc客户端软件

 Posted by at 上午 10:00