July 2017 - Users - oVirt List Archives

Re: [ovirt-users] oVIRT 4.1.3 / iSCSI / VM Multiple Disks / Snapshot deletion issue.
by Benny Zlotnik 16 Jul '17

16 Jul '17

[Adding ovirt-users] On Sun, Jul 16, 2017 at 12:58 PM, Benny Zlotnik <bzlotnik(a)redhat.com> wrote: > We can see a lot of related errors in the engine log but we are unable > to correlate to the vdsm log. Do you have more hosts? If yes, please > attach their logs as well. > And just to be sure you were attempting to perform cold merge? > > On Fri, Jul 14, 2017 at 7:32 PM, Devin Acosta <devin(a)pabstatencio.com> wrote: >> >> You can get my logs from: >> >> https://files.linuxstack.cloud/s/NjoyMF11I38rJpH >> >> They were a little to big to attach to this e-mail. Would like to know if >> this is the similar bug that Richard indicated is a possibility. >> >> -- >> >> Devin Acosta >> Red Hat Certified Architect, LinuxStack >> 602-354-1220 || devin(a)linuxguru.co >> >> On July 14, 2017 at 9:18:08 AM, Devin Acosta (devin(a)pabstatencio.com) wrote: >> >> I have attached the logs. >> >> >> >> -- >> >> Devin Acosta >> Red Hat Certified Architect, LinuxStack >> 602-354-1220 || devin(a)linuxguru.co >> >> On July 13, 2017 at 9:22:03 AM, richard anthony falzini >> (richardfalzini(a)gmail.com) wrote: >> >> Hi, >> i have the same problem with gluster. >> this is a bug that i opened >> https://bugzilla.redhat.com/show_bug.cgi?id=1461029 . >> In the bug i used single disk vm but i start to notice the problem with >> multiple disk vm. >> >> >> 2017-07-13 0:07 GMT+02:00 Devin Acosta <devin(a)pabstatencio.com>: >>> >>> We are running a fresh install of oVIRT 4.1.3, using ISCSI, the VM in >>> question has multiple Disks (4 to be exact). It snapshotted OK while on >>> iSCSI however when I went to delete the single snapshot that existed it went >>> into Locked state and never came back. The deletion has been going for well >>> over an hour, and I am not convinced since the snapshot is less than 12 >>> hours old that it’s really doing anything. >>> >>> I have seen that doing some Googling indicates there might be some known >>> issues with iSCSI/Block Storage/Multiple Disk Snapshot issues. >>> >>> In the logs on the engine it shows: >>> >>> 2017-07-12 21:59:42,473Z INFO >>> [org.ovirt.engine.core.bll.SerialChildCommandsExecutionCallback] >>> (DefaultQuartzScheduler2) [a5f6eaf2-7996-4d51-ba62-050272d1f097] Command >>> 'ColdMergeSnapshotSingleDisk' (id: '75c535fd-4558-459a-9992-875c48578a97') >>> waiting on child command id: 'd92e9a22-5f0f-4b61-aac6-5601f8ac2cda' >>> type:'PrepareMerge' to complete >>> 2017-07-12 21:59:52,480Z INFO >>> [org.ovirt.engine.core.bll.ConcurrentChildCommandsExecutionCallback] >>> (DefaultQuartzScheduler2) [a5f6eaf2-7996-4d51-ba62-050272d1f097] Command >>> 'RemoveSnapshot' (id: '40482d09-8a7c-4dbd-8324-3e789296887a') waiting on >>> child command id: '75c535fd-4558-459a-9992-875c48578a97' >>> type:'ColdMergeSnapshotSingleDisk' to complete >>> 2017-07-12 21:59:52,483Z INFO >>> [org.ovirt.engine.core.bll.SerialChildCommandsExecutionCallback] >>> (DefaultQuartzScheduler2) [a5f6eaf2-7996-4d51-ba62-050272d1f097] Command >>> 'ColdMergeSnapshotSingleDisk' (id: '75c535fd-4558-459a-9992-875c48578a97') >>> waiting on child command id: 'd92e9a22-5f0f-4b61-aac6-5601f8ac2cda' >>> type:'PrepareMerge' to complete >>> 2017-07-12 22:00:02,490Z INFO >>> [org.ovirt.engine.core.bll.ConcurrentChildCommandsExecutionCallback] >>> (DefaultQuartzScheduler6) [a5f6eaf2-7996-4d51-ba62-050272d1f097] Command >>> 'RemoveSnapshot' (id: '40482d09-8a7c-4dbd-8324-3e789296887a') waiting on >>> child command id: '75c535fd-4558-459a-9992-875c48578a97' >>> type:'ColdMergeSnapshotSingleDisk' to complete >>> 2017-07-12 22:00:02,493Z INFO >>> [org.ovirt.engine.core.bll.SerialChildCommandsExecutionCallback] >>> (DefaultQuartzScheduler6) [a5f6eaf2-7996-4d51-ba62-050272d1f097] Command >>> 'ColdMergeSnapshotSingleDisk' (id: '75c535fd-4558-459a-9992-875c48578a97') >>> waiting on child command id: 'd92e9a22-5f0f-4b61-aac6-5601f8ac2cda' >>> type:'PrepareMerge' to complete >>> 2017-07-12 22:00:12,498Z INFO >>> [org.ovirt.engine.core.bll.ConcurrentChildCommandsExecutionCallback] >>> (DefaultQuartzScheduler3) [a5f6eaf2-7996-4d51-ba62-050272d1f097] Command >>> 'RemoveSnapshot' (id: '40482d09-8a7c-4dbd-8324-3e789296887a') waiting on >>> child command id: '75c535fd-4558-459a-9992-875c48578a97' >>> type:'ColdMergeSnapshotSingleDisk' to complete >>> 2017-07-12 22:00:12,501Z INFO >>> [org.ovirt.engine.core.bll.SerialChildCommandsExecutionCallback] >>> (DefaultQuartzScheduler3) [a5f6eaf2-7996-4d51-ba62-050272d1f097] Command >>> 'ColdMergeSnapshotSingleDisk' (id: '75c535fd-4558-459a-9992-875c48578a97') >>> waiting on child command id: 'd92e9a22-5f0f-4b61-aac6-5601f8ac2cda' >>> type:'PrepareMerge' to complete >>> 2017-07-12 22:00:22,508Z INFO >>> [org.ovirt.engine.core.bll.ConcurrentChildCommandsExecutionCallback] >>> (DefaultQuartzScheduler5) [a5f6eaf2-7996-4d51-ba62-050272d1f097] Command >>> 'RemoveSnapshot' (id: '40482d09-8a7c-4dbd-8324-3e789296887a') waiting on >>> child command id: '75c535fd-4558-459a-9992-875c48578a97' >>> type:'ColdMergeSnapshotSingleDisk' to complete >>> 2017-07-12 22:00:22,511Z INFO >>> [org.ovirt.engine.core.bll.SerialChildCommandsExecutionCallback] >>> (DefaultQuartzScheduler5) [a5f6eaf2-7996-4d51-ba62-050272d1f097] Command >>> 'ColdMergeSnapshotSingleDisk' (id: '75c535fd-4558-459a-9992-875c48578a97') >>> waiting on child command id: 'd92e9a22-5f0f-4b61-aac6-5601f8ac2cda' >>> type:'PrepareMerge' to complete >>> >>> This is what I seen on the SPM when I grep’d the Snapshot ID. >>> >>> 2017-07-12 14:22:18,773-0700 INFO (jsonrpc/6) [vdsm.api] START >>> createVolume(sdUUID=u'0c02a758-4295-4199-97de-b041744b3b15', >>> spUUID=u'00000001-0001-0001-0001-000000000311', >>> imgUUID=u'6a887015-67cd-4f7b-b709-eef97142258d', size=u'107374182400', >>> volFormat=4, preallocate=2, diskType=2, >>> volUUID=u'5921ba71-0f00-46cd-b0be-3c2ac1396845', desc=u'', >>> srcImgUUID=u'6a887015-67cd-4f7b-b709-eef97142258d', >>> srcVolUUID=u'0c3de1a8-ac18-4d7b-b348-3b097bf0a0ae', initialSize=None) >>> from=::ffff:10.4.64.7,60016, flow_id=e94eebf8-75dc-407a-8916-f4ff632f843e >>> (api:46) >>> 2017-07-12 14:22:19,095-0700 WARN (tasks/6) [root] File: >>> /rhev/data-center/00000001-0001-0001-0001-000000000311/0c02a758-4295-4199-97de-b041744b3b15/images/6a887015-67cd-4f7b-b709-eef97142258d/5921ba71-0f00-46cd-b0be-3c2ac1396845 >>> already removed (utils:120) >>> 2017-07-12 14:22:19,096-0700 INFO (tasks/6) [storage.Volume] Request to >>> create snapshot >>> 6a887015-67cd-4f7b-b709-eef97142258d/5921ba71-0f00-46cd-b0be-3c2ac1396845 of >>> volume >>> 6a887015-67cd-4f7b-b709-eef97142258d/0c3de1a8-ac18-4d7b-b348-3b097bf0a0ae >>> (blockVolume:545) >>> 2017-07-12 14:22:19,676-0700 INFO (tasks/6) [storage.LVM] Change LV tags >>> (vg=0c02a758-4295-4199-97de-b041744b3b15, >>> lv=5921ba71-0f00-46cd-b0be-3c2ac1396845, delTags=['OVIRT_VOL_INITIALIZING'], >>> addTags=['MD_10', u'PU_0c3de1a8-ac18-4d7b-b348-3b097bf0a0ae', >>> u'IU_6a887015-67cd-4f7b-b709-eef97142258d']) (lvm:1344) >>> 2017-07-12 14:22:36,010-0700 INFO (jsonrpc/5) [vdsm.api] START >>> getVolumeInfo(sdUUID=u'0c02a758-4295-4199-97de-b041744b3b15', >>> spUUID=u'00000001-0001-0001-0001-000000000311', >>> imgUUID=u'6a887015-67cd-4f7b-b709-eef97142258d', >>> volUUID=u'5921ba71-0f00-46cd-b0be-3c2ac1396845', options=None) >>> from=::ffff:10.4.64.7,59664, flow_id=e94eebf8-75dc-407a-8916-f4ff632f843e >>> (api:46) >>> 2017-07-12 14:22:36,077-0700 INFO (jsonrpc/5) [storage.VolumeManifest] >>> Info request: sdUUID=0c02a758-4295-4199-97de-b041744b3b15 >>> imgUUID=6a887015-67cd-4f7b-b709-eef97142258d volUUID = >>> 5921ba71-0f00-46cd-b0be-3c2ac1396845 (volume:238) >>> 2017-07-12 14:22:36,185-0700 INFO (jsonrpc/5) [storage.VolumeManifest] >>> 0c02a758-4295-4199-97de-b041744b3b15/6a887015-67cd-4f7b-b709-eef97142258d/5921ba71-0f00-46cd-b0be-3c2ac1396845 >>> info is {'status': 'OK', 'domain': '0c02a758-4295-4199-97de-b041744b3b15', >>> 'voltype': 'LEAF', 'description': '', 'parent': >>> '0c3de1a8-ac18-4d7b-b348-3b097bf0a0ae', 'format': 'COW', 'generation': 0, >>> 'image': '6a887015-67cd-4f7b-b709-eef97142258d', 'ctime': '1499894539', >>> 'disktype': '2', 'legality': 'LEGAL', 'mtime': '0', 'apparentsize': >>> '1073741824', 'children': [], 'pool': '', 'capacity': '107374182400', >>> 'uuid': u'5921ba71-0f00-46cd-b0be-3c2ac1396845', 'truesize': '1073741824', >>> 'type': 'SPARSE', 'lease': {'owners': [], 'version': None}} (volume:272) >>> 2017-07-12 14:22:36,186-0700 INFO (jsonrpc/5) [vdsm.api] FINISH >>> getVolumeInfo return={'info': {'status': 'OK', 'domain': >>> '0c02a758-4295-4199-97de-b041744b3b15', 'voltype': 'LEAF', 'description': >>> '', 'parent': '0c3de1a8-ac18-4d7b-b348-3b097bf0a0ae', 'format': 'COW', >>> 'generation': 0, 'image': '6a887015-67cd-4f7b-b709-eef97142258d', 'ctime': >>> '1499894539', 'disktype': '2', 'legality': 'LEGAL', 'mtime': '0', >>> 'apparentsize': '1073741824', 'children': [], 'pool': '', 'capacity': >>> '107374182400', 'uuid': u'5921ba71-0f00-46cd-b0be-3c2ac1396845', 'truesize': >>> '1073741824', 'type': 'SPARSE', 'lease': {'owners': [], 'version': None}}} >>> from=::ffff:10.4.64.7,59664, flow_id=e94eebf8-75dc-407a-8916-f4ff632f843e >>> (api:52) >>> 2017-07-12 14:24:24,854-0700 INFO (jsonrpc/1) [vdsm.api] START >>> deleteVolume(sdUUID=u'0c02a758-4295-4199-97de-b041744b3b15', >>> spUUID=u'00000001-0001-0001-0001-000000000311', >>> imgUUID=u'6a887015-67cd-4f7b-b709-eef97142258d', >>> volumes=[u'5921ba71-0f00-46cd-b0be-3c2ac1396845'], postZero=u'false', >>> force=u'false', discard=False) from=::ffff:10.4.64.7,60016, >>> flow_id=c5e4bda4-9cd3-461d-8164-51d5614b995e (api:46) >>> 2017-07-12 14:24:25,010-0700 INFO (tasks/7) [storage.Volume] Request to >>> delete LV 5921ba71-0f00-46cd-b0be-3c2ac1396845 of image >>> 6a887015-67cd-4f7b-b709-eef97142258d in VG >>> 0c02a758-4295-4199-97de-b041744b3b15 (blockVolume:579) >>> 2017-07-12 14:24:25,130-0700 INFO (tasks/7) [storage.VolumeManifest] >>> sdUUID=0c02a758-4295-4199-97de-b041744b3b15 >>> imgUUID=6a887015-67cd-4f7b-b709-eef97142258d volUUID = >>> 5921ba71-0f00-46cd-b0be-3c2ac1396845 legality = ILLEGAL (volume:398) >>> 2017-07-12 14:24:38,881-0700 INFO (jsonrpc/2) [vdsm.api] START >>> getVolumeInfo(sdUUID=u'0c02a758-4295-4199-97de-b041744b3b15', >>> spUUID=u'00000001-0001-0001-0001-000000000311', >>> imgUUID=u'6a887015-67cd-4f7b-b709-eef97142258d', >>> volUUID=u'5921ba71-0f00-46cd-b0be-3c2ac1396845', options=None) >>> from=::ffff:10.4.64.7,59664, flow_id=c5e4bda4-9cd3-461d-8164-51d5614b995e >>> (api:46) >>> 2017-07-12 14:24:49,911-0700 INFO (jsonrpc/1) [vdsm.api] START >>> getVolumeInfo(sdUUID=u'0c02a758-4295-4199-97de-b041744b3b15', >>> spUUID=u'00000001-0001-0001-0001-000000000311', >>> imgUUID=u'6a887015-67cd-4f7b-b709-eef97142258d', >>> volUUID=u'0c3de1a8-ac18-4d7b-b348-3b097bf0a0ae', options=None) >>> from=::ffff:10.4.64.7,59664, flow_id=c5e4bda4-9cd3-461d-8164-51d5614b995e >>> (api:46) >>> 2017-07-12 14:24:49,912-0700 INFO (jsonrpc/1) [storage.VolumeManifest] >>> Info request: sdUUID=0c02a758-4295-4199-97de-b041744b3b15 >>> imgUUID=6a887015-67cd-4f7b-b709-eef97142258d volUUID = >>> 0c3de1a8-ac18-4d7b-b348-3b097bf0a0ae (volume:238) >>> 2017-07-12 14:24:50,036-0700 INFO (jsonrpc/1) [storage.VolumeManifest] >>> 0c02a758-4295-4199-97de-b041744b3b15/6a887015-67cd-4f7b-b709-eef97142258d/0c3de1a8-ac18-4d7b-b348-3b097bf0a0ae >>> info is {'status': 'OK', 'domain': '0c02a758-4295-4199-97de-b041744b3b15', >>> 'voltype': 'LEAF', 'description': '', 'parent': >>> '00000000-0000-0000-0000-000000000000', 'format': 'COW', 'generation': 0, >>> 'image': '6a887015-67cd-4f7b-b709-eef97142258d', 'ctime': '1499885619', >>> 'disktype': '2', 'legality': 'LEGAL', 'mtime': '0', 'apparentsize': >>> '110729625600', 'children': [], 'pool': '', 'capacity': '107374182400', >>> 'uuid': u'0c3de1a8-ac18-4d7b-b348-3b097bf0a0ae', 'truesize': '110729625600', >>> 'type': 'SPARSE', 'lease': {'owners': [], 'version': None}} (volume:272) >>> 2017-07-12 14:24:50,037-0700 INFO (jsonrpc/1) [vdsm.api] FINISH >>> getVolumeInfo return={'info': {'status': 'OK', 'domain': >>> '0c02a758-4295-4199-97de-b041744b3b15', 'voltype': 'LEAF', 'description': >>> '', 'parent': '00000000-0000-0000-0000-000000000000', 'format': 'COW', >>> 'generation': 0, 'image': '6a887015-67cd-4f7b-b709-eef97142258d', 'ctime': >>> '1499885619', 'disktype': '2', 'legality': 'LEGAL', 'mtime': '0', >>> 'apparentsize': '110729625600', 'children': [], 'pool': '', 'capacity': >>> '107374182400', 'uuid': u'0c3de1a8-ac18-4d7b-b348-3b097bf0a0ae', 'truesize': >>> '110729625600', 'type': 'SPARSE', 'lease': {'owners': [], 'version': None}}} >>> from=::ffff:10.4.64.7,59664, flow_id=c5e4bda4-9cd3-461d-8164-51d5614b995e >>> (api:52) >>> >>> HELP, Right now I am starting to think Block Storage and oVIRT = BAD! >>> >>> >>> >>> >>> -- >>> >>> Devin Acosta >>> Red Hat Certified Architect, LinuxStack >>> >>> >>> >>> _______________________________________________ >>> Users mailing list >>> Users(a)ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/users >>> >>

