- Users - oVirt List Archives

Storage Performance
by Bryan Sockel 26 Oct '17

26 Oct '17

Have a question in regards to storage performance. I have a gluster replica 3 volume that we are testing for performance. In my current configuration is 1 server has 16X1.2TB( 10K 2.5 Inch) drives configured in Raid 10 with a 256k stripe. My 2nd server is configured with 4X6TB (3.5 Inch Drives) configured Raid 10 with a 256k stripe. Each server is configured with 802.3 Bond (4X1GB) network links. Each server is configured with write-back on the raid controller. I am seeing a lot of network usage (solid 3 Gbps) when i perform file copies on the vm attached to that gluster volume, But i see spikes on the disk io when watching the dashboard through the cockpit interface. I spikes are up to 1.5 Gbps, but i would say the average through put is maybe 256 Mbps. Is this to be expected, or should it be a solid activity in the graphs for disk IO. Is it better to use a 256K stripe or a 512 strip on the hardware raid configuration? Eventually i plan on having the hardware match up for better performance. Thanks Bryan

3 2

Re: [ovirt-users] Bad volume specification after hung migration
by Michal Skrivanek 26 Oct '17

26 Oct '17

--Apple-Mail=_7EF46EB5-FF10-4695-889D-DC90FC772541 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 26 Oct 2017, at 12:32, Roberto Nunin <robnunin(a)gmail.com> wrote: >=20 > Hi Michael >=20 > By frozen I mean the action to put host in maintenance while some VM = were running on it. > This action wasn't completed after more than one hour. ok, and was the problem in this last VM not finishing the migration? Was = it migrating at all? If yes, what was the progress in UI, any failures? = There are various timeouts which should have been triggered, so if they = were not triggered it would indeed point to some internal issue. Would = be great to attach source and destination vdsm.log > Thinking that shutting down the VM could help, I've done it. Looking = at results, not. What was the result? Did it fail to shut down? Did you use Power Off to = force immediate shutdown? If it was migrating, did you try to cancel the = migration first? >=20 > Yes, I've restarted the ovirt-engine service, I've still not restarted = the hosted-engine VM. well, it=E2=80=99s not only a universal =E2=80=9Cfix=E2=80=9D of various = things, sometimes it does more harm than benefit too. Logs would be = helpful. > Hosts still not restarted. Do you think can help ? hard to say. Either way please salvage logs first >=20 > Obviously we will migrate, this activities are enabling us to have = redundancy at the storage level, then we will migrate to 4.1.x great:) Thanks, michal >=20 > Thanks >=20 > 2017-10-26 12:26 GMT+02:00 Michal Skrivanek = <michal.skrivanek(a)redhat.com <mailto:michal.skrivanek@redhat.com>>: >=20 >> On 26 Oct 2017, at 10:20, Roberto Nunin <robnunin(a)gmail.com = <mailto:robnunin@gmail.com>> wrote: >>=20 >> We are running 4.0.1.1-1.el7.centos >=20 > Hi, > any reason not to upgrade to 4.1? >=20 >>=20 >> After a frozen migration attempt, we have two VM that after shutdown, = are not anymore able to be started up again. >=20 > what do you mean by frozen? Are you talking about "VM live migration" = or =E2=80=9Clive storage migration=E2=80=9D? > How exactly did you resolve that situation, you only shut down those = VMs? No other troubleshooting steps, e.g. restarting engine, hosts, = things like that? >=20 > Thanks, > michal >>=20 >> Message returned is : >>=20 >> Bad volume specification {'index': '0', u'domainID': = u'731d95a9-61a7-4c7a-813b-fb1c3dde47ea', 'reqsize': '0', u'format': = u'cow', u'optional': u'false', u'address': {u'function': u'0x0', u'bus': = u'0x00', u'domain': u'0x0000', u'type': u'pci', u'slot': u'0x05'}, = u'volumeID': u'cffc70ff-ed72-46ef-a369-4be95de72260', 'apparentsize': = '3221225472', u'imageID': u'3fe5a849-bcc2-42d3-93c5aca4c504515b', = u'specParams': {}, u'readonly': u'false', u'iface': u'virtio', = u'deviceId': u'3fe5a849bcc2-42d3-93c5-aca4c504515b', 'truesize': = '3221225472', u'poolID': u'00000001-0001-0001-0001-0000000001ec', = u'device': u'disk', u'shared': u'false', u'propagateErrors': = u'off',u'type':u'disk'} >>=20 >> Probably this is caused by a wrong pointer into the database that = still refer to the migration image-id. >>=20 >> If we search within all_disks view, we can find that parentid field = isn't 00000000-0000-0000-0000-000000000000 like all other running vm, = but it has a value: >>=20 >> vm_names | parentid >> ----------------------+-------------------------------------- >> working01.company.xx | 00000000-0000-0000-0000-000000000000 >> working02.company.xx | 00000000-0000-0000-0000-000000000000 >> working03.company.xx | 00000000-0000-0000-0000-000000000000 >> working04.company.xx | 00000000-0000-0000-0000-000000000000 >> broken001.company.xx | 30533842-2c83-4d0e-95d2-48162dbe23bd = <<<<<<<<< >> working05.company.xx | 00000000-0000-0000-0000-000000000000 >>=20 >>=20 >> How we can recover from this ? >>=20 >> Thanks in advance >> Regards, >>=20 >> --=20 >> Robert=E2=80=8Bo=E2=80=8B >>=20 >>=20 >>=20 >> _______________________________________________ >> Users mailing list >> Users(a)ovirt.org <mailto:Users@ovirt.org> >> http://lists.ovirt.org/mailman/listinfo/users = <http://lists.ovirt.org/mailman/listinfo/users> >=20 >=20 >=20 >=20 > --=20 > Roberto >=20 >=20 >=20 --Apple-Mail=_7EF46EB5-FF10-4695-889D-DC90FC772541 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 <html><head><meta http-equiv=3D"Content-Type" content=3D"text/html = charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; = -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" = class=3D""><br class=3D""><div><blockquote type=3D"cite" class=3D""><div = class=3D"">On 26 Oct 2017, at 12:32, Roberto Nunin <<a = href=3D"mailto:robnunin@gmail.com" class=3D"">robnunin(a)gmail.com</a>> = wrote:</div><br class=3D"Apple-interchange-newline"><div class=3D""><div = dir=3D"ltr" class=3D""><div class=3D"gmail_default" style=3D"">Hi = Michael</div><div class=3D"gmail_default" style=3D""><br = class=3D""></div><div class=3D"gmail_default" style=3D"">By frozen I = mean the action to put host in maintenance while some VM were running on = it.</div><div class=3D"gmail_default" style=3D"">This action wasn't = completed after more than one = hour.</div></div></div></blockquote><div><br class=3D""></div>ok, and = was the problem in this last VM not finishing the migration? Was it = migrating at all? If yes, what was the progress in UI, any failures? = There are various timeouts which should have been triggered, so if they = were not triggered it would indeed point to some internal issue. Would = be great to attach source and destination vdsm.log</div><div><br = class=3D""><blockquote type=3D"cite" class=3D""><div class=3D""><div = dir=3D"ltr" class=3D""><div class=3D"gmail_default" style=3D"">Thinking = that shutting down the VM could help, I've done it. Looking at results, = not.</div></div></div></blockquote><div><br class=3D""></div>What was = the result? Did it fail to shut down? Did you use Power Off to force = immediate shutdown? If it was migrating, did you try to cancel the = migration first?</div><div><br class=3D""><blockquote type=3D"cite" = class=3D""><div class=3D""><div dir=3D"ltr" class=3D""><div = class=3D"gmail_default" style=3D""><br class=3D""></div><div = class=3D"gmail_default" style=3D"">Yes, I've restarted the ovirt-engine = service, I've still not restarted the hosted-engine = VM.</div></div></div></blockquote><div><br class=3D""></div>well, it=E2=80= =99s not only a universal =E2=80=9Cfix=E2=80=9D of various things, = sometimes it does more harm than benefit too. Logs would be = helpful.</div><div><br class=3D""><blockquote type=3D"cite" = class=3D""><div class=3D""><div dir=3D"ltr" class=3D""><div = class=3D"gmail_default" style=3D"">Hosts still not restarted. Do you = think can help ?</div></div></div></blockquote><div><br = class=3D""></div>hard to say. Either way please salvage logs = first</div><div><br class=3D""><blockquote type=3D"cite" class=3D""><div = class=3D""><div dir=3D"ltr" class=3D""><div class=3D"gmail_default" = style=3D""><br class=3D""></div><div class=3D"gmail_default" = style=3D"">Obviously we will migrate, this activities are enabling us to = have redundancy at the storage level, then we will migrate to = 4.1.x</div></div></div></blockquote><div><br = class=3D""></div>great:)</div><div><br = class=3D""></div><div>Thanks,</div><div>michal</div><div><br = class=3D""><blockquote type=3D"cite" class=3D""><div class=3D""><div = dir=3D"ltr" class=3D""><div class=3D"gmail_default" style=3D""><br = class=3D""></div><div class=3D"gmail_default" style=3D"">Thanks</div><div = class=3D"gmail_extra"><br class=3D""><div class=3D"gmail_quote">2017-10-26= 12:26 GMT+02:00 Michal Skrivanek <span dir=3D"ltr" class=3D""><<a = href=3D"mailto:michal.skrivanek@redhat.com" target=3D"_blank" = class=3D"">michal.skrivanek(a)redhat.com</a>></span>:<br = class=3D""><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 = .8ex;border-left:1px #ccc solid;padding-left:1ex"><div = style=3D"word-wrap:break-word" class=3D""><br class=3D""><div = class=3D""><blockquote type=3D"cite" class=3D""><div class=3D"">On 26 = Oct 2017, at 10:20, Roberto Nunin <<a = href=3D"mailto:robnunin@gmail.com" target=3D"_blank" = class=3D"">robnunin(a)gmail.com</a>> wrote:</div><br = class=3D"m_-7560322293096975458Apple-interchange-newline"><div = class=3D""><div dir=3D"ltr" class=3D""><div class=3D"">We are = running<span style=3D"font-size:large" class=3D""> <span = style=3D"font-family:'Arial Unicode = MS',Arial,sans-serif;text-align:-webkit-center;font-size:small" = class=3D"">4.0.1.1-1.el7.centos</span></span></div></div></div></blockquot= e><div class=3D""><br class=3D""></div>Hi,</div><div class=3D"">any = reason not to upgrade to 4.1?</div><div class=3D""><span class=3D""><br = class=3D""><blockquote type=3D"cite" class=3D""><div class=3D""><div = dir=3D"ltr" class=3D""><div style=3D"font-size:large" class=3D""><span = style=3D"font-family:'Arial Unicode = MS',Arial,sans-serif;text-align:-webkit-center;font-size:small" = class=3D""><br class=3D""></span></div><div style=3D"font-size:large" = class=3D""><span style=3D"font-family:'Arial Unicode = MS',Arial,sans-serif;text-align:-webkit-center;font-size:small" = class=3D"">After a frozen migration attempt, we have two VM that after = shutdown, are not anymore able to be started up = again.</span></div></div></div></blockquote><div class=3D""><br = class=3D""></div></span>what do you mean by frozen? Are you talking = about "VM live migration" or =E2=80=9Clive storage = migration=E2=80=9D?</div><div class=3D"">How exactly did you resolve = that situation, you only shut down those VMs? No other troubleshooting = steps, e.g. restarting engine, hosts, things like that?</div><div = class=3D""><br class=3D""></div><div class=3D"">Thanks,</div><div = class=3D"">michal</div><div class=3D""><blockquote type=3D"cite" = class=3D""><div class=3D""><span class=3D""><div dir=3D"ltr" = class=3D""><div style=3D"font-size:large" class=3D""><span = style=3D"font-family:'Arial Unicode = MS',Arial,sans-serif;text-align:-webkit-center;font-size:small" = class=3D""><br class=3D""></span></div><div style=3D"font-size:large" = class=3D""><span style=3D"font-family:'Arial Unicode = MS',Arial,sans-serif;text-align:-webkit-center;font-size:small" = class=3D"">Message returned is :</span></div><div = style=3D"font-size:large" class=3D""><span style=3D"font-family:'Arial = Unicode MS',Arial,sans-serif;text-align:-webkit-center;font-size:small" = class=3D""><br class=3D""></span></div><div class=3D""><span = style=3D"font-family:'Arial Unicode = MS',Arial,sans-serif;text-align:-webkit-center" class=3D""><div = style=3D"text-align:left" class=3D"">Bad volume specification {'index': = '0', u'domainID': u'731d95a9-61a7-4c7a-813b-<wbr class=3D"">fb1c3dde47ea',= 'reqsize': '0', u'format': u'cow', u'optional': u'false', u'address': = {u'function': u'0x0', u'bus': u'0x00', u'domain': u'0x0000', u'type': = u'pci', u'slot': u'0x05'}, u'volumeID': u'cffc70ff-ed72-46ef-a369-<wbr = class=3D"">4be95de72260', 'apparentsize': '3221225472', u'imageID': = u'3fe5a849-bcc2-42d3-<wbr class=3D"">93c5aca4c504515b', u'specParams': = {}, u'readonly': u'false', u'iface': u'virtio', u'deviceId': = u'3fe5a849bcc2-42d3-93c5-<wbr class=3D"">aca4c504515b', 'truesize': = '3221225472', u'poolID': u'00000001-0001-0001-0001-<wbr = class=3D"">0000000001ec', u'device': u'disk', u'shared': u'false', = u'propagateErrors': u'off',u'type':u'disk'}</div><div = style=3D"text-align:left;font-size:small" class=3D""><br = class=3D""></div></span></div><div style=3D"font-size:large" = class=3D""><span style=3D"font-family:'Arial Unicode = MS',Arial,sans-serif;text-align:-webkit-center;font-size:small" = class=3D"">Probably this is caused by a wrong pointer into the database = that still refer to the migration image-id.</span></div><div = style=3D"font-size:large" class=3D""><span style=3D"font-family:'Arial = Unicode MS',Arial,sans-serif;text-align:-webkit-center;font-size:small" = class=3D""><br class=3D""></span></div><div class=3D""><span = style=3D"font-size:small;font-family:'Arial Unicode = MS',Arial,sans-serif;text-align:-webkit-center" class=3D"">If we search = within all_disks view, we can find that parentid field = isn't </span><font face=3D"Arial Unicode MS, Arial, sans-serif" = class=3D"">00000000-0000-0000-0000-<wbr class=3D"">000000000000 like all = other running vm, but it has a value:</font></div><div class=3D""><font = face=3D"Arial Unicode MS, Arial, sans-serif" class=3D""><br = class=3D""></font></div><div class=3D""><font class=3D""><div = class=3D""><font face=3D"monospace, monospace" class=3D"">    =    vm_names       |      =          parentid</font></div><div = class=3D""><font face=3D"monospace, monospace" = class=3D"">----------------------+-------<wbr = class=3D"">------------------------------<wbr = class=3D"">-</font></div><div class=3D""><font face=3D"monospace, = monospace" class=3D""> working01.company.xx | = 00000000-0000-0000-0000-<wbr class=3D"">000000000000</font></div><div = class=3D""><font face=3D"monospace, monospace" = class=3D""> working02.company.xx | 00000000-0000-0000-0000-<wbr = class=3D"">000000000000</font></div><div class=3D""><font = face=3D"monospace, monospace" class=3D""> working03.company.xx | = 00000000-0000-0000-0000-<wbr class=3D"">000000000000</font></div><div = class=3D""><font face=3D"monospace, monospace" = class=3D""> working04.company.xx | 00000000-0000-0000-0000-<wbr = class=3D"">000000000000</font></div><div class=3D""><font = face=3D"monospace, monospace" class=3D""> broken001.company.xx | = 30533842-2c83-4d0e-95d2-<wbr class=3D"">48162dbe23bd = <<<<<<<<<</font></div><div class=3D""><font = face=3D"monospace, monospace" class=3D""> working05.company.xx | = 00000000-0000-0000-0000-<wbr class=3D"">000000000000</font></div><div = style=3D"font-family:"Arial Unicode MS",Arial,sans-serif" = class=3D""><br class=3D""></div></font></div><div class=3D""><font = face=3D"Arial Unicode MS, Arial, sans-serif" class=3D""><br = class=3D""></font></div><div class=3D""><font face=3D"Arial Unicode MS, = Arial, sans-serif" class=3D"">How we can recover from this = ?</font></div><div class=3D""><font face=3D"Arial Unicode MS, Arial, = sans-serif" class=3D""><br class=3D""></font></div><div class=3D""><font = face=3D"Arial Unicode MS, Arial, sans-serif" class=3D"">Thanks in = advance</font></div><div class=3D""><font face=3D"Arial Unicode MS, = Arial, sans-serif" class=3D"">Regards,</font></div><div class=3D""><br = class=3D""></div>-- <br class=3D""><div = class=3D"m_-7560322293096975458gmail_signature"><div dir=3D"ltr" = class=3D""><div dir=3D"ltr" class=3D""><font size=3D"4" = class=3D"">Robert<div style=3D"font-size:large;display:inline" = class=3D"">=E2=80=8Bo=E2=80=8B</div><br class=3D""><br = class=3D""></font><span class=3D""><font size=3D"4" class=3D""><br = class=3D""><br class=3D""></font></span></div></div></div> </div></span> ______________________________<wbr class=3D"">_________________<br = class=3D"">Users mailing list<br class=3D""><a = href=3D"mailto:Users@ovirt.org" target=3D"_blank" = class=3D"">Users(a)ovirt.org</a><br class=3D""><a = href=3D"http://lists.ovirt.org/mailman/listinfo/users" target=3D"_blank" = class=3D"">http://lists.ovirt.org/<wbr = class=3D"">mailman/listinfo/users</a><br = class=3D""></div></blockquote></div><br = class=3D""></div></blockquote></div><br class=3D""><br clear=3D"all" = class=3D""><div class=3D""><br class=3D""></div>-- <br class=3D""><div = class=3D"gmail_signature" data-smartmail=3D"gmail_signature"><div = dir=3D"ltr" class=3D""><div dir=3D"ltr" class=3D""><font size=3D"4" = class=3D"">Roberto<br class=3D""><br class=3D""></font><span = class=3D""><font size=3D"4" class=3D""><br class=3D""><br = class=3D""></font></span></div></div></div> </div></div> </div></blockquote></div><br class=3D""></body></html>= --Apple-Mail=_7EF46EB5-FF10-4695-889D-DC90FC772541--

