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
Nir, any update on this issue?
Ohad, please add missing info: - Versions of the relevant components - Steps to reproduce
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"?
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.
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.
Closed based on comment 9.
Gajanan, please upload engine and VDSM's logs bugzilla. Thanks!
Also, if you can specify the libvirt version you are using, that could be great.
Created attachment 1006970 [details] vdsm.log.1.xz
Created attachment 1006971 [details] engine.log-20150319.gz
Looks like a dup of bug 1115126, no?
(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?
Yes, the patch is in vdsm-4.16.8.1-8.
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.
(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.
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.