LXD 2.0 系列（十二）：调试，及给 LXD 做贡献

介绍

终于要结束了！这个大约一年前开始的这系列文章的最后一篇博文。

  1. LXD 入门
  2. 安装与配置
  3. 你的第一个 LXD 容器
  4. 资源控制
  5. 镜像管理
  6. 远程主机及容器迁移
  7. LXD 中的 Docker
  8. LXD 中的 LXD
  9. 实时迁移
  10. LXD 和 Juju
  11. LXD 和 OpenStack
  12. 调试，及给 LXD 做贡献

如果你从一开始就关注了这个系列，你应该已经使用了 LXD 相当长的时间了，并且非常熟悉它的日常操作和功能。

但如果出现问题怎么办？你可以做什么来自己跟踪问题？如果你不能，你应该记录什么信息，以便上游可以跟踪问题？

如果你想自己解决问题或通过实现你需要的功能来帮助改善LXD怎么办？如何构建，测试和贡献 LXD 代码库？

调试 LXD 并填写 bug 报告

LXD 日志文件

/var/log/lxd/lxd.log：

这是 LXD 日志的主文件。为了避免它快速充满你的磁盘，默认只会记录 INFO、WARNING 或者 ERROR 级别的日志。你可以在 LXD 守护进程中使用 –debug 改变其行为。

/var/log/lxd/CONTAINER/lxc.conf：

每当你启动容器时，此文件将更新为传递给 LXC 的配置。

这里会展示容器将如何配置，包括其所有的设备、绑定挂载等等。

/var/log/lxd/CONTAINER/forkexec.log：

这个文件包含 LXC 命令执行失败时产生的错误。这个情况是非常罕见的，因为 LXD 通常会在发生之前处理大多数错误。

/var/log/lxd/CONTAINER/forkstart.log：

这个文件包含 LXC 在启动容器时的错误信息。含 LXC 命令执行失败时产生的错误。

CRIU 日志 (对于实时迁移)

如果使用 CRIU 进行容器实时迁移或实时快照，则每次生成 CRIU 转储或恢复转储时都会记录额外的日志文件。

这些日志也可以在 /var/log/lxd/CONTAINER/ 中找到，并且有时间戳，以便你可以找到与你最近的操作所匹配的那些日志。它们包含 CRIU 转储和恢复的所有内容的详细记录，并且比典型的迁移/快照错误消息更容器理解。

LXD 调试消息

如上所述，你可以使用 -debug 选项将守护进程切换为执行调试日志记录。另一种方法是连接到守护进程的事件接口，它将显示所有日志条目，而不管配置的日志级别（即使是远程工作）。

举例说，对于 lxc init ubuntu:16.04 xen 来说，

lxd.log 会是这样：



    

  1. INFO[02-24|18:14:09] Starting container action=start created=2017-02-24T23:11:45+0000 ephemeral=false name=xen stateful=false used=1970-01-01T00:00:00+0000
    2. 

  2. INFO[02-24|18:14:10] Started container action=start created=2017-02-24T23:11:45+0000 ephemeral=false name=xen stateful=false used=1970-01-01T00:00:00+0000
    3. 



而 lxc monitor –type=logging 会是：




    

  1. metadata:
    2. 

  2.   context: {}
    3. 

  3.   level: dbug
    4. 

  4.   message: 'New events listener: 9b725741-ffe7-4bfc-8d3e-fe620fc6e00a'
    5. 

  5. timestamp: 2017-02-24T18:14:01.025989062-05:00
    6. 

  6. type: logging
    7. 

    8. 

  8. metadata:
    9. 

  9.   context:
    10. 

  10.     ip: '@'
    11. 

  11.     method: GET
    12. 

  12.     url: /1.0
    13. 

  13.   level: dbug
    14. 

  14.   message: handling
    15. 

  15. timestamp: 2017-02-24T18:14:09.341283344-05:00
    16. 

  16. type: logging
    17. 

    18. 

  18. metadata:
    19. 

  19.   context:
    20. 

  20.     driver: storage/zfs
    21. 

  21.   level: dbug
    22. 

  22.   message: StorageCoreInit
    23. 

  23. timestamp: 2017-02-24T18:14:09.341536477-05:00
    24. 

  24. type: logging
    25. 

    26. 

  26. metadata:
    27. 

  27.   context:
    28. 

  28.     ip: '@'
    29. 

  29.     method: GET
    30. 

  30.     url: /1.0/containers/xen
    31. 

  31.   level: dbug
    32. 

  32.   message: handling
    33. 

  33. timestamp: 2017-02-24T18:14:09.347709394-05:00
    34. 

  34. type: logging
    35. 

    36. 

  36. metadata:
    37. 

  37.   context:
    38. 

  38.     ip: '@'
    39. 

  39.     method: PUT
    40. 

  40.     url: /1.0/containers/xen/state
    41. 

  41.   level: dbug
    42. 

  42.   message: handling
    43. 

  43. timestamp: 2017-02-24T18:14:09.357046302-05:00
    44. 

  44. type: logging
    45. 

    46. 

  46. metadata:
    47. 

  47.   context: {}
    48. 

  48.   level: dbug
    49. 

  49.   message: 'New task operation: 2e2cf904-c4c4-4693-881f-57897d602ad3'
    50. 

  50. timestamp: 2017-02-24T18:14:09.358387853-05:00
    51. 

  51. type: logging
    52. 

    53. 

  53. metadata:
    54. 

  54.   context: {}
    55. 

  55.   level: dbug
    56. 

  56.   message: 'Started task operation: 2e2cf904-c4c4-4693-881f-57897d602ad3'
    57. 

  57. timestamp: 2017-02-24T18:14:09.358578599-05:00
    58. 

  58. type: logging
    59. 

    60. 

  60. metadata:
    61. 

  61.   context:
    62. 

  62.     ip: '@'
    63. 

  63.     method: GET
    64. 

  64.     url: /1.0/operations/2e2cf904-c4c4-4693-881f-57897d602ad3/wait
    65. 

  65.   level: dbug
    66. 

  66.   message: handling
    67. 

  67. timestamp: 2017-02-24T18:14:09.366213106-05:00
    68. 

  68. type: logging
    69. 

    70. 

  70. metadata:
    71. 

  71.   context:
    72. 

  72.     driver: storage/zfs
    73. 

  73.   level: dbug
    74. 

  74.   message: StoragePoolInit
    75. 

  75. timestamp: 2017-02-24T18:14:09.369636451-05:00
    76. 

  76. type: logging
    77. 

    78. 

  78. metadata:
    79. 

  79.   context:
    80. 

  80.     driver: storage/zfs
    81. 

  81.   level: dbug
    82. 

  82.   message: StoragePoolCheck
    83. 

  83. timestamp: 2017-02-24T18:14:09.369771164-05:00
    84. 

  84. type: logging
    85. 

    86. 

  86. metadata:
    87. 

  87.   context:
    88. 

  88.     container: xen
    89. 

  89.     driver: storage/zfs
    90. 

  90.   level: dbug
    91. 

  91.   message: ContainerMount
    92. 

  92. timestamp: 2017-02-24T18:14:09.424696767-05:00
    93. 

  93. type: logging
    94. 

    95. 

  95. metadata:
    96. 

  96.   context:
    97. 

  97.     driver: storage/zfs
    98. 

  98.     name: xen
    99. 

  99.   level: dbug
    100. 

  100.   message: ContainerUmount
    101. 

  101. timestamp: 2017-02-24T18:14:09.432723719-05:00
    102. 

  102. type: logging
    103. 

    104. 

  104. metadata:
    105. 

  105.   context:
    106. 

  106.     container: xen
    107. 

  107.     driver: storage/zfs
    108. 

  108.   level: dbug
    109. 

  109.   message: ContainerMount
    110. 

  110. timestamp: 2017-02-24T18:14:09.721067917-05:00
    111. 

  111. type: logging
    112. 

    113. 

  113. metadata:
    114. 

  114.   context:
    115. 

  115.     action: start
    116. 

  116.     created: 2017-02-24 23:11:45 +0000 UTC
    117. 

  117.     ephemeral: "false"
    118. 

  118.     name: xen
    119. 

  119.     stateful: "false"
    120. 

  120.     used: 1970-01-01 00:00:00 +0000 UTC
    121. 

  121.   level: info
    122. 

  122.   message: Starting container
    123. 

  123. timestamp: 2017-02-24T18:14:09.749808518-05:00
    124. 

  124. type: logging
    125. 

    126. 

  126. metadata:
    127. 

  127.   context:
    128. 

  128.     ip: '@'
    129. 

  129.     method: GET
    130. 

  130.     url: /1.0
    131. 

  131.   level: dbug
    132. 

  132.   message: handling
    133. 

  133. timestamp: 2017-02-24T18:14:09.792551375-05:00
    134. 

  134. type: logging
    135. 

    136. 

  136. metadata:
    137. 

  137.   context:
    138. 

  138.     driver: storage/zfs
    139. 

  139.   level: dbug
    140. 

  140.   message: StorageCoreInit
    141. 

  141. timestamp: 2017-02-24T18:14:09.792961032-05:00
    142. 

  142. type: logging
    143. 

    144. 

  144. metadata:
    145. 

  145.   context:
    146. 

  146.     ip: '@'
    147. 

  147.     method: GET
    148. 

  148.     url: /internal/containers/23/onstart
    149. 

  149.   level: dbug
    150. 

  150.   message: handling
    151. 

  151. timestamp: 2017-02-24T18:14:09.800803501-05:00
    152. 

  152. type: logging
    153. 

    154. 

  154. metadata:
    155. 

  155.   context:
    156. 

  156.     driver: storage/zfs
    157. 

  157.   level: dbug
    158. 

  158.   message: StoragePoolInit
    159. 

  159. timestamp: 2017-02-24T18:14:09.803190248-05:00
    160. 

  160. type: logging
    161. 

    162. 

  162. metadata:
    163. 

  163.   context:
    164. 

  164.     driver: storage/zfs
    165. 

  165.   level: dbug
    166. 

  166.   message: StoragePoolCheck
    167. 

  167. timestamp: 2017-02-24T18:14:09.803251188-05:00
    168. 

  168. type: logging
    169. 

    170. 

  170. metadata:
    171. 

  171.   context:
    172. 

  172.     container: xen
    173. 

  173.     driver: storage/zfs
    174. 

  174.   level: dbug
    175. 

  175.   message: ContainerMount
    176. 

  176. timestamp: 2017-02-24T18:14:09.803306055-05:00
    177. 

  177. type: logging
    178. 

    179. 

  179. metadata:
    180. 

  180.   context: {}
    181. 

  181.   level: dbug
    182. 

  182.   message: 'Scheduler: container xen started: re-balancing'
    183. 

  183. timestamp: 2017-02-24T18:14:09.965080432-05:00
    184. 

  184. type: logging
    185. 

    186. 

  186. metadata:
    187. 

  187.   context:
    188. 

  188.     action: start
    189. 

  189.     created: 2017-02-24 23:11:45 +0000 UTC
    190. 

  190.     ephemeral: "false"
    191. 

  191.     name: xen
    192. 

  192.     stateful: "false"
    193. 

  193.     used: 1970-01-01 00:00:00 +0000 UTC
    194. 

  194.   level: info
    195. 

  195.   message: Started container
    196. 

  196. timestamp: 2017-02-24T18:14:10.162965059-05:00
    197. 

  197. type: logging
    198. 

    199. 

  199. metadata:
    200. 

  200.   context: {}
    201. 

  201.   level: dbug
    202. 

  202.   message: 'Success for task operation: 2e2cf904-c4c4-4693-881f-57897d602ad3'
    203. 

  203. timestamp: 2017-02-24T18:14:10.163072893-05:00
    204. 

  204. type: logging
    205. 