1 0

Bad volume specification after hung migration
by Roberto Nunin 26 Oct '17

26 Oct '17

We are running 4.0.1.1-1.el7.centos After a frozen migration attempt, we have two VM that after shutdown, are not anymore able to be started up again. Message returned is : Bad volume specification {'index': '0', u'domainID': u'731d95a9-61a7-4c7a-813b-fb1c3dde47ea', 'reqsize': '0', u'format': u'cow', u'optional': u'false', u'address': {u'function': u'0x0', u'bus': u'0x00', u'domain': u'0x0000', u'type': u'pci', u'slot': u'0x05'}, u'volumeID': u'cffc70ff-ed72-46ef-a369-4be95de72260', 'apparentsize': '3221225472', u'imageID': u'3fe5a849-bcc2-42d3-93c5aca4c504515b', u'specParams': {}, u'readonly': u'false', u'iface': u'virtio', u'deviceId': u'3fe5a849bcc2-42d3-93c5-aca4c504515b', 'truesize': '3221225472', u'poolID': u'00000001-0001-0001-0001-0000000001ec', u'device': u'disk', u'shared': u'false', u'propagateErrors': u'off',u'type':u'disk'} Probably this is caused by a wrong pointer into the database that still refer to the migration image-id. If we search within all_disks view, we can find that parentid field isn't 00000000-0000-0000-0000-000000000000 like all other running vm, but it has a value: vm_names | parentid ----------------------+-------------------------------------- working01.company.xx | 00000000-0000-0000-0000-000000000000 working02.company.xx | 00000000-0000-0000-0000-000000000000 working03.company.xx | 00000000-0000-0000-0000-000000000000 working04.company.xx | 00000000-0000-0000-0000-000000000000 broken001.company.xx | 30533842-2c83-4d0e-95d2-48162dbe23bd <<<<<<<<< working05.company.xx | 00000000-0000-0000-0000-000000000000 How we can recover from this ? Thanks in advance Regards, -- Robert o

