MultiStrOpt vs ListOpt

最近需要设置OpenStack senlin里一个配置项event_dispatchers,这个配置项是MultiStrOpt类型的,按照官方文档尝试了很久还是不能用,senlin-engine日志报warning:

起初以为是我们用virtualenv虚拟环境的问题,没找到setup.cfg的entry_points里面配置的namespace senlin.dispatchers:

加断点单步调试,发现拿到的配置项是 ['database, message'] ,而不是 ['database', 'message'] 。

尝试把MultiStrOpt改成ListOpt之后,可以正常加载了。这表明要么是senlin的bug,要么是文档配置示例写错了。

MultiStrOpt到底怎么配置?找了好几个OpenStack项目,终于在keystone项目里面找到了一个示例

原来是要分多行写的。而ListOpt则是写一行,用逗号分隔。

二者的区别可以参考:http://markmail.org/message/5ut4rdjivpw6a6a6

我理解主要是为了支持等号后面的值里面包含逗号的配置项情况,比如”value1,value2″是一项,”value3,value4″是另一项,如果用ListOpt类型配置项,就没办法做到拆成两项(会拆成value1~4共4项),只能用MultiStrOpt来解决。

测试代码:

测试配置文件1:

执行结果:

测试配置文件2:

执行结果:

 

云涛名苑2018物业服务满意度调查结果分析

本次调查为本人个人发起,非官方组织,因此参与度较低人数较少,但也有43份问卷完成填写,小区一共400多户也有差不多10%的比例了,可以算是一次抽样调查,基本上可以代表了业主们共同的观点,问卷地址:https://www.wenjuan.in/s/umiqAn/(结果查看:https://www.wenjuan.com/r/b6F7Zn?pid=5a6eb5c3a320fc9c419edbcc&vcode=b612080b039b4e2f055c5ad5ffc05d34),针对每个问题的分析如下:

Q1是填写房间号,没有可以分析的。

Q2表明绝大部分业主都已经入住2年以上,对物业的过往服务情况是有了解和对比的,正是有对比,才有发言权和真实度。刚交付的时候物业管理相对还是比较到位的,现在是有点每况愈下的感觉。

Q3表明大部分业主还是关心业委会的成立进展的,实际是在筹建中,大家也希望业委会成立后能切实维护业主利益,在跟物业公司沟通时有更多的主动权和法律效力。

Q4表明大部分业主还是习惯用电话和去物业中心与物业沟通交流。物业是组建了一个QQ群的,当然后面也有业主反馈说希望物业能建立一个微信群,毕竟当下QQ已经在70~80~90这几代人中不如微信流行了。

 

Q5问了一个比较贴近生活的问题,大部分业主还是了解物业的通知情况的,因为物业通知停水停电信息,一般都是在QQ群,尤其是临时停水停电,所以应该是加了物业的业主沟通QQ群,并且经常打开QQ查看信息的那部分业主会相对容易收到通知。

Q6是车辆管理相关的,绝大部分业主都反馈有乱停车问题,并且还有消防通道被堵住的情况(应该是指11栋前面的消防通道),自从上次10栋业主家失火后,大家对消防通道的畅通情况就比较关注了,消防通道是生命线,必须保证任何情况下都畅通无阻。

Q7是关于公共建筑的用途变更的,大部分业主都不清楚是否有,就算没有吧,毕竟我们也没有掌握真凭实据,当然如果有业主有证据,也可以公布在业主微信群、QQ群,让其他业主也了解下相关情况。或许等业委会成立后,大家应该可以向他们询问相关情况。

Q8是关于保安人员和安保情况的,这点也是大部分业主都对保安人员不太满意,也对小区治安情况不太满意,不过今天早上看到小区保安队已经更换了,据说是外聘的,看来物业也受不了自家招聘的保安了,对新的保安队伍的表现我们拭目以待吧。

