SDB:KIWI Cookbook ONebula Cloud

截至 Kiwi 版本 4.91.3，kiwi-doc 包包含 suse-nebula-cloud 示例，该示例位于版本特定的目录中，即 /usr/share/doc/packages/kiwi/examples/extras。该示例会定期调整，以匹配 openSUSE 构建服务中 Cloud:OpenNebula 项目的新 OpenNebula 包的要求。因此，建议使用 kiwi-doc 包中的最新示例版本。

创建云镜像

准备时间

30 分钟

烹饪时间

60 分钟

配料

正在运行的 openSUSE 系统
与您希望基于其构建镜像的版本匹配的 openSUSE 仓库
已安装最新版本的 KIWI 工具集（至少版本 5.01.7）
已安装 kiwi-doc 包
大约 6.5 GB 的可用磁盘空间

kiwi-doc 包提供的示例仅在当前“受支持”的 openSUSE 版本上进行测试和支持。

在开始之前，请决定是否要沿途修改示例以自定义镜像以满足您的需求。该示例提供了云的基本设置。这意味着 VM 镜像存储在主节点的本地磁盘上，并通过 NFS 与云节点共享。云节点上的网络配置也使用最基本的方法，即设置网络桥接并允许所有 VM 连接到此网络桥接。有关更高级的存储和网络配置，请参阅 OpenNebula 文档。可以通过修改此示例提供的基本配置，将任何高级设置选项构建到 KIWI 生成的镜像中。

如果您想进行修改，建议将示例配置树复制到工作目录，例如

cp -r /usr/share/doc/packages/kiwi/examples/extras/<VERSION>/suse-nebula-cloud /tmp

就可以做到。如果不进行修改，您可以简单地使用 .readme 文件（/usr/share/doc/packages/kiwi/examples/extras/<VERSION>/suse-nebula-cloud.readme）中给出的命令。

此云基础设施示例使用 KVM（Linux 内核虚拟机）作为底层的虚拟化技术。这意味着您只能在支持虚拟化指令的硬件上部署云节点镜像。主节点镜像可以在虚拟机或“较弱”的机器上运行。让管理它的云的主节点镜像作为客户机运行是自找麻烦，因此“较弱”的机器和大量的存储空间可能是您最好的方法。

OpenNebula 还支持使用 Xen 作为底层的虚拟化技术。如果您更喜欢 Xen，则需要对示例配置文件（主节点、云节点和客户机镜像的 config.xml）进行适当的更改。其他所有内容都应该大致保持不变（尚未测试 Xen 部署）。

KIWI 的基本概念、配置树、配置文件等在其他示例中进行了说明。如果您还不熟悉 KIWI，请先查阅更基本的示例，不要将此云示例作为您的第一个 KIWI 项目。

有关云管理，请参阅 OpenNebula 文档。

创建主节点

在排除万难之后，让我们直接深入研究手头的主题。云计算的基本原理在互联网的其他地方得到了很好的解释，因此，我们将重点关注手头 OpenNebula 示例的细节。有关 OpenNebula 的所有详细信息，请参阅 OpenNebula 网站。

创建主节点配置

主节点配置树包含在 /usr/share/doc/packages/kiwi/examples/extras/<VERSION>/suse-nebula-cloud/cloud_head 中。让我们首先查看 config.xml 文件。类型部分配置如下

    <type image="oem" filesystem="ext3" boot="oemboot/suse-12.1" installstick="true" installboot="install" boottimeout="2">
        <oemconfig>
            <oem-boot-title>OpenNebula Head Node</oem-boot-title>
            <oem-shutdown>true</oem-shutdown>
            <oem-swap>true</oem-swap>
            <oem-swapsize>2048</oem-swapsize>
            <oem-unattended>true</oem-unattended>
        </oemconfig>
    </type>