lxc monitor 的格式有点不同于每个条目都缩合成一行的日志文件，但更重要的是，你可以看到所有 level：dbug 条目。


如何报告 bug


LXD 的 bug


最好报告 bug 的地方是 https://github.com/lxc/lxd/issues。确保完整填写了 bug 报告模板中的内容，这些信息可以节省我们我们时间来复现环境。


Ubuntu 的 bug


如果你发现 Ubuntu 包本身有问题，无法安装、升级或删除。或者遇到 LXD init 脚本的问题。报告此类错误的最好是在 Launchpad 上。


在 Ubuntu 系统上，你可以使用：ubuntu-bug lxd ，它将自动包括一些日志文件和包信息供我们查看。


CRIU 的 bug


与 CRIU 相关的 Bug，你可以通过 CRIU 的错误输出发现，你应该在 Launchpad 上报告这些：ubuntu-bug criu


请注意，通过 LXD 使用 CRIU 属于测试版功能，除非你愿意通过 Canonical 的支持合同付费支持，要么可能需要一段时间才能查看你的错误报告。


贡献给 LXD


LXD 用 Go 写成并托管在 Github。我们欢迎任外部的贡献。为 LXD 贡献不需要 CLA 或类似的法律协议签署，只是通常的开发者所有权证书（Signed-off-by: 行）。


