PHPor 的Blog – 第31页

windows virtio

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

kvm 之mem balloon

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

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

先让出free部分
free不够再让出cache部分（并非所有的buff/cache都是完全让出的）
实在还不够，杀进程

参考资料：

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

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

docker 之 exec失败的问题

环境：

# docker info
Containers: 56
 Running: 33
 Paused: 0
 Stopped: 23
Images: 31
Server Version: 1.12.5
Storage Driver: devicemapper
 Pool Name: data-docker_thinpool
 Pool Blocksize: 524.3 kB
 Base Device Size: 32.21 GB
 Backing Filesystem: xfs
 Data file:
 Metadata file:
 Data Space Used: 516.2 GB
 Data Space Total: 644.2 GB
 Data Space Available: 128.1 GB
 Metadata Space Used: 45.47 MB
 Metadata Space Total: 16.98 GB
 Metadata Space Available: 16.93 GB
 Thin Pool Minimum Free Space: 64.42 GB
 Udev Sync Supported: true
 Deferred Removal Enabled: true
 Deferred Deletion Enabled: false
 Deferred Deleted Device Count: 0
 Library Version: 1.02.135-RHEL7 (2016-11-16)
Logging Driver: journald
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: host bridge null overlay
Swarm: inactive
Runtimes: runc docker-runc
Default Runtime: runc
Security Options: seccomp
Kernel Version: 3.10.0-514.6.1.el7.x86_64
Operating System: CentOS Linux 7 (Core)
OSType: linux
Architecture: x86_64
Number of Docker Hooks: 2
CPUs: 40
Total Memory: 94.14 GiB
Name: VM-2-10-12
ID: NYBE:NZML:4KQQ:PF2J:RXCB:IPPI:Y3BI:CY7E:RVAC:WVWV:VDM2:3EEK
Docker Root Dir: /data1/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
Insecure Registries:
 docker-registry.i.bbtfax.com:5000
 127.0.0.0/8
Registries: docker.io (secure)

# docker info

Containers: 56

Running: 33

Paused: 0

Stopped: 23

Images: 31

Server Version: 1.12.5

Storage Driver: devicemapper

Pool Name: data-docker_thinpool

Pool Blocksize: 524.3 kB

Base Device Size: 32.21 GB

Backing Filesystem: xfs

Data file:

Metadata file:

Data Space Used: 516.2 GB

Data Space Total: 644.2 GB

Data Space Available: 128.1 GB

Metadata Space Used: 45.47 MB

Metadata Space Total: 16.98 GB

Metadata Space Available: 16.93 GB

Thin Pool Minimum Free Space: 64.42 GB

Udev Sync Supported: true

Deferred Removal Enabled: true

Deferred Deletion Enabled: false

Deferred Deleted Device Count: 0

Library Version: 1.02.135-RHEL7 (2016-11-16)

Logging Driver: journald

Cgroup Driver: cgroupfs

Plugins:

Volume: local

Network: host bridge null overlay

Swarm: inactive

Runtimes: runc docker-runc

Default Runtime: runc

Security Options: seccomp

Kernel Version: 3.10.0-514.6.1.el7.x86_64

Operating System: CentOS Linux 7 (Core)

OSType: linux

Architecture: x86_64

Number of Docker Hooks: 2

CPUs: 40

Total Memory: 94.14 GiB

Name: VM-2-10-12

ID: NYBE:NZML:4KQQ:PF2J:RXCB:IPPI:Y3BI:CY7E:RVAC:WVWV:VDM2:3EEK

Docker Root Dir: /data1/docker

Debug Mode (client): false

Debug Mode (server): false

Registry: https://index.docker.io/v1/

Insecure Registries:

docker-registry.i.bbtfax.com:5000

127.0.0.0/8

Registries: docker.io (secure)

现象：

# docker exec -it c6176f37c4b6 bash
rpc error: code = 13 desc = invalid header field value "oci runtime error: exec failed: container_linux.go:247: starting container process caused \"process_linux.go:75: starting setns process caused \\\"fork/exec /proc/self/exe: no such file or directory\\\"\"\n"

1 2	# docker exec -it c6176f37c4b6 bash rpc error: code = 13 desc = invalid header field value "oci runtime error: exec failed: container_linux.go:247: starting container process caused \"process_linux.go:75: starting setns process caused \\\"fork/exec /proc/self/exe: no such file or directory\\\"\"\n"

乍一看， /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上去就好了，如下：

