Openstack Juju 安装问题：实例启动时“文件系统结构不一致”

Question

我正在尝试使用 Openstack 设置集群。我之前曾在此集群上部署过 Train，它对我来说效果很好。我现在正在尝试根据此处提供的说明安装最新版本 Antelope、MAAS 和 Juju 捆绑包。 （我也尝试了个人魅力部署指南，但遇到了同样的问题。）

我已经使用 MAAS 调配/配置了我的机器（已调试的机器，在所有节点上将

br-ex

设置为 Open VSwitch 桥接器，为 ceph-osd 配置分区）引导 juju，设置 Vault/Placement 并且 juju 报告一切正常：

通过CLI或Horizon访问Openstack没问题，并且我已经设置了镜像、安全组、风格、公共网络、子网等。创建实例在Openstack中没有报告错误，但实例无法启动。 （我尝试过使用 cirros 映像和 Ubuntu Jammy 映像。）从控制台，我看到此错误：

我检查了虚拟机管理程序上的 /var/log/nova ，它没有显示任何错误。我还检查了各种机器上的概览、keystone、ceph 和 cinder 日志，但我没有看到任何看起来可能相关的内容。我已经从 Openstack 重新下载了图像，它们与我上传的图像匹配，并验证了我从官方存储库下载的这些图像是否匹配。

我还可以在哪里检查错误，或者任何人都需要哪些附加信息来帮助调试正在发生的事情？谢谢！

更新 登录虚拟机管理程序并检查用于启动实例的映像文件后，nova 似乎由于某种原因未正确下载实例的映像文件。不过，它在日志中没有显示任何错误。我通过安装基本映像文件来检查这一点，它几乎只有启动信息：

root@shen35:/var/lib/nova/instances/_base# file 615313348ae2e8ff2099cc01b35e30cf6e754d3d
jdh_img_test: DOS/MBR boot sector; GRand Unified Bootloader, stage1 version 0x3, 1st sector stage2 0x10c22, extended partition table (last)

root@shen35:/var/lib/nova/instances/_base# fdisk -l 615313348ae2e8ff2099cc01b35e30cf6e754d3d
Disk 615313348ae2e8ff2099cc01b35e30cf6e754d3d: 112 MiB, 117440512 bytes, 229376 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: F05EDE64-4EFD-477A-B01E-B37CCD5D3EB4

将两个分区安装在那里，可以看到看起来很正常的 grub 文件：

ls -R jdh_mount
jdh_mount:
EFI

jdh_mount/EFI:
BOOT  ubuntu

jdh_mount/EFI/BOOT:
bootx64.efi

jdh_mount/EFI/ubuntu:
grub.cfg
root@shen35:/var/lib/nova/instances/_base# fdisk -l jdh_img_test
Disk jdh_img_test: 112 MiB, 117440512 bytes, 229376 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: F05EDE64-4EFD-477A-B01E-B37CCD5D3EB4

Device         Start    End Sectors  Size Type
jdh_img_test1  18432 229342  210911  103M Linux filesystem
jdh_img_test15  2048  18431   16384    8M EFI System

Partition table entries are not in disk order.



root@shen35:/var/lib/nova/instances/_base# ls -R
.:
615313348ae2e8ff2099cc01b35e30cf6e754d3d  ephemeral_20_40d1d2c  jdh_img_test  jdh_mount  jdh_mount_linux

./jdh_mount:

./jdh_mount_linux:
boot  initrd.img  lost+found  vmlinuz

./jdh_mount_linux/boot:
config-5.3.0-26-generic  grub  initrd.img-5.3.0-26-generic  vmlinuz-5.3.0-26-generic

./jdh_mount_linux/boot/grub:
e2fs_stage1_5  menu.lst  stage1  stage2

./jdh_mount_linux/lost+found:

令我惊讶的是，其中显然没有操作系统的文件，只有引导文件。我检查了另一个基本文件，它是附加到映像的临时磁盘。很好，但也完全是空的。因此，我想我可以确认实例未启动的原因是，尽管 grub 设置正常，但没有任何映像文件实际上包含操作系统。那么，为什么 nova-compute 无法获得正确的图像呢？

更新2： 我用 Ubuntu Jammy 重试了之前的实验，看起来 nova 实际上正在正常下载镜像。 cirros 操作系统中的小分区与我在将其发送到 openstack 之前下载的映像相匹配。但是，Jammy 也不会启动：

所以，现在我认为图像已正确下载，但 QEMU 无法正确运行它们。检查 qemu 如何使用

ps

运行，我看到了这个命令的噩梦：

