- Users - oVirt List Archives

Failed Installation
by Marcello Gentile 25 Jul '19

25 Jul '19

I’m installing a self-hosted engine on CentOS7.6 using cockpit. Keep getting this error [ INFO ] TASK [ovirt.hosted_engine_setup : Wait for the host to be up] [ INFO ] ok: [localhost] [ INFO ] TASK [ovirt.hosted_engine_setup : Check host status] [ ERROR ] fatal: [localhost]: FAILED! => {"changed": false, "msg": "The host has been set in non_operational status, please check engine logs, fix accordingly and re-deploy.\n"} [ INFO ] TASK [ovirt.hosted_engine_setup : Fetch logs from the engine VM] [ INFO ] ok: [localhost] [ INFO ] TASK [ovirt.hosted_engine_setup : Set destination directory path] [ INFO ] ok: [localhost] [ INFO ] TASK [ovirt.hosted_engine_setup : Create destination directory] [ INFO ] changed: [localhost] [ INFO ] TASK [ovirt.hosted_engine_setup : include_tasks] [ INFO ] ok: [localhost] [ INFO ] TASK [ovirt.hosted_engine_setup : Find the local appliance image] [ INFO ] ok: [localhost] [ INFO ] TASK [ovirt.hosted_engine_setup : Set local_vm_disk_path] [ INFO ] ok: [localhost] [ INFO ] TASK [ovirt.hosted_engine_setup : Give the vm time to flush dirty buffers] [ INFO ] ok: [localhost -> localhost] [ INFO ] TASK [ovirt.hosted_engine_setup : Copy engine logs] [ INFO ] changed: [localhost] [ INFO ] TASK [ovirt.hosted_engine_setup : include_tasks] [ INFO ] ok: [localhost] [ INFO ] TASK [ovirt.hosted_engine_setup : Remove local vm dir] [ INFO ] changed: [localhost] [ INFO ] TASK [ovirt.hosted_engine_setup : Remove temporary entry in /etc/hosts for the local VM] [ INFO ] changed: [localhost] [ INFO ] TASK [ovirt.hosted_engine_setup : Notify the user about a failure] [ ERROR ] fatal: [localhost]: FAILED! => {"changed": false, "msg": "The system may not be provisioned according to the playbook results: please check the logs for the issue, fix accordingly or re-deploy from scratch.\n”} The logs don’t tell me much or at least the ones I’m checking Any help would be greatly appreciated Thanks

2 1

iSCSI-based storages won't login to the portals with all IPs on reboot
by nicolas＠devels.es 25 Jul '19

25 Jul '19

Hi, We're running oVirt 4.3.2. Currently, we have one storage backend (cabinet) with two controllers, each of them with 2 network interfaces (4 network interfaces in total). When we added the Storage Domain, we discovered the target for each of the 4 IPs and marked the LUN so it would be added with 4 different IPs. When we put a host on maintenance, all the paths are deactivated, and when we activate it back it discovers all the 4 paths for the storage backend. However, if we reboot the host, on activation it only activates one path. We can see this running 'multipath -ll'. We can manually activate the rest of the paths using this command for each of the IPs: # iscsiadm --mode discovery --type sendtargets --portal 10.X.X.X --login However, we wonder why oVirt wouldn't log into each of the IPs upon a boot. Is there something we're missing? Can this be fixed manually? Currently we're running a script on boot that will issue the command above for each of the IPs of the cabinet. Thanks for any help!

2 1

template permissions not inherited (4.3.4)
by Timmi 24 Jul '19

24 Jul '19

Hi oVirt List, I have just a quick question if I should open a ticket for this or if I'm doing something wrong. I created a new VM template with specific permissions in addition to the system wide permissions. If I create a new VM with the template I notices that only system permissions are copied to the permission of the new VM. Is this the intended behavior? I was somehow under the impression that the permission from the template should have been copied to the newly created VM. Tested with Version 4.3.4.3-1.el7 Best regards Christoph

4 6

if hosted engine corrupted
by Crazy Ayansh 24 Jul '19

24 Jul '19

Hi All, What is the way if self hosted engine corrupted in any environment and we need to setup it from scratch however on the new engine we need the same hosts and virtual machine without loosing data. Thanks Shashakn

2 1

reinstallation information
by nikkognt＠gmail.com 24 Jul '19

24 Jul '19

Hi, after a blackout one host of my ovirt not working properly. I tried to Reinstall it but ends with the following error "Failed to install Host ov1. Failed to execute stage 'Closing up': Failed to start service 'vdsmd'." I tried to start manually but it not start . Now, I would like to reinstall from iso ovirt node. After I put the host is in maintenance must I remove host from the cluster (Hosts -> host1 -> Remove) or I can reinstall without remove it? If I remore it from the cluster the network configurations I lose them or not? My ovirt version is oVirt Engine Version: 4.1.9.1-1.el7.centos.

2 6

Re: Storage domain 'Inactive' but still functional
by Strahil 24 Jul '19

24 Jul '19

I forgot to mention that LVM config has to be modified in order to 'inform' local LVM stack to rely on clvmd/dlm for locking purposes. Yet, this brings abother layer of complexity which I prefer to avoid , thus I use HA-LVM on my pacemaker clusters. @Martin, Check the link from Benny and if possible check if the 2 cases are related. Best Regards, Strahil NikolovOn Jul 24, 2019 11:07, Benny Zlotnik <bzlotnik(a)redhat.com> wrote: > > We have seen something similar in the past and patches were posted to deal with this issue, but it's still in progress[1] > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1553133 > > On Mon, Jul 22, 2019 at 8:07 PM Strahil <hunter86_bg(a)yahoo.com> wrote: >> >> I have a theory... But after all without any proof it will remain theory. >> >> The storage volumes are just VGs over a shared storage.The SPM host is supposed to be the only one that is working with the LVM metadata, but I have observed that when someone is executing a simple LVM command (for example -lvs, vgs or pvs ) while another one is going on on another host - your metadata can corrupt, due to lack of clvmd. >> >> As a protection, I could offer you to try the following solution: >> 1. Create new iSCSI lun >> 2. Share it to all nodes and create the storage domain. Set it to maintenance. >> 3. Start dlm & clvmd services on all hosts >> 4. Convert the VG of your shared storage domain to have a 'cluster'-ed flag: >> vgchange -c y mynewVG >> 5. Check the lvs of that VG. >> 6. Activate the storage domain. >> >> Of course test it on a test cluster before inplementing it on Prod. >> This is one of the approaches used in Linux HA clusters in order to avoid LVM metadata corruption. >> >> Best Regards, >> Strahil Nikolov >> >> On Jul 22, 2019 15:46, Martijn Grendelman <Martijn.Grendelman(a)isaac.nl> wrote: >>> >>> Hi, >>> >>> Op 22-7-2019 om 14:30 schreef Strahil: >>>> >>>> If you can give directions (some kind of history) , the dev might try to reproduce this type of issue. >>>> >>>> If it is reproduceable - a fix can be provided. >>>> >>>> Based on my experience, if something as used as Linux LVM gets broken, the case is way hard to reproduce. >>> >>> >>> Yes, I'd think so too, especially since this activity (online moving of disk images) is done all the time, mostly without problems. In this case, there was a lot of activity on all storage domains, because I'm moving all my storage (> 10TB in 185 disk images) to a new storage platform. During the online move of one the images, the metadata checksum became corrupted and the storage domain went offline. >>> >>> Of course, I could dig up the engine logs and vdsm logs of when it happened, but that would be some work and I'm not very confident that the actual cause would be in there. >>> >>> If any oVirt devs are interested in the logs, I'll provide them, but otherwise I think I'll just see it as an incident and move on. >>> >>> Best regards, >>> Martijn. >>> >>> >>> >>> >>> On Jul 22, 2019 10:17, Martijn Grendelman <Martijn.Grendelman(a)isaac.nl> wrote: >>>>> >>>>> Hi, >>>>> >>>>> Thanks for the tips! I didn't know about 'pvmove', thanks. >>>>> >>>>> In the mean time, I managed to get it fixed by restoring the VG metadata on the iSCSI server, so on the underlying Zvol directly, rather than via the iSCSI session on the oVirt host. That allowed me to perform the restore without bringing all VMs down, which was important to me, because if I had to shut down VMs, I was sure I wouldn't be able to restart them before the storage domain was back online. >>>>> >>>>> Of course this is a more a Linux problem than an oVirt problem, but oVirt did cause it ;-) >>>>> >>>>> Thanks, >>>>> Martijn. >>>>> >>>>> >>>>> >>>>> Op 19-7-2019 om 19:06 schreef Strahil Nikolov: >>>>>> >>>>>> Hi Martin, >>>>>> >>>>>> First check what went wrong with the VG -as it could be something simple. >>>>>> vgcfgbackup -f VGname will create a file which you can use to compare current metadata with a previous version. >>>>>> >>>>>> If you have Linux boxes - you can add disks from another storage an