在我们的问题追踪器工具中，我们列有许多潜在的功能需求，新的贡献者可以以此作为良好的起点。通常最好在开始处理代码先发出 issue，这样每个人都知道你正在做这项工作，以便我们可以提供一些早期反馈。


从源码源码构建 LXD


这里有上游的维护说明：https://github.com/lxc/lxd#building-from-source


你需要在 Github 上 fork 上游仓库，然后将你的更改推送到你的分支。我们建议每天 rebase 上游的 LXD，因为我们倾向于定期合并更改。


运行测试套件


LXD 维护了两套测试集，单元测试和集成测试。你可以用下面的命令测试所有：




    

  1. sudo -E make check
    2. 



要只运行单元测试，使用：




    

  1. sudo -E go test ./...
    2. 



要运行集成测试，使用：




    

  1. cd test
    2. 

  2. sudo -E ./main.sh
    3. 



后者支持相当多的环境变量来测试各种存储后端、禁用网络测试、使用 ramdisk 或只是调整日志输出。其中一些是：


    

  • LXD_BACKEND：btrfs、dir、lvm 或 zfs” 之一（默认为 dir）   
    
运行 LXD 存储驱动程序相关的所有测试。
    • 

  • LXD_CONCURRENT：true 或 false（默认为 false）   
    
这启用一些额外的并发测试。
    • 

  • LXD_DEBUG：true 或 false（默认为 false）   
    
记录所有 shell 命令，并在调试模式下运行所有​​ LXD 命令。
    • 

  • LXD_INSPECT：true 或 false（默认为 false）   
    
测试程序会在故障时挂起，以便你可以检查环境。
    • 

  • LXD_LOGS：将所有 LXD 日志文件转储到的目录（默认为 “”）   
    
所有生成的 LXD 守护进程的 logs 目录将被复制到此路径。
    • 

  • LXD_OFFLINE：true 或 false（默认为 false）   
    
禁用任何依赖于外部网络连接的测试。
    • 

  • LXD_TEST_IMAGE： unified 格式的 LXD 镜像的路径（默认为 “”）   
    
可以使用自定义测试镜像，而不是默认的最小 busybox 镜像。
    • 

  • LXD_TMPFS：true 或 false（默认为 false）   
    