1 0

oVIRT 4.1.3 / iSCSI / VM Multiple Disks / Snapshot deletion issue.
by Devin Acosta 14 Jul '17

14 Jul '17

We are running a fresh install of oVIRT 4.1.3, using ISCSI, the VM in question has multiple Disks (4 to be exact). It snapshotted OK while on iSCSI however when I went to delete the single snapshot that existed it went into Locked state and never came back. The deletion has been going for well over an hour, and I am not convinced since the snapshot is less than 12 hours old that it’s really doing anything. I have seen that doing some Googling indicates there might be some known issues with iSCSI/Block Storage/Multiple Disk Snapshot issues. In the logs on the engine it shows: 2017-07-12 21:59:42,473Z INFO [org.ovirt.engine.core.bll.SerialChildCommandsExecutionCallback] (DefaultQuartzScheduler2) [a5f6eaf2-7996-4d51-ba62-050272d1f097] Command 'ColdMergeSnapshotSingleDisk' (id: '75c535fd-4558-459a-9992-875c48578a97') waiting on child command id: 'd92e9a22-5f0f-4b61-aac6-5601f8ac2cda' type:'PrepareMerge' to complete 2017-07-12 21:59:52,480Z INFO [org.ovirt.engine.core.bll.ConcurrentChildCommandsExecutionCallback] (DefaultQuartzScheduler2) [a5f6eaf2-7996-4d51-ba62-050272d1f097] Command 'RemoveSnapshot' (id: '40482d09-8a7c-4dbd-8324-3e789296887a') waiting on child command id: '75c535fd-4558-459a-9992-875c48578a97' type:'ColdMergeSnapshotSingleDisk' to complete 2017-07-12 21:59:52,483Z INFO [org.ovirt.engine.core.bll.SerialChildCommandsExecutionCallback] (DefaultQuartzScheduler2) [a5f6eaf2-7996-4d51-ba62-050272d1f097] Command 'ColdMergeSnapshotSingleDisk' (id: '75c535fd-4558-459a-9992-875c48578a97') waiting on child command id: 'd92e9a22-5f0f-4b61-aac6-5601f8ac2cda' type:'PrepareMerge' to complete 2017-07-12 22:00:02,490Z INFO [org.ovirt.engine.core.bll.ConcurrentChildCommandsExecutionCallback] (DefaultQuartzScheduler6) [a5f6eaf2-7996-4d51-ba62-050272d1f097] Command 'RemoveSnapshot' (id: '40482d09-8a7c-4dbd-8324-3e789296887a') waiting on child command id: '75c535fd-4558-459a-9992-875c48578a97' type:'ColdMergeSnapshotSingleDisk' to complete 2017-07-12 22:00:02,493Z INFO [org.ovirt.engine.core.bll.SerialChildCommandsExecutionCallback] (DefaultQuartzScheduler6) [a5f6eaf2-7996-4d51-ba62-050272d1f097] Command 'ColdMergeSnapshotSingleDisk' (id: '75c535fd-4558-459a-9992-875c48578a97') waiting on child command id: 'd92e9a22-5f0f-4b61-aac6-5601f8ac2cda' type:'PrepareMerge' to complete 2017-07-12 22:00:12,498Z INFO [org.ovirt.engine.core.bll.ConcurrentChildCommandsExecutionCallback] (DefaultQuartzScheduler3) [a5f6eaf2-7996-4d51-ba62-050272d1f097] Command 'RemoveSnapshot' (id: '40482d09-8a7c-4dbd-8324-3e789296887a') waiting on child command id: '75c535fd-4558-459a-9992-875c48578a97' type:'ColdMergeSnapshotSingleDisk' to complete 2017-07-12 22:00:12,501Z INFO [org.ovirt.engine.core.bll.SerialChildCommandsExecutionCallback] (DefaultQuartzScheduler3) [a5f6eaf2-7996-4d51-ba62-050272d1f097] Command 'ColdMergeSnapshotSingleDisk' (id: '75c535fd-4558-459a-9992-875c48578a97') waiting on child command id: 'd92e9a22-5f0f-4b61-aac6-5601f8ac2cda' type:'PrepareMerge' to complete 2017-07-12 22:00:22,508Z INFO [org.ovirt.engine.core.bll.ConcurrentChildCommandsExecutionCallback] (DefaultQuartzScheduler5) [a5f6eaf2-7996-4d51-ba62-050272d1f097] Command 'RemoveSnapshot' (id: '40482d09-8a7c-4dbd-8324-3e789296887a') waiting on child command id: '75c535fd-4558-459a-9992-875c48578a97' type:'ColdMergeSnapshotSingleDisk' to complete 2017-07-12 22:00:22,511Z INFO [org.ovirt.engine.core.bll.SerialChildCommandsExecutionCallback] (DefaultQuartzScheduler5) [a5f6eaf2-7996-4d51-ba62-050272d1f097] Command 'ColdMergeSnapshotSingleDisk' (id: '75c535fd-4558-459a-9992-875c48578a97') waiting on child command id: 'd92e9a22-5f0f-4b61-aac6-5601f8ac2cda' type:'PrepareMerge' to complete This is what I seen on the SPM when I grep’d the Snapshot ID. 2017-07-12 14:22:18,773-0700 INFO (jsonrpc/6) [vdsm.api] START createVolume(sdUUID=u'0c02a758-4295-4199-97de-b041744b3b15', spUUID=u'00000001-0001-0001-0001-000000000311', imgUUID=u'6a887015-67cd-4f7b-b709-eef97142258d', size=u'107374182400', volFormat=4, preallocate=2, diskType=2, volUUID=u'5921ba71-0f00-46cd-b0be-3c2ac1396845', desc=u'', srcImgUUID=u'6a887015-67cd-4f7b-b709-eef97142258d', srcVolUUID=u'0c3de1a8-ac18-4d7b-b348-3b097bf0a0ae', initialSize=None) from=::ffff:10.4.64.7,60016, flow_id=e94eebf8-75dc-407a-8916-f4ff632f843e (api:46) 2017-07-12 14:22:19,095-0700 WARN (tasks/6) [root] File: /rhev/data-center/00000001-0001-0001-0001-000000000311/0c02a758-4295-4199-97de-b041744b3b15/images/6a887015-67cd-4f7b-b709-eef97142258d/5921ba71-0f00-46cd-b0be-3c2ac1396845 already removed (utils:120) 2017-07-12 14:22:19,096-0700 INFO (tasks/6) [storage.Volume] Request to create snapshot 6a887015-67cd-4f7b-b709-eef97142258d/5921ba71-0f00-46cd-b0be-3c2ac1396845 of volume 6a887015-67cd-4f7b-b709-eef97142258d/0c3de1a8-ac18-4d7b-b348-3b097bf0a0ae (blockVolume:545) 2017-07-12 14:22:19,676-0700 INFO (tasks/6) [storage.LVM] Change LV tags (vg=0c02a758-4295-4199-97de-b041744b3b15, lv=5921ba71-0f00-46cd-b0be-3c2ac1396845, delTags=['OVIRT_VOL_INITIALIZING'], addTags=['MD_10', u'PU_0c3de1a8-ac18-4d7b-b348-3b097bf0a0ae', u'IU_6a887015-67cd-4f7b-b709-eef97142258d']) (lvm:1344) 2017-07-12 14:22:36,010-0700 INFO (jsonrpc/5) [vdsm.api] START getVolumeInfo(sdUUID=u'0c02a758-4295-4199-97de-b041744b3b15', spUUID=u'00000001-0001-0001-0001-000000000311', imgUUID=u'6a887015-67cd-4f7b-b709-eef97142258d', volUUID=u'5921ba71-0f00-46cd-b0be-3c2ac1396845', options=None) from=::ffff:10.4.64.7,59664, flow_id=e94eebf8-75dc-407a-8916-f4ff632f843e (api:46) 2017-07-12 14:22:36,077-0700 INFO (jsonrpc/5) [storage.VolumeManifest] Info request: sdUUID=0c02a758-4295-4199-97de-b041744b3b15 imgUUID=6a887015-67cd-4f7b-b709-eef97142258d volUUID = 5921ba71-0f00-46cd-b0be-3c2ac1396845 (volume:238) 2017-07-12 14:22:36,185-0700 INFO (jsonrpc/5) [storage.VolumeManifest] 0c02a758-4295-4199-97de-b041744b3b15/6a887015-67cd-4f7b-b709-eef97142258d/5921ba71-0f00-46cd-b0be-3c2ac1396845 info is {'status': 'OK', 'domain': '0c02a758-4295-4199-97de-b041744b3b15', 'voltype': 'LEAF', 'description': '', 'parent': '0c3de1a8-ac18-4d7b-b348-3b097bf0a0ae', 'format': 'COW', 'generation': 0, 'image': '6a887015-67cd-4f7b-b709-eef97142258d', 'ctime': '1499894539', 'disktype': '2', 'legality': 'LEGAL', 'mtime': '0', 'apparentsize': '1073741824', 'children': [], 'pool': '', 'capacity': '107374182400', 'uuid': u'5921ba71-0f00-46cd-b0be-3c2ac1396845', 'truesize': '1073741824', 'type': 'SPARSE', 'lease': {'owners': [], 'version': None}} (volume:272) 2017-07-12 14:22:36,186-0700 INFO (jsonrpc/5) [vdsm.api] FINISH getVolumeInfo return={'info': {'status': 'OK', 'domain': '0c02a758-4295-4199-97de-b041744b3b15', 'voltype': 'LEAF', 'description': '', 'parent': '0c3de1a8-ac18-4d7b-b348-3b097bf0a0ae', 'format': 'COW', 'generation': 0, 'image': '6a887015-67cd-4f7b-b709-eef97142258d', 'ctime': '1499894539', 'disktype': '2', 'legality': 'LEGAL', 'mtime': '0', 'apparentsize': '1073741824', 'children': [], 'pool': '', 'capacity': '107374182400', 'uuid': u'5921ba71-0f00-46cd-b0be-3c2ac1396845', 'truesize': '1073741824', 'type': 'SPARSE', 'lease': {'owners': [], 'version': None}}} from=::ffff:10.4.64.7,59664, flow_id=e94eebf8-75dc-407a-8916-f4ff632f843e (api:52) 2017-07-12 14:24:24,854-0700 INFO (jsonrpc/1) [vdsm.api] START deleteVolume(sdUUID=u'0c02a758-4295-4199-97de-b041744b3b15', spUUID=u'00000001-0001-0001-0001-000000000311', imgUUID=u'6a887015-67cd-4f7b-b709-eef97142258d', volumes=[u'5921ba71-0f00-46cd-b0be-3c2ac1396845'], postZero=u'false', force=u'false', discard=False) from=::ffff:10.4.64.7,60016, flow_id=c5e4bda4-9cd3-461d-8164-51d5614b995e (api:46) 2017-07-12 14:24:25,010-0700 INFO (tasks/7) [storage.Volume] Request to delete LV 5921ba71-0f00-46cd-b0be-3c2ac1396845 of image 6a887015-67cd-4f7b-b709-eef97142258d in VG 0c02a758-4295-4199-97de-b041744b3b15 (blockVolume:579) 2017-07-12 14:24:25,130-0700 INFO (tasks/7) [storage.VolumeManifest] sdUUID=0c02a758-4295-4199-97de-b041744b3b15 imgUUID=6a887015-67cd-4f7b-b709-eef97142258d volUUID = 5921ba71-0f00-46cd-b0be-3c2ac1396845 legality = ILLEGAL (volume:398) 2017-07-12 14:24:38,881-0700 INFO (jsonrpc/2) [vdsm.api] START getVolumeInfo(sdUUID=u'0c02a758-4295-4199-97de-b041744b3b15', spUUID=u'00000001-0001-0001-0001-000000000311', imgUUID=u'6a887015-67cd-4f7b-b709-eef97142258d', volUUID=u'5921ba71-0f00-46cd-b0be-3c2ac1396845', options=None) from=::ffff:10.4.64.7,59664, flow_id=c5e4bda4-9cd3-461d-8164-51d5614b995e (api:46) 2017-07-12 14:24:49,911-0700 INFO (jsonrpc/1) [vdsm.api] START getVolumeInfo(sdUUID=u'0c02a758-4295-4199-97de-b041744b3b15', spUUID=u'00000001-0001-0001-0001-000000000311', imgUUID=u'6a887015-67cd-4f7b-b709-eef97142258d', volUUID=u'0c3de1a8-ac18-4d7b-b348-3b097bf0a0ae', options=None) from=::ffff:10.4.64.7,59664, flow_id=c5e4bda4-9cd3-461d-8164-51d5614b995e (api:46) 2017-07-12 14:24:49,912-0700 INFO (jsonrpc/1) [storage.VolumeManifest] Info request: sdUUID=0c02a758-4295-4199-97de-b041744b3b15 imgUUID=6a887015-67cd-4f7b-b709-eef97142258d volUUID = 0c3de1a8-ac18-4d7b-b348-3b097bf0a0ae (volume:238) 2017-07-12 14:24:50,036-0700 INFO (jsonrpc/1) [storage.VolumeManifest] 0c02a758-4295-4199-97de-b041744b3b15/6a887015-67cd-4f7b-b709-eef97142258d/0c3de1a8-ac18-4d7b-b348-3b097bf0a0ae info is {'status': 'OK', 'domain': '0c02a758-4295-4199-97de-b041744b3b15', 'voltype': 'LEAF', 'description': '', 'parent': '00000000-0000-0000-0000-000000000000', 'format': 'COW', 'generation': 0, 'image': '6a887015-67cd-4f7b-b709-eef97142258d', 'ctime': '1499885619', 'disktype': '2', 'legality': 'LEGAL', 'mtime': '0', 'apparentsize': '110729625600', 'children': [], 'pool': '', 'capacity': '107374182400', 'uuid': u'0c3de1a8-ac18-4d7b-b348-3b097bf0a0ae', 'truesize': '110729625600', 'type': 'SPARSE', 'lease': {'owners': [], 'version': None}} (volume:272) 2017-07-12 14:24:50,037-0700 INFO (jsonrpc/1) [vdsm.api] FINISH getVolumeInfo return={'info': {'status': 'OK', 'domain': '0c02a758-4295-4199-97de-b041744b3b15', 'voltype': 'LEAF', 'description': '', 'parent': '00000000-0000-0000-0000-000000000000', 'format': 'COW', 'generation': 0, 'image': '6a887015-67cd-4f7b-b709-eef97142258d', 'ctime': '1499885619', 'disktype': '2', 'legality': 'LEGAL', 'mtime': '0', 'apparentsize': '110729625600', 'children': [], 'pool': '', 'capacity': '107374182400', 'uuid': u'0c3de1a8-ac18-4d7b-b348-3b097bf0a0ae', 'truesize': '110729625600', 'type': 'SPARSE', 'lease': {'owners': [], 'version': None}}} from=::ffff:10.4.64.7,59664, flow_id=c5e4bda4-9cd3-461d-8164-51d5614b995e (api:52) HELP, Right now I am starting to think Block Storage and oVIRT = BAD! -- Devin Acosta Red Hat Certified Architect, LinuxStack