# nsenter  -m -t 3639 bash
# mount /dev/mapper/docker-253\:3-3221225568-4723e8178992b32b7284aa48c1c62f4011a6b785aca0c54e18d7ce5cc23b22dc -o rw,relatime,nouuid,attr2,inode64,sunit=512,swidth=1024,noquota -t xfs /data1/docker/devicemapper/mnt/4723e8178992b32b7284aa48c1c62f4011a6b785aca0c54e18d7ce5cc23b22dc

# nsenter -m -t 3639 bash

# mount /dev/mapper/docker-253\:3-3221225568-4723e8178992b32b7284aa48c1c62f4011a6b785aca0c54e18d7ce5cc23b22dc -o rw,relatime,nouuid,attr2,inode64,sunit=512,swidth=1024,noquota -t xfs /data1/docker/devicemapper/mnt/4723e8178992b32b7284aa48c1c62f4011a6b785aca0c54e18d7ce5cc23b22dc

写个脚本自动修复之：

#!/bin/bash
# author: phpor
#
LIBCONTAINERD_DIR=/var/run/docker/libcontainerd

function main() {
        local pidOfCotainerd=$(pidof docker-containerd-current)
        local mountinfo=$(< /proc/$pidOfCotainerd/mountinfo)
        for config in $LIBCONTAINERD_DIR/*/config.json;do
                local cid=$(awk -F'/' '{print $6}' <<<$config)
                local rootpath=$(jq -r .root.path $config|sed 's/\/rootfs$//')
                grep "$rootpath" <<<$mountinfo >/dev/null
                if [[ $? -eq 0 ]]; then
                        echo $cid $rootpath OK
                else
                        echo $cid $rootpath Should repair
                        local device=/dev/mapper/$(docker inspect $cid|jq -r .[0].GraphDriver.Data.DeviceName)
                        nsenter -m -p -t $pidOfCotainerd mount -t xfs -o rw,nouuid,attr2,inode64,sunit=512,swidth=1024,noquota $device $rootpath
                fi
        done
}
main

#!/bin/bash

# author: phpor

LIBCONTAINERD_DIR=/var/run/docker/libcontainerd

function main() {

local pidOfCotainerd=$(pidof docker-containerd-current)

local mountinfo=$(< /proc/$pidOfCotainerd/mountinfo)

for config in $LIBCONTAINERD_DIR/*/config.json;do

local cid=$(awk -F'/' '{print $6}' <<<$config)

local rootpath=$(jq -r .root.path $config|sed 's/\/rootfs$//')

grep "$rootpath" <<<$mountinfo >/dev/null

if [[ $? -eq 0 ]]; then

echo $cid $rootpath OK

else

echo $cid $rootpath Should repair

local device=/dev/mapper/$(docker inspect $cid|jq -r .[0].GraphDriver.Data.DeviceName)

nsenter -m -p -t $pidOfCotainerd mount -t xfs -o rw,nouuid,attr2,inode64,sunit=512,swidth=1024,noquota $device $rootpath

done

}

main

那么该mount点是如何丢掉的呢？重启dockerd能否自动修复该问题呢？（应该重启一下容器就行）稍后再研究

windows 内存计算

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

可用（60287） + 已用（37G） = 总数（96G）

已缓存（45913MB） + 空闲（14420MB） = 可用（60278MB）

所以：

已用不包含已缓存
空闲不等于可用
1. 空闲意味着真的空闲
2. 可用可能包含可以被随时踢掉的缓存

libudev on centos7

只需要安装 systemd-devel 就行了

vnc in openstack

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

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

RUNNING CONTAINERS WITH RUNC

http://www.centosabc.com/archives/1573

cloud-init 工作原理 – 每天5分钟玩转 OpenStack（171） – CloudMan6的博客 – CSDN博客

http://m.blog.csdn.net/CloudMan6/article/details/68952153

Management Tools – KVM

http://www.linux-kvm.org/page/Management_Tools

mac brew HOMEBREW_NO_GITHUB_API

brew install spinx-build 的时候可能会遇到如下错误：