Q9是保洁人员和小区卫生环境的,总体来说大部分业主还算满意,尤其是对保洁人员的服务态度,很多业主都单独反馈好评,我本人也感受到了保洁人员的良好态度,每次去地下车库出电梯口,保洁大姐都会主动打招呼致意,卫生情况也算很好。究其原因,我认为还是因为保洁是外聘的队伍,而不是物业自己的,对业主的评价更加重视,我猜测如果有投诉,会扣他们的工资或奖金,而物业公司自己的人员,相关的投诉估计都被压下来了。至于有部分业主反应地下车库有业主遛狗并且随地大小便,这个也不能全怪保洁人员,我亲眼见过几次保洁人员发现有宠物大小便都是立即清理的,毕竟保洁也不是24小时随时清理,要怪也只能怪部分养宠物的业主不道德(当然我也见过有业主用宠物粪便袋清理宠物大小便,也不是全部),但物业本身应该还是可以做更多的事情的,比如贴告示禁止在地下车库遛狗等,加强监控,如发现有此类现象及时制止等。公共区域的蚊虫消杀,也经常在电梯里看到相关的通知,还是定期执行了的。我个人感觉小区整体清洁程度也是可以的。

Q10是绿化相关的,总体也算满意,可能绿化养护的及时性稍差,我个人感觉还是可以的,没发现有大面积枯死情况,草坪也没有疯长,至于说小区商铺前面的那部分草坪,被人车踩踏碾压导致干枯死亡,这部分也只能怪保安、物业不作为,不及时制止导致的,个人感觉与绿化养护人员关系不大。绿化人员应该也是外聘的,所以表现也不差。当然也有个别业主表示,8点之前就有修剪草坪的工人在作业,影响他们休息(与之对比的是8点之前不准装修),这点也可以跟物业沟通反馈,调整作业时间应该问题不大,可能因为我住的楼层比较高,所以没有发现有此类问题。

Q11是维修人员和公共设施维护相关的,大家对维修的及时性和公共设施的维护满意度都很低,我个人也感觉如此,比如电梯、走廊灯等,一般都是等到业主反馈后过一段时间才会去修理,并且还容易再次损坏。而公共设施的维护就更差了,刚开始小区里的儿童游乐设施还可以用,现在已经基本都报废了,小区的长椅、公共区域的桌椅也都报废了,很多业主对此都有很大意见。电梯故障管理的问题就更大了,整个小区才20部左右电梯,但基本上每天都有电梯出故障,并且维修耗时也比较长,短的一两天、长的要好几周,在维修期间也没有相关告示之类的贴出来告知业主故障原因、故障处理方案、故障处理预估时间等,缺乏与业主的沟通,业主也只能每次询问,而客服也只是机械的回复正在处理了,更加造成了业主和物业之间的矛盾。我希望物业能公示设施设备故障的处理流程、预案,并在故障发生后能主动告知业主更多细节,尤其是预计修复时间,能让业主心中有数,而不是一脸懵逼,加重对物业的误解,认为物业不作为。

Q12是关于物业客服的评价,总体来说,客服态度还可以,毕竟是做客服的,专业素养还是有一些的,但是处理投诉问题的结果就不怎么样了,比如我就电话里和去前台投诉过地下车库通道乱停车问题,至今这个现象还是存在,我所看到的处理方式就是,在地下车库拉了2条横幅,提醒不要停在过道,还有就是我在QQ群里还反馈能否在转弯处贴上提示语,这个也贴了,不过貌似也没啥用,有些业主就是不在乎,依然我行我素。而客服多次收到类似投诉,也没有进一步的动作。

Q13这个问题我本意是询问大家对物业的收费服务比如更换、维修业主家的水电设施,或者其他不在物业免费服务范围内的业务的满意程度,但我估计有很多回答该问题的业主都没搞清楚是什么意义,误以为是缴纳物业费后物业提供的免费服务也算收费服务,因此这题就不分析了,毕竟如果不满意物业的收费服务,可以自己动手或者找外面的服务人员处理,简单来说就是选择度比较高,市场调节即可。

 

Q14不交物业费的原因,这个很多人都是说物业服务不到位,当然我也有同感,但这不能作为不交物业费的理由,毕竟如果你只简单的用不交物业费来表达对物业服务不满意的抗议和不满,最终吃亏的还是你自己,最终都是要交的,也就是延迟一段时间而已,买房的时候 有签订物业服务协议的,每个业主肯定都签字同意了的,凭这一点,物业就可以把不交物业费的业主告上法庭,并且违约业主几乎没有胜算,一旦判决败诉,就可能对个人的信用履约情况会产生不良影响(以后贷款、子女从事部分职业等都可能受影响),这在新闻报道里是有很多先例的,并且即使你后续要卖房子,也得先把物业费补齐了才能交接。所以我觉得业主们不积极给物业反应问题,要求物业改进,而是通过不交、缓交物业费来表达抗议,这么做只会便宜物业,让他们可以有不作为的借口(没人反馈我做的不好,就说明我做的挺好的),就算最终换了物业,换之前这段时间还是让物业占了大便宜,而吃亏的还是自己。更合适的办法是,在业委会成立之前,业主们联合起来,把物业做的不到位的事项列出来,统一交给物业解决,如果不给满意答复,就可以据此投票更换物业公司,毕竟业委会早晚都会成立的,物业也不会永远无视业主的诉求而肆意妄为(除非他们想激起民愤,不想干下去了),这也是我组织这次调查的初衷。正好业委会这几天正在进行选举,我本人都业委会的积极作用还是抱有一定的期望的,至少他们的话语权比较大,也更有法律意义,中国已经逐步进入法治社会(虽然还有很多人治的领域),在民事合同相关领域还是比较尊重法律法规的。

至少得让大家了解情况物业哪方面做的不好,也让物业知道自己哪方面做的不好,业主们是有动作的,不是一味忍让的。

Q15这个没啥分析的,各占3分之1,反正肯定不能物业公司自己定。我倾向于市场调节,服务业市场已经非常开放没有垄断壁垒,性价比高的公司就应该得到更多的发展空间。但就怕招标过程有猫腻。

Q16群众的眼睛是雪亮的,做的好就是好,做的不好就是不好,物业收发快递等便民服务确实给业主带来了很多便利(虽然现在小区里有很多快递柜了),卫生绿化这些方面,上面已经分析过,是外聘的保洁绿化公司在做,服务质量更高一些,大家明显都能感觉到,还有好几位邻居在其他里专门填写了保洁人员的服务态度很好,物业监督他们,关联到工资,还是有效果的,而物业本身谁来监督呢?只能是业主了,所以我们要监督起来,积极反馈意见。