在 tmpfs 安装中运行整个测试套件，这会使用相当多的内存，但会使测试速度明显更快。
    • 

  • LXD_VERBOSE：true 或 false（默认为 false）   
    
不太极端的 LXD_DEBUG 版本。shell 命令仍然会记录，但 -debug 不会传递给 LXC 命令，LXD 守护进程只能使用 -verbose 运行。
    • 



测试程序将在实际运行之前提醒你任何缺失的依赖项。在相当快的机器上运行该测试可在 10 分钟内完成。


原文发布时间为：2017-03-09


本文来自合作伙伴“Linux中国”
				


				
时间： 2024-09-22 06:33:14

		
		


		


	

	
	

		


		
LXD 2.0 系列（十二）：调试，及给 LXD 做贡献的相关文章


						

		

			

                LXD 2.0系列之二：LXD安装和配置
			

		

		

									

				本文讲的是LXD 2.0系列之二:LXD安装和配置,[编者的话]第三方调查报告显示LXD有潜质成为一款受欢迎的第三方容器管理工具.本文是LXD核心维护者.加拿大程序员Stéphane Graber有关LXD连载博文的第二篇. [LXD 2.0系列开篇:是时候讨论LXD的一切了][LXD 2.0系列之一:LXD简介][LXD 2.0系列之二:LXD安装和配置][LXD 2.0系列之三:你的第一个LXD容器][LXD 2.0系列之四:资源管理][LXD 2.0系列之五:镜像管理][LXD 2.0系列			

		

	

				

		

			

                LXD 2.0 系列（二）：安装与配置
			

		

		

									

				安装篇 有很多种办法可以获得 LXD.我们推荐你配合最新版的 LXC 和 Linux 内核使用 LXD,这样就可以享受到它的全部特性.需要注意的是,我们现在也在慢慢的降低对旧版本 Linux 发布版的支持. Ubuntu 标准版 所有新发布的 LXD 都会在发布几分钟后上传到 Ubuntu 开发版的安装源里.这个安装包然后就会作为 Ubuntu 用户的其他安装包源的种子. 如果使用 Ubuntu 16.04,可以直接安装: sudo apt install lxd 如果运行的是 Ubuntu 1			

		

	

				

		

			

                LXD 2.0系列之开篇：是时候讨论LXD的一切了
			

		

		

									

				本文讲的是LXD 2.0系列之开篇:是时候讨论LXD的一切了,[编者的话]第三方调查报告显示LXD有潜质成为一款受欢迎的第三方容器管理工具.本文是LXD核心维护者.加拿大程序员Stéphane Graber有关LXD连载博文的开篇. 我们一年半前开始这个项目,当越来越接近LXC,LXD和LXCFS 2.0的最终版本时,我想,是时候讨论一下LXD的一切. 这将是一个连载博文,和很多年前我写的"LXC 1.0我做了什么"系列类似,内容包括: [LXD 2.0系列开篇:是时候讨论LXD的一切			

		

	

				

		

			

                LXD 2.0系列之一：LXD简介
			

		

		

									

				本文讲的是LXD 2.0系列之一:LXD简介,[编者的话]第三方调查报告显示LXD有潜质成为一款受欢迎的第三方容器管理工具.本文是LXD核心维护者.加拿大程序员Stéphane Graber有关LXD连载博文的第一篇. [LXD 2.0系列开篇:是时候讨论LXD的一切了][LXD 2.0系列之一:LXD简介][LXD 2.0系列之二:LXD安装和配置][LXD 2.0系列之三:你的第一个LXD容器][LXD 2.0系列之四:资源管理][LXD 2.0系列之五:镜像管理][LXD 2.0系列之六:			

		

	

				

		

			

                LXD 2.0系列之三：你的第一个LXD容器
			

		

		

									

				本文讲的是LXD 2.0系列之三:你的第一个LXD容器,[编者的话]第三方调查报告显示LXD有潜质成为一款受欢迎的第三方容器管理工具.本文是LXD核心维护者.加拿大程序员Stéphane Graber有关LXD连载博文的第三篇. [LXD 2.0系列开篇:是时候讨论LXD的一切了][LXD 2.0系列之一:LXD简介][LXD 2.0系列之二:LXD安装和配置][LXD 2.0系列之三:你的第一个LXD容器][LXD 2.0系列之四:资源管理][LXD 2.0系列之五:镜像管理][LXD 2.0			

		

	

				

		

			

                LXD 2.0 系列（十二）：调试，及给LXD做贡献
			

		

		

									

				介绍 终于要结束了!这个大约一年前开始的这系列文章的最后一篇博文. LXD 入门 安装与配置 你的第一个 LXD 容器 资源控制 镜像管理 远程主机及容器迁移 LXD 中的 Docker LXD 中的 LXD 实时迁移 LXD 和 Juju LXD 和 OpenStack 调试,及给 LXD 做贡献 如果你从一开始就关注了这个系列,你应该已经使用了 LXD 相当长的时间了,并且非常熟悉它的日常操作和功能. 但如果出现问题怎么办?你可以做什么来自己跟踪问题?如果你不能,你应该记录什么信息,以便上游			

		

	

				

		

			

                Silverlight & Blend动画设计系列十二
			

		

		

									

				Silverlight & Blend动画设计系列十二:三角函数(Trigonometry)动画之自由旋转(Free-form rotation) 说到对象的旋转,或许就会联想到对象角度的概念.对象的旋转实现实际上就是利用对象 的角度改变来实现的位置变换,在<Silverlight & Blend动画设计系列二:旋转动画( RotateTransform)>一文中有对对象的不同角度变换的实现介绍,本篇要介绍的自由旋转( Free-form rotation)将借助<Fun			

		

	

				

		

			

                黄聪：Microsoft Enterprise Library 5.0 系列教程(二) Cryptography Application Block (高级)
			

		

		

									

				原文:黄聪:Microsoft Enterprise Library 5.0 系列教程(二) Cryptography Application Block (高级) 本章介绍的是企业库加密应用程序模块Cryptographyproviders中为对称加密配置Key文件的3种方式: create a new key  : 使用一串字符串作为Key,然后通过加密保存到一个Key文件中. use an existing DPAPI-protected key file  : 使用一个现有的Key文件进			

		

	

				

		

			

                xen虚拟化实战系列(十二)之xen虚拟机高可用之在线迁移
			

		

		

									

				原创作品,允许转载,转载时请务必以超链接形式标明文章 原始出处 .作者信息和本声明.否则将追究法律责任.http://koumm.blog.51cto.com/703525/1286643 xen虚拟化实战系列文章列表 xen虚拟化实战系列(一)之xen虚拟化环境安装xen虚拟化实战系列(二)之xen虚拟机安装xen虚拟化实战系列(三)之xen虚拟机复制xen虚拟化实战系列(四)之xen虚拟机扩展磁盘空间一法xen虚拟化实战系列(五)之xen虚拟机扩展磁盘空间再一法xen虚拟化实战系列(六)之x			

		

	

				

		

			

                LXD 2.0 系列（三）：你的第一个 LXD 容器
			

		

		

									

				这是 LXD 2.0 系列介绍文章的第三篇博客. LXD 入门 安装与配置 你的第一个 LXD 容器 资源控制 镜像管理 远程主机及容器迁移 LXD 中的 Docker LXD 中的 LXD 实时迁移 LXD 和 Juju LXD 和 OpenStack 调试,及给 LXD 做贡献 由于在管理 LXD 容器时涉及到大量的命令,所以这篇文章的篇幅是比较长的,如果你更喜欢使用同样的命令来快速的一步步实现整个过程,你可以尝试我们的在线示例! 创建并启动一个新的容器 正如我在先前的文章中提到的一样,LX