2 1

Change iSCSI target IP address
by Colin Coe 25 Oct '17

25 Oct '17

Hi all Running RHV 4.1.6, I need to move an iSCSI appliance to a new subnet. There are VMs that I need to keep on this appliance. What would be the best way to point RHV at the new IP address? Thanks CC

2 2

direct lun resizing
by Jiří Sléžka 25 Oct '17

25 Oct '17

This is a cryptographically signed message in MIME format. --------------ms010105050605010202080105 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Hi all, one of our user uses direct lun inside one of his vm. Now he expanded this lun on the disk array side from 500GB to 600GB but this change was not reflected on oVirt nor vm side. How is direct lun resizing handled in oVirt? Cheers, Jiri --------------ms010105050605010202080105 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC Cn4wggUJMIID8aADAgECAhACt8ndrdK9CetZxFyQDGB4MA0GCSqGSIb3DQEBCwUAMGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0xNDExMTgx MjAwMDBaFw0yNDExMTgxMjAwMDBaMHIxCzAJBgNVBAYTAk5MMRYwFAYDVQQIEw1Ob29yZC1I b2xsYW5kMRIwEAYDVQQHEwlBbXN0ZXJkYW0xDzANBgNVBAoTBlRFUkVOQTEmMCQGA1UEAxMd VEVSRU5BIGVTY2llbmNlIFBlcnNvbmFsIENBIDMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQCwp9Jj5Aej1xPkS1GV3LvBdemFmkUR//nSzBodqsU3dv2BCRD30r4gt5oRsYty qDGF2nnItxV1SkwVoDxFeRzOIHYNYvBRHaiGvCQjEXzPRTocOSVfWpmq/zAL/QOEqpJogeM+ 0IBGiJcAENJshl7UcfjYbBnN5qStk74f52VWFf/aiF7MVJnsUr3oriQvXYOzs8N/NXyyQyim atBbumJVCNszF1X+XHCGfPNvxlNFW9ktv7azK0baminfLcsh6ubCdINZc+Nof2lU387NCDgg oh3KsYVcZTSuhh7qp6MjxE5VqOZod1hpXXzDOkjK+DAMC57iZXssncp24eaN08VlAgMBAAGj ggGmMIIBojASBgNVHRMBAf8ECDAGAQH/AgEAMA4GA1UdDwEB/wQEAwIBhjB5BggrBgEFBQcB AQRtMGswJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcw AoY3aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZElEUm9vdENB LmNydDCBgQYDVR0fBHoweDA6oDigNoY0aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lD ZXJ0QXNzdXJlZElEUm9vdENBLmNybDA6oDigNoY0aHR0cDovL2NybDQuZGlnaWNlcnQuY29t L0RpZ2lDZXJ0QXNzdXJlZElEUm9vdENBLmNybDA9BgNVHSAENjA0MDIGBFUdIAAwKjAoBggr BgEFBQcCARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29tL0NQUzAdBgNVHQ4EFgQUjJ8RLubj egSlHlWLRggEpu2XcKYwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZI hvcNAQELBQADggEBAI5HEV91Oen8WHFCoJkeu2Av+b/kWTV2qH/YNI1Xsbou2hHKhh4IyNkF OxA/TUiuK2qQnQ5hAS0TIrs9SJ1Ke+DjXd/cTBiw7lCYSW5hkzigFV+iSivninpItafWqYBS WxITl1KHBS9YBskhEqO5GLliDMPiAgjqUBQ/H1qZMlZNQIuFu0UaFUQuZUpJFr4+0zpzPxsB iWU2muAoGItwbaP55EYshM7+v/J+x6kIhAJt5Dng8fOmOvR9F6Vw2/E0EZ6oQ8g1fdhwM101 S1OI6J1tUil1r7ES/svNqVWVb7YkUEBcPo8ppfHnTI/uxsn2tslsWefsOGJxNYUUSMAb9Eow ggVtMIIEVaADAgECAhAJGghy20GNQBKKy20wIXVXMA0GCSqGSIb3DQEBCwUAMHIxCzAJBgNV BAYTAk5MMRYwFAYDVQQIEw1Ob29yZC1Ib2xsYW5kMRIwEAYDVQQHEwlBbXN0ZXJkYW0xDzAN BgNVBAoTBlRFUkVOQTEmMCQGA1UEAxMdVEVSRU5BIGVTY2llbmNlIFBlcnNvbmFsIENBIDMw HhcNMTYxMDE3MDAwMDAwWhcNMTcxMTE2MTIwMDAwWjCBkzETMBEGCgmSJomT8ixkARkWA29y ZzEWMBQGCgmSJomT8ixkARkWBnRlcmVuYTETMBEGCgmSJomT8ixkARkWA3RjczELMAkGA1UE BhMCQ1oxJTAjBgNVBAoTHFNpbGVzaWFuIFVuaXZlcnNpdHkgaW4gT3BhdmExGzAZBgNVBAMT EkppcmkgU2xlemthIHNsZXprYTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAPd3 XaprhIlr9KQ0VkOzTRn8wTrzw26B1SWOr6M+/lL9x/T33HMJTwavfoATuzczB/PnURjHu3kW j5449dAKHmne3LgsNgLPp14YbhhXJtoe5WuJoZ/P1g2o5tR6neKkSlIMWUWBBiCMmZU70EfZ 2NmDjVAhyxOJedSw+Uk4lWs3nrRgtzg3c/K8fkalDnAbTrlCRs0UOUu0NdebrHDdc0AyGpdU apsdD/vBIMlh0aF0il5qfBeCMjND/YAMlJileuYAH59+XWZVnZ2vWwyhE1WEeEpDUhyr3P4B oWTkivIzlT/jynCIYlmoGlwA8qs3aMkcAF0z1xN+zmuJcJ//T30CAwEAAaOCAdswggHXMB8G A1UdIwQYMBaAFIyfES7m43oEpR5Vi0YIBKbtl3CmMB0GA1UdDgQWBBSs4bsp5TEqufKnjp5U kbi2XfR8vzAMBgNVHRMBAf8EAjAAMB0GA1UdEQQWMBSBEmppcmkuc2xlemthQHNsdS5jejAO BgNVHQ8BAf8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMDQGA1UdIAQt MCswDAYKKoZIhvdMBQICATAMBgpghkgBhv1sBB8BMA0GCyqGSIb3TAUCAwMDMIGFBgNVHR8E fjB8MDygOqA4hjZodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vVEVSRU5BZVNjaWVuY2VQZXJz b25hbENBMy5jcmwwPKA6oDiGNmh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9URVJFTkFlU2Np ZW5jZVBlcnNvbmFsQ0EzLmNybDB7BggrBgEFBQcBAQRvMG0wJAYIKwYBBQUHMAGGGGh0dHA6 Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBFBggrBgEFBQcwAoY5aHR0cDovL2NhY2VydHMuZGlnaWNl cnQuY29tL1RFUkVOQWVTY2llbmNlUGVyc29uYWxDQTMuY3J0MA0GCSqGSIb3DQEBCwUAA4IB AQCg0e3UlUq/MB5fHWNWvp4sz2mknbburgqrARkEX2JUlcKe1rRZbN/6E4qBKqGvVeXdvIhi G9GQAhhXG2phojtY2r/MjmWt+vEE7zQoVhOyBxEY4ganXG4dhi4VLwsF7zggLh2XbqmhWcdZ G/SBwF3wEqiOI4hX9ryaPcKM4c/2ojzzNrHI/WQez7LzrRJKrQY1k8dCKXliW7Am7garfIEs L0xXK/6u4rZ5nH+PmvDVpr7MC0UpPP5AcfFAgf4dyu65IZ3TS3+ig0fqplGCpqCvaxGziWbn YyQsUWgcdQJZckUWOg234UAUd4aIvt3fx2aDK9o1hunXShp5Xstzf9xeMYIDwzCCA78CAQEw gYYwcjELMAkGA1UEBhMCTkwxFjAUBgNVBAgTDU5vb3JkLUhvbGxhbmQxEjAQBgNVBAcTCUFt c3RlcmRhbTEPMA0GA1UEChMGVEVSRU5BMSYwJAYDVQQDEx1URVJFTkEgZVNjaWVuY2UgUGVy c29uYWwgQ0EgMwIQCRoIcttBjUASisttMCF1VzANBglghkgBZQMEAgEFAKCCAg0wGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcxMDE5MTAzMDQyWjAvBgkq hkiG9w0BCQQxIgQgL3lP63oO+ea8KdXgmdFMhul22kx94uPY01tPTbx/WWIwbAYJKoZIhvcN AQkPMV8wXTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBlwYJKwYB BAGCNxAEMYGJMIGGMHIxCzAJBgNVBAYTAk5MMRYwFAYDVQQIEw1Ob29yZC1Ib2xsYW5kMRIw EAYDVQQHEwlBbXN0ZXJkYW0xDzANBgNVBAoTBlRFUkVOQTEmMCQGA1UEAxMdVEVSRU5BIGVT Y2llbmNlIFBlcnNvbmFsIENBIDMCEAkaCHLbQY1AEorLbTAhdVcwgZkGCyqGSIb3DQEJEAIL MYGJoIGGMHIxCzAJBgNVBAYTAk5MMRYwFAYDVQQIEw1Ob29yZC1Ib2xsYW5kMRIwEAYDVQQH EwlBbXN0ZXJkYW0xDzANBgNVBAoTBlRFUkVOQTEmMCQGA1UEAxMdVEVSRU5BIGVTY2llbmNl IFBlcnNvbmFsIENBIDMCEAkaCHLbQY1AEorLbTAhdVcwDQYJKoZIhvcNAQEBBQAEggEA3bpB ci/PjZjaFT5E9jXh3u+gxllDyRPnSqfR7sqKIt+jWHNSV9/GbJBJeY/PqHcMeYsPB/IHhvEu pQo9pCQubdg1ZxRh0rDK2o4atecwecdKvnvw/ptLbPWiTmWQWZPkoLSWooNhAG8MQ8dbwKwH gc/QlEeKeWeG1Z8rr4i6FvGxvwQzMCDbJzrOOIhMQhCsQXqoH1VpDM8k0/Z61HLnmDi8UTdP idwCtIHuKOfcgc47sJEGFlbdZLu83vPpuKRhOM7OQsFoG/LZAUze6mpnZSGDWHLDTtCpoZMO dBP1m6qMv7+Xqhxl0rnYnpoVgjJS+MwuIRI436qjRpQS6O88VQAAAAAAAA== --------------ms010105050605010202080105--

