Bug 1192123 - Live migration fails because of libvirt's bios uuid checking
Summary: Live migration fails because of libvirt's bios uuid checking
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Virtualization Tools
Classification: Community
Component: libvirt
Version: unspecified
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Libvirt Maintainers
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-02-12 16:22 UTC by Yang Luo
Modified: 2017-10-22 11:53 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-02-12 16:51:56 UTC
Embargoed:


Attachments (Terms of Use)

Description Yang Luo 2015-02-12 16:22:26 UTC
Description of problem:
I am an OpenStack user. When live-migrating a virtual machine from a compute node to another one with the same bios uuid, libvirt would fail the migration because of the bios uuid checking.

nova-compute.log from the source node:
2014-12-27 05:23:19.889 1923 ERROR nova.virt.libvirt.driver [-] [instance: a0c91586-afaf-49d7-8799-0a17e3087c56] Live Migration failure: internal error: Attempt to migrate guest to the same host 564d1e3d-01e7-fd2e-0185-625ea40bd715


Version-Release number of selected component (if applicable):
Libvirt 1.2.2

How reproducible:
Reproduciable

Steps to Reproduce:
When cloning a new compute node from an existing one, bios uuid usually remains the same, this issue happens when launching a live-migration between two compute nodes with the same bios uuid.
Both nodes should be based on KVM, libvirt.

Actual results:
No clear message.

Expected results:
The error message from libvirt is obscure and not that helpful, because it's hard for an admin to tell what 564d1e3d-01e7-fd2e-0185-625ea40bd715 is, and the bios uuid is not a commonly known concept.
OpenStack's same host checking should be consistent with libvirt's checkings, no matter whether allowing for the same bios uuid nodes or not. At least a clear error message should be given.

Additional info: (Souce code location for libvirt and OpenStack)
*********************************************************************
Libvirt 1.2.2
path: /src/qemu/qemu_migration.c
function: static int qemuMigrationCookieXMLParse(qemuMigrationCookiePtr mig, virQEMUDriverPtr driver, xmlDocPtr doc, xmlXPathContextPtr ctxt, unsigned int flags)
line: 825:
if (STREQ(mig->remoteHostname, mig->localHostname))
{
 virReportError(VIR_ERR_INTERNAL_ERROR, _("Attempt to migrate guest to the same host %s"), mig->remoteHostname);
 goto error;
}

line 842:
if (memcmp(mig->remoteHostuuid, mig->localHostuuid, VIR_UUID_BUFLEN) == 0)
{
 virReportError(VIR_ERR_INTERNAL_ERROR, _("Attempt to migrate guest to the same host %s"), tmp);
 goto error;
}
*********************************************************************
nova Icehouse
/nova/conductor/tasks/live_migrate.py
class: LiveMigrationTask
function: def _check_destination_is_not_source(self):
line 102:
def _check_destination_is_not_source(self):
        if self.destination == self.source:
            raise exception.UnableToMigrateToSelf(
                    instance_id=self.instance.uuid, host=self.destination)
*********************************************************************

Comment 1 Daniel Berrangé 2015-02-12 16:51:56 UTC
(In reply to Yang Luo from comment #0)
> Steps to Reproduce:
> When cloning a new compute node from an existing one, bios uuid usually
> remains the same, this issue happens when launching a live-migration between
> two compute nodes with the same bios uuid.

There is your problem. Cloning VMs and keeping the UUID the same is absolutely *not* a normal or reasonable thing todo. If you clone Vms it is your responsibility to ensure any unique identifiers like UUID, MAC address, ssh keys and more, all get changed or reset.

NB, libvirt does  allow you to specify a custom Host UUID in /etc/libvirt/libvirtd.conf, but really you should fix your cloning method to scrub/update unique identifiers.


Note You need to log in before you can comment on or make changes to this bug.