4 5

oVirt Metrics
by Arsène Gschwind 14 Jul '17

14 Jul '17

This is a multi-part message in MIME format. --------------9A99E910BE6E6C7F1C6C0B2C Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi all, I'm trying to setup oVirt metrics as described at https://www.ovirt.org/develop/release-management/features/engine/metrics-st… using SSO. My oVirt installation is based on Version: 4.1.3.5-1.el7.centos. I'm missing the SSO tool called ovirt-register-sso-client as written in the doc to register new SSO client. I couldn't figure out which package contains that tool, is it included in the latest distribution ? Thanks for any help. rgds, Arsène -- *Arsène Gschwind* Fa. Sapify AG im Auftrag der Universität Basel IT Services Klingelbergstr. 70 | CH-4056 Basel | Switzerland Tel. +41 79 449 25 63 | http://its.unibas.ch <http://its.unibas.ch/> ITS-ServiceDesk: support-its(a)unibas.ch | +41 61 267 14 11 --------------9A99E910BE6E6C7F1C6C0B2C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit <html> <head> <meta http-equiv="content-type" content="text/html; charset=utf-8"> </head> <body text="#000000" bgcolor="#FFFFFF"> Hi all, I'm trying to setup oVirt metrics as described at <a class="moz-txt-link-freetext" href="https://www.ovirt.org/develop/release-management/features/engine/metrics-st…">https://www.ovirt.org/develop/release-management/features/engine/metrics-st…</a> using SSO. My oVirt installation is based on Version: 4.1.3.5-1.el7.centos. I'm missing the SSO tool called ovirt-register-sso-client as written in the doc to register new SSO client. I couldn't figure out which package contains that tool, is it included in the latest distribution ? Thanks for any help. rgds, Arsène <div class="moz-signature">-- Arsène Gschwind Fa. Sapify AG im Auftrag der Universität Basel IT Services Klingelbergstr. 70 | CH-4056 Basel | Switzerland Tel. +41 79 449 25 63 | <a href="http://its.unibas.ch/"> http://its.unibas.ch </a> ITS-ServiceDesk: <a class="moz-txt-link-abbreviated" href="mailto:support-its@unibas.ch">support-its(a)unibas.ch</a> | +41 61 267 14 11 </div> </body> </html> --------------9A99E910BE6E6C7F1C6C0B2C--