Q17不满意的点比较分散,但大头是在小区的外来人员和车辆管理,车库和停车管理这两个大方向,其次就是电梯故障管理了,这个也是非常让邻居们心烦的,毕竟电梯时天天都在用的东西,为啥没排在第一位,我个人感觉是因为小区每个单元都有两部电梯,一般情况下都不会同时出故障,所以还不至于要经常爬楼梯上下楼,最多也就是多等几分钟,很大程度上弱化了故障的影响程度,如果只有一部并且时不时出故障,邻居们就要疯了。目前看起来小区的外来人员和车辆管理基本处于无人管理状态,大门常开门禁失效或谁来都给开门,车辆方面地面停车也是来了就抬杆,随意无序停放,连11栋前面的消防通道都经常被占,而物业却没有任何实质性的动作来制止(最多就是贴一张禁止停车的通知单,没有任何实际作用),还是那句话,消防通道是生命线,必须保证任何时间都不被堵塞。地下车库的门禁也是一直常开的,不管有没有车库出入卡都能随意进出,另外众所周知,射频卡方式的门禁很容易被复制或借用,这也进一步导致地下车库通道乱停车的现象十分严重。要解决上述问题,必须要求物业做到如下几点:

  1. 加强外来人员管理,严格执行无卡登记、门禁刷卡流程,防止推销、诈骗等人员进入小区(清洗油烟机的骗子已经来我家至少3次了),并接受业主的监督和测试(我也希望业主们能理解和自觉遵守,如果有业主违反,邻居们可以进行批评谴责,并支持保安的做法,我也相信绝大部分邻居都是通情达理的)
  2. 加强非机动车停车管理,这点物业已经做了很多事情,至少9栋门口已经很少有电瓶车、自行车乱停放了(当然也跟公安部门的强力推动有很大关系),10栋下面的,如果没有飞线充电并且不影响出行的(比如走道旁边的角落里),可以以劝说为主,如果有占道或者飞线充电的,可以采取强制措施。之前业主们反应电瓶车不好推到地下车库,坡太陡太窄,物业已经改进加宽,太陡的问题因为是开发商建设就这样,不好整改,所以在小区最北面建设了非机动车停车场并安装了充电设施,我记得调查的时候还说要在7栋那边也建一个,有部分业主认为会占用绿化用地没有同意
  3. 加强机动车管理,包含3个部分,地面停车场和地下车库。地面部分,严格限制停车场进入车辆总量(不能超过总停车位数量),并规范停车秩序防止乱停乱放、碾压草坪等行为;地下车库,改进闸机设备,采用更加安全的车牌识别方案替换射频卡方案,一个车位同时只能有一辆车进入车库(多辆车的家庭要么买多个车位、要么租赁车位,要么只能同时进入购买或租赁的车位数量相等的车辆),非同时进入的不限制车辆牌号(比如只有1个车位但有2辆车,可以轮换进入,但不能同时都在地下车库停放),这么做可以提高地下车库的租赁比例,对物业没有坏处(当前的情况是,很多空着的租赁车位,但就是没人租,都想免费停车),当然这么做的前提是得保证闸机不能常开,只能识别通过的车辆进入;第3个部分是地下车库里泽园楼饭店购买的车位,我个人认为11栋地下车库出口开放就是因为这部分车位,物业的理由是一个出口不够用(我是没发现),我的问题是,物业是如何管理这部分车位的?怎么做到只允许泽园楼的顾客按需停放,而不会放入其他无关车辆?如果物业不加甄别,那就算更新了车牌识别闸机,也仍然不能避免地下车库无车位车辆的乱停放问题(我说我是来泽园楼吃饭的,保安敢不放我下车库?下了车库我还不是想停哪停哪?反正停多久都不收费,停哪里都没人管),我个人认为超时收费方案是个不错的选择(免费停放几个小时,或者只要不过夜都不收费,一旦过夜了就收费),就看物业愿不愿意做了
  4. 加强电梯故障管理,电梯出现故障,我个人认为大部分情况都不是物业的错,电梯质量不好,也只能怪开发商(我买房的时候就知道这个牌子的电梯不怎么样,因此还问过售楼员,他肯定说还可以的,但毕竟也没啥好说的,谁让咱明知道用的这个电梯的牌子还要买这个小区呢?)。但这不能说物业就可以不管不顾,我认为物业能做的就是在电梯出现故障的时候,及时联系维修人员进行处理,并督促尽快修复,另外就是及时张贴相关进展情况通知,毕竟有些故障不是一时半会能修好的。我建议的故障处理流程如下:1)定期巡检(这部分是电梯维护公司在做),2)24小时接受业主故障反馈(这部分有消控中心24小时值班),3)故障后及时通知维修人员(这部分对物业来说也没啥成本),4)与维修人员沟通故障情况和预估修复时间(这个也不难做到),5)及时张贴故障情况通报(包括故障情况、维修方案、预计修复时间等),让业主做到心中有数,减少与物业的沟通成本,也可在很大程度上缓解业主的焦虑情绪和抵触情绪,6)维修中有新的情况需要说明的,也建议及时更新通报(比如备件到货延期、发现新的故障等导致的预计修复时间后延)。

Q18这个问题表明大家都不知道该去哪投诉,很多人选了找业委会,但我们小区业委会还没成立,所以这部分人也可以算作是投诉无门那部分,我这边建议可以先找物业公司领导,如果找不到或者不给解决,可以投诉到中粮地产物业杭州分公司,然后继续投诉到中粮地产物业的深圳总公司,再不行可以投诉到市长热线、1818黄金眼等,最终方案是找律师起诉物业公司。我也专门网上搜索了中粮物业杭州分公司的联系方式:0571-85317296(本人未核验),非官方网址:http://hzzhongl.5858.com/contact/,中粮地产集团联系方式:集团呼叫中心电话0755-23999000(本人未核验),中粮地产集团深圳物业管理有限公司联系电话0755-23999114(本人未核验),官方网址:http://www.cofco-property.com/category.aspx?NodeID=18(本人已在工信部域名备案系统核验)。

Q19我挑选了杭州市面上声誉比较好的几家物业公司,大部分邻居还是比较相信这些公司的,把其他选项排第一的很少。

