[Users] Migration issues with ovirt 3.3

[Dan Kenigsberg]

On Tue, Sep 24, 2013 at 02:41:58PM -0300, emitor at gmail.com wrote:
> Thanks for your answer Dan!
> 
> Yesterday was talking with an user in the IRC and gave me the hint to
> upgrade the libvirt to the 1.1.2 after trying in his implementation the
> live migration successfully.
> 
> I've upgraded the libvirt but I'm still having the issue. I send to you the
> logs that you asked to me and the information bellow:
> OS Version:
> Fedora - 19 - 3
> Kernel Version:
> 3.11.1 - 200.fc19.x86_64
> KVM Version:
> 1.4.2 - 9.fc19
> LIBVIRT Version:
> libvirt-1.1.2-1.fc19
> VDSM Version:
> vdsm-4.12.1-2.fc19
> SPICE Version:
> 0.12.4 - 1.fc19
> iSCSI Initiator Name:
> iqn.1994-05.com.redhat:d990cf85cdeb
> SPM Priority:
> Medium
> Active VMs:
> 1
> CPU Name:
> Intel Westmere Family
> CPU Type:
> Intel(R) Xeon(R) CPU           E5620  @ 2.40GHz
> CPU Sockets:
> 1
> CPU Cores per Socket:
> 4
> CPU Threads per Core:
> 2 (SMT Enabled)
> Physical Memory:
> 12007 MB total, 2762 MB used, 9245 MB free
> Swap Size:
> 15999 MB total, 0 MB used, 15999 MB free
> Shared Memory:
> 0%
> Max free Memory for scheduling new VMs:
> 15511.5 MB
> Memory Page Sharing:
> Inactive
> Automatic Large Pages:
> Always
> 
> (Both hypervisors have the same hardware and software version)
> 
> I'm going to keep trying some things becouse something must get messed up
> because now i have a VM with Debian that doesn't start giving me the error
> "Failed to run VM debian on Host ovirt1." and "Failed to run VM debian on
> Host ovirt2."
> 
> Anyway I'll wait for your answer.
> Very Regards!
> Emiliano

Your destination Vdsm has

vmId=`1f7e60c7-51cb-469a-8016-58a5837f3316`::The vm start process failed
Traceback (most recent call last):
  File "/usr/share/vdsm/vm.py", line 2022, in _startUnderlyingVm
    self._run()
  File "/usr/share/vdsm/vm.py", line 2819, in _run
    devices = self.buildConfDevices()
  File "/usr/share/vdsm/vm.py", line 1839, in buildConfDevices
    devices = self.getConfDevices()
  File "/usr/share/vdsm/vm.py", line 1806, in getConfDevices
    self.normalizeDrivesIndices(devices[DISK_DEVICES])
  File "/usr/share/vdsm/vm.py", line 1990, in normalizeDrivesIndices
    if drv['iface'] not in self._usedIndices:
KeyError: 'iface'

Which looks just like
    Bug 1011472 - [vdsm] cannot recover VM upon vdsm restart after a disk has
    been hot plugged to it.

Could it be that you have hot-plugged a disk to your VM at the source host?
Somehow, Vdsm forgets to keep the 'iface' element passed from Engine for the
hot-plugged disk.

Dan.