3 2

Fwd: Windows USB Redirection
by Abi Askushi 14 Jul '17

14 Jul '17

Hi All, I have Ovirt 4.1 with 3 nodes on top glusterfs. I Have 2 VMs: Windows 2016 64bit and Windows 10 64bit When I attach a USB flash disk to a VM (from host devices) the VM cannot see the USB drive and report driver issue at device manager (see attached). This happens with both VMs when tested. When testing with Windows 7 or Windows XP USB is attached and accessed normally. Have you encountered such issue? I have installed latest guest tools on both VMs. Many thanx

2 3

Removing iSCSI domain: host side part
by Gianluca Cecchi 14 Jul '17

14 Jul '17

Hello, I have cleanly removed an iSCSI domain from oVirt. There is another one (connecting to another storage array) that is the master domain. But I see that oVirt hosts still maintain the iscsi session to the LUN. So I want to clean from os point of view before removing the LUN itself from storage. At the moment I still see the multipath lun on both hosts [root@ov301 network-scripts]# multipath -l . . . 364817197b5dfd0e5538d959702249b1c dm-2 EQLOGIC ,100E-00 size=4.0T features='0' hwhandler='0' wp=rw `-+- policy='round-robin 0' prio=0 status=active |- 9:0:0:0 sde 8:64 active undef running `- 10:0:0:0 sdf 8:80 active undef running and [root@ov301 network-scripts]# iscsiadm -m session tcp: [1] 10.10.100.9:3260,1 iqn.2001-05.com.equallogic:4-771816-e5d0dfb59-1c9b240297958d53-ovsd3910 (non-flash) tcp: [2] 10.10.100.9:3260,1 iqn.2001-05.com.equallogic:4-771816-e5d0dfb59-1c9b240297958d53-ovsd3910 (non-flash) . . . Do I have to clean the multipath paths and multipath device and then iSCSI logout, or is it sufficient to iSCSI logout and the multipath device and its path will be cleanly removed from OS point of view? I would like not to have multipath device in stale condition. Thanks Gianluca

