Boot from ISO is different in XS/KVM

Who's assignee of this bug?

If the root hard drive still exists, what's the size in XenServer? same as the iso size?

Fix proposed to branch: master
Review: https://review.openstack.org/9791

Reviewed: https://review.openstack.org/9791
Committed: http://github.com/openstack/nova/commit/b63a3e8cbd8fe57d0be119368bf47964543270c2
Submitter: Jenkins
Branch: master

commit b63a3e8cbd8fe57d0be119368bf47964543270c2
Author: Josh Kearney <email address hidden>
Date: Fri Jul 13 15:57:54 2012 -0500

    Attach ISO as separate disk if given proper instruction.

    This gives the option to attach the ISO as a separate drive, like we do in
    XenServer, and boot from that instead of replacing the root drive.

    Fixes bug 914484.

    Change-Id: I0e0560f5fcbc361b60ff1284e7369997dd770fd9

Fix proposed to branch: master
Review: https://review.openstack.org/10045

The first patch that was commited did not operate correctly & is being reverted. If someone can explain in a little more detail what the exactly guest visible disks should be, I'll see about creating a new patch

Reviewed: https://review.openstack.org/10045
Committed: http://github.com/openstack/nova/commit/4d3a50a48011b412bf66b1386292f85cccf1db74
Submitter: Jenkins
Branch: master

commit 4d3a50a48011b412bf66b1386292f85cccf1db74
Author: Daniel P. Berrange <email address hidden>
Date: Fri Jul 20 10:26:19 2012 +0100

    Revert "Attach ISO as separate disk if given proper instruction"

    The following commit

      commit b63a3e8cbd8fe57d0be119368bf47964543270c2
      Author: Josh Kearney <email address hidden>
      Date: Fri Jul 13 15:57:54 2012 -0500

        Attach ISO as separate disk if given proper instruction.

        This gives the option to attach the ISO as a separate drive, like we do in
        XenServer, and boot from that instead of replacing the root drive.

        Fixes bug 914484.

        Change-Id: I0e0560f5fcbc361b60ff1284e7369997dd770fd9

    Results in this XML config

      <devices>
        <disk type="file" device="cdrom">
          <driver type="qcow2" cache="none"/>
          <source file="instance-00000001/disk"/>
          <target bus="virtio" dev="vda"/>
        </disk>
        <disk type="file" device="cdrom">
          <driver type="qcow2" cache="none"/>
          <source file="instance-00000001/disk"/>
          <target bus="ide" dev="vda"/>
        </disk>
       ...
      </devices>

    which is broken in many ways

     - The same backing file is used in read/write mode on 2 disks
       which will cause data corruption on write.
     - The 'virtio' bus type does not allow device="cdrom" disks
     - The 'dev' attribute is given the same value on 2 disks

    To compound the problems, the original commit completely lacks
    any tests which would have caught the brokeness and/or identified
    what was actually intended.

    Change-Id: If1ec286f98fc91f9f411800bbb0adbf2797d2114
    Signed-off-by: Daniel P. Berrange <email address hidden>

Is this still in progress? Should it really be a blueprint?

This is causing https://bugs.launchpad.net/nova/+bug/1231874
Although nova should using the specified mountpoint instead of incrementing the root_device_name

Is this issue still being worked on? ISO deployment capabilities would be a great enabler for my tenants switching over from traditional Enterprise Infrastructure.

sushanta - since you have not updated this in 2 years I am removing you as the assignee. Please take it back if you plan on working on it

This feature is already exist in the version icehouse.
Using this feature, you need to create a specific ephemeral disk size' flavors.

I still think this is sort of broken.

One of the use cases for being able to boot from ISO is to be able to install an OS to the root disk in order to be able to capture it as an image. If the ISO replaces the root disk, you have to install to the ephemeral disk which cannot be captured with a snapshot. Shouldn't think be aligned to how XenAPI works today?

I think the behavior should be that it boot from ISO first but still allows for root disk and ephemeral disks to exist if set on the instance_type.

You mean, in the KVM, boot from ISO'temporary memory file system should be replaced by root disk? If yes, then this function needs to be supported by the KVM.

As of Icehouse this is still an issue.

Booting from ISO is typically something you do if you want to install a new OS as a user, without having to go through a local hypervisor on your laptop.

The sensible approach would be like the behaviour of Xen, where it behaves much like botting from a CDROM on your server or desktop to install the software on the local hard drive.

So if you boot an ISO on a flavor with 30GB root disk, what should happen is that a Instance is created with an empty /dev/vda of 30GB and the ISO on /dev/vdb (or /dev/sd0 depending on) which is booted from.
It's now straight forward to install the software and save an image.

I know, if you want to do this,you can boot from ISO,then attach an empty volume, install OS into it.There you can use it to boot VM,and use this VM create an image.I think they should meet your needs.