/System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/2.0.0/open-uri.rb:353:in `open_http': 422 Unprocessable Entity (GitHub::Error)
	from /System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/2.0.0/open-uri.rb:709:in `buffer_open'
	from /System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/2.0.0/open-uri.rb:210:in `block in open_loop'
	from /System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/2.0.0/open-uri.rb:208:in `catch'
	from /System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/2.0.0/open-uri.rb:208:in `open_loop'
	from /System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/2.0.0/open-uri.rb:149:in `open_uri'
	from /System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/2.0.0/open-uri.rb:689:in `open'
	from /System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/2.0.0/open-uri.rb:30:in `open'
	from /usr/local/Library/Homebrew/utils.rb:367:in `open'
	from /usr/local/Library/Homebrew/utils.rb:397:in `issues_matching'
	from /usr/local/Library/Homebrew/utils.rb:425:in `issues_for_formula'
	from /usr/local/Library/Homebrew/exceptions.rb:145:in `fetch_issues'
	from /usr/local/Library/Homebrew/exceptions.rb:141:in `issues'
	from /usr/local/Library/Homebrew/exceptions.rb:184:in `dump'
	from /usr/local/Library/brew.rb:167:in `rescue in <main>'
	from /usr/local/Library/brew.rb:65:in `<main>'

/System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/2.0.0/open-uri.rb:353:in `open_http': 422 Unprocessable Entity (GitHub::Error)

from /System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/2.0.0/open-uri.rb:709:in `buffer_open'

from /System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/2.0.0/open-uri.rb:210:in `block in open_loop'

from /System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/2.0.0/open-uri.rb:208:in `catch'

from /System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/2.0.0/open-uri.rb:208:in `open_loop'

from /System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/2.0.0/open-uri.rb:149:in `open_uri'

from /System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/2.0.0/open-uri.rb:689:in `open'

from /System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/2.0.0/open-uri.rb:30:in `open'

from /usr/local/Library/Homebrew/utils.rb:367:in `open'

from /usr/local/Library/Homebrew/utils.rb:397:in `issues_matching'

from /usr/local/Library/Homebrew/utils.rb:425:in `issues_for_formula'

from /usr/local/Library/Homebrew/exceptions.rb:145:in `fetch_issues'

from /usr/local/Library/Homebrew/exceptions.rb:141:in `issues'

from /usr/local/Library/Homebrew/exceptions.rb:184:in `dump'

from /usr/local/Library/brew.rb:167:in `rescue in <main>'

from /usr/local/Library/brew.rb:65:in `<main>'

修改 /usr/local/Library/Homebrew/utils.rb 的代码，打印url看看：

https://api.github.com/search/issues?q=sphinx+repo:Homebrew/homebrew+in:title+state:open&amp;per_page=100

1	https://api.github.com/search/issues?q=sphinx+repo:Homebrew/homebrew+in:title+state:open&per_page=100

莫非访问不了api.github.com ？

$ curl "https://api.github.com/search/issues?q=sphinx+repo:Homebrew/homebrew+in:title+state:open&per_page=100"
{
  "message": "Validation Failed",
  "errors": [
    {
      "message": "The listed users and repositories cannot be searched either because the resources do not exist or you do not have permission to view them.",
      "resource": "Search",
      "field": "q",
      "code": "invalid"
    }
  ],
  "documentation_url": "https://developer.github.com/v3/search/"
}

$ curl "https://api.github.com/search/issues?q=sphinx+repo:Homebrew/homebrew+in:title+state:open&per_page=100"

{

"message": "Validation Failed",

"errors": [

{

"message": "The listed users and repositories cannot be searched either because the resources do not exist or you do not have permission to view them.",

"resource": "Search",

"field": "q",

"code": "invalid"

}

"documentation_url": "https://developer.github.com/v3/search/"

}

看起来是有返回值的，而且是合法的json，继续看 /System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/2.0.0/open-uri.rb 的代码，发现很可能是httpcode的问题：

curl -v "https://api.github.com/search/issues?q=sphinx+repo:Homebrew/homebrew+in:title+state:open&amp;per_page=100"

1	curl -v "https://api.github.com/search/issues?q=sphinx+repo:Homebrew/homebrew+in:title+state:open&per_page=100"

发现http code为 422 ，而/System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/2.0.0/open-uri.rb 遇到 422 是走异常逻辑的，如果能简单修改代码使其认为是正常似乎是可以的；但是mac 不让修改/System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/lib/ruby/2.0.0/open-uri.rb ， root账号也不行

回头看 /usr/local/Library/Homebrew/utils.rb ，发现如下逻辑：

export HOMEBREW_NO_GITHUB_API=1

问题解决

其实 spinx-build 是在生成man page的时候用到的，某些情况下，大可不必非要去生成man page