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
