Public bug reported: Issue reported by one of our users in our Trusty/Icehouse controller + Precise/Havana compute + nova-network cloud:
--- If I put the instance into rescue mode: $ nova rescue 598ec2ba-9d87-484d-ae3a-4661b4be3d91 And then *immediately* try to ssh in: $ ssh ubu...@fixed.ip -i ~/.ssh/some_key.pem I get no errors, but even if I get a connection refused message, the instance does not go into rescue mode properly. However, if I put the instance into rescue mode: $ nova rescue 598ec2ba-9d87-484d-ae3a-4661b4be3d91 And then wait until Nova list tells me that the instance is in rescue mode: $ nova list +--------------------------------------+---------+--------+------------+-------------+-------------------+ | ID | Name | Status | Task State | Power State | Networks | +--------------------------------------+---------+--------+------------+-------------+-------------------+ | 598ec2ba-9d87-484d-ae3a-4661b4be3d91 | tester2 | RESCUE | - | Running | public= | +--------------------------------------+---------+--------+------------+-------------+-------------------+ & only then ssh in, everything is sweetness and light. So to my untrained eye, it would appear that eagerly ssh'ing in to the instance is affecting the rescue operation. --- Console log for the instance shows: An error occurred while mounting /mnt. keys:Press S to skip mounting or M for manual recovery Looks like it failed to mount the rescue disk partition at /dev/vda1 and instead mounts /dev/vdb1 as the root disk, which is the disk from the original instance being rescued: Filesystem Size Used Avail Use% Mounted on /dev/vdb1 9.8G 833M 8.4G 9% / I can mount /dev/vda1 to /mnt manually and it looks like an untouched ubuntu image. ** Affects: nova Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1392134 Title: nova rescue fails if connection made before RESCUE state Status in OpenStack Compute (Nova): New Bug description: Issue reported by one of our users in our Trusty/Icehouse controller + Precise/Havana compute + nova-network cloud: --- If I put the instance into rescue mode: $ nova rescue 598ec2ba-9d87-484d-ae3a-4661b4be3d91 And then *immediately* try to ssh in: $ ssh ubu...@fixed.ip -i ~/.ssh/some_key.pem I get no errors, but even if I get a connection refused message, the instance does not go into rescue mode properly. However, if I put the instance into rescue mode: $ nova rescue 598ec2ba-9d87-484d-ae3a-4661b4be3d91 And then wait until Nova list tells me that the instance is in rescue mode: $ nova list +--------------------------------------+---------+--------+------------+-------------+-------------------+ | ID | Name | Status | Task State | Power State | Networks | +--------------------------------------+---------+--------+------------+-------------+-------------------+ | 598ec2ba-9d87-484d-ae3a-4661b4be3d91 | tester2 | RESCUE | - | Running | public= | +--------------------------------------+---------+--------+------------+-------------+-------------------+ & only then ssh in, everything is sweetness and light. So to my untrained eye, it would appear that eagerly ssh'ing in to the instance is affecting the rescue operation. --- Console log for the instance shows: An error occurred while mounting /mnt. keys:Press S to skip mounting or M for manual recovery Looks like it failed to mount the rescue disk partition at /dev/vda1 and instead mounts /dev/vdb1 as the root disk, which is the disk from the original instance being rescued: Filesystem Size Used Avail Use% Mounted on /dev/vdb1 9.8G 833M 8.4G 9% / I can mount /dev/vda1 to /mnt manually and it looks like an untouched ubuntu image. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1392134/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp