8月 062018
 

 

首先,nsenter想进入进程的名字空间看看都是失败的:

详细的关键信息如下:

 

看看进程在干啥:

wchan 显示不全,这样来看:

或者更直接的如下:

其实不知道为啥走到了这个系统调用,更好的办法:

直接看进程的内核栈:

大概是内存资源不太够吧,其实现在已经把进程从cgroup中迁移出来了,还是不行,给对应的cgroup添加更多的内存也是不行

 

 

 

试图将915的cpuset   cgroup迁移到其它地方时,阻塞了,(难道某个事情没有完成时是不能切换cpu的?),此时,连查看 /proc/915/cgroup 也要阻塞了:

 

此时也无法修改该cgroup的cpuset集合:

 

对应的该容器的xfs进程处于D状态:

 

 

 

 

/usr/lib/virtualbox/VirtualBox–commentzhiyong.man_172.16.162.7–startvm138fd168-b0ce-441e-9514-cf1145b6566e–no-startvm-errormsgbox
/usr/lib/virtualbox/VirtualBox–commentzhiyong.man_172.16.162.8–startvmbd1542ca-323b-4cde-99ee-17bc8ae48f63–no-startvm-errormsgbox
/usr/lib/virtualbox/VirtualBox–commentzhiyong.man_172.16.162.9–startvmef0063fc-e42d-4feb-beb4-6d86ab666ac1–no-startvm-errormsgbox
/usr/lib/virtualbox/VirtualBox–commentzhiyong.man_172.16.162.10–startvmbcdf6b3d-6909-4040-bd68-0753f5c1d89c–no-startvm-errormsgbox
/usr/lib/virtualbox/VirtualBox–commentwin7–startvm37305191-6f8b-498d-ac29-4155a838fca0–no-startvm-errormsgbox
/usr/lib/virtualbox/VirtualBox–commentzhiyong.man_172.16.162.6–startvm0a9902dd-fbc1-4228-8b7f-281a0c4158e9–no-startvm-errormsgbox

 

 

参考:

 Posted by at 上午 11:40
8月 012018
 

阿里云内网SLB使用:

 

ECS(A) —–> SLB(TCP)  —–> ECS(B)

 

我们来看看数据包路径:

ECS(A)【 IP(A) –> IP(SLB) 】  ======> SLB (目的地址转换,源地址不转换) ========> ECS(B)【 IP(A) —-> IP(B) 】

那么, ECS(B)该如何回包呢?

因为ECS(B)认为数据包是从ECS(A)过来的,自然回包给ECS(A),而事实上ECS(B)是可以直接访问到ECS(A)的,于是乎,不经过SLB就直接回包了; 那么,数据包到了ECS(A)能被认可吗?

当然不会,因为ECS(A)只知道给SLB发送过请求,不知道给ECS(B)发送过请求。

 

所以, 对于这种情况,SLB的TCP模式是行不通的。同理,UDP模式也是不行的。

 Posted by at 下午 3:21
7月 242018
 

情景: 拿容器当虚拟机用,容器有内存也有swap

问题:

有些程序(Java)只用内存,swap闲着也不用,当内存用完时,由于有大量空闲的swap,所以不会oom,但是进程申请内存被阻塞,该进程的cmdline读取不了,就影响宿主机ps,top

 Posted by at 上午 8:24
6月 282018
 

问题:

 

分析:

tcpdump 抓包、wireshark分析:

基本是由于ssl版本导致的:

client想使用TLS 1.0 , server说,不行,太低

 

解决办法:

 

每次都带上个选项多不方便,使用 .curlrc ; linux上的程序一般都这个套路,在用户目录下写个配置文件:

配置文件格式就是直接写curl的命令行选项,简单粗暴高效。

 

有些curl -v 就能看到握手的ssl版本号

 Posted by at 下午 5:30
6月 072018
 

时移世易,变法宜矣

上胡不法先王之法,非不贤也,为其不可得而法。先王之法,经乎上世而来者也,人或益之,人或损之,胡可得而法?虽人弗损益,犹若不可得而法
凡先王之法,有要於时也,时不与法俱至。法虽今而至,犹若不可法。故释先王之成法,而法其所以为法。先王之所以为法者何也?先王之所以为法者人也。而己亦人也,故察己则可以知人,察今则可以知古,古今一也,人与我同耳。有道之士,贵以近知远,以今知古,以益所见,知所不见。故审堂下之阴,而知日月之行、阴阳之变;见瓶水之冰,而知天下之寒、鱼鳖之藏也;尝一脟肉,而知一镬之味、一鼎之调。

http://blog.sina.cn/dpool/blog/s/blog_5d245fe70102w9j9.html

 Posted by at 下午 6:52
5月 242018
 

如下图: 虚拟机管理器和计算主机中显示的主机的名字不同,为什么呢?

 

说明:

虚拟机管理器说的是hypervisor,具体来讲就是libvirtd

主机说的是虚拟机管理器所在的宿主机,就是我们所谓的计算节点

二者的信息都是记录在nova.compute_nodes 表中的,二者都没有唯一约束;

当然,host是不会重复的;特殊情况下hypervisor_hostname 重复是有可能的; 从dashboard来看,节点资源是hypervisor的,而不是host的。

而且也可以存在一个host上有多个虚拟机管理器的情况,一个nova-compute接到任务后,可以通过不同的虚拟机管理器来创建虚拟机

 

分析:

不同计算节点上使用相同hypervisor_hostname时,hypervisor将拥有了多个机器的资源,那么虚拟机调度时参考hypervisor_hostname的资源的话,虚拟机分配的任务最终会被分配到哪个host上呢?毕竟不同host上都有nova-compute进程的; 另,上报资源时使用的是node的uuid还是host还是hypervisor_hostname?

node的uuid又是如何生成的呢?

hypervisor_hostname 是如何获取到的呢?hypervisor_hostname是不是第一次注册的时候写入后来就不再修改了呢?

主机资源是记录在 nova_api.resource_providers 表中的:

当然,只有nova.compute_nodes 表中记录的uuid才是有效的resource_providers,才会被dashboard显示

 

为什么node节点的hostname已经修改了,虚拟机管理器中显示的还是以前的名字?

nova-compute.log 中会有错误信息:

 

问题: 谁和谁不一致?重启谁?

解决办法:

比较: hostname 和virsh hostname的结果:

二者是不同的,前者的信息是从libvirtd中获取到的,也就是说,libvirtd中显示的主机名和当前的主机名不一致,需要重启libvirtd, 相关逻辑:

 

 

问题:

  1. 重启libvirtd需要先关闭所有虚拟机吗?
    答案: 不需要的,直接重启就行
  2. 虽然我重启了libvirtd,但是virsh hostname 还是 和 hostname不一样,为什么?
    答案: 因为我在/etc/resolv.conf 中配置了search i.beebank.com, libvirtd会自动suffix上search domain的
  3. 虽然现在virsh hostname 和hostname一致了,但是dashboard中看到的还是原来的,为什么?
    答案: 重启一下openstack-nova-compute

 

总结:

  1. 确认一下 /etc/resolv.conf  的配置
  2. systemctl restart libvirtd && systemctl restart openstack-nova-compute

注意:

  1. 修改了libvirtd的hostname之后,需要去数据库中手动修改相关虚拟机(nova.instances表中)的hypervisor_hostname,否则,就找不到这些机器的hypervisor了,而新的hypervisor下也是没有虚拟机的

 

 

 Posted by at 上午 11:13