# Boot from ISO, install to volume, reboot from volume

Hi,

this is the very classic case where you have software in an ISO image (e.g. a Linux Debian installer ISO), you want to install it on a disk, and then always boot from your disk.

This was easily done with Grizzly, however I don't seem to be able to achieve the same with Icehouse. How do I achieve it in Icehouse?

On my Devstack/Icehouse setup running on Ubuntu 14.04 with KVM I've tried the following (e0cba508-981e-476d-a7fc-9e2d49c84b7b is the ID of my ISO image, which (FYI) is a Debian Jessie Net installer):

1) nova boot --flavor 2 --block-device source=image,id=e0cba508-981e-476d-a7fc-9e2d49c84b7b,dest=volume,size=2,shutdown=remove,bootindex=0 --nic net-id=5dedde68-3b6f-4ce3-b289-cfdeb143eef5 MyVM-1

This works with qcow2 images but not with ISO images, which fail with "No bootable device". While it is probably expected, IMHO documentation at http://docs.openstack.org/user-guide/... should explicitly mention it.

2) nova boot --flavor 2 --image e0cba508-981e-476d-a7fc-9e2d49c84b7b --block-device source=volume,id=3b0d0f7f-2738-471a-acbc-16c61b4abb35,dest=volume,shutdown=remove --nic net-id=5dedde68-3b6f-4ce3-b289-cfdeb143eef5 MyVM-2

This boots the image from ISO and I can install the software on the volume. However, VM will always boot from CDROM and never from the volume

$virsh dumpxml instance-00000047|grep 'boot dev' <boot dev='cdrom'\/>$


3) nova boot --flavor 2 --image e0cba508-981e-476d-a7fc-9e2d49c84b7b --block-device source=volume,id=3b0d0f7f-2738-471a-acbc-16c61b4abb35,dest=volume,shutdown=remove,bootindex=0 --nic net-id=5dedde68-3b6f-4ce3-b289-cfdeb143eef5 MyVM-3

ERROR (BadRequest): Block Device Mapping is Invalid: Boot sequence for the instance and image/block device mapping combination is not valid. (HTTP 400) (Request-ID: req-70a7f366-e54e-48c2-8451-a1c2563f5c9d)


How do I force something like

<boot dev='hd'/>
<boot dev='cdrom'/>


in libvirt's domain config so that it boots from cdrom when hd is not bootable?

So far the only way I could achieve something similar to what I wanted is use option 2) with shutdown=preserve, install my software on the volume, terminate my instance and later on boot from volume or a snapshot of that volume. However this is a nightmare and I cannot possibly think of doing this for all my different ISOs.

Thank you in advance.

Kind Regards,

Paolo

edit retag close merge delete

Sort by » oldest newest most voted

I have had problems along the same vein. The only option I was able to come up with was some database hacking and a hard reboot to regenerate the virsh config.

It is not a pretty option but you _can_ fix this with some database triggers. Otherwise you will need to dig into the source to make the appropriate updates to the database. I was utterly unsuccessful in modifing the source to meet my needs in this area. I went with triggers.

more

What I've done to accomplish this task is to play with the image/volume and block storage services, via the Dashboard (sorry, am a little lazy to use the CLI right now): try this:

1. Upload your ISO image in ISO format
2. Create a Volume with Size according to the installation of your ISO image, be sure to mark it as bootable
3. Launch an instance from the ISO image, don't worry about the Flavor, just choose o create one that lets you build the instance.
4. BEFORE starting your installation of your ISO image, attach the volume you created on step 2 to this instance
5. Proceed with installation in the instance, be sure to identify the volume and install your distro or OS there.
6. Once you have finished the installation, stop the instance, detach the volume and you can safely delete the Instance
7. Go to Volumes, select the one you created and choose "Upload to Images"
8. Launch your new installed OS or Distro from the Image you've just created!

Hope this helps somebody :)

more

I found a sneaky way to do something like this. I can't guarantee it will work for you too, but I wanted to share it.

I am on Newton. basically you can change the libvirt xml file and the restart the instance via virsh fast enough that openstack doesn't re-write the xml file (until the instance is restarted normally)

so, make 2 volumes the first volume is a empty disk. say 40GB, no source, empty volume, bootable the second volume is created using the DVD ISO of the install media for source. say CentOS-4.8-64bit-binDVD.iso or any OS install, bootable.

create an instance using the first volume as vHD, when the instance boots it will fail because vda is a empty drive. note: there may also be a vdb if a metadata drive is being defined automatically.

attach the second DVD ISO volume to the instance, this may end up being vdc.

Boot the instance again to see it fails boot again for the same reason as above

find the hypervisor running the instance, and the instance's uuid

login to the hypervisor and find the instance you are working with "grep <uuid> /etc/libvirt/qemu"

say grep shows filename instance-00001cd1.xml

run "virsh edit instance-00001cd1"

reorder the <disk..... <="" disk=""> sections so that the vdc DVD ISO volume is first.

exit the editor and quickly "virsh destroy instance-00001cd1" (destroy is only a stop/shutdown)

and then quickly "virsh start instance-00001cd1"

if all has gone well openstack won't re-write to the instance-00001cd1.xml file and the DVD ISO volume will boot. check the console.

install the OS onto vdc and reboot the instance.

at this point the xml file will be re-written and the first volume will again be the first boot device and the newly installed OS will boot.

at this point you can detached the DVD ISO volume, vdc, if desired

worked for me! hope it works for you!

more

or

virsh edit instance-00xyz

remove <boot dev="hd"/> in <os> section

add <boot order="1"/> in the <disk> section of the vHD u want to boot temporarily.

virsh destroy instance-00xyz; virsh start instance-00xyz (quickly)

Openstack will revert this change after a few normal reboots from Horizon

( 2018-08-17 15:06:15 -0500 )edit

Since you are using a persistent volume, you could install the OS onto that volume, delete the instance (but retain the volume), then remount the volume inside a new instance which is not configured to use a CDROM.

more

Trouble with this approach is; if ISO is needed after first OS boot, it will be hard to have it accessible. Thinking back to the olden MS Windows days, it used to boot from CD, copy most files to HD, reboot to HD and then copy files from CD as required. Not possible with this approach.

( 2014-11-06 08:33:58 -0500 )edit

Please start posting anonymously - your entry will be published after you log in or create a new account.