External snapshots cannot be used in fuel-devops with 'host-passthrough' cpu mode

Bug #1535259 reported by Dennis Dmitriev
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Fuel for OpenStack
Fix Released
Medium
Aliaksei Cherniakou

Bug Description

Steps to reproduce:
  1. export SNAPSHOTS_EXTERNAL=true
  2. Run any test case from fuel-qa repository, for example, 'deploy_neutron_gre_ha'

* Expected result: snapshots are creating and reverting successfully.

* Actual result: when used snapshotCreateXML() with libvirt.VIR_DOMAIN_SNAPSHOT_CREATE_REDEFINE flag, it doesn't accept xml of previously created snapshot for the node [1].

The error message:
libvirtError: unsupported configuration: Target CPU model <null> does not match source SandyBridge

It happens because cpu <model>, that actually exists in the snapthot's XML file, missed in the object that returns by the libvirt method domain.snapshotCurrent(0) [2]

* Known workaround:
  export DRIVER_USE_HOST_CPU=false

Libvirt version: 1.2.12

[1] https://github.com/openstack/fuel-devops/blob/2.9.15/devops/driver/libvirt/libvirt_driver.py#L452-L455
[2] https://github.com/openstack/fuel-devops/blob/2.9.15/devops/driver/libvirt/libvirt_driver.py#L536

Tags: area-qa
Changed in fuel:
status: New → Confirmed
description: updated
Changed in fuel:
milestone: none → 9.0
Maciej Relewicz (rlu)
tags: added: area-qa
Changed in fuel:
status: Confirmed → Triaged
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to fuel-devops (master)

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

Changed in fuel:
assignee: Fuel QA Team (fuel-qa) → Aliaksei Cherniakou (acherniakou)
status: Triaged → In Progress
Revision history for this message
Artem Panchenko (apanchenko-8) wrote :

@Dennis,

what version of python-libvirt do you use? Does external snapshot xml is saved correctly if you do it using virsh? Here is a bug at RedHat with similar symptoms:

https://bugzilla.redhat.com/show_bug.cgi?id=1180521

This issue sounds for me like a bug in libvirt/qemu/python-libvirt and I don't want to just workaround it in fuel-devops.

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

Reviewed: https://review.openstack.org/269021
Committed: https://git.openstack.org/cgit/openstack/fuel-devops/commit/?id=b25c7c7ffa7fe25055333c1ca701dcf245324daa
Submitter: Jenkins
Branch: master

commit b25c7c7ffa7fe25055333c1ca701dcf245324daa
Author: Aliaksei Cherniakou <email address hidden>
Date: Mon Jan 18 15:02:46 2016 +0300

    External snapshots with host-passthrough cpu mode

    Domain/cpu node in XML description of external snapshots now being
    updated with an appropriate information from domain XML description when
    'host-passthrough' cpu mode is selected. This is implemented in Snapshot
    class from libvirt-driver module.

    The reason why it was done is libvirt rejects calls for restoring VMs to
    the states from external snapshots and redefining external snapshots
    without specifying cpu model and vendor.
    Currently libvirt does neither return cpu model and vendor when calling
    getXMLDesc for snapshot object for domains with 'host-passthrough' cpu
    mode selected nor accept additional flags for the mentioned method to
    get such information.
    Fortunately, this can be done using XMLDesc domain method by passing
    VIR_DOMAIN_XML_UPDATE_CPU flag.

    Change-Id: I06c574c16f3a39d22a773bf306527293882a015a
    Closes-Bug: #1535259

Changed in fuel:
status: In Progress → Fix Committed
Revision history for this message
Dennis Dmitriev (ddmitriev) wrote :

Fix released in fuel-devops@2.9.17

Changed in fuel:
status: Fix Committed → Fix Released
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Change abandoned on fuel-qa (master)

Change abandoned by Dmitry Kaigarodsev (<email address hidden>) on branch: master
Review: https://review.openstack.org/272023
Reason: outdated since we're already using 2.9.19

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.