xenapi: issues with resize/boot when root_gb=0 in flavor

[Mate Lakat]

I am running tempest tests, with an image, whose auto_disk_config has been set:

nova image-meta IMAGEID set auto_disk_config=true

stack@DevStackOSDomU:~/tempest$ nosetests tempest.tests.compute.servers.test_server_actions:ServerActionsTestXML.test_resize_server_confirm

This is the error that I get in cpu log:

Traceback (most recent call last):
  File "/opt/stack/nova/nova/openstack/common/rpc/amqp.py", line 393, in _process_data
    rval = self.proxy.dispatch(ctxt, version, method, **args)
  File "/opt/stack/nova/nova/openstack/common/rpc/dispatcher.py", line 133, in dispatch
    return getattr(proxyobj, method)(ctxt, **kwargs)
  File "/opt/stack/nova/nova/exception.py", line 117, in wrapped
    temp_level, payload)
  File "/usr/lib/python2.7/contextlib.py", line 24, in __exit__
    self.gen.next()
  File "/opt/stack/nova/nova/exception.py", line 94, in wrapped
    return f(self, context, *args, **kw)
  File "/opt/stack/nova/nova/compute/manager.py", line 208, in decorated_function
    pass
  File "/usr/lib/python2.7/contextlib.py", line 24, in __exit__
    self.gen.next()
  File "/opt/stack/nova/nova/compute/manager.py", line 194, in decorated_function
    return function(self, context, *args, **kwargs)
  File "/opt/stack/nova/nova/compute/manager.py", line 259, in decorated_function
    function(self, context, *args, **kwargs)
  File "/opt/stack/nova/nova/compute/manager.py", line 236, in decorated_function
    e, sys.exc_info())
  File "/usr/lib/python2.7/contextlib.py", line 24, in __exit__
    self.gen.next()
  File "/opt/stack/nova/nova/compute/manager.py", line 223, in decorated_function
    return function(self, context, *args, **kwargs)
  File "/opt/stack/nova/nova/compute/manager.py", line 2208, in resize_instance
    block_device_info)
  File "/opt/stack/nova/nova/virt/xenapi/driver.py", line 236, in migrate_disk_and_power_off
    dest, instance_type)
  File "/opt/stack/nova/nova/virt/xenapi/vmops.py", line 869, in migrate_disk_and_power_off
    context, instance, dest, instance_type, vm_ref, sr_path)
  File "/opt/stack/nova/nova/virt/xenapi/vmops.py", line 786, in _migrate_disk_resizing_down
    instance_type)
  File "/opt/stack/nova/nova/virt/xenapi/vm_utils.py", line 724, in resize_disk
    auto_configure_disk(session, copy_ref, instance_type['root_gb'])
  File "/opt/stack/nova/nova/virt/xenapi/vm_utils.py", line 769, in auto_configure_disk
    _resize_part_and_fs(dev, start, old_sectors, new_sectors)
  File "/opt/stack/nova/nova/virt/xenapi/vm_utils.py", line 2032, in _resize_part_and_fs
    run_as_root=True)
  File "/opt/stack/nova/nova/utils.py", line 243, in execute
    cmd=' '.join(cmd))
ProcessExecutionError: Unexpected error while running command.
Command: sudo nova-rootwrap /etc/nova/rootwrap.conf resize2fs /dev/xvdb1 -63s
Exit code: 1
Stdout: ''
Stderr: "resize2fs 1.42 (29-Nov-2011)\n/sbin/resize2fs: invalid option -- '6'\nUsage: /sbin/resize2fs [-d debug_flags] [-f] [-F] [-M] [-P] [-p] device [new_size]\n\n"

[John Garbutt (johngarbutt)]

you need to check for instance_type == 0 in the resize disk code in vm_utils I think.
It should not resize the disk, even is auto_disk_configure = True when instance_type disk size == 0.

[Mate Lakat (mate-lakat)]

What do you mean on instance_type == 0 ?
I think that launching an image with a flavor that has a zero disk size, should not prevent you from sizing it up.
http://docs.openstack.org/api/openstack-compute/2/content/Resize_Server-d1e3707.html
I think we should instead somehow get the actual size of the disk, and use that, instead.

[John Garbutt (johngarbutt)]

Sorry I rushed that comment.

instance_type['root_gb']==0 means there is no need to change the disk size, because, by definition, it is the correct size, I think.

I think the other thing is to check if new_sectors > 0 before calling out, which I guess is the case we are also worried about. This should probably throw an exception, because with the above check, it should never get here if glance is correctly configured with minimum GB setting. If not stopping, the resize of the VDI is sure to lead to data loss.

[John Garbutt (johngarbutt)]

Gotcha, I was thinking about resizing up for some reason.

[John Garbutt (johngarbutt)]

There is talk of deprecating this feature of root_disk=0, reducing the priority.

[Vangelis Tasoulas (cyberang3l)]

If auto_disk_config=True is set for CirrOS image, the image cannot boot at all and it gives similar errors in the nova-compute.log like the ones in this bug.

Probably because CirrOS doesn't use any disk at all?

[John Garbutt (johngarbutt)]

The above booting CirrOS image is a different erorr, auto_disk_config=True fails because of disk=0 in the flavor and not being able to choose the correct size to resize the disk to.

[John Garbutt (johngarbutt)]

This is making XenAPI support look bad to new users, we need to handle images with root_disk=0 much better.

[John Garbutt (johngarbutt)]

Progress has stalled, taking a look at this one myself.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/46475

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/46475
Committed: http://github.com/openstack/nova/commit/dfd9afb51ff704566196fff295481070bd2c6af8
Submitter: Jenkins
Branch: master

commit dfd9afb51ff704566196fff295481070bd2c6af8
Author: John Garbutt <email address hidden>
Date: Fri Sep 13 11:11:02 2013 +0100

    xenapi: fix where root_gb=0 causes problems

    Auto_config disk and resize up should be able to correctly handle when
    the flavor specifies root_gb=0.

    When you try to resize down to root_gb=0, it doesn't really make sense,
    so throw a reasonable error message, instead of failing in the middle of
    the resize calculations.

    Fixes bug 1152268
    Change-Id: Ib26170d7d563cc8fd664c3680fecc4ac04e57b04