2 3

Problems to log into portal
by Juan Pablo Lorier 25 Oct '17

25 Oct '17

Hi, I'm trying to log into a fresh install (4.1 on centos 7) but though I've set the hostname-ip mapping in /etc/hosts of the server and my desktop, it keep complaining with the error: The client is not authorized to request an authorization. It's required to access the system using FQDN. Engine log shows the same error: ERROR [org.ovirt.engine.core.sso.utils.SsoUtils] (default task-9) [] The client is not authorized to request an authorization. It's required to access the system using FQDN What else should I do to get access? Regards

2 3

Testing ansible playbook against a mock engine?
by Luca 'remix_tj' Lorenzetto 25 Oct '17

25 Oct '17

Hello, i'm planning to create a big standardization playbook for my environment to ensure that all the required configs (networks, hosts, host's nics and networks....) are correctly set up. Since i don't want to test against a running setup, i'd like to spawn a transient one for testing. I already know Lago, but i think is bit overkill for testing an ansible playbook. Is there any tool that creates only an engine instance with some fake hosts configured so i can test the playbook against it? Luca -- "E' assurdo impiegare gli uomini di intelligenza eccellente per fare calcoli che potrebbero essere affidati a chiunque se si usassero delle macchine" Gottfried Wilhelm von Leibnitz, Filosofo e Matematico (1646-1716) "Internet è la più grande biblioteca del mondo. Ma il problema è che i libri sono tutti sparsi sul pavimento" John Allen Paulos, Matematico (1945-vivente) Luca 'remix_tj' Lorenzetto, http://www.remixtj.net , <lorenzetto.luca(a)gmail.com>

