Hey Tomoe,
> Great idea! Both of those sound good to me. Would you like to implement > this?:) > Lol, perhaps, but at the very least this warrants a blueprint: https://blueprints.launchpad.net/nova/+spec/nova-create-bootable-volume > Also what do you think about the issue on required imageRef? Do you still > think it's a bug? > Well, it is definitely weird, but from the looks of things imageRef seems to be used when booting: the kernel and ramdisk from the specified image get baked into the libvirt.xml. This was somewhat unexpected for me, as I was expecting the volume to be treated as a whole disk image. Anthony > > Cheers, > Tomoe > > > > > > >> >> A >> >> >> >>> >>> So, I made some changes with the patch below and got it working. >>> >>> midokura@midokura-iMac:~/git/devstack.forked/exercises$ diff -u >>> boot_from_volume_new-8fe133bebcd90fa94c7a1d12c00b3f2cca18a35c.sh >>> bfv.sh >>> --- boot_from_volume_new-8fe133bebcd90fa94c7a1d12c00b3f2cca18a35c.sh >>> 2012-02-11 >>> 05:49:08.000000000 +0900 >>> +++ bfv.sh 2012-02-14 14:30:44.233636001 +0900 >>> @@ -99,13 +99,13 @@ >>> fi >>> >>> # Add floating ip to our server >>> -nova add-floating-ip $VM_UUID $FLOATING_IP >>> +#nova add-floating-ip $VM_UUID $FLOATING_IP >>> >>> # Test we can ping our floating ip within ASSOCIATE_TIMEOUT seconds >>> -if ! timeout $ASSOCIATE_TIMEOUT sh -c "while ! ping -c1 -w1 >>> $FLOATING_IP; do sleep 1; done"; then >>> - echo "Couldn't ping server with floating ip" >>> - exit 1 >>> -fi >>> +#if ! timeout $ASSOCIATE_TIMEOUT sh -c "while ! ping -c1 -w1 >>> $FLOATING_IP; do sleep 1; done"; then >>> +# echo "Couldn't ping server with floating ip" >>> +# exit 1 >>> +#fi >>> >>> # Create our volume >>> nova volume-create --display_name=$VOL_NAME 1 >>> @@ -116,6 +116,9 @@ >>> exit 1 >>> fi >>> >>> +# get private ip >>> +IP=$(nova show $VM_UUID |grep priv | awk -F '|' '{print $3}'|sed -e 's/ >>> //') >>> + >>> # FIXME (anthony) - python-novaclient should accept a volume_id for >>> the attachment param >>> DEVICE=/dev/vdb >>> VOLUME_ID=`nova volume-list | grep $VOL_NAME | cut -d '|' -f 2 | tr -d >>> ' '` >>> @@ -131,7 +134,7 @@ >>> # To do this, ssh to the builder instance, mount volume, and build a >>> volume-backed image. >>> STAGING_DIR=/tmp/stage >>> CIRROS_DIR=/tmp/cirros >>> -ssh -o StrictHostKeyChecking=no -i $KEY_FILE cirros@$FLOATING_IP << EOF >>> +ssh -o StrictHostKeyChecking=no -i $KEY_FILE cirros@$IP << EOF >>> set -o errexit >>> set -o xtrace >>> sudo mkdir -p $STAGING_DIR >>> @@ -177,16 +180,16 @@ >>> sleep 1 >>> >>> # Add floating ip to our server >>> -nova add-floating-ip $VOL_VM_UUID $FLOATING_IP >>> +#nova add-floating-ip $VOL_VM_UUID $FLOATING_IP >>> >>> # Test we can ping our floating ip within ASSOCIATE_TIMEOUT seconds >>> -if ! timeout $ASSOCIATE_TIMEOUT sh -c "while ! ping -c1 -w1 >>> $FLOATING_IP; do sleep 1; done"; then >>> - echo "Couldn't ping volume-backed server with floating ip" >>> - exit 1 >>> -fi >>> +#if ! timeout $ASSOCIATE_TIMEOUT sh -c "while ! ping -c1 -w1 >>> $FLOATING_IP; do sleep 1; done"; then >>> +# echo "Couldn't ping volume-backed server with floating ip" >>> +# exit 1 >>> +#fi >>> >>> # Make sure our volume-backed instance launched >>> -ssh -o StrictHostKeyChecking=no -i $KEY_FILE cirros@$FLOATING_IP << EOF >>> +ssh -o StrictHostKeyChecking=no -i $KEY_FILE cirros@$IP << EOF >>> echo "success!" >>> EOF >>> >>> @@ -206,7 +209,7 @@ >>> nova delete $INSTANCE_NAME >>> >>> # De-allocate the floating ip >>> -nova floating-ip-delete $FLOATING_IP >>> +#nova floating-ip-delete $FLOATING_IP >>> >>> # Delete secgroup >>> nova secgroup-delete $SECGROUP >>> ---------------------------------------------- >>> >>> Hope this helps. >>> >>> Cheers, >>> Tomoe >>> >>> >>> On Sat, Feb 11, 2012 at 10:31 PM, Tomoe Sugihara <to...@midokura.com> >>> wrote: >>> > Hi Anthony, >>> > >>> > Thanks for following it up. >>> > >>> > On Sat, Feb 11, 2012 at 2:58 PM, Anthony Young >>> > <sleepsonthefl...@gmail.com> wrote: >>> >> On Fri, Feb 10, 2012 at 8:51 PM, Tomoe Sugihara <to...@midokura.com> >>> wrote: >>> >>> >>> >>> Hi folks, >>> >>> >>> >>> Could someone tell me what is the right way to do boot-from-volume? >>> >>> Especially, how to create boot-from-volume capable image and volume? >>> >>> My understanding is that, since openstack API requires imageRef, we >>> >>> need to pass in both image and volume ids. >>> >> >>> >> >>> >> I was actually playing with this today, and just put up a review that >>> adds a >>> >> devstack exercise to create and launch a bootable volume. It is true >>> that >>> >> --image is still required when booting from a volume - I have not >>> >> investigated yet if that is a bug or a consequence of how >>> boot-from-volume >>> >> is implemented as an extension (which still may fall into the bug >>> category). >>> >> >>> >> https://review.openstack.org/4044 >>> > >>> > Current servers API, which boot-from-volume inherits from, throws an >>> > exception when imageRef is missing: >>> > >>> https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/servers.py#L646 >>> > >>> https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/servers.py#L965 >>> > >>> >> >>> >>> >>> >>> I thought that create_image in EC2 API would be the one and tried, >>> but >>> >>> it's totally broken now: >>> >>> https://bugs.launchpad.net/nova/+bug/923546 >>> >>> And, I didn't find equivalent code in OpenStack API. >>> >>> >>> >>> >>> >>> I'd appreciate any help on this and I'd be happy to help debug the >>> issue. >>> >> >>> >> >>> >> Hopefully the code above will give you some direction to get started. >>> My >>> >> experience thus far is that the end-to-end experience of using this >>> feature >>> >> needs some work, so I'll probably file some bugs and patches while I >>> muck >>> >> with it. So it would be great if you took a look and did the same:) >>> > >>> > That helps me understand the end-to-end workflow a lot :) >>> > In your script, you log in to a guest and copy a bootable image by cp >>> > command to a volume, but I'm wondering if there's a way to create >>> > bootable volume using only APIs. Otherwise it's a bit hard to manage >>> > from operator's or dashboard's point of view. >>> > >>> > I'll run your script next week and see how it goes. Thanks a lot! >>> > >>> > Tomoe >>> > >>> >> >>> >> Anthony >>> >> >>> >>> >>> >>> Cheers, >>> >>> Tomoe >>> >>> >>> >>> _______________________________________________ >>> >>> Mailing list: https://launchpad.net/~openstack >>> >>> Post to : openstack@lists.launchpad.net >>> >>> Unsubscribe : https://launchpad.net/~openstack >>> >>> More help : https://help.launchpad.net/ListHelp >>> >> >>> >> >>> >> >> >
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