该镜像是一个 OEM 镜像，即它是自安装的，如 image 属性的值所示。config.xml 文件中的 boot 属性值可能不同，具体取决于您正在查看的示例版本。该镜像设置为从 USB 驱动器部署，如 installstick 属性的值所示。使用 installboot 属性，我们选择默认启动选项为 install 模式，而不是尝试从硬盘启动。boottimeout 属性设置启动加载程序在启动所选选项之前等待的时间。在类型的基本配置之后，为 OEM 镜像配置了一些特定选项。首先，使用 <oem-boot-title> 元素将部署镜像的启动标题设置为 OpenNebula Head Node。<oem-shutdown> 元素的值设置为 true，以强制系统在部署后关机。结合 <oem-unattended> 功能，您可以将驱动器插入目标机器，打开它并离开。当您回来并且机器关闭时，您就知道部署已完成。多么方便。安装时间主要取决于系统中磁盘的大小，因为文件系统是在整个磁盘上创建的。如果您有一个大驱动器，您肯定有时间喝杯咖啡。

根密码在 config.xml 文件的 users 部分中设置为 cloudDemo。但是，根密码会在首次启动过程中更改，因此，此配置在某种程度上是无关紧要的（有关首次启动过程的更多信息，请参见下文）。

    <users group="root">
        <user pwd="cloudDemo" pwdformat="plain" home="/root" name="root"/>
    </users>

在继续配置树中的下一个文件之前，请查看仓库的配置。除了分发版本的“标准”仓库之外，还添加了来自 openSUSE 构建服务的 Cloud:OpenNebula 项目仓库。此仓库提供了安装 OpenNebula 作为云基础设施所需的软件包。

config.xml 文件的其余部分非常标准，应该可以自行解释。

接下来，让我们看一下 config.sh 脚本。在 openSUSE 12.1 示例中，您会找到如下所示的代码，用于操作 opennebula 和 opennebula-sunstone 的默认服务文件。

  sed -i 's/\[Unit\]/\[Unit\]\nAfter=YaST2-Firstboot.service\nRequisite=YaST2-Firstboot.service/' /lib/systemd/system/sunstone.service
  sed -i 's/\[Unit\]/\[Unit\]\nAfter=YaST2-Firstboot.service\nRequisite=YaST2-Firstboot.service/' /lib/systemd/system/one.service

我们希望确保在首次启动过程（有关首次启动过程的更多信息，请参见下文）完成后启动服务。使用 KIWI 提供的 suseInsertService 函数添加服务到系统。

  suseInsertService nfsserver
  suseInsertService sshd

这些调用启用了系统上的 NFS 和 SSH 服务。suseInsertService 函数透明地处理 SysV init 系统和 systemd 实现之间的差异。在版本 12.1 示例中，您还会找到以下内容

  suseInsertService cloudinfo
  suseInsertService noderegistrar
  suseInsertService one
  suseInsertService rcpbind
  suseInsertService sunstone

不在这个顺序

在 openSUSE 12.1 之前和 systemd 之前，这些服务在 finalizeSetup 脚本的末尾启用。通过 SysV init 和 systemd 之间的行为变化，现在这些服务在构建阶段启用。通过前面显示的 sed 命令对 systemd 单元文件进行操作，确保了适当的排序。

OpenNebula 使用 ssh 在云节点和主节点之间进行操作。NFS 服务器需要导出云管理员（oneadmin）的主目录并允许在云节点上通过 NFS 挂载它。请注意，在 openSUSE 12.1 中，并非所有服务都完全集成到 systemd 中，因此需要手动排序，在 config.sh 中找到了适当的注释。有关云管理员和共享主目录的信息，请参阅 OpenNebula 文档中的“规划安装”。