1 0

Re: Storage domain 'Inactive' but still functional
by Martijn Grendelman 24 Jul '19

24 Jul '19

Op 24-7-2019 om 10:07 schreef Benny Zlotnik: We have seen something similar in the past and patches were posted to deal with this issue, but it's still in progress[1] [1] https://bugzilla.redhat.com/show_bug.cgi?id=1553133 That's some interesting reading, and it sure looks like the problem I had. Thanks! Best regards, Martijn. On Mon, Jul 22, 2019 at 8:07 PM Strahil <hunter86_bg(a)yahoo.com<mailto:hunter86_bg@yahoo.com>> wrote: I have a theory... But after all without any proof it will remain theory. The storage volumes are just VGs over a shared storage.The SPM host is supposed to be the only one that is working with the LVM metadata, but I have observed that when someone is executing a simple LVM command (for example -lvs, vgs or pvs ) while another one is going on on another host - your metadata can corrupt, due to lack of clvmd. As a protection, I could offer you to try the following solution: 1. Create new iSCSI lun 2. Share it to all nodes and create the storage domain. Set it to maintenance. 3. Start dlm & clvmd services on all hosts 4. Convert the VG of your shared storage domain to have a 'cluster'-ed flag: vgchange -c y mynewVG 5. Check the lvs of that VG. 6. Activate the storage domain. Of course test it on a test cluster before inplementing it on Prod. This is one of the approaches used in Linux HA clusters in order to avoid LVM metadata corruption. Best Regards, Strahil Nikolov On Jul 22, 2019 15:46, Martijn Grendelman <Martijn.Grendelman(a)isaac.nl<mailto:Martijn.Grendelman@isaac.nl>> wrote: Hi, Op 22-7-2019 om 14:30 schreef Strahil: If you can give directions (some kind of history) , the dev might try to reproduce this type of issue. If it is reproduceable - a fix can be provided. Based on my experience, if something as used as Linux LVM gets broken, the case is way hard to reproduce. Yes, I'd think so too, especially since this activity (online moving of disk images) is done all the time, mostly without problems. In this case, there was a lot of activity on all storage domains, because I'm moving all my storage (> 10TB in 185 disk images) to a new storage platform. During the online move of one the images, the metadata checksum became corrupted and the storage domain went offline. Of course, I could dig up the engine logs and vdsm logs of when it happened, but that would be some work and I'm not very confident that the actual cause would be in there. If any oVirt devs are interested in the logs, I'll provide them, but otherwise I think I'll just see it as an incident and move on. Best regards, Martijn. On Jul 22, 2019 10:17, Martijn Grendelman <Martijn.Grendelman(a)isaac.nl><mailto:Martijn.Grendelman@isaac.nl> wrote: Hi, Thanks for the tips! I didn't know about 'pvmove', thanks. In the mean time, I managed to get it fixed by restoring the VG metadata on the iSCSI server, so on the underlying Zvol directly, rather than via the iSCSI session on the oVirt host. That allowed me to perform the restore without bringing all VMs down, which was important to me, because if I had to shut down VMs, I was sure I wouldn't be able to restart them before the storage domain was back online. Of course this is a more a Linux problem than an oVirt problem, but oVirt did cause it ;-) Thanks, Martijn. Op 19-7-2019 om 19:06 schreef Strahil Nikolov: Hi Martin, First check what went wrong with the VG -as it could be something simple. vgcfgbackup -f VGname will create a file which you can use to compare current metadata with a previous version. If you have Linux boxes - you can add disks from another storage and then pvmove the data inside the VM. Of course , you will need to reinstall grub on the new OS disk , or you won't be able to boot afterwards. If possible, try with a test VM before proceeding with important ones. Backing up the VMs is very important , because working on LVM metada _______________________________________________ Users mailing list -- users(a)ovirt.org<mailto:users@ovirt.org> To unsubscribe send an email to users-leave(a)ovirt.org<mailto:users-leave@ovirt.org> Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/37UDAWDXON3UR… -- Met vriendelijke groet, Kind regards, [Martijn]<mailto:martijn.grendelman@isaac.nl> Martijn Grendelman Infrastructure Architect T: +31 (0)40 264 94 44 [ISAAC]<https://www.isaac.nl> ISAAC Marconilaan 16 5621 AA Eindhoven The Netherlands T: +31 (0)40 290 89 79 www.isaac.nl<https://www.isaac.nl> [ISAAC #1 Again!]<https://www.isaac.nl/nl/over-ons/nieuws/isaac-news/ISAAC-voor-tweede-keer-n…> Dit e-mail bericht is alleen bestemd voor de geadresseerde(n). Indien dit bericht niet voor u is bedoeld wordt u verzocht de afzender hiervan op de hoogte te stellen door het bericht te retourneren en de inhoud niet te gebruiken. Aan dit bericht kunnen geen rechten worden ontleend.

1 0

Re: Storage domain 'Inactive' but still functional
by Strahil 24 Jul '19

24 Jul '19

I have a theory... But after all without any proof it will remain theory. The storage volumes are just VGs over a shared storage.The SPM host is supposed to be the only one that is working with the LVM metadata, but I have observed that when someone is executing a simple LVM command (for example -lvs, vgs or pvs ) while another one is going on on another host - your metadata can corrupt, due to lack of clvmd. As a protection, I could offer you to try the following solution: 1. Create new iSCSI lun 2. Share it to all nodes and create the storage domain. Set it to maintenance. 3. Start dlm & clvmd services on all hosts 4. Convert the VG of your shared storage domain to have a 'cluster'-ed flag: vgchange -c y mynewVG 5. Check the lvs of that VG. 6. Activate the storage domain. Of course test it on a test cluster before inplementing it on Prod. This is one of the approaches used in Linux HA clusters in order to avoid LVM metadata corruption. Best Regards, Strahil NikolovOn Jul 22, 2019 15:46, Martijn Grendelman <Martijn.Grendelman(a)isaac.nl> wrote: > > Hi, > > Op 22-7-2019 om 14:30 schreef Strahil: >> >> If you can give directions (some kind of history) , the dev might try to reproduce this type of issue. >> >> If it is reproduceable - a fix can be provided. >> >> Based on my experience, if something as used as Linux LVM gets broken, the case is way hard to reproduce. > > > Yes, I'd think so too, especially since this activity (online moving of disk images) is done all the time, mostly without problems. In this case, there was a lot of activity on all storage domains, because I'm moving all my storage (> 10TB in 185 disk images) to a new storage platform. During the online move of one the images, the metadata checksum became corrupted and the storage domain went offline. > > Of course, I could dig up the engine logs and vdsm logs of when it happened, but that would be some work and I'm not very confident that the actual cause would be in there. > > If any oVirt devs are interested in the logs, I'll provide them, but otherwise I think I'll just see it as an incident and move on. > > Best regards, > Martijn. > > > > > On Jul 22, 2019 10:17, Martijn Grendelman <Martijn.Grendelman(a)isaac.nl> wrote: >>> >>> Hi, >>> >>> Thanks for the tips! I didn't know about 'pvmove', thanks. >>> >>> In the mean time, I managed to get it fixed by restoring the VG metadata on the iSCSI server, so on the underlying Zvol directly, rather than via the iSCSI session on the oVirt host. That allowed me to perform the restore without bringing all VMs down, which was important to me, because if I had to shut down VMs, I was sure I wouldn't be able to restart them before the storage domain was back online. >>> >>> Of course this is a more a Linux problem than an oVirt problem, but oVirt did cause it ;-) >>> >>> Thanks, >>> Martijn. >>> >>> >>> >>> Op 19-7-2019 om 19:06 schreef Strahil Nikolov: >>>> >>>> Hi Martin, >>>> >>>> First check what went wrong with the VG -as it could be something simple. >>>> vgcfgbackup -f VGname will create a file which you can use to compare current metadata with a previous version. >>>> >>>> If you have Linux boxes - you can add disks from another storage and then pvmove the data inside the VM. Of course , you will need to reinstall grub on the new OS disk , or you won't be able to boot afterwards. >>>> If possible, try with a test VM before proceeding with important ones. >>>> >>>> Backing up the VMs is very important , because working on LVM metada

2 1

USB turns off and wont come alive
by Darin Schmidt 24 Jul '19

24 Jul '19

I have 2 usb controllers installed via a riser card plugged into a M.2 slot. (Like those used for mining with GPU's). Everything works great for a long time, then my Windows 10 VM freezes and I lose all USB activity. LSPCI still sees the devices: 0a:00.0 USB controller: ASMedia Technology Inc. ASM1142 USB 3.1 Host Controller 0b:00.0 USB controller: ASMedia Technology Inc. ASM1142 USB 3.1 Host Controller 43:00.0 USB controller: ASMedia Technology Inc. ASM1142 USB 3.1 Host Controller 44:00.0 USB controller: ASMedia Technology Inc. ASM1142 USB 3.1 Host Controller I assume a and b are the same physical card as its supposed to have 2 channels each, same with 44 and 43. I tried for both 44 and 43 echo "1" > /sys/bus/pci/devices/0000\:43\:00.0/remove echo "1" > /sys/bus/pci/rescan echo "1" > /sys/bus/pci/devices/0000\:43\:00.0/reset This did not work. I cannot determine if its just the VM thats no longer seeing/using the hardware or if its the hardware itself. I wonder if its a power state thing as well? Nothing I plug into the card seems to be recognized. Any Suggestions? rebooting the VM doesnt help either. It appears the hardware is functioning, but anything you plug into it isnt being detected.

2 1

Import VM from ovirt-exported ova
by david.paning＠gmx.ch 24 Jul '19

24 Jul '19

Hello, i installed a new oVirt 4.3.4 from scratch and am attempting to restore the VMs which ran perfectly fine on my last oVirt 4.2.8, where i exported the VM to the export domain and also as an OVA file. Importing the export domain fails, which i plan to debug later. But importing the OVA file via the Administration Portal also fails with Error ID: 1153 Message: Failed to import the VM to Data Center, Cluster. The VM name is still recognised by the import routine, which tells me the file is readable... Now my questions: Is there any option to try the same from CLI, hoping to get better clues for what is going on? Are there specific log options which could give some clues? Would it be better in general to import the VM from an export-storage domain instead of using a OVA export? Any hint would highly appreciated. Best

3 2