Bug 1119031

Summary: Error taking a snapshot: libvirtError: unsupported configuration: source for disk 'vda' is not a regular file; refusing to generate external snapshot name
Product: Red Hat Enterprise Virtualization Manager Reporter: Ohad Basan <obasan>
Component: vdsmAssignee: Nir Soffer <nsoffer>
Status: CLOSED WORKSFORME QA Contact: Aharon Canan <acanan>
Severity: medium Docs Contact:
Priority: medium    
Version: 3.5.0CC: alitke, amureini, bazulay, eedri, gchakkar, gklein, iheim, lpeer, nsoffer, obasan, scohen, tnisan, yeylon
Target Milestone: ovirt-3.6.3Keywords: Reopened, Triaged
Target Release: 3.6.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard: storage
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-04-20 21:14:25 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: Storage RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Ohad Basan 2014-07-13 11:10:59 UTC
Description of problem:

System is failing to save a snapshot.
this problem is reproducing 100% of the time.

Thread-13::DEBUG::2014-07-13 13:19:22,543::libvirtconnection::143::root::(wrapper) Unknown libvirterror: ecode: 67 edom: 35 level: 2 message: unsupported configuration: source for disk 'vda' is not a regular fil
e; refusing to generate external snapshot name
Thread-13::DEBUG::2014-07-13 13:19:22,543::vm::4202::vm.Vm::(snapshot) vmId=`d5268804-24b1-46b4-aafc-6d039979e7b6`::Snapshot failed using the quiesce flag, trying again without it (unsupported configuration: sou
rce for disk 'vda' is not a regular file; refusing to generate external snapshot name)
Thread-13::DEBUG::2014-07-13 13:19:22,551::libvirtconnection::143::root::(wrapper) Unknown libvirterror: ecode: 67 edom: 35 level: 2 message: unsupported configuration: source for disk 'vda' is not a regular fil
e; refusing to generate external snapshot name
Thread-13::ERROR::2014-07-13 13:19:22,552::vm::4206::vm.Vm::(snapshot) vmId=`d5268804-24b1-46b4-aafc-6d039979e7b6`::Unable to take snapshot
Traceback (most recent call last):
  File "/usr/share/vdsm/virt/vm.py", line 4204, in snapshot
    self._dom.snapshotCreateXML(snapxml, snapFlags)
  File "/usr/share/vdsm/virt/vm.py", line 604, in f
    ret = attr(*args, **kwargs)
  File "/usr/lib64/python2.6/site-packages/vdsm/libvirtconnection.py", line 111, in wrapper
    ret = f(*args, **kwargs)
  File "/usr/lib64/python2.6/site-packages/libvirt.py", line 1636, in snapshotCreateXML
    if ret is None:raise libvirtError('virDomainSnapshotCreateXML() failed', dom=self)
libvirtError: unsupported configuration: source for disk 'vda' is not a regular file; refusing to generate external snapshot name

Comment 4 Allon Mureinik 2014-07-23 08:45:42 UTC
Nir, any update on this issue?

Comment 5 Nir Soffer 2014-07-23 09:50:53 UTC
Ohad, please add missing info:

- Versions of the relevant components
- Steps to reproduce

Comment 7 Allon Mureinik 2014-07-23 11:18:29 UTC
Ohad, two more questions please:
- can you also please add the output of "rpm -qa | grep kvm"?
- can you also please add the output of "cat /etc/redhat-release"?

Comment 8 Nir Soffer 2014-07-23 12:10:48 UTC
Ohad, please give more details, you cannot reproduce this by creating a vm - you need a storage domain of some type, and a disk, right?

Please describe the steps to reproduce it on a clean installation.

Comment 9 Ohad Basan 2014-09-01 11:52:59 UTC
I tried to reprouce that on a clean environment and didn't succeed.
I suggest to close it for now until this issue will reappear.

Comment 10 Nir Soffer 2014-09-01 14:09:04 UTC
Closed based on comment 9.

Comment 12 Allon Mureinik 2015-03-19 07:14:45 UTC
Gajanan, please upload engine and VDSM's logs bugzilla.
Thanks!

Comment 13 Allon Mureinik 2015-03-22 15:19:11 UTC
Also, if you can specify the libvirt version you are using, that could be great.

Comment 14 Gajanan 2015-03-26 19:39:48 UTC
Created attachment 1006970 [details]
vdsm.log.1.xz

Comment 15 Gajanan 2015-03-26 19:46:59 UTC
Created attachment 1006971 [details]
engine.log-20150319.gz

Comment 19 Allon Mureinik 2015-04-02 06:25:22 UTC
Looks like a dup of bug 1115126, no?

Comment 20 Nir Soffer 2015-04-05 21:08:34 UTC
(In reply to Allon Mureinik from comment #19)
> Looks like a dup of bug 1115126, no?

Looks like a dup, but this should be fixed in ovirt-3.5, while the reporter is running rhev 3.5.0. Adam, is your fix included in vdsm-4.16.8.1-8?

Comment 21 Adam Litke 2015-04-06 18:14:59 UTC
Yes, the patch is in vdsm-4.16.8.1-8.

Comment 22 Adam Litke 2015-04-06 18:34:27 UTC
I've also verified in the src.rpm for vdsm-4.16.8.1-8.el6ev.x86_64 that the fix is there.  From the provided log, I see a snapshot XML being created without the 'file' attribute which is not possible with vdsm-4.16.8.1-8.el6ev.x86_64 since the code looks like this:

def _diskSnapshot(vmDev, newPath, sourceType):
            """Libvirt snapshot XML"""

            disk = XMLElement('disk', name=vmDev, snapshot='external',
                              type=sourceType)
            # Libvirt versions before 1.2.2 do not understand 'type' and treat
            # all snapshots as if they are type='file'.  In order to ensure
            # proper handling of block snapshots in modern libvirt versions,
            # we specify type='block' and dev=path for block volumes but we
            # always speficy the file=path for backwards compatibility.
            args = {'type': sourceType, 'file': newPath}
            if sourceType == 'block':
                args['dev'] = newPath
            disk.appendChildWithArgs('source', **args)
            return disk

As you can see, the file attribute is specified unconditionally.

Comment 23 Nir Soffer 2015-04-06 18:48:53 UTC
(In reply to Adam Litke from comment #22)
> I've also verified in the src.rpm for vdsm-4.16.8.1-8.el6ev.x86_64 that the
> fix is there.  From the provided log, I see a snapshot XML being created
> without the 'file' attribute which is not possible with
> vdsm-4.16.8.1-8.el6ev.x86_64 since the code looks like this:

So this must be a duplicate of bug 1115126, and the vdsm version mentioned
in comment 11 must be wrong.

Gajanan, please make sure you are running vdsm-4.16.8.1-8.el6ev.x86_64 and
try to reproduce this.

Comment 24 Allon Mureinik 2015-04-20 21:14:25 UTC
We are unable to reproduce with the given libvirt version.
Gajanan, if you can reproduce this, please file a new bug with exact steps to reproduce.