Q20大部分邻居还是可以接受更换物业可能导致物业费上涨的情况的,大家都想有好的服务,也有极个别的不能接受,估计是认为当前的物业费已经比较高,不能再涨价了,其实如果已经比较高,那么更换物业公司一般也不会涨价的。

Q20、21这两个问题可以归位一类来分析,这两个问题里面反馈的很多问题在上面已经分析过了,我大概整理了下,主要包含如下几类问题(按反馈数量排序):

  1. 门禁、保安、外来人员管理
  2. 电梯问题
  3. 乱停车
  4. 监控问题(数量不够、有死角)
  5. 公共设施维护
  6. 其他(顶楼漏水、楼顶种植蔬菜等、小区内烧纸、楼梯口杂物堆放、房屋质量等等)非共性问题

除了第6项,其他几项我都会整理好改进建议,交给物业处理。

 

keystone revocation event (part)

问题症状

在虚拟机里部署OpenStack环境,遇到一个问题,openstack token issue可以正常生成token,但nova list等命令都报401错误,用curl GET请求验证生成的token也都401错误。

解决方法先讲下,最终发现是因为虚拟机的时间不同步导致的,用ntpdate命令同步下时间之后就可以了。虚拟机时间不同步,应该是做快照过程中pause虚拟机导致其时间停止,从而发生时间延后,因为延后的时间比较长,有好几个小时,所以才导致这个问题。

分析过程

keystone日志看到如下告警:

但明明是刚生成的token,怎么会不可用?

直接加断点调试,调到最后发现token invalid的原因在:

头一次听说还要检查token的生成时间,以前看老版本keystone代码,貌似只有对expires_at过期时间的检查。

继续看为啥要检查生成时间,找到了revoke event,在更新用户、revoke token等操作过程中就会执行相关检查,event的注册代码:

以revoke token为例说明相关流程:

token内容类似(有audit_ids,但没看到audit_chain_id):

数据库更新记录:

 

再以更新用户为例:

之后执行注册好的回调:

之后就与上面的revoke token流程类似了,数据库更新记录:

 

补充知识

为啥要有revoke流程?(以下内容为个人猜测,未经验证)

之前用uuid格式的token,都存在token表里面,有个valid字段标识是否可用,删掉或者更新用户导致失效的,就把这个字段改成0,表示已失效,但是fernet格式token没有数据库记录,没办法做这种操作,只能改为把revoke相关记录保存在单独的表中,也就是revocation_event表。

这只是revocation event相关流程的一部分,所以本文的标题加了part,其他部分还没研究,等后面有机会看明白了再补充。

 

neutron resource notifications

对neutron各种资源操作时,如果配置了oslo_messaging_notifications的dirver,如下所示:

则会发送消息到Queue notifications.info,例如更新port属性:

neutron-server日志可以看到(需要打开debug级别):

消息队列中信息为:

加入断点调试,bt看调用栈如下:

找到发送notification的位置:

上面的self._resource就是neutron的资源之一,如network、subnet、port、router等(也可以是各种extension资源如vpnaas、lbaas、fwaas等)。

发送notification使用的是oslo.messaging库,因为功能单一,所以文档比较简单,有需要可以考虑使用:https://docs.openstack.org/oslo.messaging/latest/

nova extension api原理与实现

注意:新版本已经移除在主流程之前插入自定义扩展api的功能,但在主流程之后加扩展继续保留,参考:https://review.openstack.org/#/c/332436/(remove support for legacy v2 generator extensions),去掉的原因在nova.api.openstack.wsgi.Resource#pre_process_extensions方法上面的注释里有写,说是nova里面已经没有api在用这个功能了,但我还要用啊:<。后面要升级版本的话,在主流程之前做操作只能采用在源码上添加装饰器的方式了,虽然恶心了点,但至少不用在主流程里面插入代码。下面是正题:


这几天要重构一个功能,系统盘的配额管理,之前是在web后端实现的,没有写在nova里,主要是为了减少对社区代码的侵入,对OpenStack原版无代码侵入是我当前实现产品功能的首要条件,目前看来基本算是实现了的,当前我们VisionStack产品开发的这么多功能,只有在线扩容云主机的代码还在nova里面,这个后续也考虑移出来(除了设置maxcpu和maxmemory这两个xml参数的代码目前没想到好办法移出来,其他操作代码都考虑移走)。

