Bug 1085852
| Summary: | GlusterFS: Instance is not using the correct snapshot backing file after reboot | |||
|---|---|---|---|---|
| Product: | Red Hat OpenStack | Reporter: | Eric Harney <eharney> | |
| Component: | openstack-nova | Assignee: | Eric Harney <eharney> | |
| Status: | CLOSED ERRATA | QA Contact: | Yogev Rabl <yrabl> | |
| Severity: | high | Docs Contact: | ||
| Priority: | high | |||
| Version: | 4.0 | CC: | breeler, eharney, fpercoco, ndipanov, nlevinki, scohen, sgordon, vpopovic, yeylon | |
| Target Milestone: | rc | |||
| Target Release: | 5.0 (RHEL 7) | |||
| Hardware: | Unspecified | |||
| OS: | Unspecified | |||
| Whiteboard: | ||||
| Fixed In Version: | openstack-nova-2014.1.1-1.el7ost | Doc Type: | Bug Fix | |
| Doc Text: |
The GlusterFS driver changes the file name used to point to a volume when a snapshot is changed, but in the past the new file name was not stored in Compute's block device information.
As a result, if the VM was shut down and started again, the old file name in the snapshot chain was used, resulting in corruption of the qcow2 chain and unexpected results in the instance.
This has been fixed by persisting the new file name in Compute's block device info when a snapshot is created.
Now, GlusterFS volumes work as expected after creating or deleting a snapshot and then rebooting the instance.
|
Story Points: | --- | |
| Clone Of: | ||||
| : | 1100473 (view as bug list) | Environment: | ||
| Last Closed: | 2014-07-24 17:22:55 UTC | Type: | Bug | |
| Regression: | --- | Mount Type: | --- | |
| Documentation: | --- | CRM: | ||
| Verified Versions: | Category: | --- | ||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | ||
| Cloudforms Team: | --- | Target Upstream Version: | ||
| Embargoed: | ||||
| Bug Depends On: | ||||
| Bug Blocks: | 1045196, 1100473 | |||
|
Description
Eric Harney
2014-04-09 13:58:39 UTC
From the libvirt.xml:
<disk type="file" device="disk">
<driver name="qemu" type="qcow2" cache="none"/>
<source file="/var/lib/nova/mnt/e3a1bfd120fee28370d03856c402d81a/volume-d50ee694-f8eb-4284-a6a3-ac8127b28848.301f8bab-4364-4522-9329-ce67bf010c8e"/>
<target bus="virtio" dev="vdb"/>
<serial>d50ee694-f8eb-4284-a6a3-ac8127b28848</serial>
</disk>
verified in version:
openstack-cinder-2014.1.1-1.el7ost.noarch
python-cinder-2014.1.1-1.el7ost.noarch
python-cinderclient-1.0.9-1.el7ost.noarch
python-nova-2014.1.1-4.el7ost.noarch
openstack-nova-console-2014.1.1-4.el7ost.noarch
openstack-nova-compute-2014.1.1-4.el7ost.noarch
openstack-nova-scheduler-2014.1.1-4.el7ost.noarch
openstack-nova-api-2014.1.1-4.el7ost.noarch
openstack-nova-cert-2014.1.1-4.el7ost.noarch
python-novaclient-2.17.0-2.el7ost.noarch
openstack-nova-novncproxy-2014.1.1-4.el7ost.noarch
openstack-nova-network-2014.1.1-4.el7ost.noarch
openstack-nova-common-2014.1.1-4.el7ost.noarch
openstack-nova-conductor-2014.1.1-4.el7ost.noarch
libvirt-daemon-1.1.1-29.el7_0.1.x86_64
libvirt-daemon-kvm-1.1.1-29.el7_0.1.x86_64
libvirt-daemon-driver-nodedev-1.1.1-29.el7_0.1.x86_64
libvirt-client-1.1.1-29.el7_0.1.x86_64
libvirt-daemon-driver-qemu-1.1.1-29.el7_0.1.x86_64
libvirt-daemon-driver-interface-1.1.1-29.el7_0.1.x86_64
libvirt-daemon-config-network-1.1.1-29.el7_0.1.x86_64
libvirt-python-1.1.1-29.el7_0.1.x86_64
libvirt-daemon-driver-nwfilter-1.1.1-29.el7_0.1.x86_64
libvirt-daemon-driver-storage-1.1.1-29.el7_0.1.x86_64
libvirt-daemon-config-nwfilter-1.1.1-29.el7_0.1.x86_64
libvirt-daemon-driver-secret-1.1.1-29.el7_0.1.x86_64
libvirt-1.1.1-29.el7_0.1.x86_64
libvirt-daemon-driver-network-1.1.1-29.el7_0.1.x86_64
libvirt-daemon-driver-lxc-1.1.1-29.el7_0.1.x86_64
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHSA-2014-0940.html |