在添加服务之后，我们通过修改 FIRSTBOOT_WELCOME_DIR 变量使用 KIWI 提供的 baseUpdateSysConfig 函数来设置首次启动过程的欢迎文本。此函数仅修改现有值，不会将新变量插入配置文件中。如注释所示，禁用 IPv6 以用于云。

  baseUpdateSysConfig /etc/sysconfig/firstboot FIRSTBOOT_WELCOME_DIR /usr/share/susenebula
  # Disable IPv6
  echo “alias net-pf-10 off” >> /etc/modprobe.conf.local
  echo “alias ipv6 off” >> /etc/modprobe.conf.local

最后但并非最不重要的一点，我们修复了一些重要的权限，以使一切正常工作并允许我们以非 root 用户身份运行云基础设施。

  # Directory for authentication file must exist such that YaST module can
  # write the file
  mkdir /var/lib/one/.one
  # Set the desired permissions
  chown oneadmin:cloud /var/lib/one/.one
  # The permissions for the testcase
  chown -R oneadmin:cloud /home/ctester

/var/lib/one 目录是 opennebula 包在 OBS 上的 OpenNebula 项目中构建时设置的 oneadmin 用户的家目录。ctester 目录设置在叠加树中，可用于基于此示例提供的配置测试云的基本功能。如果您构建了自己的云，则不需要此目录，它仅用于演示和验证目的。

通常，在使用 KIWI（以及必然的系统配置）构建镜像时，不需要进行所有权管理，因为 kiwi 通常会设置适当的所有权。但是，在这种情况下，我们正在超出 kiwi 的所有权分配算法的范围。Kiwi 应用一个简单的所有权规则。用户主目录中的所有内容都由该用户拥有，在镜像构建期间创建的所有内容都由 root 拥有。在我们的例子中，我们没有在 config.xml 文件中创建一个 ctester 用户，因为系统不需要“ctester”用户帐户。因此，kiwi 将 /home/ctester 目录（来自叠加树，稍后会对此进行介绍）视为 kiwi 未分配所有权权限的已创建目录。这导致 kiwi 将所有权设置为 root。但是，由于我们希望将此目录用作云基础设施的测试用例，因此我们需要 oneadmin 用户具有读/写访问权限。

config.sh 文件中的其他条目非常标准，不应需要解释。

现在让我们看一下叠加树的内容。由于这是一个 KIWI（以及必然的系统配置）示例，而不是给定编程语言或相关主题的教程，因此省略了脚本的实现细节。

对于 openSUSE 12.1 之前的版本，cloud_head/root/etc/init.d 中存在两个 init 脚本。一个用于控制注册服务，另一个用于控制信息服务，稍后会对此进行介绍。对于 openSUSE 12.1 及更高版本，这些服务的控制由 systemd 处理，单元文件位于 cloud_head/root/lib/systemd/system 中。

cloud_head/root/etc/YaST2/ 目录包含描述首次启动过程的 firstboot.xml 文件。config.sh 中设置的 FIRSTBOOT_WELCOME_DIR 变量引导首次启动过程来获取在 cloud_head/root/usr/share/susenebula/welcome.txt 中找到的专用欢迎消息。首次启动过程配置为显示许可证（如果存在），并让用户配置键盘布局、时间和日期以及根密码。这些是标准的 YaST 模块。firstboot.xml 中描述的最终配置步骤是一个名为 opennebula.ycp 的自定义模块，位于 cloud_head/root/usr/share/YaST2/clients/ 中。此模块用于配置完成主节点设置所需的信息。cloud_head/root/usr/share/firstboot/scripts/finalizeSetup（用 Python 编写）脚本在首次启动过程中所有基于“GUI”的步骤完成后运行。有关配置首次启动过程的信息，请参阅 YaST Firstboot 文档。有关 ycp，YaST 模块的实现语言，请参阅 YaST 文档。叠加树中与首次启动相关的最后一部分是文件 cloud_head/root/var/lib/YaST2/reconfig_system。此文件是“空的”（实际上它包含一个 1，否则将被用于开发 KIWI 的源代码控制系统删除），并且是启动首次启动过程的触发文件，只需存在即可。