这次的系统盘配额功能,需要改到nova代码里,否则用命令行创建、删除云主机,配额就不准了。

即使是要加代码到nova,也要尽量做到不改动主流程,做到插件化。幸好nova支持扩展api,nova show接口返回keypairs等额外信息就是通过这种方式实现的,而我们要做到在API主流程之前执行配额检查流程(只检查不保存usage,usage直接统计instances表,符合官方新版本的配额管理逻辑,配额管理功能介绍可参考之前的这篇文章,还有这篇)。

老版本的扩展api很好实现,新版本更简单,并且改动也很小,只不过之前一直没搞清楚实现的原理,这次同事在开发的时候,顺便让她研究了下原理,当然还是靠田田专家指点的入口在哪(虽然田田专家已经跳出云计算OpenStack的坑了,但H版本的OpenStack代码居然还保存在他的博客服务器上,肯定是真爱粉)。

下面的源码部分是根据同事的实现截取的其中一部分,实现原理分析也是参考她整理的。

实现

 

原理

大概介绍下,反正已经被删掉了,代码位置在nova.api.openstack.wsgi.Resource#_process_stack,里面调用了nova.api.openstack.wsgi.Resource#pre_process_extensions,这个方法里会遍历所有包含generator的extension,并执行,之后才执行到主流程nova.api.openstack.wsgi.Resource#dispatch,最后执行nova.api.openstack.wsgi.Resource#post_process_extensions,主流程之后的extension。

 

云主机创建、删除、关机、重启过程ovs tap网卡相关流程

写这篇的起因是前段时间同事处理了一个打开基于ovs的安全组功能后,重启云主机后ovs流表刷新太慢导致云主机网络不通的问题,这个问题最终定位是neutron已经修复的bug:https://bugs.launchpad.net/neutron/+bug/1645655(没有backport到M版本),但由于对整个云主机tap网卡的创建、清理生命周期流程不清楚,所以走了一些弯路,因此决定整体分析下相关流程。

nova相关流程

基于nova Mitaka版本源码

创建云主机

创建云主机的整个nova流程比较复杂,要全部介绍的话得把nova代码翻一遍了,这里只描述跟libvirt相关的部分。

之前创建云主机整理的流程图(基于ceph系统盘),很多细节没考虑比如nova-conductor、neutron、MQ、DB等,供参考吧:

 

nova准备好云主机启动所需的全部资源后,就调用libvirt接口(通过libvirt-python api调用C库最后转到libvirtd),正式进入libvirt的create流程:

重启云主机

重启分为两种类型,soft和hard,区别是soft调用的libvirt接口是virDomainShutdownFlags+virDomainCreateWithFlags(virsh命令对应shutdown+start),hard是virDomainDestroyFlags+virDomainCreateWithFlags(virsh命令对应destroy+start)。

这里仅分析soft类型,hard类似:

删除过程主要是destroy并清理资源,就不多介绍了。

上述流程分析可以看到,nova里面其实是不管理tap设备的,只是通过查询neutron接口,找到云主机上绑定的port信息,用来生成libvirt所需的xml文件,tap设备的生命周期管理交给libvirt维护。

libvirt相关流程

基于libvirt v3.2.0版本源码

nova创建、重启过程中的启动过程,类似virsh start vm,会执行add-port命令,libvirtd的debug日志如下:

gdb debug调用栈如下,流程比较清晰,没有回调之类的,因此不再分析:

 

nova删除、关机、重启过程中的关机流程,类似virsh shutdown/destroy vm(shutdown的话,还分为使用qemu guest agent关机和使用ACPI接口关机两种,优先使用前一种),会删除ovs tap设备执行del-port命令,libvirtd的debug日志如下:

调用栈如下:

qemuProcessEventHandler发现qemu monitor退出,执行processMonitorEOFEvent,qemuProcessEventHandler为回调函数,负责处理qemu进程状态变更事件,回调函数的流程一般分为注册和执行两部分,

  • 注册流程:libvirtd.c:main–>libvirtd.c:daemonInitialize(VIR_DAEMON_LOAD_MODULE(qemuRegister, “qemu”))–>src\qemu\qemu_driver.c:qemuRegister–>libvirt.c:virRegisterStateDriver(完成注册);
  • 执行流程:main–>daemonStateInit–>daemonRunStateInit–>virStateInitialize–>qemuStateInitialize(qemu_driver->workerPool = virThreadPoolNew(0, 1, 0, qemuProcessEventHandler, qemu_driver))(遍历所有注册的state driver并执行完成初始化调用)

