Hi Matt, 

thanks for your reply!

My set up has a cinder volume service with lvm2 on each compute host. Confusion might come from the fact that the vg 'cinder-volume' is the only volume group visible to libvirt guests. According to the cinder recommendation, I have filtered out all other vg's so that they are not visible on openstack level. This does NOT mean that cinder creates the swap volume ...

The standard flavors assume swap devices when creating an instance and if I look into the libvirt xml files /etc/libvirt/qemu/instance-00000xxx.xml), this swap device is created then in the volume group 'cinder-volume'. The lines in the xml files are:

(...)
<metadata>
    <nova:instance xmlns:nova="http://openstack.org/xmlns/libvirt/nova/1.0">
      <nova:package version="16.0.3"/>
      <nova:name>datenbankserver</nova:name>
      <nova:creationTime>2018-03-02 21:24:07</nova:creationTime>
      <nova:flavor name="m1.medium">
        <nova:memory>4000</nova:memory>
        <nova:disk>40</nova:disk>
        <nova:swap>4000</nova:swap>
        <nova:ephemeral>0</nova:ephemeral>
        <nova:vcpus>2</nova:vcpus>
      </nova:flavor>
      <nova:owner>
        <nova:user uuid="8287f31XXXXXXXXXXXXXXXXX">user_name</nova:user>
        <nova:project uuid="18e26500a53944XXXXXXXXXXXXX">project_name</nova:project>
      </nova:owner>
    </nova:instance>
  </metadata>

(...)

<devices>
    <emulator>/usr/bin/kvm-spice</emulator>
    <disk type='block' device='disk'>
      <driver name='qemu' type='raw' cache='none' io='native'/>
      <source dev='/dev/sdn'/>
      <target dev='vda' bus='virtio'/>
      <serial>4863707c-c62f-4e68-bbd0-76bc35952123</serial>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
    </disk>
    <disk type='block' device='disk'>
      <driver name='qemu' type='raw' cache='none' io='native'/>
      <source dev='/dev/cinder-volumes/6be19160-d8c8-45db-9c82-271e641c3710_disk.swap'/>
      <target dev='vdb' bus='virtio'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/>
    </disk>
(...)

I am not sure what triggers how the swap device is then put as lvm into the cinder-volume group in detail (but I assume that this happens on libvirt level, not necessarily openstack level ??!). However, the nova code is at the end assuming the swap device under /var/lib/nova/instances/<uuid>/<uuid>_disk.swap. The entire resizing is not coming so far that it could be attempted to create a swap device on the target host as the error stops the resizing already with the failed attempted to 'scp' the swap device from the wrong place.

Analysis of the code alongside the stack trace in /usr/lib/python2.7/dist-packages/nova/virt/libvirt/driver.py (line 8024ff) shows that the 'real' swap device has no chance to be correctly recognized and handled:

                (...)
                # We will not copy over the swap disk here, and rely on
                # finish_migration to re-create it for us. This is ok because
                # the OS is shut down, and as recreating a swap disk is very
                # cheap it is more efficient than copying either locally or
                # over the network. This also means we don't have to resize it.
        ---->   if 'disk.swap' in fname:
                #if fname == 'disk.swap': <---- Original code
                    continue
                compression = info['type'] not in NO_COMPRESSION_TYPES
        ---->   if os.path.exists(from_path):
                    libvirt_utils.copy_image(from_path, img_path, host=dest,
                                         on_execute=on_execute,
                                         on_completion=on_completion,
                                         compression=compression)

with my corrections (---->) (fname is '/dev/cinder-volume/<uuid>_disk.swap') the unintended copy of the swap device is prevented as the loop is interrupted (as intended). 

Another change I made in the same file around line 8100 is 

            path = info['path']
            disk_name = os.path.basename(path)
            
     ---->  if ('disk.swap' in disk_name):
     ---->      continue
to prevent that it is attempted to convert the swap device into qcow2 format after recreation on the target host

(Both changes may be much likely not more than dirty workarounds and require rework (my apologies - I have improved my python skills but I am still no python expert ;-))however it makes resizing almost work for my setup. The only missing piece is still that on the OLD host, the swap device is not destroyed with lvremove when the instance is moved away.)

I consider this thing as critical as IT NOT ONLY MAKES RESIZING IMPOSSIBLE BUT ALSO ANY KIND OF INSTANCE MIGRATION. My setup is imho straightforwardly implementing an Openstack standard installation as being described in the Openstack docs.

I hope that I could sort out with that the confusion I might have triggered with my report

Br br