上述 init 系统控制的服务是 cloud_head/root/usr/sbin/suseNebulaRegSrv 和 cloud_head/root/usr/sbin/suseNebulaConfSrv（在 openSUSE 12.1 之前的版本中，这些文件位于 /sbin）。这两个服务都是用 Python 实现的。suseNebulaRegSrv 是注册服务，允许云节点在首次启动时（cloud node firstboot）进行注册。基本上，它是一个服务，在头节点配置的网络接口上监听端口 8445，并根据连接发送者提供的信息，将云节点注册到头节点上运行的云基础设施代码中。注册服务还会修改文件 /etc/dhcpd.conf，以确保注册的节点始终获得相同的 IP 地址，否则云节点每次启动时都需要更改与云基础设施的注册信息，这完全没有必要。在 suseNebulaConfSrv 中实现的提供信息服务，为云节点提供信息，以便云节点可以进行自配置。提供的信息包含由 opennebula 包在头节点上创建的 oneadmin 帐户的用户和组信息。它还包含头节点的 IP 地址，云节点代码使用该 IP 地址在 /etc/fstab 中设置挂载信息（更多信息请参见云节点部分）。请查看代码，以了解通过信息服务提供的所有信息。

我们还有一个 cloud_head/root/etc/exports 导出文件。该文件只是导出 /var/lib/one 目录，以便可以通过 NFS 挂载。

最后，我们到达 cloud_head/root/home/ctester 目录。该目录的内容仅用于支持对云设置功能的快速验证。设置好头节点和一个云节点后，可以将 cloud_guest 镜像创建的 .qcow2 镜像复制到 /home/ctester 目录，然后以 oneadmin 用户身份运行 startTestVM 脚本。这将注册镜像并启动镜像的 VM。文件 testVM.dsconf、testVM.one 和 testVM.vmd 分别是 OpenNebula 镜像存储设置、镜像注册和 VM（虚拟机）设置的配置文件。有关配置文件的详细信息，请参阅 Image Guide。.README 文件对此有简短的提醒。

在继续检查云节点设置之前，关于头节点还有一些细节。头节点在配置的网络桥接（br0）上运行 DHCP 服务器（仅 IPv4）。该桥接具有在首次启动期间配置的静态 IP 地址，并且具有链路本地 IP 169.254.1.1 的别名。链路本地 IP 用作信息服务在端口 8445 上监听的 IP。这样，我们可以将云节点的发现信息硬编码为连接到此别名，而无需通过 avahi 进行动态发现（在这种情况下，avahi 会过于复杂）。此外，我们的 DHCP 服务器已设置为具有“特殊功能”（这发生在 opennebula.ycp YaST 模块中）。此“特殊功能”标识此 DHCP 服务器，我们使用它来确保云节点仅接受来自此 DHCP 服务器的租约。因此，即使网络上存在其他 DHCP 服务器，我们的云节点也不会接受租约，除非它们是由云头节点提供的。有关使用此小功能的详细信息，您可以浏览 opennebula.ycp 代码或查阅 DHCP man pages。

这基本上解释了头节点的镜像设置，并涵盖了正在运行的头节点的设置和功能。现在是时候继续云节点镜像了。

创建云节点

对于 OpenNebula 云节点，我们只需要一台运行 hypervisor 的机器，云节点上没有安装 OpenNebula 代码。所需的 OpenNebula 代码包含在 oneadmin 用户的 NFS 挂载主目录中。云节点的这种最小要求反映在云节点的 config.xml 文件中。

创建云节点配置

与基本的基于 KVM 的 hypervisor 配置的区别在于额外的 Ruby 包。云节点配置设置为 OEM 镜像，就像头节点一样。因此，<type> 元素定义仅与头节点定义中的 GRUB 菜单条目的标题不同。与头节点配置一样，设置了 root 用户密码。但是，这无关紧要，因为云节点将在自配置过程中继承头节点配置期间设置的 root 密码。

config.sh 文件关闭 IPv6，如头节点配置中看到的，并将 IPv6 DHCP 客户端设置为 /bin/false 以禁用 IPv6 DHCP 客户端的启动。

  # Disable IPv6
  baseUpdateSysConfig /etc/sysconfig/network/dhcp DHCLIENT6_BIN /bin/false
  echo “alias net-pf-10 off” >> /etc/modprobe.conf.local
  echo “alias ipv6 off” >> /etc/modprobe.conf.local
  sed -i "s/#net.ipv6.conf.all.disable_ipv6 = 1/net.ipv6.conf.all.disable_ipv6 = 1" /etc/sysctl.conf

以下行在 config.sh 中，

  baseUpdateSysConfig /etc/sysconfig/network/dhcp DHCLIENT_BIN dhclient

将 DHCP 客户端设置为 ISC 客户端，而不是默认的 dhcpcd 客户端。设置此设置的原因是 dhcpcd 不尊重 /etc/dhclient.conf 中的设置，并且没有选项可以配置从特定 DHCP 服务器接受租约的限制。云节点的自配置、云节点注册和正确的云操作都依赖于此 DHCP 功能。因此，必须在云节点（以及客户机镜像内）使用 ISC 客户端。当然还有其他网络配置选项，请参阅 Networking Guide 以获取更多信息。DHCP 客户端的配置发生在 cloudNodeConfig 脚本中（稍后会详细介绍此脚本）。

在 dhcp 设置之后，config.sh 脚本修改了 libvirt 守护程序的配置文件。

  sed -i "s/#listen_tcp = 1/listen_tcp = 1/" /etc/libvirt/libvirtd.conf

此更改允许 libvirt 守护程序侦听 tcp 连接。OpenNebula 基础设施使用 libvirt API 来管理云节点上的虚拟机。libvirt 守护程序在云节点上作为 config.sh 通过以下方式插入服务运行

  suseInsertService libvirtd

在镜像构建过程中。与头节点配置一样，openSUSE 12.1 和早期版本之间服务激活的处理方式存在差异。

在 config.sh 中更改 libvitd 配置文件后，以下行修改了 qemu 配置文件。

sed -i "s/#dynamic_ownership = 1/dynamic_ownership = 0/" /etc/libvirt/qemu.conf
sed -i "s/#user = \"root\"/user = \"oneadmin\"/" /etc/libvirt/qemu.conf
sed -i "s/#group = \"root\"/group = \"cloud\"/" /etc/libvirt/qemu.conf

第一次更改可防止由 libvirtd 运行的 qemu 进程动态更改镜像的所有权。这可能会导致权限问题。对 qemu.conf 的第 2 次和第 3 次更改将进程所有权设置为云组中的 oneadmin 用户。这对于防止在从属于 oneadmin 用户拥有的磁盘镜像文件启动 VM 时出现权限问题是必要的。

最后但并非最不重要的一点，从 qemu-kvm 可执行文件到名称 kvm 的软链接已创建。kvm 名称硬编码到 OpenNebula 代码中，未由 qemu 包提供。这完成了 config.sh 文件的概述。

云节点镜像的叠加树比头节点镜像的叠加树简单一些。节点的 hostname 预先配置为 node-1，位于 cloud_cloud/root/etc/HOSTNAME 中。但是，此设置将在首次启动时的自配置阶段更改（毕竟，我们不希望所有云节点都命名为 node-1）。头节点维护一个计数器，节点会分配一个 hostname（有关详细信息，请参阅 cloud_head/root/sbin/suseNebulaConfSrv 的实现）。首次启动的“魔术”由 cloud_cloud/root/etc/init.d/boot.local 的实现处理，对于 openSUSE 12.1，这将被 cloud_cloud/root/lib/systemd/system 中的服务替换，该服务在存在触发文件 cloud_cloud/root/var/lib/firstboot 的情况下调用 cloud_cloud/root/usr/share/firstboot/scripts/cloudNodeConfig 脚本。cloudNodeConfig 脚本找到第一个连接的网络接口，并将网络配置为链路本地地址 169.254.1.2。这样，头节点上端口 8445 上运行的配置服务就可以联系到 169.254.1.1，并检索配置信息。这种设置导致内置的竞争条件，当两个节点同时运行首次启动时会发生竞争条件，在第一次打开节点时大约 10 秒的延迟应该足以避免竞争条件。作为自配置的一部分，云节点上的 /etc/fstab 文件被修改，以启用 oneadmin 用户主目录到 /var/lib/one 的 NFS 挂载。配置节点后，使用绑定到第一个以太网设备 (eth0) 的桥接 (名为 br0) 设置生产/云网络。获得来自头节点的 dhcp 地址后，该地址将与头节点注册，以确保如果云节点重新启动，它将获得相同的 IP 地址。云节点的自配置和注册的各个方面都包含在相当简单的 cloudNodeConfig 脚本中（用 Python 实现）。最后，叠加树包含以下 Policykit 规则

[Remote libvirt SSH access]
 Identity=unix-user:oneadmin
 Action=org.libvirt.unix.manage
 ResultAny=yes
 ResultInactive=yes
 ResultActive=yes

这允许 oneadmin 用户访问 libvirt 并控制云中的虚拟机。该规则包含在 cloud_cloud/root/etc/polkit-1/localauthority/50-local.d/60-suseNebula-access.pkla 文件中。

这完成了云节点的配置。根据提供的 .readme 文件中的说明构建镜像。构建完成后，您可以将生成的镜像转储到 USB 驱动器上，并使用它来安装您想要添加到云设置中的任意数量的云节点。与头节点一样，安装以无人值守模式进行，机器将在初始安装完成后自行关闭。在移除 USB 驱动器后首次启动（首次启动）时，云节点将如前所述进行自配置。无需将键盘或显示器连接到云节点，只需打开机器并“观看”（实际上没有什么可看的）魔术发生。云节点当然必须连接到与头节点相同的网络。

您可以监视头节点上的系统日志，以查看云节点注册何时完成，或者您可以简单地使用头节点上的 onehost list 命令来监视新云节点何时出现。消息会写入头节点和云节点上的系统日志。

创建客户机

设置 OpenNebula 云基础设施很棒，但如果没有在基础设施上运行的虚拟机，该设置就不是真正的云。随 KIWI 示例提供的客户机镜像配置只是一个基本的镜像，用于显示客户机镜像的格式。以这个示例为指导，您可以相对容易地构建满足您需求的客户机镜像。此外，您可以使用其他人构建的虚拟机。请查看 SUSE Gallery，您可能会找到您想要的东西，而无需构建镜像。对于更多的 GUI 乐趣，您可以遵循 OpenNebula 网站上的 Using SUSE Studio with OpenNebula 指南，使用 SUSE Studio 构建镜像。

底层的 KVM 虚拟化技术也乐于处理 VMware 镜像，因此您不一定需要本地 KVM 虚拟磁盘镜像。在 OpenNebula 中使用不同的镜像类型在 VM 配置模板中配置，请参阅 OpenNebula 文档。

创建客户机配置

config.xml 文件仅指定一组最小的软件包。关键是 <type> 元素设置。

  <type image="vmx" primary="true" filesystem="ext4" boot="vmxboot/suse-12.1" format="qcow2"/>

客户机镜像是一个虚拟机，因此我们需要镜像的类型为 vmx，并且由于我们已选择 KVM 作为云的虚拟化基础设施，因此我们希望我们的客户机镜像采用 qcow2 格式，即本地 KVM 镜像格式。config.xml 文件的其余部分是“标准”内容，应该很熟悉。

config.sh 脚本有一些自定义设置，如下所示

  baseUpdateSysConfig /etc/sysconfig/bootloader LOADER_LOCATION mbr
  baseUpdateSysConfig /etc/sysconfig/network/dhcp DHCLIENT_BIN dhclient
  # Disable IPv6
  baseUpdateSysConfig /etc/sysconfig/network/dhcp DHCLIENT6_BIN /bin/false
  echo “alias net-pf-10 off” >> /etc/modprobe.conf.local
  echo “alias ipv6 off” >> /etc/modprobe.conf.local
  sed -i "s/#net.ipv6.conf.all.disable_ipv6 = 1/net.ipv6.conf.all.disable_ipv6 = 1" /etc/sysctl.conf

  echo "option suse-nebula code 239 = ip-address;" >> /etc/dhclient.conf
  echo "require suse-nebula;" >> /etc/dhclient.conf
  echo "request suse-nebula;" >> /etc/dhclient.conf

与头节点和云节点一样，IPv6 已禁用。引导加载程序位置设置为 Master Boot Record (MBR)，并且 ISC dhclient 被配置为 DHCP 客户端。我们希望客户机从运行在云头节点上的 DHCP 服务器获取其 IP 地址，而不是云可能连接的网络上的其他 DHCP 服务器。在此示例中，控制租约提供被接受的 DHCP 功能（上述代码片段的最后 3 行）被硬编码为头节点配置中的默认设置。对这个设置进行硬编码是完全合理的，因为您将在配置头节点并设置 KIWI 配置以用于您的客户机后，知道您分配给 dhcp 服务器的功能名称。如果您有多个云或想要更灵活一些，您可以添加类似于云节点自配置的自配置。对于客户机，您只需要来自头节点的 dhcp 功能。

叠加树基本上是空的，仅包含足够的信息来启动客户机中的网络。

根据提供的 .readme 文件中的信息构建客户机镜像。生成的镜像可以轻松地在具有 KVM 的机器上进行测试，只需运行 qemu-kvm 并提供镜像的路径即可。这样，您就可以确保您的镜像在部署到云之前表现如您所期望。请注意客户机镜像中的 DHCP 设置，如果您在没有网络访问云头节点的机器上进行测试，将无法通过网络进入该机器。

这就是全部。如果您将生成的镜像复制到云头节点上的 /home/ctester 目录，将其权限更改为可被 oneadmin 用户读取，然后以 oneadmin 用户身份运行 startTestVM 脚本，则创建的客户机镜像将被部署到云中。客户机运行着 sshd，因此您可以连接到它，或者您可以使用 vncviewer 连接到端口 5905（参见 testVM.vmd）的云节点，虚拟机已放置在该节点上（使用 onevm list 获取信息）。

在结束之前，快速说明一下 oneadmin 用户帐户。该用户由 OBS 中的 opennebula 包设置，并且在安装过程中会为 oneadmin 用户生成一个随机密码。该软件包还会为 oneadmin 帐户创建 ssh 密钥。无需以 oneadmin 用户身份登录即可操作 OpenNebula 云。对于引用“以 oneadmin 用户身份运行”的说明，请使用 sudo -u oneadmin 命令。作为管理员，您当然可以自由地根据自己的喜好更改此行为。

GUI 呢？

OpenNebula 通过 Sunstone 服务提供 Web-UI 进行云管理。KIWI 版本 4.91.3 中包含的配置未激活或考虑 Web-UI 服务。从 KIWI 版本 4.92.3 开始，提供的配置支持使用 Sunstone 服务。对于 openSUSE 12.1 之前的版本，sunstone 服务在 finalizeSetup 的末尾插入，而对于 12.1 及更高版本，如前所述，该服务在 config.sh 中插入。系统启动后，您可以从可以连接到头节点的机器上的浏览器连接到端口 9869 上的 Web-UI。

摘要

这个示例提供了构建“盒子里的云”所需的一切。在不到 2 小时的时间内，您可以启动并运行一个私有云。

有关云管理，请参考 OpenNebula 文档。