processMonitorEOFEvent事件回调函数的处理流程的另一个分支是结束qemu进程,libvirt发现qemu monitor socket关闭就会kill qemu主进程(monitor是libvirtd跟qemu进程的通信通道,通道断了libvirtd就无法控制qemu进程了,也就无法响应用户的各种查询、热插拔等操作,因此libvirtd选择杀死qemu进程,一了百了,不留后患),正常情况下都是qemu进程退出导致的monitor socket关闭,所以这种情况下会打日志“2018-01-08 07:38:18.427+0000: 1560: debug : qemuProcessKill:5897 : VM ‘instance-0000000e’ not active”,提示vm已关机,return 0返回不执行任何操作;异常退出情况下会kill掉qemu进程:

gdb调试调用栈如下:

 

 

调用qemu monitor回调,shutdown/destroy时执行(发现qemu monitor服务退出调用eofNotify,发现异常调用errorNotify,其他monitor事件则调用对应的回调,比如qemu进程发送的SHUTDOWN事件会调用qemuMonitorJSONHandleShutdown回调,):

上面是destroy操作加的断点调试信息输出。qemuMonitorJSONHandleShutdown会调用注册好的关机事件回调,src\qemu\qemu_monitor_json.c:

src\qemu\qemu_monitor.c(最终调用到mon->cb的domainShutdown回调函数):

 

注册qemu monitor回调过程是在创建vm时执行的,如domainShutdown的回调是qemuProcessHandleShutdown:

全部回调定义在src\qemu\qemu_process.c:

qemu事件处理方法定义在src\qemu\qemu_monitor_json.c:

 

qemu事件定义,在qemu源码的qapi/run-state.json文件中,具体的事件发送流程还没分析,应该是封装好之后通过monitor socket传递的,类似qemu-guest-agent的命令结果传递流程:

 

Centos7 libvirtd gdb调试

简单描述下,有两种方法,一种是通过yum安装debuginfo包,好处是方便快捷,执行 yum install libvirt-debuginfo 即可,但是编译优化没关导致单步调试有些地方跟源码对应不起来,还有就是变量经常被优化掉看不到具体的值,我上面为了方便采用的这种方式。debuginfo的源一般没有镜像,直接使用官方的:

另外一种是自己从编译debug二进制,推荐第二种方式,但是编译依赖有点多,参考:https://libvirt.org/compiling.html

之前记录的debian7环境下老版本libvirt编译方法(应该是1.1.4版本的),可以参考依赖包和编译步骤:

apt-get install gcc  make pkg-config libxml2-dev libgnutls-dev libdevmapper-dev python-dev libnl-dev libyajl-dev libpciaccess-dev build-essential libhal-dev libudev-dev libtool(–with-hal=yes –with-udev=yes用到)
后面这两个用来解决这个问题:sudo virsh nodedev-list
error: Failed to count node devices
error: this function is not supported by the connection driver: virNodeNumOfDevices
./configure –prefix=/usr –libdir=/usr/lib –localstatedir=/var –sysconfdir=/etc –with-hal=yes –with-udev=yes
./configure –prefix=/usr –libdir=/usr/lib –localstatedir=/var –sysconfdir=/etc –with-selinux
######error: failed to get the hypervisor version
######error: internal error Cannot find suitable emulator for x86_64
解决方法:安装libyajl-dev之后重新./configure,make,make install
libvirt-1.1.4编译:
make报错:aclocal-1.13: command not found
解决方法:执行./autogen.sh –system(autoreconf),然后make

neutron相关流程

基于neutron Mitaka版本源码,VLAN type driver+ovs mechanism driver,ovs安全组未开启(所以也没有相关流表的操作)。

主要分析tap设备插入、删除操作后,neutron-openvswitch-agent都做了哪些事情。

在不清楚代码流程的情况下,翻日志是最快的方式,云主机启动tap设备插入操作的neutron-openvswitch-agent debug日志: