- Users - oVirt List Archives

Fwd: Install Windows VM issues
by Jon bae 19 Feb '18

19 Feb '18

Hi Markus, I install Windows 2016 just for two weeks, so in general it must work. Have you insert the windows iso to the dvd drive and the floppy file to the floppy? After booting and selecting installation, a bit after must come a menu where you normally choice the hard drive for installation, but this is empty. There is a button with install driver or something similar. When you click on it, you can navigate to the floppy drive. When this is not working, you can also change your HDD to IDE, install Windows. Add a second drive with virtIO, insert den driver CD install the driver. Reboot, remove the second HDD and change the main disk to virtIO to. But this is a bit hacky :). Jonathan Hi Jonathan, thanks for your quick reply! I startet with run once and attached the flv to the floppy, but still there’s no floppy or cd-rom drive with the drivers on it. Any hint on this? Markus Hi Markus, you need to use the "run onces" option, to be able to insert the floppy. Jonathan 2018-02-19 8:58 GMT+01:00 <Markus.Schaufler(a)ooe.gv.at>: Hi! I’m new here – hope you can forgive my „newbie questions“. I want to install a Server 2016 – so I uploaded both the Windows ISO and the virtio drivers iso to the ISO Domain location. In the VM Options I can choose both ISO files. But as refered in a Howto, I need to use a Floppy device with a flv file. I found the FLV drivers file, but I cannot find any Floppy device – there’s no option to choose. So I tried to add a second CD-Rom because in Proxmox that already did work. But I cannot find any option to add a second CD-Rom too. Any idea how I can provide the drivers for the windows installation? Thanks for any help! Markus

2 1

Unable to connect to the graphic server
by Alex Bartonek 18 Feb '18

18 Feb '18

This is a multi-part message in MIME format. --b1_576a8a5bb40fefc5c569d4cd3c0b589a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 SSd2ZSBidWlsdCBhbmQgcmVidWlsdCBhYm91dCA0IG9WaXJ0IHNlcnZlcnMuICBDb25zaWRlciBt eXNlbGYgcHJldHR5IGdvb2QgYXQgdGhpcy4gIExPTC4KU28gSSBhbSBzZXR0aW5nIHVwIGEgb1Zp cnQgc2VydmVyIGZvciBhIGZyaWVuZCBvbiBoaXMgcjcxMC4gIENlbnRPUyA3LCBvdmlydCA0LjIu ICAgL2V0Yy9ob3N0cyBoYXMgdGhlIGNvcnJlY3QgSVAgYW5kIEZRRE4gc2V0dXAuCgpXaGVuIEkg YnVpbGQgYSBWTSBhbmQgdHJ5IHRvIG9wZW4gYSBjb25zb2xlIHNlc3Npb24gdmlhICBTUElDRSBJ IGFtIHVuYWJsZSB0byBjb25uZWN0IHRvIHRoZSBncmFwaGljIHNlcnZlci4gIEknbSBjb25uZWN0 aW5nIGZyb20gYSBXaW5kb3dzIDEwIGJveC4gICBVc2luZyB2aXJ0LW1hbmFnZXIgdG8gY29ubmVj dC4KCkkndmUgZ29vZ2xlZCBhbmQgSSBqdXN0IGNhbnQgc2VlbSB0byBmaW5kIGFueSByZXNvbHV0 aW9uIHRvIHRoaXMuICBOb3csIEkgZGlkIGJ1aWxkIHRoZSBzZXJ2ZXIgb24gbXkgaG9tZSBuZXR3 b3JrIGJ1dCB0aGUgc3VibmV0IGl0cyBvbiBpcyB0aGUgc2FtZS4uIGludGVybmFsIDE5Mi4xNjgu MS54eHguICAgVGhlIHdlYiBpbnRlcmZhY2UgaXMgYWNjZXNzaWJsZSBhbHNvLgoKQW55IGhpbnRz IGFzIHRvIHdoYXQgZWxzZSBJIGNhbiBjaGVjaz8KClRoYW5rcyEKClNlbnQgd2l0aCBbUHJvdG9u TWFpbF0oaHR0cHM6Ly9wcm90b25tYWlsLmNvbSkgU2VjdXJlIEVtYWlsLg== --b1_576a8a5bb40fefc5c569d4cd3c0b589a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 PGRpdj5JJ3ZlIGJ1aWx0IGFuZCByZWJ1aWx0IGFib3V0IDQgb1ZpcnQgc2VydmVycy4mbmJzcDsg Q29uc2lkZXIgbXlzZWxmIHByZXR0eSBnb29kIGF0IHRoaXMuJm5ic3A7IExPTC48YnI+PC9kaXY+ PGRpdj5TbyBJIGFtIHNldHRpbmcgdXAgYSBvVmlydCBzZXJ2ZXIgZm9yIGEgZnJpZW5kIG9uIGhp cyByNzEwLiZuYnNwOyBDZW50T1MgNywgb3ZpcnQgNC4yLiZuYnNwOyZuYnNwOyAvZXRjL2hvc3Rz IGhhcyB0aGUgY29ycmVjdCBJUCBhbmQgRlFETiBzZXR1cC48YnI+PC9kaXY+PGRpdj48YnI+PC9k aXY+PGRpdj5XaGVuIEkgYnVpbGQgYSBWTSBhbmQgdHJ5IHRvIG9wZW4gYSBjb25zb2xlIHNlc3Np b24gdmlhJm5ic3A7IFNQSUNFIEkgYW0gdW5hYmxlIHRvIGNvbm5lY3QgdG8gdGhlIGdyYXBoaWMg c2VydmVyLiZuYnNwOyBJJ20gY29ubmVjdGluZyBmcm9tIGEgV2luZG93cyAxMCBib3guJm5ic3A7 Jm5ic3A7IFVzaW5nIHZpcnQtbWFuYWdlciB0byBjb25uZWN0Ljxicj48L2Rpdj48ZGl2Pjxicj48 L2Rpdj48ZGl2PkkndmUgZ29vZ2xlZCBhbmQgSSBqdXN0IGNhbnQgc2VlbSB0byBmaW5kIGFueSBy ZXNvbHV0aW9uIHRvIHRoaXMuJm5ic3A7IE5vdywgSSBkaWQgYnVpbGQgdGhlIHNlcnZlciBvbiBt eSBob21lIG5ldHdvcmsgYnV0IHRoZSBzdWJuZXQgaXRzIG9uIGlzIHRoZSBzYW1lLi4gaW50ZXJu YWwgMTkyLjE2OC4xLnh4eC4mbmJzcDsmbmJzcDsgVGhlIHdlYiBpbnRlcmZhY2UgaXMgYWNjZXNz aWJsZSBhbHNvLjxicj48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PkFueSBoaW50cyBhcyB0byB3 aGF0IGVsc2UgSSBjYW4gY2hlY2s/PGJyPjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+VGhhbmtz ITxicj48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2IGNsYXNzPSJwcm90b25tYWlsX3NpZ25hdHVy ZV9ibG9jayI+PGRpdiBjbGFzcz0icHJvdG9ubWFpbF9zaWduYXR1cmVfYmxvY2stdXNlciBwcm90 b25tYWlsX3NpZ25hdHVyZV9ibG9jay1lbXB0eSI+PGJyPjwvZGl2PjxkaXYgY2xhc3M9InByb3Rv bm1haWxfc2lnbmF0dXJlX2Jsb2NrLXByb3RvbiI+U2VudCB3aXRoIDxhIGhyZWY9Imh0dHBzOi8v cHJvdG9ubWFpbC5jb20iPlByb3Rvbk1haWw8L2E+IFNlY3VyZSBFbWFpbC48YnI+PC9kaXY+PC9k aXY+PGRpdj48YnI+PC9kaXY+ --b1_576a8a5bb40fefc5c569d4cd3c0b589a--

2 7

qcow2 images corruption
by Nicolas Ecarnot 18 Feb '18

18 Feb '18

Hello, TL; DR : qcow2 images keep getting corrupted. Any workaround? Long version: This discussion has already been launched by me on the oVirt and on qemu-block mailing list, under similar circumstances but I learned further things since months and here are some informations : - We are using 2 oVirt 3.6.7.5-1.el7.centos datacenters, using CentOS 7.{2,3} hosts - Hosts : - CentOS 7.2 1511 : - Kernel = 3.10.0 327 - KVM : 2.3.0-31 - libvirt : 1.2.17 - vdsm : 4.17.32-1 - CentOS 7.3 1611 : - Kernel 3.10.0 514 - KVM : 2.3.0-31 - libvirt 2.0.0-10 - vdsm : 4.17.32-1 - Our storage is 2 Equallogic SANs connected via iSCSI on a dedicated network - Depends on weeks, but all in all, there are around 32 hosts, 8 storage domains and for various reasons, very few VMs (less than 200). - One peculiar point is that most of our VMs are provided an additional dedicated network interface that is iSCSI-connected to some volumes of our SAN - these volumes not being part of the oVirt setup. That could lead to a lot of additional iSCSI traffic. From times to times, a random VM appears paused by oVirt. Digging into the oVirt engine logs, then into the host vdsm logs, it appears that the host considers the qcow2 image as corrupted. Along what I consider as a conservative behavior, vdsm stops any interaction with this image and marks it as paused. Any try to unpause it leads to the same conservative pause. After having found (https://access.redhat.com/solutions/1173623) the right logical volume hosting the qcow2 image, I can run qemu-img check on it. - On 80% of my VMs, I find no errors. - On 15% of them, I find Leaked cluster errors that I can correct using "qemu-img check -r all" - On 5% of them, I find Leaked clusters errors and further fatal errors, which can not be corrected with qemu-img. In rare cases, qemu-img can correct them, but destroys large parts of the image (becomes unusable), and on other cases it can not correct them at all. Months ago, I already sent a similar message but the error message was about No space left on device (https://www.mail-archive.com/qemu-block@gnu.org/msg00110.html) This time, I don't have this message about space, but only corruption. I kept reading and found a similar discussion in the Proxmox group : https://lists.ovirt.org/pipermail/users/2018-February/086750.html https://forum.proxmox.com/threads/qcow2-corruption-after-snapshot-or-heavy-… What I read similar to my case is : - usage of qcow2 - heavy disk I/O - using the virtio-blk driver In the proxmox thread, they tend to say that using virtio-scsi is the solution. Having asked this question to oVirt experts (https://lists.ovirt.org/pipermail/users/2018-February/086753.html) but it's not clear the driver is to blame. I agree with the answer Yaniv Kaul gave to me, saying I have to properly report the issue, so I'm longing to know which peculiar information I can give you now. As you can imagine, all this setup is in production, and for most of the VMs, I can not "play" with them. Moreover, we launched a campaign of nightly stopping every VM, qemu-img check them one by one, then boot. So it might take some time before I find another corrupted image. (which I'll preciously store for debug) Other informations : We very rarely do snapshots, but I'm close to imagine that automated migrations of VMs could trigger similar behaviors on qcow2 images. Last point about the versions we use : yes that's old, yes we're planning to upgrade, but we don't know when. Regards, -- Nicolas ECARNOT

5 8

Ovirt backups lead to unresponsive VM
by Alex K 18 Feb '18

18 Feb '18

Hi all, I have a cluster with 3 nodes, using ovirt 4.1 in a self hosted setup on top glusterfs. On some VMs (especially one Windows server 2016 64bit with 500 GB of disk). Guest agents are installed at VMs. i almost always observe that during the backup of the VM the VM is rendered unresponsive (dashboard shows a question mark at the VM status and VM does not respond to ping or to anything). For scheduled backups I use: https://github.com/wefixit-AT/oVirtBackup The script does the following: 1. snapshot VM (this is done ok without any failure) 2. Clone snapshot (this steps renders the VM unresponsive) 3. Export Clone 4. Delete clone 5. Delete snapshot Do you have any similar experience? Any suggestions to address this? I have never seen such issue with hosted Linux VMs. The cluster has enough storage to accommodate the clone. Thanx, Alex

3 7

Failing live migration with SPICE
by Alex K 18 Feb '18

18 Feb '18

Hi all, I am running a 3 node ovirt 4.1 selft hosted setup. I have consistently observed that windows 10 VMs with SPICE console fail to live migrate. Other VMs (windows server 2016) do migrate normally. VDSM log indicates: internal error: unable to execute QEMU command 'migrate': qxl: guest bug: command not in ram bar (migration:287) 2018-02-18 11:41:59,586+0000 ERROR (migsrc/2cf3a254) [virt.vm] (vmId='2cf3a254-8450-44cf-b023-e0a49827dac0') Failed to migrate (migration:429) if ret == -1: raise libvirtError ('virDomainMigrateToURI3() failed', dom=self) libvirtError: internal error: unable to execute QEMU command 'migrate': qxl: guest bug: command not in ram bar Seems as a guest agent bug for Windows 10? Is there any fix? Thanx, Alex

2 4

ovirt change of email alert
by Alex K 18 Feb '18

18 Feb '18

Hi all, I had put a specif email alert during the deploy and then I wanted to change it. I did the following: At one of the hosts ra: hosted-engine --set-shared-config destination-emails alerts(a)domain.com --type=broker systemctl restart ovirt-ha-broker.service I had to do the above since changing the email from GUI did not have any effect. After the above the emails are received at the new email address but the cluster seems to have some issue recognizing the state of engine. i am flooded with emails that " EngineMaybeAway-EngineUnexpectedlyDown " I have restarted at each host also the ovirt-ha-agent.service. Did put the cluster to global maintenance and then disabled global maintenance. host agent logs I have: MainThread::ERROR::2018-02-18 11:12:20,751::hosted_engine::720::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(_initialize_sanlock) cannot get lock on host id 1: host already holds lock on a different host id One other host logs: MainThread::INFO::2018-02-18 11:20:23,692::states::682::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(score) Score is 0 due to unexpected vm shutdown at Sun Feb 18 11:15:13 2018 MainThread::INFO::2018-02-18 11:20:23,692::hosted_engine::453::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(start_monitoring) Current state EngineUnexpectedlyDown (score: 0) The engine status on 3 hosts is: hosted-engine --vm-status --== Host 1 status ==-- conf_on_shared_storage : True Status up-to-date : True Hostname : v0 Host ID : 1 Engine status : {"reason": "vm not running on this host", "health": "bad", "vm": "down", "detail": "unknown"} Score : 0 stopped : False Local maintenance : False crc32 : cfd15dac local_conf_timestamp : 4721144 Host timestamp : 4721144 Extra metadata (valid at timestamp): metadata_parse_version=1 metadata_feature_version=1 timestamp=4721144 (Sun Feb 18 11:20:33 2018) host-id=1 score=0 vm_conf_refresh_time=4721144 (Sun Feb 18 11:20:33 2018) conf_on_shared_storage=True maintenance=False state=EngineUnexpectedlyDown stopped=False timeout=Tue Feb 24 15:29:44 1970 --== Host 2 status ==-- conf_on_shared_storage : True Status up-to-date : True Hostname : v1 Host ID : 2 Engine status : {"reason": "vm not running on this host", "health": "bad", "vm": "down", "detail": "unknown"} Score : 0 stopped : False Local maintenance : False crc32 : 5cbcef4c local_conf_timestamp : 2499416 Host timestamp : 2499416 Extra metadata (valid at timestamp): metadata_parse_version=1 metadata_feature_version=1 timestamp=2499416 (Sun Feb 18 11:20:46 2018) host-id=2 score=0 vm_conf_refresh_time=2499416 (Sun Feb 18 11:20:46 2018) conf_on_shared_storage=True maintenance=False state=EngineUnexpectedlyDown stopped=False timeout=Thu Jan 29 22:18:42 1970 --== Host 3 status ==-- conf_on_shared_storage : True Status up-to-date : False Hostname : v2 Host ID : 3 Engine status : unknown stale-data Score : 3400 stopped : False Local maintenance : False crc32 : f064d529 local_conf_timestamp : 2920612 Host timestamp : 2920611 Extra metadata (valid at timestamp): metadata_parse_version=1 metadata_feature_version=1 timestamp=2920611 (Sun Feb 18 10:47:31 2018) host-id=3 score=3400 vm_conf_refresh_time=2920612 (Sun Feb 18 10:47:32 2018) conf_on_shared_storage=True maintenance=False state=GlobalMaintenance stopped=False Putting each host at maintenance then activating them back does not resolve the issue. Seems I have to avoid defining email address during deploy and have it set only later at GUI. How one can recover from this situation? Thanx, Alex

1 0

Re: [ovirt-users] Import Domain and snapshot issue ... please help !!!
by Enrico Becchetti 18 Feb '18

18 Feb '18

This is a cryptographically signed message in MIME format. --------------ms050607070104000301070509 Content-Type: multipart/alternative; boundary="------------ED6337BCF2BC492470FB68A8" Content-Language: it-IT This is a multi-part message in MIME format. --------------ED6337BCF2BC492470FB68A8 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable =C2=A0 Hi, also you can download them throught these links: https://owncloud.pg.infn.it/index.php/s/QpsTyGxtRTPYRTD https://owncloud.pg.infn.it/index.php/s/ph8pLcABe0nadeb Thanks again !!!! Best Regards Enrico > Il 13/02/2018 14:52, Maor Lipchuk ha scritto: >> >> >> On Tue, Feb 13, 2018 at 3:51 PM, Maor Lipchuk <mlipchuk(a)redhat.com=20 >> <mailto:mlipchuk@redhat.com>> wrote: >> >> >> On Tue, Feb 13, 2018 at 3:42 PM, Enrico Becchetti >> <enrico.becchetti(a)pg.infn.it >> <mailto:enrico.becchetti@pg.infn.it>> wrote: >> >> see the attach files please ... thanks for your attention !!! >> >> >> >> Seems like the engine logs does not contain the entire process, >> can you please share older logs since the import operation? >> >> >> And VDSM logs as well from your host >> >> Best Regards >> Enrico >> >> >> Il 13/02/2018 14:09, Maor Lipchuk ha scritto: >>> >>> >>> On Tue, Feb 13, 2018 at 1:48 PM, Enrico Becchetti >>> <enrico.becchetti(a)pg.infn.it >>> <mailto:enrico.becchetti@pg.infn.it>> wrote: >>> >>> =C2=A0Dear All, >>> I have been using ovirt for a long time with three >>> hypervisors and an external engine running in a centos vm= . >>> >>> This three hypervisors have HBAs and access to fiber >>> channel storage. Until recently I used version 3.5, then >>> I reinstalled everything from scratch and now I have 4.2.= >>> >>> Before formatting everything, I detach the storage data >>> domani (FC) with the virtual machines and reimported it >>> to the new 4.2 and all went well. In >>> this domain there were virtual machines with and without >>> snapshots. >>> >>> Now I have two problems. The first is that if I try to >>> delete a snapshot the process is not end successful and >>> remains hanging and the second problem is that >>> in one case I lost the virtual machine !!! >>> >>> >>> >>> Not sure that I fully understand the scneario.' >>> How was the virtual machine got lost if you only tried to >>> delete a snapshot? >>> >>> >>> So I need your help to kill the three running zombie >>> tasks because with taskcleaner.sh I can't do anything >>> and then I need to know how I can delete the old snapshot= s >>> made with the 3.5 without losing other data or without >>> having new processes that terminate correctly. >>> >>> If you want some log files please let me know. >>> >>> >>> >>> Hi Enrico, >>> >>> Can you please attach the engine and VDSM logs >>> >>> >>> Thank you so much. >>> Best Regards >>> Enrico >>> >>> >>> >>> _______________________________________________ >>> 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 >> ______________________________________________________________= _________ >> >> Enrico Becchetti Servizio di Calcolo e Reti= >> >> Istituto Nazionale di Fisica Nucleare - Sezione di Perugia >> Via Pascoli,c/o Dipartimento di Fisica 06123 Perugia (ITALY) >> Phone:+39 075 5852777 <tel:+39%20075%20585%202777> = Mail: Enrico.Becchetti<at>pg.infn.it <http://pg.infn.it> >> ______________________________________________________________= ________ >> >> >> > > --=20 > _______________________________________________________________________= > > Enrico Becchetti Servizio di Calcolo e Reti > > Istituto Nazionale di Fisica Nucleare - Sezione di Perugia > Via Pascoli,c/o Dipartimento di Fisica 06123 Perugia (ITALY) > Phone:+39 075 5852777 Mail: Enrico.Becchetti<at>pg.infn.it > ______________________________________________________________________ --=20 _______________________________________________________________________ Enrico Becchetti Servizio di Calcolo e Reti Istituto Nazionale di Fisica Nucleare - Sezione di Perugia Via Pascoli,c/o Dipartimento di Fisica 06123 Perugia (ITALY) Phone:+39 075 5852777 Mail: Enrico.Becchetti<at>pg.infn.it ______________________________________________________________________ --------------ED6337BCF2BC492470FB68A8 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <html> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dutf= -8"> </head> <body text=3D"#000000" bgcolor=3D"#FFFFFF"> =C2=A0 Hi, <div class=3D"moz-cite-prefix">also you can download them throught these<br> links:<br> <br> <a class=3D"moz-txt-link-freetext" href=3D"https://owncloud.pg.infn= =2Eit/index.php/s/QpsTyGxtRTPYRTD">https://owncloud.pg.infn.it/index.php/= s/QpsTyGxtRTPYRTD</a><br> </div> <a class=3D"moz-txt-link-freetext" href=3D"https://owncloud.pg.infn.i= t/index.php/s/ph8pLcABe0nadeb">https://owncloud.pg.infn.it/index.php/s/ph= 8pLcABe0nadeb</a><br> <br> Thanks again !!!!<br> Best Regards<br> Enrico<br> <br> <blockquote type=3D"cite" cite=3D"mid:54306728-1b78-6634-0bcb-26f836cb1cf9@pg.infn.it"> <div class=3D"moz-cite-prefix"> Il 13/02/2018 14:52, Maor Lipchuk h= a scritto:<br> </div> <blockquote type=3D"cite" cite=3D"mid:CAJ1JNOfTOG850gVAznZpC1qfRPU1ws9ow3OGSJUK=3Dk+dVAzjdg@mail.gm= ail.com"> <div dir=3D"ltr"><br> <div class=3D"gmail_extra"><br> <div class=3D"gmail_quote">On Tue, Feb 13, 2018 at 3:51 PM, Maor Lipchuk <span dir=3D"ltr"><<a href=3D"mailto:mlipchuk@redhat.com" target=3D"_blank" moz-do-not-send=3D"true">mlipchuk(a)redhat.com</a>></s= pan> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div dir=3D"ltr"> <div class=3D"gmail_extra"><br> <div class=3D"gmail_quote"><span class=3D"">On Tue, F= eb 13, 2018 at 3:42 PM, Enrico Becchetti <span dir=3D"ltr"><<a href=3D"mailto:enrico.becchetti@pg.infn.it" target=3D"_blank" moz-do-not-send=3D"true">en= rico.becchetti(a)pg.infn.it</a>></span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <div bgcolor=3D"#FFFFFF"> <div class=3D"m_1867120190031562186gmail-m_-8783= 667902876592593moz-cite-prefix">see the attach files please ... thanks for your attention !!!<br> </div> </div> </blockquote> <div class=3D"gmail_quote"><br> </div> <div class=3D"gmail_quote"><br> </div> </span>Seems like the engine logs does not contain the entire process, can you please share older logs since the import operation?</div> </div> </div> </blockquote> <div><br> </div> <div>And VDSM logs as well from your host</div> <div>=C2=A0</div> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div dir=3D"ltr"> <div class=3D"gmail_extra"> <div class=3D"gmail_quote"> <div> <div class=3D"h5"> <div>=C2=A0</div> <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <div bgcolor=3D"#FFFFFF"> <div class=3D"m_1867120190031562186gmail-m_-87= 83667902876592593moz-cite-prefix"> Best Regards<br> Enrico <div> <div class=3D"m_1867120190031562186gmail-h= 5"><br> <br> Il 13/02/2018 14:09, Maor Lipchuk ha scritto:<br> </div> </div> </div> <div> <div class=3D"m_1867120190031562186gmail-h5"= > <blockquote type=3D"cite"> <div dir=3D"ltr"><br> <div class=3D"gmail_extra"><br> <div class=3D"gmail_quote">On Tue= , Feb 13, 2018 at 1:48 PM, Enrico Becchetti <span dir=3D"ltr"><<a href=3D"mailto:enrico.becch= etti(a)pg.infn.it" target=3D"_blank" moz-do-not-send=3D"true">en= rico.becchetti(a)pg.infn.it</a>></span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">=C2=A0Dear All,<br> I have been using ovirt for a long time with three hypervisors and an external engine running in a centos vm .<br> <br> This three hypervisors have HBAs and access to fiber channel storage. Until recently I used version 3.5, then I reinstalled everything from scratch and now I have 4.2.<br> <br> Before formatting everything, I detach the storage data domani (FC) with the virtual machines and reimported it to the new 4.2 and all went well. In<br>= this domain there were virtual machines with and without snapshots.<br> <br> Now I have two problems. The first is that if I try to delete a snapshot the process is not end successful and remains hanging and the second problem is that<br> in one case I lost the virtual machine !!!<br> </blockquote> <div><br> </div> <div><br> </div> <div>Not sure that I fully understand the scneario.'</di= v> <div>How was the virtual machine got lost if you only tried to delete a snapshot?</= div> <div>=C2=A0</div> <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <br> So I need your help to kill the three running zombie tasks because with taskcleaner.sh I can't do anything and then I need to know how I can delete the old snapshots<br> made with the 3.5 without losing other data or without having new processes that terminate correctly.<br> <br> If you want some log files please let me know.<br> </blockquote> <div><br> </div> <div><br> </div> <div>Hi Enrico,</div> <div><br> </div> <div>Can you please attach the engine and VDSM logs</div> <div>=C2=A0=C2=A0</div> <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <br> Thank you so much.<br> Best Regards<span class=3D"m_1867120190031562= 186gmail-m_-8783667902876592593gmail-HOEnZb"><font color=3D"#888888"><br> Enrico<br> <br> <br> </font></span><br> ______________________________<wbr>_________________<br> Users mailing list<br> <a href=3D"mailto:Users@ovirt.= org" target=3D"_blank" moz-do-not-send=3D"true">Us= ers(a)ovirt.org</a><br> <a href=3D"http://lists.ovirt.= org/mailman/listinfo/users" rel=3D"noreferrer" target=3D"_blank" moz-do-not-send=3D"true">ht= tp://lists.ovirt.org/mailman<wbr>/listinfo/users</a><br> <br> </blockquote> </div> <br> </div> </div> </blockquote> <p><br> </p> </div> </div> <span class=3D"m_1867120190031562186gmail-HOEnZ= b"><font color=3D"#888888"> <pre class=3D"m_1867120190031562186gmai= l-m_-8783667902876592593moz-signature" cols=3D"72">--=20 ______________________________<wbr>______________________________<wbr>___= ________ Enrico Becchetti Servizio di Calcolo e Reti Istituto Nazionale di Fisica Nucleare - Sezione di Perugia Via Pascoli,c/o Dipartimento di Fisica 06123 Perugia (ITALY) Phone:<a href=3D"tel:+39%20075%20585%202777" value=3D"+390755852777" targ= et=3D"_blank" moz-do-not-send=3D"true">+39 075 5852777</a> Ma= il: Enrico.Becchetti<at><a href=3D"http://pg.infn.it" target=3D"_bl= ank" moz-do-not-send=3D"true">pg.infn.it</a> ______________________________<wbr>______________________________<wbr>___= _______ </pre> </font></span></div> </blockquote> </div> </div> </div> <br> </div> </div> </blockquote> </div> <br> </div> </div> </blockquote> <p><br> </p> <pre class=3D"moz-signature" cols=3D"72">--=20 _______________________________________________________________________ Enrico Becchetti Servizio di Calcolo e Reti Istituto Nazionale di Fisica Nucleare - Sezione di Perugia Via Pascoli,c/o Dipartimento di Fisica 06123 Perugia (ITALY) Phone:+39 075 5852777 Mail: Enrico.Becchetti<at>pg.infn= =2Eit ______________________________________________________________________ </= pre> </blockquote> <p><br> </p> <pre class=3D"moz-signature" cols=3D"72">--=20 _______________________________________________________________________ Enrico Becchetti Servizio di Calcolo e Reti Istituto Nazionale di Fisica Nucleare - Sezione di Perugia Via Pascoli,c/o Dipartimento di Fisica 06123 Perugia (ITALY) Phone:+39 075 5852777 Mail: Enrico.Becchetti<at>pg.infn= =2Eit ______________________________________________________________________ </= pre> </body> </html> --------------ED6337BCF2BC492470FB68A8-- --------------ms050607070104000301070509 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: Firma crittografica S/MIME MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC BZMwggWPMIIDd6ADAgECAgMAkbUwDQYJKoZIhvcNAQELBQAwQzELMAkGA1UEBhMCSVQxDTAL BgNVBAoTBElORk4xJTAjBgNVBAMTHElORk4gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcN MTcwMjIyMTM0NDU1WhcNMTgwMjIyMTM0NDU1WjBoMQswCQYDVQQGEwJJVDENMAsGA1UEChME SU5GTjEdMBsGA1UECxMUUGVyc29uYWwgQ2VydGlmaWNhdGUxEDAOBgNVBAcTB1BlcnVnaWEx GTAXBgNVBAMTEEVucmljbyBCZWNjaGV0dGkwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQDM9hqLromxJFRrJxIkfgn+pYWI6IJmy0zu0OH6x/zrp8eEpTkI6Rlngg3jVexYWldr obFy6TSSW429GDbkszGjy/yNJKtgQnRama8Izihm/RY5m/j8iTqvw4RPdk6CrxO8AD3FGiR8 sSImHzBagHmvAHwA9Ba5gTCJVgRO4MsGAMaxKNkwUrGIZK+Rmi5zVLW2yfjqsSiO4sCZDXey /Ndm17b8FF5HG5rNWjwG8A0y2s25AWTxURvM1gNnTXl8zOPWmtvZcpp5dBp3VlA6N/0Pk3uy klBIBEEK67W9+vqcDfqNON24hL+Cm3OsGrW/XpIIb/oQNdLp5dtSUG3qTn8BAgMBAAGjggFl MIIBYTAMBgNVHRMBAf8EAjAAMA4GA1UdDwEB/wQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcD AgYIKwYBBQUHAwQwPwYDVR0fBDgwNjA0oDKgMIYuaHR0cDovL3NlY3VyaXR5LmZpLmluZm4u aXQvQ0EvSU5GTi1DQS0yMDE1LmNybDAlBgNVHSAEHjAcMAwGCisGAQQB0SMKAQgwDAYKKoZI hvdMBQICATAdBgNVHQ4EFgQUiw04Jlbw6qOmGOQVq8eXcDhG08cwcwYDVR0jBGwwaoAUQ4xN /uyWyunvCqR9wZ0C5Z+9loChR6RFMEMxCzAJBgNVBAYTAklUMQ0wCwYDVQQKEwRJTkZOMSUw IwYDVQQDExxJTkZOIENlcnRpZmljYXRpb24gQXV0aG9yaXR5ggkAsyYCxn1JJicwJgYDVR0R BB8wHYEbZW5yaWNvLmJlY2NoZXR0aUBwZy5pbmZuLml0MA0GCSqGSIb3DQEBCwUAA4ICAQBY SsKt/XTw+Kc+Vc1pjVi5uuEf/oP0U/nQQywIyM+rhbkeHy8c1eokA5k8Xnycwx8kzAh0e2lz W0a8gM2tSI799DF6N8s5NfCo6RoPciSYA+7edylWlE8TfGoJ2I5pNZV3IctYlfokSiz59EPz CNhQsfVbF8qkINB/J8HlbKvm0ERDOAse1pBjNwdU3Lt5nxmw3Yd08b9jPw4g5eMSmW4XmRzP kERTjAQxophM4OIKb0Vj0XfqONBt+LansgyzHcWbo+aKJmgQDvdumnGsNoQbRI4TxjnlB4Dg Vgbvo0mKZYfu0Sr2U9+wpRJ0U/+YljbVEuzmD9hl/eBRoBgIhx9dwoBYsuXEkWo8RkgeVpnt z8ze4zubi7+4BnuuVLZeq1VWQFy1qU7KGTou4a6B+gM88ZviGJI6o03oDhE976uOST5v5pZ7 q7uhgBd8FW594PAWdI1oPQ5YVKX+NX6XrXwf7GYf18OTmV3kNxWllrNVz3YLLhbnSSf1o3sd FLZXMu1r4dbeQuk7duYa/c/POyl3f8H/JGAPIOVQWfotMm8X/WET9Rhglc5Ead18rZPePTpj zyjfB+k0C0ZH1cM7ynTpMDxrk9X7Zq4wbKFlzG1OVKSzTiZGLQrjhciXoSDHs4J9RNM5ar2G IYWhWFkQ+tVY/73EOsNHHXjk438qUUD33jGCAwgwggMEAgEBMEowQzELMAkGA1UEBhMCSVQx DTALBgNVBAoTBElORk4xJTAjBgNVBAMTHElORk4gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkC AwCRtTANBglghkgBZQMEAgEFAKCCAY8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkq hkiG9w0BCQUxDxcNMTgwMjE0MDgxMTQyWjAvBgkqhkiG9w0BCQQxIgQgWNGQtbBzZ41OMyBw nGzdNpVSgpH9TRdai8vep1YqQYAwWQYJKwYBBAGCNxAEMUwwSjBDMQswCQYDVQQGEwJJVDEN MAsGA1UEChMESU5GTjElMCMGA1UEAxMcSU5GTiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eQID AJG1MFsGCyqGSIb3DQEJEAILMUygSjBDMQswCQYDVQQGEwJJVDENMAsGA1UEChMESU5GTjEl MCMGA1UEAxMcSU5GTiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eQIDAJG1MGwGCSqGSIb3DQEJ DzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0D AgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcN AQEBBQAEggEAcjFESE65z2g5Tc/bjY5/qPeWr9bljHuiUHx41Yq9AbJi8ODtkL+g4ntC2Upd H964sFzA+0RoakYOwDJH4dAMgbdrX93uR5V3/s5cjMuaxaU9ko+dgVmjq1ptl1mAOJVWCcsg 8p1lC250ursn0QnU4gURm4KT+11PsrCEF5qrbuIXvsuqiOsLA70wYCq4PSRW4sqNLTaXR8oc 3g4v9jP1aolER0UTA7UQapU928/mYZZkTXCCAsKfDhQvEVe9/QJyikRxXsuH8PU6ywKp25sK WXc/1dwteceSyz8aCBM6e4+mhGe+RirP7b9Rf2sqTJf+m2SSHwJ2ARzcVjlHQBxGZgAAAAAA AA== --------------ms050607070104000301070509--

2 6

database restoration
by Fabrice Bacchella 18 Feb '18

18 Feb '18

I'm running a restoration test and getting the following log generated by engine-backup --mode=restore: pg_restore: [archiver (db)] Error while PROCESSING TOC: pg_restore: [archiver (db)] Error from TOC entry 4274; 0 0 COMMENT EXTENSION plpgsql pg_restore: [archiver (db)] could not execute query: ERROR: must be owner of extension plpgsql Command was: COMMENT ON EXTENSION plpgsql IS 'PL/pgSQL procedural language'; pg_restore: WARNING: no privileges could be revoked for "public" pg_restore: WARNING: no privileges could be revoked for "public" pg_restore: WARNING: no privileges were granted for "public" pg_restore: WARNING: no privileges were granted for "public" WARNING: errors ignored on restore: 1 Do I need to worry, as this error is ignored ?

2 2

Unable to put Host into Maintenance mode
by Mark Steele 16 Feb '18

16 Feb '18

I have a host that is currently reporting down with NO VM's on it or associated with it. However when I attempt to put it into maintenance mode, I get the following error: Host hv-01 cannot change into maintenance mode - not all Vms have been migrated successfully. Consider manual intervention: stopping/migrating Vms: <UNKNOWN> (User: admin) I am running oVirt Engine Version: 3.5.0.1-1.el6 *** *Mark Steele* CIO / VP Technical Operations | TelVue Corporation TelVue - We Share Your Vision 16000 Horizon Way, Suite 100 | Mt. Laurel, NJ 08054 800.885.8886 x128 | msteele(a)telvue.com | http://www.telvue.com twitter: http://twitter.com/telvue | facebook: https://www.facebook.com/telvue

7 11

Username / password for ovirt-shell
by Mark Steele 16 Feb '18

16 Feb '18

Hello, I'm not the original system architect of our Cluster and I'm not able to locate any documentation regarding the username and password for our ovirt-shell CLI. Is there a config file on the HostedEngine that would point me in the right direction? Best regards, *** *Mark Steele* CIO / VP Technical Operations | TelVue Corporation TelVue - We Share Your Vision 16000 Horizon Way, Suite 100 | Mt. Laurel, NJ 08054 800.885.8886 x128 | msteele(a)telvue.com | http://www.telvue.com twitter: http://twitter.com/telvue | facebook: https://www.facebook.com/telvue

1 1