2 1

Re: [ovirt-users] move disk and lv not removed
by Idan Shaby 24 Oct '17

24 Oct '17

Hi Gianluca, Can you try to reproduce it with FC? Maybe it's somehow related to that. Did you try to lvremove the old lv's, or are they still in use? Trying to do this from the SPM should be ok. What do you mean synchronize the information at the other node side? In any case, this is a disk that you don't need anymore, isn't it? You said that the copy part of the move operation went well. Regards, Idan On Thu, Oct 19, 2017 at 10:47 AM, Gianluca Cecchi <gianluca.cecchi(a)gmail.com > wrote: > On Thu, Oct 19, 2017 at 7:36 AM, Idan Shaby <ishaby(a)redhat.com> wrote: > >> Hi Gianluca, >> >> This sounds like a bug to me. >> Can you please attach engine and vdsm logs? >> >> >> Thanks, >> Idan >> > > Hi Idan, > I have not at hand the full files right now, but these were the snippets I > cut from vdsm log and engine.log yesterday around the time of the first > error after sending the first e-mail > It seems vdsm reports that the logical volume is still in use while trying > to remove it.... > I have tried to replicate on another environment also based on block > storage, but now iSCSI and not FC and I was not able to get the error: the > move disk operation of the powered off vm always completed successfully. > Both tests were done trying to move preallocated disks if that matters > > vdsm.log of host1 > > 2017-10-18 14:59:28,907+0200 ERROR (libvirt/events) > [storage.TaskManager.Task] (Task='6331ec00-b75b-465e-8d9c-04d465c09ea1') > Unexpected error (task:872) > Traceback (most recent call last): > File "/usr/share/vdsm/storage/task.py", line 879, in _run > return fn(*args, **kargs) > File "<string>", line 2, in teardownImage > File "/usr/lib/python2.7/site-packages/vdsm/common/api.py", line 48, in > method > ret = func(*args, **kwargs) > File "/usr/share/vdsm/storage/hsm.py", line 3189, in teardownImage > dom.deactivateImage(imgUUID) > File "/usr/share/vdsm/storage/blockSD.py", line 1289, in deactivateImage > lvm.deactivateLVs(self.sdUUID, volUUIDs) > File "/usr/share/vdsm/storage/lvm.py", line 1304, in deactivateLVs > _setLVAvailability(vgName, toDeactivate, "n") > File "/usr/share/vdsm/storage/lvm.py", line 843, in _setLVAvailability > raise error(str(e)) > CannotDeactivateLogicalVolume: Cannot deactivate Logical Volume: ('General > Storage Exception: ("5 [] [\' Logical volume c5d360f5-cd90-4b3e-bdef- > 924649bfbc5f/eff58f10-12bf-412f-a5db-944bfb10904d is used by another > device.\']\\nc5d360f5-cd90-4b3e-bdef-924649bfbc5f/[\' > eff58f10-12bf-412f-a5db-944bfb10904d\']",)',) > 2017-10-18 14:59:28,907+0200 INFO (libvirt/events) > [storage.TaskManager.Task] (Task='6331ec00-b75b-465e-8d9c-04d465c09ea1') > aborting: Task is aborted: 'Cannot deactivate Logical Volume: (\'General > Storage Exception: ("5 [] [\\\' Logical volume c5d360f5-cd90-4b3e-bdef- > 924649bfbc5f/eff58f10-12bf-412f-a5db-944bfb10904d is used by another > device.\\\']\\\\nc5d360f5-cd90-4b3e-bdef-924649bfbc5f/[\ > \\'eff58f10-12bf-412f-a5db-944bfb10904d\\\']",)\',)' - code 552 > (task:1177) > 2017-10-18 14:59:28,908+0200 ERROR (libvirt/events) [storage.Dispatcher] > FINISH teardownImage error=Cannot deactivate Logical Volume: ('General > Storage Exception: ("5 [] [\' Logical volume c5d360f5-cd90-4b3e-bdef- > 924649bfbc5f/eff58f10-12bf-412f-a5db-944bfb10904d is used by another > device.\']\\nc5d360f5-cd90-4b3e-bdef-924649bfbc5f/[\' > eff58f10-12bf-412f-a5db-944bfb10904d\']",)',) (dispatcher:81) > > engine.log > 2017-10-18 15:01:53,097+02 INFO [org.ovirt.engine.core.dal. > dbbroker.auditloghandling.AuditLogDirector] (D > efaultQuartzScheduler6) [] EVENT_ID: USER_MOVED_DISK_FINISHED_SUCCESS(2,010), > Correlation ID: a8948cbf-80a > 2-462d-8805-91da94868c6e, Job ID: ffba7504-a324-43ca-ab4c-481610c1098b, > Call Stack: null, Custom ID: null, > Custom Event ID: -1, Message: User gcecchi@internal-authz finished > moving disk padora1_u01 to domain SATA > _ALLBCK. > 2017-10-18 15:01:54,029+02 ERROR [org.ovirt.engine.core.dal. > dbbroker.auditloghandling.AuditLogDirector] (DefaultQuartzScheduler5) > [394f8568] EVENT_ID: VDS_BROKER_COMMAND_FAILURE(10,802), Correlation ID: > null, Call Stack: null, Custom ID: null, Custom Event ID: -1, Message: VDSM > host1 command HSMGetAllTasksStatusesVDS failed: Cannot remove Logical > Volume: (['Cannot remove Logical Volume: (u\'c5d360f5-cd90-4b3e-bdef-924649bfbc5f\', > "[\'2255c544-165b-4126-86ee-70e6d1edef9a\']")'],) > 2017-10-18 15:01:54,029+02 INFO [org.ovirt.engine.core.bll.tasks.SPMAsyncTask] > (DefaultQuartzScheduler5) [394f8568] SPMAsyncTask::PollTask: Polling task > '8446a883-9bb0-40a5-b1eb-8a919defe4c0' (Parent Command 'RemoveImage', > Parameters Type 'org.ovirt.engine.core.common.asynctasks.AsyncTaskParameters') > returned status 'finished', result 'cleanSuccess'. > 2017-10-18 15:01:54,029+02 ERROR [org.ovirt.engine.core.bll.tasks.SPMAsyncTask] > (DefaultQuartzScheduler5) [394f8568] BaseAsyncTask::logEndTaskFailure: > Task '8446a883-9bb0-40a5-b1eb-8a919defe4c0' (Parent Command > 'RemoveImage', Parameters Type 'org.ovirt.engine.core.common.asynctasks.AsyncTaskParameters') > ended with failure: > -- Result: 'cleanSuccess' > -- Message: 'VDSGenericException: VDSErrorException: Failed in vdscommand > to HSMGetAllTasksStatusesVDS, error = Cannot remove Logical Volume: > (['Cannot remove Logical Volume: (u\'c5d360f5-cd90-4b3e-bdef-924649bfbc5f\', > "[\'2255c544-165b-4126-86ee-70e6d1edef9a\']")'],)', > -- Exception: 'VDSGenericException: VDSErrorException: Failed in > vdscommand to HSMGetAllTasksStatusesVDS, error = Cannot remove Logical > Volume: (['Cannot remove Logical Volume: (u\'c5d360f5-cd90-4b3e-bdef-924649bfbc5f\', > "[\'2255c544-165b-4126-86ee-70e6d1edef9a\']")'],)' > > Is there any command I can run to consistently remove the stale LVs? > As oVirt doesn't use clvmd I don't think it is sufficient to issue the > remove lv from the SPM node.. How will "synchronize" the information at the > other node side? > > Thanks, > Gianluca > >

