** Changed in: nova
Status: Incomplete = Invalid
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to nova in Ubuntu.
https://bugs.launchpad.net/bugs/1000710
Title:
Attaching volume during instance boot doesn't work
To manage
This bug lacks the necessary information to effectively reproduce and
fix it, therefore it has been closed. Feel free to reopen the bug by
providing the requested information and set the bug status back to
''New''.
** Changed in: nova (Ubuntu)
Status: Triaged = Invalid
--
You received
We cannot solve the issue you reported without more information. Could
you please provide the requested information ?
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to nova in Ubuntu.
https://bugs.launchpad.net/bugs/1000710
Title:
** Also affects: nova
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to nova in Ubuntu.
https://bugs.launchpad.net/bugs/1000710
Title:
Attaching volume during instance boot doesn't work
To
What release was this canonistack region running at the time the problem
was seen?
** Changed in: nova
Status: New = Incomplete
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to nova in Ubuntu.
So you tried to attacht the volume while its being created?
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to nova in Ubuntu.
https://bugs.launchpad.net/bugs/1000710
Title:
Attaching volume during instance boot doesn't work
To manage
Our current hypothesis for how this situation happened in the first
place is that because nova-api returns success early, it's possible to
run the attach before the volume has actually been successfully created.
It looks like the attach needs to block internally to wait for the
volume creation to
I'm confused because
a.) dmesg on the first boot did not have anything in it
b.) reboot (without re-attach) showed the drive.
Those two items in the bug report just seem strange.
** Changed in: nova (Ubuntu)
Importance: Undecided = Medium
** Changed in: nova (Ubuntu)
Status: New =
** Description changed:
Using the newly enabled volume support on canonistack, it arrived at a
state where the volume believed it was in-use by the instance, but the
instance had not registered it. The volume then refused to be detached
from the instance, the command succeeded but no
** Attachment added: first boot dmesg
https://bugs.launchpad.net/ubuntu/+source/nova/+bug/1000710/+attachment/3150591/+files/nova-medium-dmesg.log
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to nova in Ubuntu.
** Attachment added: reboot dmesg
https://bugs.launchpad.net/ubuntu/+source/nova/+bug/1000710/+attachment/3150603/+files/nova-medium-dmesg-reboot.log
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to nova in Ubuntu.
I've attached dmesg output from first boot and second boot that Martin provided
me with.
Some things to note:
* instance was 12.04 ubuntu-precise-12.04-amd64-server-20120424
* both first boot and reboot took 90 seconds to get to the acpi messages.
These messages come as a result of
I'm currently not able to reproduce this, with something like the
following:
ami=ami-00bf
zone=nova
size=2
instsize=m1.medium
key=mykey
isready() { local s=$(euca-describe-instances $1 | awk '$2 == i {
print $6 }' i=$1 ); echo $s 12; [ $s = running ]; }
out=$(euca-create-volume -z $zone -s
OK.
so, re-reading the above, and conversing with Martin.
things of note:
* after first boot, the volume showed as 'in-use', but the disk was not
attached to the instance.
* after re-boot, the volume showed as 'available' again. Basically, the
volume got stuck in 'in-use' when it really
14 matches
Mail list logo