/usr/bin/qemu-system-x86_64 -name guest=instance-00000004,debug-threads=on -S -object {"qom-type":"secret","id":"masterKey0","format":"raw","file":"/var/lib/libvirt/qemu/domain-4-instance-00000004/master-key.aes"} -machine pc-i440fx-6.2,usb=off,dump-guest-core=off,memory-backend=pc.ram -accel kvm -cpu Broadwell-IBRS,vme=on,ss=on,vmx=on,pdcm=on,f16c=on,rdrand=on,hypervisor=on,arat=on,tsc-adjust=on,umip=on,md-clear=on,stibp=on,arch-capabilities=on,ssbd=on,xsaveopt=on,pdpe1gb=on,abm=on,ibpb=on,ibrs=on,amd-stibp=on,amd-ssbd=on,skip-l1dfl-vmentry=on,pschange-mc-no=on -m 2 -object {"qom-type":"memory-backend-ram","id":"pc.ram","size":2097152} -overcommit mem-lock=off -smp 1,sockets=1,dies=1,cores=1,threads=1 -uuid d4920f5a-0491-4e1f-b1fc-875660d11eda -smbios type=1,manufacturer=OpenStack Foundation,product=OpenStack Nova,version=27.0.0,serial=d4920f5a-0491-4e1f-b1fc-875660d11eda,uuid=d4920f5a-0491-4e1f-b1fc-875660d11eda,family=Virtual Machine -no-user-config -nodefaults -chardev socket,id=charmonitor,fd=39,server=on,wait=off -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc,driftfix=slew -global kvm-pit.lost_tick_policy=delay -no-hpet -no-shutdown -boot strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -blockdev {"driver":"file","filename":"/var/lib/nova/instances/_base/56f431310d4bce927e45584a70e34f29141f40af","node-name":"libvirt-4-storage","cache":{"direct":true,"no-flush":false},"auto-read-only":true,"discard":"unmap"} -blockdev {"node-name":"libvirt-4-format","read-only":true,"discard":"unmap","cache":{"direct":true,"no-flush":false},"driver":"raw","file":"libvirt-4-storage"} -blockdev {"driver":"file","filename":"/var/lib/nova/instances/d4920f5a-0491-4e1f-b1fc-875660d11eda/disk","node-name":"libvirt-2-storage","cache":{"direct":true,"no-flush":false},"auto-read-only":true,"discard":"unmap"} -blockdev {"node-name":"libvirt-2-format","read-only":false,"discard":"unmap","cache":{"direct":true,"no-flush":false},"driver":"qcow2","file":"libvirt-2-storage","backing":"libvirt-4-format"} -device virtio-blk-pci,bus=pci.0,addr=0x4,drive=libvirt-2-format,id=virtio-disk0,bootindex=1,write-cache=on -blockdev {"driver":"file","filename":"/var/lib/nova/instances/_base/ephemeral_20_40d1d2c","node-name":"libvirt-3-storage","cache":{"direct":true,"no-flush":false},"auto-read-only":true,"discard":"unmap"} -blockdev {"node-name":"libvirt-3-format","read-only":true,"discard":"unmap","cache":{"direct":true,"no-flush":false},"driver":"raw","file":"libvirt-3-storage"} -blockdev {"driver":"file","filename":"/var/lib/nova/instances/d4920f5a-0491-4e1f-b1fc-875660d11eda/disk.eph0","node-name":"libvirt-1-storage","cache":{"direct":true,"no-flush":false},"auto-read-only":true,"discard":"unmap"} -blockdev {"node-name":"libvirt-1-format","read-only":false,"discard":"unmap","cache":{"direct":true,"no-flush":false},"driver":"qcow2","file":"libvirt-1-storage","backing":"libvirt-3-format"} -device virtio-blk-pci,bus=pci.0,addr=0x5,drive=libvirt-1-format,id=virtio-disk1,write-cache=on -netdev tap,fd=42,id=hostnet0,vhost=on,vhostfd=44 -device virtio-net-pci,host_mtu=1500,netdev=hostnet0,id=net0,mac=fa:16:3e:dd:7e:73,bus=pci.0,addr=0x3 -add-fd set=3,fd=41 -chardev pty,id=charserial0,logfile=/dev/fdset/3,logappend=on -device isa-serial,chardev=charserial0,id=serial0 -device usb-tablet,id=input0,bus=usb.0,port=1 -audiodev {"id":"audio1","driver":"none"} -vnc 10.246.117.211:2,audiodev=audio1 -device virtio-vga,id=video0,max_outputs=1,bus=pci.0,addr=0x2 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6 -object {"qom-type":"rng-random","id":"objrng0","filename":"/dev/urandom"} -device virtio-rng-pci,rng=objrng0,id=rng0,bus=pci.0,addr=0x7 -device vmcoreinfo -sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny -msg timestamp=on

不过，没有什么明显的错误。仍然不知道出了什么问题。

Answer 1

我终于明白问题出在哪里了。我的 openstack

flavor

将

--ram

设置为

2

。意思是2MB，不是我想象的那样（2GB）。这导致 grub 无法加载内核，并给出非常无用的错误消息。是的，这确实花了我一个多月的时间才弄清楚。 :/