Up until recently in tripleo booting, from a cinder volume was confined to virtual instances, but now thanks to some recent work in ironic, baremetal instances can also be booted backed by a cinder volume.
Below I’ll go through the process of how to take a CentOS cloud image, prepare and load it into a cinder volume so that it can be used to back the root partition of a baremetal instance.
First I do make a few assumptions
- you have a working ironic in a tripleo overcloud
– if this isn’t something you’re familiar with you’ll find some instructions here
– If you can boot and ssh to a baremetal instance on the provisioning network then your good to go
- You have a working cinder in the TripleO overcloud with enough storage to store the volumes
- I’ve tested tripleo(and openstack) using RDO as of 2017-11-14, earlier versions had at least one bug and wont work
Baremetal instances in the overcloud traditionally use config-drive for cloud-init to read config data from, config-drive isn’t supported in ironic boot from volume, so we need to make sure that the metadata service is available. To do this, if your subnet isn’t already attached to one, you need to create a neutron router and attach it to the subnet you’ll be booting your baremetal instances with,
$ neutron router-create r1 $ neutron router-interface-add r1 provisioning-subnet
Each node defined in ironic that you would like to use for booting from volume needs to use the cinder storage driver, the iscsi_boot capability needs to be set and it requires a unique connector id (increment <NUM> for each node)
$ openstack baremetal node set --property capabilities=iscsi_boot:true --storage-interface cinder <NODEID> $ openstack baremetal volume connector create --node <NODEID> --type iqn --connector-id iqn.2010-10.org.openstack.node<NUM>
The last thing you’ll need is a image capable of booting from iscsi, we’ll be starting with the Centos Cloud image but need to alter it slightly so that its capable of booting over iscsi
1. download the image
$ curl https://cloud.centos.org/centos/7/images/CentOS-7-x86_64-GenericCloud.qcow2.xz > /tmp/CentOS-7-x86_64-GenericCloud.qcow2.xz $ unxz /tmp/CentOS-7-x86_64-GenericCloud.qcow2.xz
2. mount it and change root into the image
$ mkdir /tmp/mountpoint $ guestmount -i -a /tmp/CentOS-7-x86_64-GenericCloud.qcow2 /tmp/mountpoint $ chroot /tmp/mountpoint /bin/bash
3. load the dracut iscsi module into the ramdisk
chroot> mv /etc/resolv.conf /etc/resolv.conf_ chroot> echo "nameserver 22.214.171.124" > /etc/resolv.conf chroot> yum install -y iscsi-initiator-utils chroot> mv /etc/resolv.conf_ /etc/resolv.conf # Be careful here to update the correct ramdisk (check/boot/grub2/grub.cfg) chroot> dracut --force --add "network iscsi" /boot/initramfs-3.10.0-693.5.2.el7.x86_64.img 3.10.0-693.5.2.el7.x86_64
4. enable rd.iscsi.firmware so that dracut gets the iscsi target details from the firmware
The kernel must be booted with rd.iscsi.firmware=1 so that the iscsi target details are read from the firmware (passed to it by ipxe), this needs to be added to the grub config
5. leave the chroot, unmount the image and update the grub config
chroot> exit $ guestunmount /tmp/mountpoint $ guestfish -a /tmp/CentOS-7-x86_64-GenericCloud.qcow2 -m /dev/sda1 sh "/sbin/grub2-mkconfig -o /boot/grub2/grub.cfg"
You now have a image that is capable of mounting its root disk over iscsi, load it into glance and create a volume from it
$ openstack image create --disk-format qcow2 --container-format bare --file /tmp/CentOS-7-x86_64-GenericCloud.qcow2 centos-bfv $ openstack volume create --size 10 --image centos-bfv --bootable centos-test-volume
Once the cinder volume is finish creating(wait for it to become “available”) you should be able to boot a baremetal instance from the newly created cinder volume
$ openstack server create --flavor baremetal --volume centos-test-volume --key default centos-test $ nova list $ ssh firstname.lastname@example.org [centos@centos-test ~]$ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 10G 0 disk └─sda1 8:1 0 10G 0 part / vda 253:0 0 80G 0 disk [centos@centos-test ~]$ ls -l /dev/disk/by-path/ total 0 lrwxrwxrwx. 1 root root 9 Nov 14 16:59 ip-192.168.24.7:3260-iscsi-iqn.2010-10.org.openstack:volume-e44073e9-0df9-43a0-ad05-9a6c41c80670-lun-0 -> ../../sda lrwxrwxrwx. 1 root root 10 Nov 14 16:59 ip-192.168.24.7:3260-iscsi-iqn.2010-10.org.openstack:volume-e44073e9-0df9-43a0-ad05-9a6c41c80670-lun-0-part1 -> ../../sda1 lrwxrwxrwx. 1 root root 9 Nov 14 16:58 virtio-pci-0000:00:04.0 -> ../../vda
To see how the cinder volume target information is being passed to the hardware you need to take a look at the iPXE template for the server in questions e.g.
$ cat /var/lib/ironic/httpboot/<NODEID>/config <snip/> :boot_iscsi imgfree set username vRefJtDXrEyfDUetpf9S set password mD5n2hk4FEvNBGSh set initiator-iqn iqn.2010-10.org.openstack.node1 sanhook --drive 0x80 iscsi:192.168.24.7::3260:0:iqn.2010-10.org.openstack:volume-e44073e9-0df9-43a0-ad05-9a6c41c80670 || goto fail_iscsi_retry sanboot --no-describe || goto fail_iscsi_retry <snip/>
 – due to bug in dracut(now fixed upstream ) setting this means that the image can’t be used for local boot
 – https://github.com/dracutdevs/dracut/pull/298