Unable to boot from volume when flavor disk too small
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
| OpenStack Compute (nova) |
Undecided
|
Matthew Booth | ||
| Kilo |
Undecided
|
Unassigned | ||
| nova (Ubuntu) |
High
|
Liang Chen | ||
| Vivid |
High
|
Unassigned |
Bug Description
[Impact]
* Without the backport, booting from volume requires flavor disk size larger than volume size, which is wrong. This patch skips flavor disk size checking when booting from volume.
[Test Case]
* 1. create a bootable volume
2. boot from this bootable volume with a flavor that has disk size smaller than the volume size
3. error should be reported complaining disk size too small
4. apply this patch
5. boot from that bootable volume with a flavor that has disk size smaller than the volume size again
6. boot should succeed
[Regression Potential]
* none
Version: 1:2015.
I attempt to boot an instance from a volume:
nova boot --nic net-id=[NET ID] --flavor v.512mb --block-device source=
This results in nova-api raising a FlavorDiskTooSmall exception in the "_check_
[1] http://
Log (first line is debug output I added showing that it's looking at the image that the volume was created from):
2015-05-21 10:28:00.586 25835 INFO nova.compute.api [req-1fb882c7-
2015-05-21 10:28:00.587 25835 INFO nova.api.
Temporary solution: I have special flavor for volume-backed instances so I just set the root disk on those to 0, but this doesn't work if volume are used on other flavors.
Reproduce: create flavor with 1 GB root disk size, then try to boot an instance from a volume created from an image that is larger than 1 GB.
Related branches
- Billy Olsen (community): Needs Fixing on 2015-09-08
- Ubuntu Server Developers: Pending requested 2015-08-18
-
Diff: 3090 lines (+1634/-650) (has conflicts)77 files modifieddebian/changelog (+237/-0)
debian/compat (+1/-1)
debian/control (+150/-141)
debian/nova-api-ec2.init.in (+20/-0)
debian/nova-api-ec2.logrotate (+0/-7)
debian/nova-api-ec2.upstart (+0/-18)
debian/nova-api-metadata.init.in (+20/-0)
debian/nova-api-metadata.logrotate (+0/-7)
debian/nova-api-metadata.upstart (+0/-18)
debian/nova-api-os-compute.init.in (+20/-0)
debian/nova-api-os-compute.logrotate (+0/-7)
debian/nova-api-os-compute.upstart (+0/-18)
debian/nova-api.init.in (+20/-0)
debian/nova-api.logrotate (+0/-7)
debian/nova-api.upstart (+0/-18)
debian/nova-baremetal.init.in (+20/-0)
debian/nova-baremetal.install (+0/-2)
debian/nova-baremetal.logrotate (+0/-7)
debian/nova-baremetal.upstart (+0/-18)
debian/nova-cells.init.in (+20/-0)
debian/nova-cells.logrotate (+0/-7)
debian/nova-cells.upstart (+0/-17)
debian/nova-cert.init.in (+20/-0)
debian/nova-cert.logrotate (+0/-7)
debian/nova-cert.upstart (+0/-18)
debian/nova-common.logrotate (+7/-0)
debian/nova-common.nova-manage.logrotate (+0/-7)
debian/nova-compute.init.in (+26/-0)
debian/nova-compute.install (+0/-1)
debian/nova-compute.logrotate (+0/-7)
debian/nova-conductor.init.in (+20/-0)
debian/nova-conductor.logrotate (+0/-7)
debian/nova-conductor.upstart (+0/-18)
debian/nova-console.init.in (+18/-0)
debian/nova-console.logrotate (+0/-8)
debian/nova-console.upstart (+0/-19)
debian/nova-consoleauth.init.in (+18/-0)
debian/nova-consoleauth.logrotate (+0/-8)
debian/nova-consoleauth.upstart (+0/-19)
debian/nova-network.init.in (+18/-0)
debian/nova-network.logrotate (+0/-7)
debian/nova-network.nova-dhcpbridge.logrotate (+0/-7)
debian/nova-network.upstart (+0/-17)
debian/nova-novncproxy.init.in (+20/-0)
debian/nova-novncproxy.logrotate (+0/-7)
debian/nova-novncproxy.upstart (+0/-17)
debian/nova-objectstore.init.in (+18/-0)
debian/nova-objectstore.logrotate (+0/-10)
debian/nova-objectstore.upstart (+0/-17)
debian/nova-scheduler.init.in (+18/-0)
debian/nova-scheduler.logrotate (+0/-7)
debian/nova-scheduler.upstart (+0/-18)
debian/nova-serialproxy.init.in (+20/-0)
debian/nova-serialproxy.install (+1/-0)
debian/nova-serialproxy.manpages (+1/-0)
debian/nova-spiceproxy.init.in (+21/-0)
debian/nova-spiceproxy.logrotate (+0/-7)
debian/nova-spiceproxy.manpages (+1/-0)
debian/nova-spiceproxy.upstart (+0/-17)
debian/nova-xvpvncproxy.init.in (+16/-0)
debian/nova-xvpvncproxy.logrotate (+0/-7)
debian/nova-xvpvncproxy.upstart (+0/-17)
debian/patches/arm-console-patch.patch (+13/-13)
debian/patches/disable-websockify-tests.patch (+92/-0)
debian/patches/neutron-floating-ip-list.patch (+1/-6)
debian/patches/not-check-disk-size.patch (+486/-0)
debian/patches/rate-limit-power-syncs.patch (+179/-0)
debian/patches/series (+8/-1)
debian/patches/skip-cinder-tests.patch (+61/-0)
debian/patches/skip-proxy-test.patch (+15/-0)
debian/patches/skip-ubuntu-tests.patch (+0/-39)
debian/patches/update-run-tests.patch (+1/-1)
debian/pydist-overrides (+14/-0)
debian/rules (+10/-20)
debian/tests/control (+1/-1)
debian/tests/nova-daemons (+1/-1)
debian/watch (+1/-1)
- Ubuntu Server Developers: Pending requested 2015-09-08
-
Diff: 524 lines (+500/-0)3 files modifieddebian/changelog (+5/-0)
debian/patches/not-check-disk-size.patch (+494/-0)
debian/patches/series (+1/-0)
description: | updated |
description: | updated |
description: | updated |
wangxiyuan (wangxiyuan) wrote : | #1 |
Changed in nova: | |
assignee: | nobody → wangxiyuan (wangxiyuan) |
Favyen Bastani (fbastani) wrote : | #2 |
Hm, why is it okay in that case? The admin documentation I linked above indicates that the flavor root disk limit does not apply to volumes. It seems like it is fine if the flavor has root disk 1 GB but you want to boot a larger image from it.
Also I'm not certain whether it is comparing the image size against the flavor root disk limit, or comparing the volume size. If it is comparing the volume size then I think this is an even larger problem. But if it's image size it's still bad, since what if you have a 20 GB snapshot that you want to provision volume-backed instance from on a small flavor?
wangxiyuan (wangxiyuan) wrote : | #3 |
You are right. There is no need to check the disk in flavor if boot from volume.
But in nova code, it is a common function :
https:/
If boot from image,we must check it. So there is two ways to solve this problem.One is to check whether is boot from volume before _check_
I have submit a patch about this problem with the second way.You can test whether it's solved or not :)
Favyen Bastani (fbastani) wrote : | #5 |
I looked at the patch, it seems like it still compares the size of the image that volume was created from with the flavor root disk size. I can understand why this check is needed for the min_ram / flavor memory, but why is it needed for the disk?
I'm afraid of situation where user creates a large snapshot, creates a volume from it, and then is unable to boot it from a flavor that has small memory / disk parameters.
wangxiyuan (wangxiyuan) wrote : | #6 |
My patch just avoid raising FlavorDiskTooSmall error in some ways.
So,the best way is that we don't have to check disk size with flavor if booting from volume.
like this:
if root_gb and not boot_from_volume: # add a judgment condition
if int(image.
if int(image.
is it looks ok?
Changed in nova: | |
status: | New → In Progress |
Change abandoned by wangxiyuan (<email address hidden>) on branch: master
Review: https:/
Reason: I think We should have a discuess about how to check bdm in api side.
First of all,maybe we should fix RT's bug :
wangxiyuan (wangxiyuan) wrote : | #8 |
This bug is similar to the one below :
https:/
and it's difficulte to reach an agreement about how to solve it.
so I hava abandoned the patch.You can follow it if you are interested .
Changed in nova: | |
assignee: | wangxiyuan (wangxiyuan) → nobody |
Solving an inconsistency: The bug is "in progress" but without an assignee.
I set the status back to "new" because of comment #8 (possible duplicate?).
Feel free to assign the bug to yourself. If you do so, please set it to
"in progress".
Changed in nova: | |
status: | In Progress → New |
tags: | added: launch volumes |
Changed in nova: | |
assignee: | nobody → Feodor Tersin (ftersin) |
status: | New → In Progress |
Fix proposed to branch: master
Review: https:/
Changed in nova: | |
assignee: | Feodor Tersin (ftersin) → Matthew Booth (mbooth-9) |
Changed in nova: | |
assignee: | Matthew Booth (mbooth-9) → Daniel Berrange (berrange) |
Changed in nova: | |
assignee: | Daniel Berrange (berrange) → Matthew Booth (mbooth-9) |
Reviewed: https:/
Committed: https:/
Submitter: Jenkins
Branch: master
commit 642c986f0636d52
Author: Matthew Booth <email address hidden>
Date: Wed Jul 22 14:56:52 2015 +0100
Don't check flavor disk size when booting from volume
When creating a volume from an image, cinder copies the image metadata
into volume properties. When booting from the volume, we read this
metadata from the volume and use it as image metadata once again.
While fixing the check against min_ram,
change I861a78b5c7efa7
regression which prevents a user from booting a volume which is larger
than the flavor's disk. As we are not creating this disk, this check
does not make sense. Similarly, it checks the image metadata's
min_disk against the flavor disk size, which is not being used.
This change leaves the image metadata check unaltered when creating a
flavor disk. When booting from a volume, we check min_disk from image
metadata against the actual size of the volume. We don't check the
volume size at all. The check against min_ram is retained unaltered.
Closes-Bug: #1457517
Closes-Bug: #1459491
Closes-Bug: #1466305
Change-Id: I264493172da20b
Changed in nova: | |
status: | In Progress → Fix Committed |
Change abandoned by Feodor Tersin (<email address hidden>) on branch: master
Review: https:/
Fix proposed to branch: stable/kilo
Review: https:/
tags: | added: sts |
description: | updated |
Changed in nova (Ubuntu): | |
assignee: | nobody → Liang Chen (cbjchen) |
Launchpad Janitor (janitor) wrote : | #14 |
Status changed to 'Confirmed' because the bug affects multiple users.
Changed in nova (Ubuntu): | |
status: | New → Confirmed |
Reviewed: https:/
Committed: https:/
Submitter: Jenkins
Branch: stable/kilo
commit 8794b938dcb983b
Author: Matthew Booth <email address hidden>
Date: Wed Jul 22 14:56:52 2015 +0100
Don't check flavor disk size when booting from volume
When creating a volume from an image, cinder copies the image metadata
into volume properties. When booting from the volume, we read this
metadata from the volume and use it as image metadata once again.
While fixing the check against min_ram,
change I861a78b5c7efa7
regression which prevents a user from booting a volume which is larger
than the flavor's disk. As we are not creating this disk, this check
does not make sense. Similarly, it checks the image metadata's
min_disk against the flavor disk size, which is not being used.
This change leaves the image metadata check unaltered when creating a
flavor disk. When booting from a volume, we check min_disk from image
metadata against the actual size of the volume. We don't check the
volume size at all. The check against min_ram is retained unaltered.
Closes-Bug: #1457517
Closes-Bug: #1459491
Closes-Bug: #1466305
Change-Id: I264493172da20b
(cherry picked from commit 642c986f0636d52
tags: | added: in-stable-kilo |
Changed in nova: | |
milestone: | none → liberty-3 |
status: | Fix Committed → Fix Released |
Changed in nova (Ubuntu): | |
milestone: | none → vivid-updates |
milestone: | vivid-updates → none |
Billy Olsen (billy-olsen) wrote : | #16 |
Adding debdiff, which is also available in the ubuntu vivid upload queue (merged into lp:~ubuntu-server-dev/nova/vivid)
Serge Hallyn (serge-hallyn) wrote : | #17 |
This fix is in the current wily package, so marking fix released there.
Changed in nova (Ubuntu): | |
status: | Confirmed → Fix Released |
Serge Hallyn (serge-hallyn) wrote : | #18 |
Pushed the debdiff from comment #16 to New sru queue - thanks.
Changed in nova (Ubuntu Vivid): | |
importance: | Undecided → High |
Changed in nova (Ubuntu): | |
importance: | Undecided → High |
Hello Favyen, or anyone else affected,
Accepted nova into vivid-proposed. The package will build now and be available at https:/
Please help us by testing this new package. See https:/
If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-
Further information regarding the verification process can be found at https:/
Changed in nova (Ubuntu Vivid): | |
status: | New → Fix Committed |
tags: | added: verification-needed |
Billy Olsen (billy-olsen) wrote : | #20 |
I was able to verify this bug fix today by the following:
1. Setup a vivid-kilo openstack cloud
2. Create a 5G volume from a cirros image
3. Boot an m1.tiny instance using the 5G volume created as the boot source,
--> verify command is rejected due to size issue
4. Log into nova-cloud-
5. Boot an m1.tiny instance using the %G volume created as the boot source
--> verify command is accepted and instance boots
tags: |
added: verification-done removed: verification-needed |
Chris J Arges (arges) wrote : Update Released | #21 |
The verification of the Stable Release Update for nova has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.
Launchpad Janitor (janitor) wrote : | #22 |
This bug was fixed in the package nova - 1:2015.1.1-0ubuntu2
---------------
nova (1:2015.
[ Corey Bryant ]
* d/rules: Prevent dh_python2 from guessing dependencies.
[ Liang Chen ]
* d/p/not-
when flavor disk too small (LP: #1457517)
-- Corey Bryant <email address hidden> Thu, 13 Aug 2015 15:13:43 -0400
Changed in nova (Ubuntu Vivid): | |
status: | Fix Committed → Fix Released |
Changed in nova: | |
milestone: | liberty-3 → 12.0.0 |
it's confirmed.But I think we have to discuss whether it's a bug.
For example:
create a 2G bootable volume and the image is large than 1G(maybe 1.5G)
then the error "flavor disk too small" is ok.