Stuck with OnApp error: internal error Attempt to migrate guest to the same host? We can help you.

As part of our Server Virtualization Technologies and Services, we assist our customers with several OnApp queries.

Today, let us see how we can fix the migration error in OnApp.

OnApp error: internal error Attempt to migrate guest to the same host

The above error can occur due to different reason. Check the following:

• When trying to hot migrate a VS on a static compute resource, the migration fails with the error “error: internal error Attempt to migrate guest to the same host”.
• When trying to hot migrate a VS on a cloud-boot compute resource, the migration fails with the error “error: internal error Attempt to migrate guest to the same host”.

Issue can cause if same UUIDS across source and destination compute resources.

Before the migration starts, virsh checks the UUID of the system by executing virsh sysinfo.

Also, it executes the same command on the host that the VS will be migrated to.

This is to avoid migrating to the same server in case of a cluster of compute resources.

How to resolve “internal error Attempt to migrate guest to the same host” on static compute resource?

To resolve the issue, you need to configure the unique libvirt UUID.

• Firstly, check the current libvirt UUID with the command:

# virsh capabilities | grep uuid

<uuid>b4eef507-e834-428f-82f5-188ab3d1b26e</uuid>

• Then, generate the new libvirt UUID:

# uuidgen

b1285b1c-7fa0-4c07-8ec7-cb8237b41140

• Edit file /etc/libvirt/libvirtd.conf and add/edit the following line:

host_uuid = “b1285b1c-7fa0-4c07-8ec7-cb8237b41140”

• Finally, restart libvirtd# service:

# service libvirtd restart
Redirecting to /bin/systemctl restart libvirtd.service

How to resolve it on cloud-boot compute resource?

Before the migration starts, virsh check the UUID of the system by executing virsh sysinfo.

Also, it executes the same command on the host that the VS will be migrated to.

In order to troubleshoot the issue, please follow the steps below:

• Firstly, check what virsh sysinfo returns for your compute resources.

dmidecode -s system-uuid
4C4C4544-0053-4C10-8038-B2C04F334831

dmidecode -s system-uuid
4C4C4544-0053-4C10-8038-B2C04F334831

dmidecode -s system-uuid
4C4C4544-0053-4C10-8038-B2C04F334831

dmidecode -s system-uuid
4C4C4544-0053-4C10-8038-B2C04F334831

• As you can see they all have the same UUID, so in this case this was Dell all in one 4x servers in one enclosure.

Now, let us go through the steps followed by our Support Techs in order to resolve it.

1.Firstly, go to the images directory:

cd /tftpboot/images/centos6/ramdisk-kvm/

2.Then, backup the initrd:

cp initrd.img initrd.img.backup

3.Create the directory where we will unpack the original initrd:

mkdir -v /tftpboot/images/centos6/ramdisk-kvm/initrd.unpacked && cd /tftpboot/images/centos6/ramdisk-

kvm/initrd.unpacked

4.Decompress the intrd:

zcat ../initrd.img | cpio -id

5.Mount the usr directory (it will be readonly):

mount -o loop usr.cramfs usr

6.Copy the info of the usr to another location so we can edit and apply the changes:

rsync -av usr/ /tmp/cramfs-usr/

7.Copy the real binary “demidecode”:

cp usr/sbin/dmidecode sbin/dmidecode.orig

8.Now download the wrapper and copy it to the temporary directory and give permissions to execute:

wget http://downloads.repo.onapp.com/dmidecode

cp demidecode (This should be the wrapper) /tmp/cramfs-usr/sbin/dmidecode

chmod +x /tmp/cramfs-usr/sbin/dmidecode

9.Again, from within the /tftpboot/images/centos6/ramdisk-kvm/initrd.unpacked directory umount the usr.cramfs image and delete it:

umount usr.cramfs

rm -rf usr.cramfs

10.Create the usr.cramfs with the wrapper applied, this will create a ro cramfs image:

mkfs.cramfs /tmp/cramfs-usr/ usr.cramfs

11.Recreate the initrd and clean the dirs created:

find . | cpio -H newc --quiet -o | gzip -9 > ../initrd.img.new && cd .. && mv -fv initrd.img.new initrd.img

12.Now clean user:

rm -rf /tmp/cramfs-usr/

13.Add the following custom config to all compute resources. Create a UUID with uuidgen so that the UUIDs are different:

##uuid for libvirtd.conf##
echo 'host_uuid = "BA7CC229-D375-410F-88E9-0A918DAA7120" ' >> /etc/libvirt/libvirtd.conf
service libvirtd restart
#####

14.Reboot the compute resources in order to load the new initrd and Custom config.

15.Check that the new UUID is being used by libvirtd.

As you can see, the UUID in libvirtd.conf is the same as the one we get when doing virsh sysinfo:

tail /etc/libvirt/libvirtd.conf
# sending any keepalive messages.
#
#keepalive_interval = 5
#keepalive_count = 5
#
# If set to 1, libvirtd will refuse to talk to clients that do not
# support keepalive protocol. Defaults to 0.
#
#keepalive_required = 1
host_uuid = "BA7CC229-D375-410F-88E9-0A918DAA7120"

virsh sysinfo | grep uuid
<entry name='uuid'>BA7CC229-D375-410F-88E9-0A918DAA7120</entry>

[Need help with the fix? We are here for you]

Conclusion

In short, today we saw how our Support Techs resolve OnApp error: internal error Attempt to migrate guest to the same host.