Retrieving instance XML in libvirt driver is inconsistent

Bug #1081373 reported by Rafi Khardalian
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Compute (nova)
Fix Released
Undecided
Rafi Khardalian

Bug Description

There are many libvirt operations which require the instance XML to function. We use a combination of the existing defined XML, the XML in the instances directory or to_xml function. There's no reason to ever use the the XML files stored in the instances directory; it is there for operational purposes only. Unless we absolutely need the running XML, we should use to_xml to generate the configuration based on what Nova absolutely knows about the instance. Also, we should make sure that if we're keeping an XML file around in the instances directory for operations, that it's always kept up to date.

This will undo any one-off/by-hand changes in favor of absolute consistency with the database, which is preferred. For example, if a running VM references a block device which Nova does not know about, today we'll fail to start that VM based on the fact that none of the logic to re-create iSCSI connections (or otherwise) are executed.

Changed in nova:
assignee: nobody → Rafi Khardalian (rkhardalian)
status: New → In Progress
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to nova (master)

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

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to nova (master)

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

commit bed78bc1db64dd97af50d1f737dd2c8af63ed61d
Author: Rafi Khardalian <email address hidden>
Date: Sat Jan 19 07:12:46 2013 +0000

    More consistent libvirt XML handling and cleanup

    Fixes bug 1081373

    The overall goal of this effort is to make handling of libvirt XMLs
    more consistent. First, the on-disk XML file in the instances
    directory is never to be used by the libvirt driver. It will be
    generated via to_xml(). Second, anytime it is safe to re-define the
    XML using the version we programatically generate, we do so.

    Extended to_xml() to support a new write_to_disk argument. When true,
    this the resulting XML will be written to the instances directory.
    Renamed _get_domain_xml to _get_existing_domain_xml, as it should only
    be used when we need the XML for a defined domain. It will continue to
    fall back to using to_xml() if the defined version is not available.

    Hard reboots will now assume nothing about the defined state within
    libvirt. Rather, we generate and define the domain every time. This
    eliminates the possibility of the hypervisor and Nova database going
    out of sync (i.e. volume attached in defined XML with Nova having no
    knowledge). We no longer need to pass an xml argument into
    _hard_reboot() since it is always generated.

    Resume state on boot has been updated with logic similar to that of
    _hard_reboot. Again, after a hypervisor reboot (or detection of downed
    VMs on compute start), we should not assume the defined XML is valid.
    The state or configuration of the VM, from Nova's perspective, may
    have been changed while the system was down.

    The post_live_migration_on_destination() method used to call to_xml()
    without block_device_info. This would result in an on-disk XML without
    any volume mappings. The compute manager has been updated to pass bdi
    so that this XML can be generated and written correctly. The Mox stub
    for this function has been replaced by a stub in the fake virt driver.

    Change-Id: I4aa1068fa3aa54fdb7e690d46b6cf2e41bb20bc9

Changed in nova:
status: In Progress → Fix Committed
Thierry Carrez (ttx)
Changed in nova:
milestone: none → grizzly-3
status: Fix Committed → Fix Released
Thierry Carrez (ttx)
Changed in nova:
milestone: grizzly-3 → 2013.1
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.