2 3

Troubles uploading iso files via engine-iso-uploader
by Edward Clay 24 Oct '17

24 Oct '17

Hello, I've recently ran into a problem after removing an old nfs mounted ISO domain and recreating it using glusterfs. When I attempt to upload an iso using engine-iso-uploader it shows that it's attempting to access the storage domain via nfs. ---snipet---- DEBUG: /bin/mount -t nfs -o rw,sync,soft 10.4.16.11:/ISOSB /tmp/tmpr4lwKy ------------- from the engine server I am able to mount the gluster volume from the above path without issues. Iguess I'm confused as to why it's attempting to connecting using nfs when I created the storage domain for it using glusterfs. I have 1 ovirt engine server with 7 host/hypervisors and a 3 node replicated gluster volume. I've created seperate storage domains for VM images(data) and for ISO images. Both storage domains are accessible from the engine server and all host. Meaning I'm able to mount the glusterfs volume from all 8 servers. -- Edward Clay Systems Adminstrator UK2 Group -- US Operations Phone: 1-800-222-2165 E-Mail: edward.clay(a)uk2group.com

1 0

Lisa17 conference
by Niyazi Elvan 24 Oct '17

24 Oct '17

Hi folks, Is anyone attending to Lisa17 conference starting at this weekend ? I will be there and it would be nice to meet any of you. Cheers. Niyazi -- Niyazi Elvan

1 0