2 2

Failed to create template
by aduckers 13 Jul '17

13 Jul '17

I’m running 4.1 with a hosted engine, using FC SAN storage. I’ve uploaded a qcow2 image, then created a VM and attached that image. When trying to create a template from that VM, we get failures with: failed: low level image copy failed VDSM command DeleteImageGroupVDS failed: Image does not exist in domain failed to create template What should I be looking at to resolve this? Anyone recognize this issue? Thanks

3 11

Re: [ovirt-users] Detach disk from one VM, attach to another VM
by Victor José Acosta Domínguez 13 Jul '17

13 Jul '17

Hello Yes it is possible, you must remove from first VM's configuration (be careful, do not delete your virtual disk) After that you can attach ad that disk to another VM Process should be: - Detach disk from VM1 - Delete disk from VM1's configuration - Attach disk to VM2 Victor Acosta

3 2

2 hosts starting the engine at the same time?
by Gianluca Cecchi 13 Jul '17

13 Jul '17

Hello. I'm on 4.1.3 with self hosted engine and glusterfs as storage. I updated the kernel on engine so I executed these steps: - enable global maintenace from the web admin gui - wait some minutes - shutdown the engine vm from inside its OS - wait some minutes - execute on one host [root@ovirt02 ~]# hosted-engine --set-maintenance --mode=none I see that the qemu-kvm process for the engine starts on two hosts and then on one of them it gets a "kill -15" and stops Is it expected behaviour? It seems somehow dangerous to me.. - when in maintenance [root@ovirt02 ~]# hosted-engine --vm-status !! Cluster is in GLOBAL MAINTENANCE mode !! --== Host 1 status ==-- conf_on_shared_storage : True Status up-to-date : True Hostname : ovirt01.localdomain.local Host ID : 1 Engine status : {"health": "good", "vm": "up", "detail": "up"} Score : 2597 stopped : False Local maintenance : False crc32 : 7931c5c3 local_conf_timestamp : 19811 Host timestamp : 19794 Extra metadata (valid at timestamp): metadata_parse_version=1 metadata_feature_version=1 timestamp=19794 (Sun Jul 9 21:31:50 2017) host-id=1 score=2597 vm_conf_refresh_time=19811 (Sun Jul 9 21:32:06 2017) conf_on_shared_storage=True maintenance=False state=GlobalMaintenance stopped=False --== Host 2 status ==-- conf_on_shared_storage : True Status up-to-date : True Hostname : 192.168.150.103 Host ID : 2 Engine status : {"reason": "vm not running on this host", "health": "bad", "vm": "down", "detail": "unknown"} Score : 3400 stopped : False Local maintenance : False crc32 : 616ceb02 local_conf_timestamp : 2829 Host timestamp : 2812 Extra metadata (valid at timestamp): metadata_parse_version=1 metadata_feature_version=1 timestamp=2812 (Sun Jul 9 21:31:52 2017) host-id=2 score=3400 vm_conf_refresh_time=2829 (Sun Jul 9 21:32:09 2017) conf_on_shared_storage=True maintenance=False state=GlobalMaintenance stopped=False --== Host 3 status ==-- conf_on_shared_storage : True Status up-to-date : True Hostname : ovirt03.localdomain.local Host ID : 3 Engine status : {"reason": "vm not running on this host", "health": "bad", "vm": "down", "detail": "unknown"} Score : 3400 stopped : False Local maintenance : False crc32 : 871204b2 local_conf_timestamp : 24584 Host timestamp : 24567 Extra metadata (valid at timestamp): metadata_parse_version=1 metadata_feature_version=1 timestamp=24567 (Sun Jul 9 21:31:52 2017) host-id=3 score=3400 vm_conf_refresh_time=24584 (Sun Jul 9 21:32:09 2017) conf_on_shared_storage=True maintenance=False state=GlobalMaintenance stopped=False !! Cluster is in GLOBAL MAINTENANCE mode !! [root@ovirt02 ~]# - then I exit global maintenance [root@ovirt02 ~]# hosted-engine --set-maintenance --mode=none - During monitoring of status, at some point I see "EngineStart" on both host2 and host3 [root@ovirt02 ~]# hosted-engine --vm-status --== Host 1 status ==-- conf_on_shared_storage : True Status up-to-date : True Hostname : ovirt01.localdomain.local Host ID : 1 Engine status : {"reason": "bad vm status", "health": "bad", "vm": "down", "detail": "down"} Score : 3230 stopped : False Local maintenance : False crc32 : 25cadbfb local_conf_timestamp : 20055 Host timestamp : 20040 Extra metadata (valid at timestamp): metadata_parse_version=1 metadata_feature_version=1 timestamp=20040 (Sun Jul 9 21:35:55 2017) host-id=1 score=3230 vm_conf_refresh_time=20055 (Sun Jul 9 21:36:11 2017) conf_on_shared_storage=True maintenance=False state=EngineDown stopped=False --== Host 2 status ==-- conf_on_shared_storage : True Status up-to-date : True Hostname : 192.168.150.103 Host ID : 2 Engine status : {"reason": "vm not running on this host", "health": "bad", "vm": "down", "detail": "unknown"} Score : 3400 stopped : False Local maintenance : False crc32 : e6951128 local_conf_timestamp : 3075 Host timestamp : 3058 Extra metadata (valid at timestamp): metadata_parse_version=1 metadata_feature_version=1 timestamp=3058 (Sun Jul 9 21:35:59 2017) host-id=2 score=3400 vm_conf_refresh_time=3075 (Sun Jul 9 21:36:15 2017) conf_on_shared_storage=True maintenance=False state=EngineStart stopped=False --== Host 3 status ==-- conf_on_shared_storage : True Status up-to-date : True Hostname : ovirt03.localdomain.local Host ID : 3 Engine status : {"reason": "vm not running on this host", "health": "bad", "vm": "down", "detail": "unknown"} Score : 3400 stopped : False Local maintenance : False crc32 : 382efde5 local_conf_timestamp : 24832 Host timestamp : 24816 Extra metadata (valid at timestamp): metadata_parse_version=1 metadata_feature_version=1 timestamp=24816 (Sun Jul 9 21:36:01 2017) host-id=3 score=3400 vm_conf_refresh_time=24832 (Sun Jul 9 21:36:17 2017) conf_on_shared_storage=True maintenance=False state=EngineStart stopped=False [root@ovirt02 ~]# and then [root@ovirt02 ~]# hosted-engine --vm-status --== Host 1 status ==-- conf_on_shared_storage : True Status up-to-date : True Hostname : ovirt01.localdomain.local Host ID : 1 Engine status : {"reason": "bad vm status", "health": "bad", "vm": "down", "detail": "down"} Score : 3253 stopped : False Local maintenance : False crc32 : 3fc39f31 local_conf_timestamp : 20087 Host timestamp : 20070 Extra metadata (valid at timestamp): metadata_parse_version=1 metadata_feature_version=1 timestamp=20070 (Sun Jul 9 21:36:26 2017) host-id=1 score=3253 vm_conf_refresh_time=20087 (Sun Jul 9 21:36:43 2017) conf_on_shared_storage=True maintenance=False state=EngineDown stopped=False --== Host 2 status ==-- conf_on_shared_storage : True Status up-to-date : True Hostname : 192.168.150.103 Host ID : 2 Engine status : {"reason": "vm not running on this host", "health": "bad", "vm": "down", "detail": "unknown"} Score : 3400 stopped : False Local maintenance : False crc32 : 4a05c31e local_conf_timestamp : 3109 Host timestamp : 3079 Extra metadata (valid at timestamp): metadata_parse_version=1 metadata_feature_version=1 timestamp=3079 (Sun Jul 9 21:36:19 2017) host-id=2 score=3400 vm_conf_refresh_time=3109 (Sun Jul 9 21:36:49 2017) conf_on_shared_storage=True maintenance=False state=EngineStarting stopped=False --== Host 3 status ==-- conf_on_shared_storage : True Status up-to-date : True Hostname : ovirt03.localdomain.local Host ID : 3 Engine status : {"reason": "vm not running on this host", "health": "bad", "vm": "down", "detail": "unknown"} Score : 3400 stopped : False Local maintenance : False crc32 : 382efde5 local_conf_timestamp : 24832 Host timestamp : 24816 Extra metadata (valid at timestamp): metadata_parse_version=1 metadata_feature_version=1 timestamp=24816 (Sun Jul 9 21:36:01 2017) host-id=3 score=3400 vm_conf_refresh_time=24832 (Sun Jul 9 21:36:17 2017) conf_on_shared_storage=True maintenance=False state=EngineStart stopped=False [root@ovirt02 ~]# and [root@ovirt02 ~]# hosted-engine --vm-status --== Host 1 status ==-- conf_on_shared_storage : True Status up-to-date : True Hostname : ovirt01.localdomain.local Host ID : 1 Engine status : {"reason": "bad vm status", "health": "bad", "vm": "down", "detail": "down"} Score : 3253 stopped : False Local maintenance : False crc32 : 3fc39f31 local_conf_timestamp : 20087 Host timestamp : 20070 Extra metadata (valid at timestamp): metadata_parse_version=1 metadata_feature_version=1 timestamp=20070 (Sun Jul 9 21:36:26 2017) host-id=1 score=3253 vm_conf_refresh_time=20087 (Sun Jul 9 21:36:43 2017) conf_on_shared_storage=True maintenance=False state=EngineDown stopped=False --== Host 2 status ==-- conf_on_shared_storage : True Status up-to-date : True Hostname : 192.168.150.103 Host ID : 2 Engine status : {"reason": "vm not running on this host", "health": "bad", "vm": "down", "detail": "unknown"} Score : 3400 stopped : False Local maintenance : False crc32 : 4a05c31e local_conf_timestamp : 3109 Host timestamp : 3079 Extra metadata (valid at timestamp): metadata_parse_version=1 metadata_feature_version=1 timestamp=3079 (Sun Jul 9 21:36:19 2017) host-id=2 score=3400 vm_conf_refresh_time=3109 (Sun Jul 9 21:36:49 2017) conf_on_shared_storage=True maintenance=False state=EngineStarting stopped=False --== Host 3 status ==-- conf_on_shared_storage : True Status up-to-date : True Hostname : ovirt03.localdomain.local Host ID : 3 Engine status : {"reason": "vm not running on this host", "health": "bad", "vm": "down", "detail": "unknown"} Score : 3400 stopped : False Local maintenance : False crc32 : fc1e8cf9 local_conf_timestamp : 24868 Host timestamp : 24836 Extra metadata (valid at timestamp): metadata_parse_version=1 metadata_feature_version=1 timestamp=24836 (Sun Jul 9 21:36:21 2017) host-id=3 score=3400 vm_conf_refresh_time=24868 (Sun Jul 9 21:36:53 2017) conf_on_shared_storage=True maintenance=False state=EngineStarting stopped=False [root@ovirt02 ~]# and at the end Host3 goes to "ForceStop" for the engine [root@ovirt02 ~]# hosted-engine --vm-status --== Host 1 status ==-- conf_on_shared_storage : True Status up-to-date : True Hostname : ovirt01.localdomain.local Host ID : 1 Engine status : {"reason": "bad vm status", "health": "bad", "vm": "down", "detail": "down"} Score : 3312 stopped : False Local maintenance : False crc32 : e9d53432 local_conf_timestamp : 20120 Host timestamp : 20102 Extra metadata (valid at timestamp): metadata_parse_version=1 metadata_feature_version=1 timestamp=20102 (Sun Jul 9 21:36:58 2017) host-id=1 score=3312 vm_conf_refresh_time=20120 (Sun Jul 9 21:37:15 2017) conf_on_shared_storage=True maintenance=False state=EngineDown stopped=False --== Host 2 status ==-- conf_on_shared_storage : True Status up-to-date : True Hostname : 192.168.150.103 Host ID : 2 Engine status : {"reason": "bad vm status", "health": "bad", "vm": "up", "detail": "powering up"} Score : 3400 stopped : False Local maintenance : False crc32 : 7d2330be local_conf_timestamp : 3141 Host timestamp : 3124 Extra metadata (valid at timestamp): metadata_parse_version=1 metadata_feature_version=1 timestamp=3124 (Sun Jul 9 21:37:04 2017) host-id=2 score=3400 vm_conf_refresh_time=3141 (Sun Jul 9 21:37:21 2017) conf_on_shared_storage=True maintenance=False state=EngineStarting stopped=False --== Host 3 status ==-- conf_on_shared_storage : True Status up-to-date : True Hostname : ovirt03.localdomain.local Host ID : 3 Engine status : {"reason": "Storage of VM is locked. Is another host already starting the VM?", "health": "bad", "vm": "already_locked", "detail": "down"} Score : 3400 stopped : False Local maintenance : False crc32 : 179825e8 local_conf_timestamp : 24900 Host timestamp : 24883 Extra metadata (valid at timestamp): metadata_parse_version=1 metadata_feature_version=1 timestamp=24883 (Sun Jul 9 21:37:08 2017) host-id=3 score=3400 vm_conf_refresh_time=24900 (Sun Jul 9 21:37:24 2017) conf_on_shared_storage=True maintenance=False state=EngineForceStop stopped=False [root@ovirt02 ~]# Comparing /var/log/libvirt/qemu/HostedEngine of host2 and host3 Host2: 2017-07-09 19:36:36.094+0000: starting up libvirt version: 2.0.0, package: 10.el7_3.9 (CentOS BuildSystem <http://bugs.centos.org>, 2017-05-25-20:52:28, c1bm.rdu2.centos.org) qemu version: 2.6.0 (qemu-kvm-ev-2.6.0-28.el7.10.1), hostname: ovirt02.localdomain.local ... char device redirected to /dev/pts/1 (label charconsole0) warning: host doesn't support requested feature: CPUID.07H:EBX.erms [bit 9] Host3: 2017-07-09 19:36:38.143+0000: starting up libvirt version: 2.0.0, package: 10.el7_3.9 (CentOS BuildSystem <http://bu gs.centos.org>, 2017-05-25-20:52:28, c1bm.rdu2.centos.org) qemu version: 2.6.0 (qemu-kvm-ev-2.6.0-28.el7.10.1), hos tname: ovirt03.localdomain.local ... char device redirected to /dev/pts/1 (label charconsole0) 2017-07-09 19:36:38.584+0000: shutting down 2017-07-09T19:36:38.589729Z qemu-kvm: terminating on signal 15 from pid 1835 any comment? Is it only a matter of powering on the VM in paused mode before starting the OS itself, or do I risk corruption due to 2 qemu-kvm processes trying to start the engine vm os? Thanks, Gianluca

4 16

Installation of oVirt 4.1, Gluster Storage and Hosted Engine
by Simone Marchioni 13 Jul '17

13 Jul '17

Hi to all, I have an old installation of oVirt 3.3 with the Engine on a separate server. I wanted to test the last oVirt 4.1 with Gluster Storage and Hosted Engine. Followed the following tutorial: http://www.ovirt.org/blog/2017/04/up-and-running-with-ovirt-4.1-and-gluster… I have 3 hosts as shown in the tutorial. Installed CentOS 7.3, the oVirt 4.1 repo and all required packages. Configured passwordless ssh as stated. Then I log in cockpit web interface, selected "Hosted Engine with Gluster" and hit the Start button. Configured the parameters as shown in the tutorial. In the last step (5) the Generated Gdeply configuration (note: replaced the real domain with "domain.it"): #gdeploy configuration generated by cockpit-gluster plugin [hosts] ha1.domain.it ha2.domain.it ha3.domain.it [script1] action=execute ignore_script_errors=no file=/usr/share/ansible/gdeploy/scripts/grafton-sanity-check.sh -d sdb -h ha1.domain.it,ha2.domain.it,ha3.domain.it [disktype] raid6 [diskcount] 12 [stripesize] 256 [service1] action=enable service=chronyd [service2] action=restart service=chronyd [shell2] action=execute command=vdsm-tool configure --force [script3] action=execute file=/usr/share/ansible/gdeploy/scripts/disable-multipath.sh [pv1] action=create devices=sdb ignore_pv_errors=no [vg1] action=create vgname=gluster_vg_sdb pvname=sdb ignore_vg_errors=no [lv1:{ha1.domain.it,ha2.domain.it}] action=create poolname=gluster_thinpool_sdb ignore_lv_errors=no vgname=gluster_vg_sdb lvtype=thinpool size=110GB poolmetadatasize=1GB [lv2:ha3.domain.it] action=create poolname=gluster_thinpool_sdb ignore_lv_errors=no vgname=gluster_vg_sdb lvtype=thinpool size=80GB poolmetadatasize=1GB [lv3:{ha1.domain.it,ha2.domain.it}] action=create lvname=gluster_lv_engine ignore_lv_errors=no vgname=gluster_vg_sdb mount=/gluster_bricks/engine lvtype=thinlv poolname=gluster_thinpool_sdb virtualsize=50GB [lv4:ha3.domain.it] action=create lvname=gluster_lv_engine ignore_lv_errors=no vgname=gluster_vg_sdb mount=/gluster_bricks/engine lvtype=thinlv poolname=gluster_thinpool_sdb virtualsize=20GB [lv5:{ha1.domain.it,ha2.domain.it}] action=create lvname=gluster_lv_data ignore_lv_errors=no vgname=gluster_vg_sdb mount=/gluster_bricks/data lvtype=thinlv poolname=gluster_thinpool_sdb virtualsize=20GB [lv6:ha3.domain.it] action=create lvname=gluster_lv_data ignore_lv_errors=no vgname=gluster_vg_sdb mount=/gluster_bricks/data lvtype=thinlv poolname=gluster_thinpool_sdb virtualsize=20GB [lv7:{ha1.domain.it,ha2.domain.it}] action=create lvname=gluster_lv_export ignore_lv_errors=no vgname=gluster_vg_sdb mount=/gluster_bricks/export lvtype=thinlv poolname=gluster_thinpool_sdb virtualsize=20GB [lv8:ha3.domain.it] action=create lvname=gluster_lv_export ignore_lv_errors=no vgname=gluster_vg_sdb mount=/gluster_bricks/export lvtype=thinlv poolname=gluster_thinpool_sdb virtualsize=20GB [lv9:{ha1.domain.it,ha2.domain.it}] action=create lvname=gluster_lv_iso ignore_lv_errors=no vgname=gluster_vg_sdb mount=/gluster_bricks/iso lvtype=thinlv poolname=gluster_thinpool_sdb virtualsize=20GB [lv10:ha3.domain.it] action=create lvname=gluster_lv_iso ignore_lv_errors=no vgname=gluster_vg_sdb mount=/gluster_bricks/iso lvtype=thinlv poolname=gluster_thinpool_sdb virtualsize=20GB [selinux] yes [service3] action=restart service=glusterd slice_setup=yes [firewalld] action=add ports=111/tcp,2049/tcp,54321/tcp,5900/tcp,5900-6923/tcp,5666/tcp,16514/tcp services=glusterfs [script2] action=execute file=/usr/share/ansible/gdeploy/scripts/disable-gluster-hooks.sh [shell3] action=execute command=usermod -a -G gluster qemu [volume1] action=create volname=engine transport=tcp replica=yes replica_count=3 key=group,storage.owner-uid,storage.owner-gid,network.ping-timeout,performance.strict-o-direct,network.remote-dio,cluster.granular-entry-heal value=virt,36,36,30,on,off,enable brick_dirs=ha1.domain.it:/gluster_bricks/engine/engine,ha2.domain.it:/gluster_bricks/engine/engine,ha3.domain.it:/gluster_bricks/engine/engine ignore_volume_errors=no arbiter_count=1 [volume2] action=create volname=data transport=tcp replica=yes replica_count=3 key=group,storage.owner-uid,storage.owner-gid,network.ping-timeout,performance.strict-o-direct,network.remote-dio,cluster.granular-entry-heal value=virt,36,36,30,on,off,enable brick_dirs=ha1.domain.it:/gluster_bricks/data/data,ha2.domain.it:/gluster_bricks/data/data,ha3.domain.it:/gluster_bricks/data/data ignore_volume_errors=no arbiter_count=1 [volume3] action=create volname=export transport=tcp replica=yes replica_count=3 key=group,storage.owner-uid,storage.owner-gid,network.ping-timeout,performance.strict-o-direct,network.remote-dio,cluster.granular-entry-heal value=virt,36,36,30,on,off,enable brick_dirs=ha1.domain.it:/gluster_bricks/export/export,ha2.domain.it:/gluster_bricks/export/export,ha3.domain.it:/gluster_bricks/export/export ignore_volume_errors=no arbiter_count=1 [volume4] action=create volname=iso transport=tcp replica=yes replica_count=3 key=group,storage.owner-uid,storage.owner-gid,network.ping-timeout,performance.strict-o-direct,network.remote-dio,cluster.granular-entry-heal value=virt,36,36,30,on,off,enable brick_dirs=ha1.domain.it:/gluster_bricks/iso/iso,ha2.domain.it:/gluster_bricks/iso/iso,ha3.domain.it:/gluster_bricks/iso/iso ignore_volume_errors=no arbiter_count=1 When I hit "Deploy" button the Deployment fails with the following error: PLAY [gluster_servers] ********************************************************* TASK [Run a shell script] ****************************************************** fatal: [ha1.domain.it]: FAILED! => {"failed": true, "msg": "The conditional check 'result.rc != 0' failed. The error was: error while evaluating conditional (result.rc != 0): 'dict object' has no attribute 'rc'"} fatal: [ha2.domain.it]: FAILED! => {"failed": true, "msg": "The conditional check 'result.rc != 0' failed. The error was: error while evaluating conditional (result.rc != 0): 'dict object' has no attribute 'rc'"} fatal: [ha3.domain.it]: FAILED! => {"failed": true, "msg": "The conditional check 'result.rc != 0' failed. The error was: error while evaluating conditional (result.rc != 0): 'dict object' has no attribute 'rc'"} to retry, use: --limit @/tmp/tmpcV3lam/run-script.retry PLAY RECAP ********************************************************************* ha1.domain.it : ok=0 changed=0 unreachable=0 failed=1 ha2.domain.it : ok=0 changed=0 unreachable=0 failed=1 ha3.domain.it : ok=0 changed=0 unreachable=0 failed=1 What I'm doing wrong? Maybe I need to initializa glusterfs in some way... What are the logs used to log the status of this deployment so I can check the errors? Thanks in advance! Simone

3 18

Problems with vdsm-tool and ovn-config option
by Gianluca Cecchi 13 Jul '17

13 Jul '17

Hello, on February I installed OVN controller on some hypervisors (CentOS 7.3 hosts). At that time the vdsm-tool command was part of vdsm-python-4.19.4-1.el7.centos.noarch I was able to configure my hosts with command vdsm-tool ovn-config OVN_central_server_IP local_OVN_tunneling_IP as described here: https://www.ovirt.org/blog/2016/11/ovirt-provider-ovn/ and now here https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.1/ht… I have 2 hosts that I added later and on which I want to configure OVN external network provider too. But now, with vdsm-python at version vdsm-python-4.19.10.1-1.el7.centos.noarch I get an usage error trying to execute the command [root@ov301 ~]# vdsm-tool ovn-config 10.4.192.43 10.4.167.41 Usage: /bin/vdsm-tool [options] <action> [arguments] Valid options: -h, --help Show this help menu. -l, --logfile <path> ... Also, the changelog of the package seems quite broken: [root@ov301 ~]# rpm -q --changelog vdsm-python * Wed Aug 03 2016 Yaniv Bronhaim <ybronhei(a)redhat.com> - 4.18.999 - Re-review of vdsm.spec to return it to fedora Bug #1361659 * Sun Oct 13 2013 Yaniv Bronhaim <ybronhei(a)redhat.com> - 4.13.0 - Removing vdsm-python-cpopen from the spec - Adding dependency on formal cpopen package * Sun Apr 07 2013 Yaniv Bronhaim <ybronhei(a)redhat.com> - 4.9.0-1 - Adding cpopen package * Wed Oct 12 2011 Federico Simoncelli <fsimonce(a)redhat.com> - 4.9.0-0 - Initial upstream release * Thu Nov 02 2006 Simon Grinberg <simong(a)qumranet.com> - 0.0-1 - Initial build [root@ov301 ~]# How can I configure OVN? Thanks in advance, Gianluca

1 1