Re: [ovirt-users] oVirt 4.2.1 rc1 and upload iso to data domain test
Hi, I will look into it. Is it also not working also for non-iso images? Thanks, Fred On Jan 14, 2018 8:16 PM, "Gianluca Cecchi" wrote: > Hello, > I see in release notes this > > BZ 1530730 [downstream clone - 4.2.1] [RFE] Allow uploading ISO images to > data domains and using them in VMs > It is now possible to upload an ISO file to a data domain and attach it to > a VM as a CDROM device. > In order to do so the user has to upload an ISO file via the UI (which > will recognize the ISO by it's header and will upload it as ISO) or via the > APIs in which case the request should define the disk container > "content_type" property as "iso" before the upload. > Once the ISO exists on an active storage domain in the data center it will > be possible to attach it to a VM as a CDROM device either through the "Edit > VM" dialog or through the APIs (see example in comment #27 > > So I'm trying it on an HCI Gluster environment of mine for testing. > I get this in image-proxy.log > > (Thread-39 ) INFO 2018-01-14 18:35:38,066 web:95:web:(log_start) START > [192.168.150.101] PUT /images/0d852f7a-b19e-447d-82ad-966755070701 > (Thread-39 ) WARNING 2018-01-14 18:35:38,067 web:112:web:(log_error) ERROR > [192.168.150.101] PUT /images/0d852f7a-b19e-447d-82ad-966755070701: [401] > Not authorized (0.00s) > (Thread-40 ) INFO 2018-01-14 18:35:38,106 web:95:web:(log_start) START > [192.168.150.101] PUT /images/0d852f7a-b19e-447d-82ad-966755070701 > (Thread-40 ) WARNING 2018-01-14 18:35:38,106 web:112:web:(log_error) ERROR > [192.168.150.101] PUT /images/0d852f7a-b19e-447d-82ad-966755070701: [401] > Not authorized (0.00s) > > > Does this mean the functionality is not completely ready yet or what? > Any one has already tried on iSCSI and/or FC? > > Thanks, > Gianluca > > > ___ > Users mailing list > Users@ovirt.org > http://lists.ovirt.org/mailman/listinfo/users > > ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [ovirt-users] Shutdown all VM's command line
Hey, thanks for sending this to me. Works like a charm. I have this tied in with a UPS script that monitors the UPS on another system, and fires off your script before a shutdown command. Works pretty well so far! I am using the default certificates. Took me a second to find out where they are stored, but after pointing directly to it, everything is working like a champ. Thanks! On Thu, Jan 11, 2018 at 6:47 AM, Giorgio Biacchi wrote: > On 01/11/2018 11:44 AM, Kapetanakis Giannis wrote: > >> On 10/01/18 22:11, Wesley Stewart wrote: >> >>> Marcelo, >>> >>> I would greatly appreciate seeing a script! It would be an excellent >>> chance for me to learn a bit about using ovirt from the command line as >>> well! >>> >> >> I'm using something like this with ovirt-shell >> >> vm_shutdown: >> #!/bin/sh >> LOG=/root/ovirt/vm_shutdown_log >> echo `date` >> $LOG >> /usr/bin/ovirt-shell -f /root/ovirt/vm_shutdown_script >> $LOG >> echo "" >> $LOG >> >> vm_shutdown_script: >> list vms --kwargs status-state=up|grep name | sed s/'name >> :'/'action vm'/ | sed -e 's/$/ shutdown/' > /root/ovirt/new_vm_shutdown_sc >> ript >> file /root/ovirt/new_vm_shutdown_script >> >> new_vm_shutdown_script now lists entries like this: >> action vm vm1 shutdown >> action vm vm2 shutdown >> etc. >> >> G >> >> >> ___ >> Users mailing list >> Users@ovirt.org >> http://lists.ovirt.org/mailman/listinfo/users >> >> > You can use python SDK. > > Somthing like this should work > > #!/usr/bin/env python > > import ovirtsdk4 as sdk > > ovaddress = "" > username="admin@internal" > password="*" > > connection = sdk.Connection( > url=ovaddress, > username=username, > password=password, > ca_file='ca.crt', > insecure=True > ) > > system_service = connection.system_service() > vms_service = system_service.vms_service() > vms = vms_service.list() > > for vm in vms: > vm_service = vms_service.vm_service(vm.id) > vm_service.shutdown() > > connection.close() > > -- > gb > > PGP Key: http://pgp.mit.edu/ > Primary key fingerprint: C510 0765 943E EBED A4F2 69D3 16CC DC90 B9CB 0F34 > > ___ > Users mailing list > Users@ovirt.org > http://lists.ovirt.org/mailman/listinfo/users > ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [ovirt-users] Are Ovirt updates nessessary after CVE-2017-5754 CVE-2017-5753 CVE-2017-5715
Thanks. I guess that means I need to upgrade both OS and Ovirt simultaneously. And if I recall correctly I need to upgrade my hosted engine first and then upgrade the host? (This is a single-host hosted-engine setup). I've never actually upgraded an ovirt release beyond point releases (I started with 4.0, and currently run 4.0.6). I did upgrade from 7.2 to 7.3, which was relatively straightforward. My plan is to follow the instructions at https://www.ovirt.org/release/4.1.0/ -- will the engine-setup also wind up pulling in the OS update? I suppose I can run a yum update after running engine-setup? Thanks, -derek On Mon, January 15, 2018 1:10 pm, Yaniv Kaul wrote: > On Mon, Jan 15, 2018 at 6:28 PM, Derek Atkins wrote: > >> Thanks. >> >> I guess it still boils down to updating to 7.4. :( >> >> In the short term, will Ovirt 4.0 continue to run in 7.4? Or MUST I >> > > We don't know, but I would assume NO. Every minor release of EL required > some small adjustments to expected and unexpected changes in the platform. > We have worked with 4.1 to support 7.3 and then 7.4, I would not presume > 4.0 works with it. > Y. > > >> upgrade both the OS and ovirt simultaneously? My time is very short >> over >> the next few weeks (I'm moving) so I'd like to get as much bang for the >> buck with as little down time as possible. I can't spend 12 hours of my >> time working to repair a botched upgrade from 4.0 to 4.1 or 4.2. >> >> Thanks again! >> >> -derek >> >> On Mon, January 15, 2018 11:05 am, Arman Khalatyan wrote: >> > If you see that after the update of your OS dmesg shows RED alert in >> > the spectra check script in the second position then you should follow >> > the intel's read.me. >> > As in readme described on Centos 7.4: >> > rsync -Pa intel-ucode /lib/firmware/ >> > On the recent kernels(>2.6.xx) the dd method does not work, dont do >> that. >> > To confirm that microcode loaded: >> > dmesg | grep micro >> > look for the release dates. >> > But I beleve that v4 should be already in the microcode_ctl package of >> > the CentOS7.4 ( in my case 2650v2 was not inside, but the v3 and v4 >> > were there) >> > I have a script to enable or disable the protection so you can see the >> > performance impact on your case: >> > https://arm2armcos.blogspot.de/2018/01/lustrefs-big- >> performance-hit-on-lfs.html >> > >> > >> > >> > On Mon, Jan 15, 2018 at 4:28 PM, Derek Atkins wrote: >> >> Arman, >> >> >> >> Thanks for the info... And sorry for taking so long to reply. It's >> >> been a busy weekend. >> >> >> >> First, thank you for the links. Useful information. >> >> >> >> However, could you define "recent"? My system is from Q3 2016. Is >> that >> >> considered recent enough to not need a bios updte? >> >> >> >> My /proc/cpuinfo reports: >> >> model name : Intel(R) Xeon(R) CPU E5-2620 v4 @ 2.10GHz >> >> >> >> I downloaded the microcode.tgz file, which is dated Jan 8. I noticed >> >> that the microcode_ctl package in my repo is dated Jan 4, which >> implies >> >> it probably does NOT contain the Jan 8 tgz from Intel. It LOOKS like >> I >> >> can just replace the intel-ucode files with those from the tgz, but >> I'm >> >> not sure what, if anything, I need to do with the microcode.dat file >> in >> >> the tgz? >> >> >> >> Thanks, >> >> >> >> -derek >> >> >> >> Arman Khalatyan writes: >> >> >> >>> if you have recent supermicro you dont need to update the bios, >> >>> >> >>> Some tests: >> >>> Crack test: >> >>> https://github.com/IAIK/meltdown >> >>> >> >>> Check test: >> >>> https://github.com/speed47/spectre-meltdown-checker >> >>> >> >>> the intel microcodes you can find here: >> >>> https://downloadcenter.intel.com/download/27431/Linux- >> Processor-Microcode-Data-File?product=41447 >> >>> good luck. >> >>> Arman. >> >>> >> >>> >> >>> >> >>> On Thu, Jan 11, 2018 at 4:32 PM, Derek Atkins >> wrote: >> Hi, >> >> On Thu, January 11, 2018 9:53 am, Yaniv Kaul wrote: >> >> > No one likes downtime but I suspect this is one of those serious >> > vulnerabilities that you really really must be protected against. >> > That being said, before planning downtime, check your HW vendor >> for >> > firmware or Intel for microcode for the host first. >> > Without it, there's not a lot of protection anyway. >> > Note that there are 4 steps you need to take to be fully >> protected: >> > CPU, >> > hypervisor, guests and guest CPU type - plan ahead! >> > Y. >> >> Is there a HOW-To written up somewhere on this? ;) >> >> I built the hardware from scratch myself, so I can't go off to Dell >> or >> someone for this. So which do I need, motherboard firmware or >> Intel >> microcode? I suppose I need to go to the motherboard manufacturer >> (Supermicro) to look for updated firmware? Do I also need to look >> at >> Intel? Is this either-or or a "both" situation? Of course I have >> no >> idea >> how to refl
Re: [ovirt-users] Are Ovirt updates nessessary after CVE-2017-5754 CVE-2017-5753 CVE-2017-5715
On Mon, Jan 15, 2018 at 6:28 PM, Derek Atkins wrote: > Thanks. > > I guess it still boils down to updating to 7.4. :( > > In the short term, will Ovirt 4.0 continue to run in 7.4? Or MUST I > We don't know, but I would assume NO. Every minor release of EL required some small adjustments to expected and unexpected changes in the platform. We have worked with 4.1 to support 7.3 and then 7.4, I would not presume 4.0 works with it. Y. > upgrade both the OS and ovirt simultaneously? My time is very short over > the next few weeks (I'm moving) so I'd like to get as much bang for the > buck with as little down time as possible. I can't spend 12 hours of my > time working to repair a botched upgrade from 4.0 to 4.1 or 4.2. > > Thanks again! > > -derek > > On Mon, January 15, 2018 11:05 am, Arman Khalatyan wrote: > > If you see that after the update of your OS dmesg shows RED alert in > > the spectra check script in the second position then you should follow > > the intel's read.me. > > As in readme described on Centos 7.4: > > rsync -Pa intel-ucode /lib/firmware/ > > On the recent kernels(>2.6.xx) the dd method does not work, dont do that. > > To confirm that microcode loaded: > > dmesg | grep micro > > look for the release dates. > > But I beleve that v4 should be already in the microcode_ctl package of > > the CentOS7.4 ( in my case 2650v2 was not inside, but the v3 and v4 > > were there) > > I have a script to enable or disable the protection so you can see the > > performance impact on your case: > > https://arm2armcos.blogspot.de/2018/01/lustrefs-big- > performance-hit-on-lfs.html > > > > > > > > On Mon, Jan 15, 2018 at 4:28 PM, Derek Atkins wrote: > >> Arman, > >> > >> Thanks for the info... And sorry for taking so long to reply. It's > >> been a busy weekend. > >> > >> First, thank you for the links. Useful information. > >> > >> However, could you define "recent"? My system is from Q3 2016. Is that > >> considered recent enough to not need a bios updte? > >> > >> My /proc/cpuinfo reports: > >> model name : Intel(R) Xeon(R) CPU E5-2620 v4 @ 2.10GHz > >> > >> I downloaded the microcode.tgz file, which is dated Jan 8. I noticed > >> that the microcode_ctl package in my repo is dated Jan 4, which implies > >> it probably does NOT contain the Jan 8 tgz from Intel. It LOOKS like I > >> can just replace the intel-ucode files with those from the tgz, but I'm > >> not sure what, if anything, I need to do with the microcode.dat file in > >> the tgz? > >> > >> Thanks, > >> > >> -derek > >> > >> Arman Khalatyan writes: > >> > >>> if you have recent supermicro you dont need to update the bios, > >>> > >>> Some tests: > >>> Crack test: > >>> https://github.com/IAIK/meltdown > >>> > >>> Check test: > >>> https://github.com/speed47/spectre-meltdown-checker > >>> > >>> the intel microcodes you can find here: > >>> https://downloadcenter.intel.com/download/27431/Linux- > Processor-Microcode-Data-File?product=41447 > >>> good luck. > >>> Arman. > >>> > >>> > >>> > >>> On Thu, Jan 11, 2018 at 4:32 PM, Derek Atkins wrote: > Hi, > > On Thu, January 11, 2018 9:53 am, Yaniv Kaul wrote: > > > No one likes downtime but I suspect this is one of those serious > > vulnerabilities that you really really must be protected against. > > That being said, before planning downtime, check your HW vendor for > > firmware or Intel for microcode for the host first. > > Without it, there's not a lot of protection anyway. > > Note that there are 4 steps you need to take to be fully protected: > > CPU, > > hypervisor, guests and guest CPU type - plan ahead! > > Y. > > Is there a HOW-To written up somewhere on this? ;) > > I built the hardware from scratch myself, so I can't go off to Dell or > someone for this. So which do I need, motherboard firmware or Intel > microcode? I suppose I need to go to the motherboard manufacturer > (Supermicro) to look for updated firmware? Do I also need to look at > Intel? Is this either-or or a "both" situation? Of course I have no > idea > how to reflash new firmware onto this motherboard -- I don't have DOS. > > As you can see, planning I can do. Execution is more challenging ;) > > Thanks! > > >> > Y. > > -derek > > -- > Derek Atkins 617-623-3745 > de...@ihtfp.com www.ihtfp.com > Computer and Internet Security Consultant > > ___ > Users mailing list > Users@ovirt.org > http://lists.ovirt.org/mailman/listinfo/users > >>> > >>> > >> > >> -- > >>Derek Atkins 617-623-3745 > >>de...@ihtfp.com www.ihtfp.com > >>Computer and Internet Security Consultant > > > > > -- >Derek Atkins 617-623-3745 >de...@ihtfp.com
[ovirt-users] ovirt-guest-agent on atomic ?
Hi all, I didn't find any working ovirt-guest-agent for atomic7, and it is a requirement for launching atomic from vagrant-ovirt4 plugin. I tried installing ovirt-guest-agent inside, I tried installing ovirtguestagent/centos7-atomic, but I had no success Does any official project exist for it? -- Nathanaël Blanchet Supervision réseau Pôle Infrastrutures Informatiques 227 avenue Professeur-Jean-Louis-Viala 34193 MONTPELLIER CEDEX 5 Tél. 33 (0)4 67 54 84 55 Fax 33 (0)4 67 54 84 14 blanc...@abes.fr ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [ovirt-users] Are Ovirt updates nessessary after CVE-2017-5754 CVE-2017-5753 CVE-2017-5715
Thanks. I guess it still boils down to updating to 7.4. :( In the short term, will Ovirt 4.0 continue to run in 7.4? Or MUST I upgrade both the OS and ovirt simultaneously? My time is very short over the next few weeks (I'm moving) so I'd like to get as much bang for the buck with as little down time as possible. I can't spend 12 hours of my time working to repair a botched upgrade from 4.0 to 4.1 or 4.2. Thanks again! -derek On Mon, January 15, 2018 11:05 am, Arman Khalatyan wrote: > If you see that after the update of your OS dmesg shows RED alert in > the spectra check script in the second position then you should follow > the intel's read.me. > As in readme described on Centos 7.4: > rsync -Pa intel-ucode /lib/firmware/ > On the recent kernels(>2.6.xx) the dd method does not work, dont do that. > To confirm that microcode loaded: > dmesg | grep micro > look for the release dates. > But I beleve that v4 should be already in the microcode_ctl package of > the CentOS7.4 ( in my case 2650v2 was not inside, but the v3 and v4 > were there) > I have a script to enable or disable the protection so you can see the > performance impact on your case: > https://arm2armcos.blogspot.de/2018/01/lustrefs-big-performance-hit-on-lfs.html > > > > On Mon, Jan 15, 2018 at 4:28 PM, Derek Atkins wrote: >> Arman, >> >> Thanks for the info... And sorry for taking so long to reply. It's >> been a busy weekend. >> >> First, thank you for the links. Useful information. >> >> However, could you define "recent"? My system is from Q3 2016. Is that >> considered recent enough to not need a bios updte? >> >> My /proc/cpuinfo reports: >> model name : Intel(R) Xeon(R) CPU E5-2620 v4 @ 2.10GHz >> >> I downloaded the microcode.tgz file, which is dated Jan 8. I noticed >> that the microcode_ctl package in my repo is dated Jan 4, which implies >> it probably does NOT contain the Jan 8 tgz from Intel. It LOOKS like I >> can just replace the intel-ucode files with those from the tgz, but I'm >> not sure what, if anything, I need to do with the microcode.dat file in >> the tgz? >> >> Thanks, >> >> -derek >> >> Arman Khalatyan writes: >> >>> if you have recent supermicro you dont need to update the bios, >>> >>> Some tests: >>> Crack test: >>> https://github.com/IAIK/meltdown >>> >>> Check test: >>> https://github.com/speed47/spectre-meltdown-checker >>> >>> the intel microcodes you can find here: >>> https://downloadcenter.intel.com/download/27431/Linux-Processor-Microcode-Data-File?product=41447 >>> good luck. >>> Arman. >>> >>> >>> >>> On Thu, Jan 11, 2018 at 4:32 PM, Derek Atkins wrote: Hi, On Thu, January 11, 2018 9:53 am, Yaniv Kaul wrote: > No one likes downtime but I suspect this is one of those serious > vulnerabilities that you really really must be protected against. > That being said, before planning downtime, check your HW vendor for > firmware or Intel for microcode for the host first. > Without it, there's not a lot of protection anyway. > Note that there are 4 steps you need to take to be fully protected: > CPU, > hypervisor, guests and guest CPU type - plan ahead! > Y. Is there a HOW-To written up somewhere on this? ;) I built the hardware from scratch myself, so I can't go off to Dell or someone for this. So which do I need, motherboard firmware or Intel microcode? I suppose I need to go to the motherboard manufacturer (Supermicro) to look for updated firmware? Do I also need to look at Intel? Is this either-or or a "both" situation? Of course I have no idea how to reflash new firmware onto this motherboard -- I don't have DOS. As you can see, planning I can do. Execution is more challenging ;) Thanks! >> > Y. -derek -- Derek Atkins 617-623-3745 de...@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users >>> >>> >> >> -- >>Derek Atkins 617-623-3745 >>de...@ihtfp.com www.ihtfp.com >>Computer and Internet Security Consultant > -- Derek Atkins 617-623-3745 de...@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [ovirt-users] Are Ovirt updates nessessary after CVE-2017-5754 CVE-2017-5753 CVE-2017-5715
If you see that after the update of your OS dmesg shows RED alert in the spectra check script in the second position then you should follow the intel's read.me. As in readme described on Centos 7.4: rsync -Pa intel-ucode /lib/firmware/ On the recent kernels(>2.6.xx) the dd method does not work, dont do that. To confirm that microcode loaded: dmesg | grep micro look for the release dates. But I beleve that v4 should be already in the microcode_ctl package of the CentOS7.4 ( in my case 2650v2 was not inside, but the v3 and v4 were there) I have a script to enable or disable the protection so you can see the performance impact on your case: https://arm2armcos.blogspot.de/2018/01/lustrefs-big-performance-hit-on-lfs.html On Mon, Jan 15, 2018 at 4:28 PM, Derek Atkins wrote: > Arman, > > Thanks for the info... And sorry for taking so long to reply. It's > been a busy weekend. > > First, thank you for the links. Useful information. > > However, could you define "recent"? My system is from Q3 2016. Is that > considered recent enough to not need a bios updte? > > My /proc/cpuinfo reports: > model name : Intel(R) Xeon(R) CPU E5-2620 v4 @ 2.10GHz > > I downloaded the microcode.tgz file, which is dated Jan 8. I noticed > that the microcode_ctl package in my repo is dated Jan 4, which implies > it probably does NOT contain the Jan 8 tgz from Intel. It LOOKS like I > can just replace the intel-ucode files with those from the tgz, but I'm > not sure what, if anything, I need to do with the microcode.dat file in > the tgz? > > Thanks, > > -derek > > Arman Khalatyan writes: > >> if you have recent supermicro you dont need to update the bios, >> >> Some tests: >> Crack test: >> https://github.com/IAIK/meltdown >> >> Check test: >> https://github.com/speed47/spectre-meltdown-checker >> >> the intel microcodes you can find here: >> https://downloadcenter.intel.com/download/27431/Linux-Processor-Microcode-Data-File?product=41447 >> good luck. >> Arman. >> >> >> >> On Thu, Jan 11, 2018 at 4:32 PM, Derek Atkins wrote: >>> Hi, >>> >>> On Thu, January 11, 2018 9:53 am, Yaniv Kaul wrote: >>> No one likes downtime but I suspect this is one of those serious vulnerabilities that you really really must be protected against. That being said, before planning downtime, check your HW vendor for firmware or Intel for microcode for the host first. Without it, there's not a lot of protection anyway. Note that there are 4 steps you need to take to be fully protected: CPU, hypervisor, guests and guest CPU type - plan ahead! Y. >>> >>> Is there a HOW-To written up somewhere on this? ;) >>> >>> I built the hardware from scratch myself, so I can't go off to Dell or >>> someone for this. So which do I need, motherboard firmware or Intel >>> microcode? I suppose I need to go to the motherboard manufacturer >>> (Supermicro) to look for updated firmware? Do I also need to look at >>> Intel? Is this either-or or a "both" situation? Of course I have no idea >>> how to reflash new firmware onto this motherboard -- I don't have DOS. >>> >>> As you can see, planning I can do. Execution is more challenging ;) >>> >>> Thanks! >>> > > Y. >>> >>> -derek >>> >>> -- >>>Derek Atkins 617-623-3745 >>>de...@ihtfp.com www.ihtfp.com >>>Computer and Internet Security Consultant >>> >>> ___ >>> Users mailing list >>> Users@ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/users >> >> > > -- >Derek Atkins 617-623-3745 >de...@ihtfp.com www.ihtfp.com >Computer and Internet Security Consultant ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [ovirt-users] Are Ovirt updates nessessary after CVE-2017-5754 CVE-2017-5753 CVE-2017-5715
Arman, Thanks for the info... And sorry for taking so long to reply. It's been a busy weekend. First, thank you for the links. Useful information. However, could you define "recent"? My system is from Q3 2016. Is that considered recent enough to not need a bios updte? My /proc/cpuinfo reports: model name : Intel(R) Xeon(R) CPU E5-2620 v4 @ 2.10GHz I downloaded the microcode.tgz file, which is dated Jan 8. I noticed that the microcode_ctl package in my repo is dated Jan 4, which implies it probably does NOT contain the Jan 8 tgz from Intel. It LOOKS like I can just replace the intel-ucode files with those from the tgz, but I'm not sure what, if anything, I need to do with the microcode.dat file in the tgz? Thanks, -derek Arman Khalatyan writes: > if you have recent supermicro you dont need to update the bios, > > Some tests: > Crack test: > https://github.com/IAIK/meltdown > > Check test: > https://github.com/speed47/spectre-meltdown-checker > > the intel microcodes you can find here: > https://downloadcenter.intel.com/download/27431/Linux-Processor-Microcode-Data-File?product=41447 > good luck. > Arman. > > > > On Thu, Jan 11, 2018 at 4:32 PM, Derek Atkins wrote: >> Hi, >> >> On Thu, January 11, 2018 9:53 am, Yaniv Kaul wrote: >> >>> No one likes downtime but I suspect this is one of those serious >>> vulnerabilities that you really really must be protected against. >>> That being said, before planning downtime, check your HW vendor for >>> firmware or Intel for microcode for the host first. >>> Without it, there's not a lot of protection anyway. >>> Note that there are 4 steps you need to take to be fully protected: CPU, >>> hypervisor, guests and guest CPU type - plan ahead! >>> Y. >> >> Is there a HOW-To written up somewhere on this? ;) >> >> I built the hardware from scratch myself, so I can't go off to Dell or >> someone for this. So which do I need, motherboard firmware or Intel >> microcode? I suppose I need to go to the motherboard manufacturer >> (Supermicro) to look for updated firmware? Do I also need to look at >> Intel? Is this either-or or a "both" situation? Of course I have no idea >> how to reflash new firmware onto this motherboard -- I don't have DOS. >> >> As you can see, planning I can do. Execution is more challenging ;) >> >> Thanks! >> > Y. >> >> -derek >> >> -- >>Derek Atkins 617-623-3745 >>de...@ihtfp.com www.ihtfp.com >>Computer and Internet Security Consultant >> >> ___ >> Users mailing list >> Users@ovirt.org >> http://lists.ovirt.org/mailman/listinfo/users > > -- Derek Atkins 617-623-3745 de...@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [ovirt-users] hosted-engine unknow stale-data
Hello, I have uploaded 2 archives with all relevant logs to shared hosting files from host 1 (which is currently running all VM's including hosted_engine) - https://yadi.sk/d/PttRoYV63RTvhK files from second host - https://yadi.sk/d/UBducEsV3RTvhc I have tried to restart both ovirt-ha-agent and ovirt-ha-broker but it gives no effect. I have also tried to shutdown hosted_engine VM, stop ovirt-ha-agent and ovirt-ha-broker services disconnect storage and connect it again - no effect as well. Also I tried to reinstall second host from WebGUI - this lead to the interesting situation - now hosted-engine --vm-status shows that both hosts have the same address. [root@ovirt1 ~]# hosted-engine --vm-status --== Host 1 status ==-- conf_on_shared_storage : True Status up-to-date : True Hostname : ovirt1.telia.ru Host ID: 1 Engine status : {"health": "good", "vm": "up", "detail": "up"} Score : 3400 stopped: False Local maintenance : False crc32 : a7758085 local_conf_timestamp : 259327 Host timestamp : 259327 Extra metadata (valid at timestamp): metadata_parse_version=1 metadata_feature_version=1 timestamp=259327 (Mon Jan 15 14:06:48 2018) host-id=1 score=3400 vm_conf_refresh_time=259327 (Mon Jan 15 14:06:48 2018) conf_on_shared_storage=True maintenance=False state=EngineUp stopped=False --== Host 2 status ==-- conf_on_shared_storage : True Status up-to-date : False Hostname : ovirt1.telia.ru Host ID: 2 Engine status : unknown stale-data Score : 0 stopped: True Local maintenance : False crc32 : c7037c03 local_conf_timestamp : 7530 Host timestamp : 7530 Extra metadata (valid at timestamp): metadata_parse_version=1 metadata_feature_version=1 timestamp=7530 (Fri Jan 12 16:10:12 2018) host-id=2 score=0 vm_conf_refresh_time=7530 (Fri Jan 12 16:10:12 2018) conf_on_shared_storage=True maintenance=False state=AgentStopped stopped=True Gluster seems working fine. all gluster nodes showing connected state. Any advises on how to resolve this situation are highly appreciated! Regards, Artem On Mon, Jan 15, 2018 at 11:45 AM, Kasturi Narra wrote: > Hello Artem, > > Can you check if glusterd service is running on host1 and all the > peers are in connected state ? If yes, can you restart ovirt-ha-agent and > broker services and check if things are working fine ? > > Thanks > kasturi > > On Sat, Jan 13, 2018 at 12:33 AM, Artem Tambovskiy < > artem.tambovs...@gmail.com> wrote: > >> Explored logs on both hosts. >> broker.log shows no errors. >> >> agent.log looking not good: >> >> on host1 (which running hosted engine) : >> >> MainThread::ERROR::2018-01-12 21:51:03,883::agent::205::ovir >> t_hosted_engine_ha.agent.agent.Agent::(_run_agent) Traceback (most >> recent call last): >> File >> "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/agent/agent.py", >> line 191, in _run_agent >> return action(he) >> File >> "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/agent/agent.py", >> line 64, in action_proper >> return he.start_monitoring() >> File >> "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/agent/hosted_engine.py", >> line 411, in start_monitoring >> self._initialize_sanlock() >> File >> "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/agent/hosted_engine.py", >> line 749, in _initialize_sanlock >> "Failed to initialize sanlock, the number of errors has" >> SanlockInitializationError: Failed to initialize sanlock, the number of >> errors has exceeded the limit >> >> MainThread::ERROR::2018-01-12 21:51:03,884::agent::206::ovir >> t_hosted_engine_ha.agent.agent.Agent::(_run_agent) Trying to restart >> agent >> MainThread::WARNING::2018-01-12 21:51:08,889::agent::209::ovir >> t_hosted_engine_ha.agent.agent.Agent::(_run_agent) Restarting agent, >> attempt '1' >> MainThread::INFO::2018-01-12 21:51:08,919::hosted_engine::2 >> 42::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(_get_hostname) >> Found certificate common name: ovirt1.telia.ru >> MainThread::INFO::2018-01-12 21:51:08,921::hosted_engine::6 >> 04::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(_initialize_vdsm) >> Initializing VDSM >> MainThread::INFO::2018-01-12 21:51:11,398::hosted_engine::6 >> 30::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(_initialize_storage_images) >> Connecting the storage >> MainThread::INFO::2018-01-12
Re: [ovirt-users] Problems with some vms
Hi Endre, Mount logs will be in below format inside /var/log/glusterfs : /var/log/glusterfs/rhev-data-center-mnt-glusterSD-*\:_engine.log /var/log/glusterfs/rhev-data-center-mnt-glusterSD-*\:_data.log /var/log/glusterfs/rhev-data-center-mnt-glusterSD-*\:_vmstore.log On Mon, Jan 15, 2018 at 11:57 AM, Endre Karlson wrote: > Hi. > > What are the gluster mount logs ? > > I have these gluster logs. > cli.log etc-glusterfs-glusterd.vol.log glfsheal-engine.log > glusterd.lognfs.log > rhev-data-center-mnt-glusterSD-ovirt0:_engine.log rhev-data-center-mnt- > glusterSD-ovirt3:_iso.log > cmd_history.log glfsheal-data.log glfsheal-iso.log > glustershd.log rhev-data-center-mnt-glusterSD-ovirt0:_data.log > rhev-data-center-mnt-glusterSD-ovirt0:_iso.log statedump.log > > > I am running version > glusterfs-server-3.12.4-1.el7.x86_64 > glusterfs-geo-replication-3.12.4-1.el7.x86_64 > libvirt-daemon-driver-storage-gluster-3.2.0-14.el7_4.7.x86_64 > glusterfs-libs-3.12.4-1.el7.x86_64 > glusterfs-api-3.12.4-1.el7.x86_64 > python2-gluster-3.12.4-1.el7.x86_64 > glusterfs-client-xlators-3.12.4-1.el7.x86_64 > glusterfs-cli-3.12.4-1.el7.x86_64 > glusterfs-events-3.12.4-1.el7.x86_64 > glusterfs-rdma-3.12.4-1.el7.x86_64 > vdsm-gluster-4.20.9.3-1.el7.centos.noarch > glusterfs-3.12.4-1.el7.x86_64 > glusterfs-fuse-3.12.4-1.el7.x86_64 > > // Endre > > 2018-01-15 6:11 GMT+01:00 Gobinda Das : > >> Hi Endre, >> Can you please provide glusterfs mount logs? >> >> On Mon, Jan 15, 2018 at 6:16 AM, Darrell Budic >> wrote: >> >>> What version of gluster are you running? I’ve seen a few of these since >>> moving my storage cluster to 12.3, but still haven’t been able to determine >>> what’s causing it. Seems to be happening most often on VMs that haven’t >>> been switches over to libgfapi mounts yet, but even one of those has paused >>> once so far. They generally restart fine from the GUI, and nothing seems to >>> need healing. >>> >>> -- >>> *From:* Endre Karlson >>> *Subject:* [ovirt-users] Problems with some vms >>> *Date:* January 14, 2018 at 12:55:45 PM CST >>> *To:* users >>> >>> Hi, we are getting some errors with some of our vms in a 3 node server >>> setup. >>> >>> 2018-01-14 15:01:44,015+0100 INFO (libvirt/events) [virt.vm] >>> (vmId='2c34f52d-140b-4dbe-a4bd-d2cb467b0b7c') abnormal vm stop device >>> virtio-disk0 error eother (vm:4880) >>> >>> We are running glusterfs for shared storage. >>> >>> I have tried setting global maintenance on the first server and then >>> issuing a 'hosted-engine --vm-start' but that leads to nowhere. >>> ___ >>> Users mailing list >>> Users@ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/users >>> >>> >>> >>> ___ >>> Users mailing list >>> Users@ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/users >>> >>> >> >> >> -- >> Thanks, >> Gobinda >> +91-9019047912 <+91%2090190%2047912> >> > > -- Thanks, Gobinda +91-9019047912 ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [ovirt-users] ha-agent and broker continually crashing after 4.2 update
I actually do not agree with Simone here. The fix he talks about adds a call to prepareImage, but your log clearly shows that prepareImage is the call that fails: Jan 12 16:52:36 cultivar0 journal: vdsm storage.Dispatcher ERROR FINISH prepareImage error=Volume does not exist: (u'8582bdfc-ef54-47af-9f1e-f5b7ec1f1cf8',) I have to ask how old the environment is. Was it by any chance installed back in 3.3/3.4 days and upgraded since then? Martin On Mon, Jan 15, 2018 at 10:17 AM, Simone Tiraboschi wrote: > > > On Fri, Jan 12, 2018 at 9:54 PM, Jayme wrote: >> >> recently upgraded to 4.2 and had some problems with engine vm running, got >> that cleared up now my only remaining issue is that now it seems >> ovirt-ha-broker and ovirt-ha-agent are continually crashing on all three of >> my hosts. Everything is up and working fine otherwise, all VMs running and >> hosted engine VM is running along with interface etc. > > > I think it's due to https://bugzilla.redhat.com/show_bug.cgi?id=1527394 with > got recently fixed. > ovirt-hosted-engine-ha-2.2.3 should address it, please let us know if not. > > >> >> >> Jan 12 16:52:34 cultivar0 journal: vdsm storage.Dispatcher ERROR FINISH >> prepareImage error=Volume does not exist: >> (u'8582bdfc-ef54-47af-9f1e-f5b7ec1f1cf8',) >> Jan 12 16:52:34 cultivar0 python: detected unhandled Python exception in >> '/usr/share/ovirt-hosted-engine-ha/ovirt-ha-broker' >> Jan 12 16:52:34 cultivar0 abrt-server: Not saving repeating crash in >> '/usr/share/ovirt-hosted-engine-ha/ovirt-ha-broker' >> Jan 12 16:52:34 cultivar0 systemd: ovirt-ha-broker.service: main process >> exited, code=exited, status=1/FAILURE >> Jan 12 16:52:34 cultivar0 systemd: Unit ovirt-ha-broker.service entered >> failed state. >> Jan 12 16:52:34 cultivar0 systemd: ovirt-ha-broker.service failed. >> Jan 12 16:52:34 cultivar0 systemd: ovirt-ha-broker.service holdoff time >> over, scheduling restart. >> Jan 12 16:52:34 cultivar0 systemd: Cannot add dependency job for unit >> lvm2-lvmetad.socket, ignoring: Unit is masked. >> Jan 12 16:52:34 cultivar0 systemd: Started oVirt Hosted Engine High >> Availability Communications Broker. >> Jan 12 16:52:34 cultivar0 systemd: Starting oVirt Hosted Engine High >> Availability Communications Broker... >> Jan 12 16:52:36 cultivar0 journal: vdsm storage.TaskManager.Task ERROR >> (Task='73141dec-9d8f-4164-9c4e-67c43a102eff') Unexpected error#012Traceback >> (most recent call last):#012 File >> "/usr/lib/python2.7/site-packages/vdsm/storage/task.py", line 882, in >> _run#012return fn(*args, **kargs)#012 File "", line 2, in >> prepareImage#012 File >> "/usr/lib/python2.7/site-packages/vdsm/common/api.py", line 48, in >> method#012ret = func(*args, **kwargs)#012 File >> "/usr/lib/python2.7/site-packages/vdsm/storage/hsm.py", line 3162, in >> prepareImage#012raise >> se.VolumeDoesNotExist(leafUUID)#012VolumeDoesNotExist: Volume does not >> exist: (u'8582bdfc-ef54-47af-9f1e-f5b7ec1f1cf8',) >> Jan 12 16:52:36 cultivar0 journal: vdsm storage.Dispatcher ERROR FINISH >> prepareImage error=Volume does not exist: >> (u'8582bdfc-ef54-47af-9f1e-f5b7ec1f1cf8',) >> Jan 12 16:52:36 cultivar0 python: detected unhandled Python exception in >> '/usr/share/ovirt-hosted-engine-ha/ovirt-ha-broker' >> Jan 12 16:52:36 cultivar0 abrt-server: Not saving repeating crash in >> '/usr/share/ovirt-hosted-engine-ha/ovirt-ha-broker' >> Jan 12 16:52:36 cultivar0 systemd: ovirt-ha-broker.service: main process >> exited, code=exited, status=1/FAILURE >> Jan 12 16:52:36 cultivar0 systemd: Unit ovirt-ha-broker.service entered >> failed state. >> Jan 12 16:52:36 cultivar0 systemd: ovirt-ha-broker.service failed. >> >> Jan 12 16:52:36 cultivar0 systemd: ovirt-ha-broker.service holdoff time >> over, scheduling restart. >> Jan 12 16:52:36 cultivar0 systemd: Cannot add dependency job for unit >> lvm2-lvmetad.socket, ignoring: Unit is masked. >> Jan 12 16:52:36 cultivar0 systemd: Started oVirt Hosted Engine High >> Availability Communications Broker. >> Jan 12 16:52:36 cultivar0 systemd: Starting oVirt Hosted Engine High >> Availability Communications Broker... >> Jan 12 16:52:37 cultivar0 journal: vdsm storage.TaskManager.Task ERROR >> (Task='bc7af1e2-0ab2-4164-ae88-d2bee03500f9') Unexpected error#012Traceback >> (most recent call last):#012 File >> "/usr/lib/python2.7/site-packages/vdsm/storage/task.py", line 882, in >> _run#012return fn(*args, **kargs)#012 File "", line 2, in >> prepareImage#012 File >> "/usr/lib/python2.7/site-packages/vdsm/common/api.py", line 48, in >> method#012ret = func(*args, **kwargs)#012 File >> "/usr/lib/python2.7/site-packages/vdsm/storage/hsm.py", line 3162, in >> prepareImage#012raise >> se.VolumeDoesNotExist(leafUUID)#012VolumeDoesNotExist: Volume does not >> exist: (u'8582bdfc-ef54-47af-9f1e-f5b7ec1f1cf8',) >> Jan 12 16:52:37 cultivar0 journal: vdsm storage.Dispatcher ERROR FINISH >> prepareImage error=Volume does not exist: >> (u'8582bdfc-ef54-47af-9f1e-f
Re: [ovirt-users] ha-agent and broker continually crashing after 4.2 update
On Fri, Jan 12, 2018 at 9:54 PM, Jayme wrote: > recently upgraded to 4.2 and had some problems with engine vm running, got > that cleared up now my only remaining issue is that now it seems > ovirt-ha-broker and ovirt-ha-agent are continually crashing on all three of > my hosts. Everything is up and working fine otherwise, all VMs running and > hosted engine VM is running along with interface etc. > I think it's due to https://bugzilla.redhat.com/show_bug.cgi?id=1527394 with got recently fixed. ovirt-hosted-engine-ha-2.2.3 should address it, please let us know if not. > > Jan 12 16:52:34 cultivar0 journal: vdsm storage.Dispatcher ERROR FINISH > prepareImage error=Volume does not exist: (u'8582bdfc-ef54-47af-9f1e- > f5b7ec1f1cf8',) > Jan 12 16:52:34 cultivar0 python: detected unhandled Python exception in > '/usr/share/ovirt-hosted-engine-ha/ovirt-ha-broker' > Jan 12 16:52:34 cultivar0 abrt-server: Not saving repeating crash in > '/usr/share/ovirt-hosted-engine-ha/ovirt-ha-broker' > Jan 12 16:52:34 cultivar0 systemd: ovirt-ha-broker.service: main process > exited, code=exited, status=1/FAILURE > Jan 12 16:52:34 cultivar0 systemd: Unit ovirt-ha-broker.service entered > failed state. > Jan 12 16:52:34 cultivar0 systemd: ovirt-ha-broker.service failed. > Jan 12 16:52:34 cultivar0 systemd: ovirt-ha-broker.service holdoff time > over, scheduling restart. > Jan 12 16:52:34 cultivar0 systemd: Cannot add dependency job for unit > lvm2-lvmetad.socket, ignoring: Unit is masked. > Jan 12 16:52:34 cultivar0 systemd: Started oVirt Hosted Engine High > Availability Communications Broker. > Jan 12 16:52:34 cultivar0 systemd: Starting oVirt Hosted Engine High > Availability Communications Broker... > Jan 12 16:52:36 cultivar0 journal: vdsm storage.TaskManager.Task ERROR > (Task='73141dec-9d8f-4164-9c4e-67c43a102eff') Unexpected > error#012Traceback (most recent call last):#012 File > "/usr/lib/python2.7/site-packages/vdsm/storage/task.py", line 882, in > _run#012return fn(*args, **kargs)#012 File "", line 2, in > prepareImage#012 File "/usr/lib/python2.7/site-packages/vdsm/common/api.py", > line 48, in method#012ret = func(*args, **kwargs)#012 File > "/usr/lib/python2.7/site-packages/vdsm/storage/hsm.py", line 3162, in > prepareImage#012raise > se.VolumeDoesNotExist(leafUUID)#012VolumeDoesNotExist: > Volume does not exist: (u'8582bdfc-ef54-47af-9f1e-f5b7ec1f1cf8',) > Jan 12 16:52:36 cultivar0 journal: vdsm storage.Dispatcher ERROR FINISH > prepareImage error=Volume does not exist: (u'8582bdfc-ef54-47af-9f1e- > f5b7ec1f1cf8',) > Jan 12 16:52:36 cultivar0 python: detected unhandled Python exception in > '/usr/share/ovirt-hosted-engine-ha/ovirt-ha-broker' > Jan 12 16:52:36 cultivar0 abrt-server: Not saving repeating crash in > '/usr/share/ovirt-hosted-engine-ha/ovirt-ha-broker' > Jan 12 16:52:36 cultivar0 systemd: ovirt-ha-broker.service: main process > exited, code=exited, status=1/FAILURE > Jan 12 16:52:36 cultivar0 systemd: Unit ovirt-ha-broker.service entered > failed state. > Jan 12 16:52:36 cultivar0 systemd: ovirt-ha-broker.service failed. > > Jan 12 16:52:36 cultivar0 systemd: ovirt-ha-broker.service holdoff time > over, scheduling restart. > Jan 12 16:52:36 cultivar0 systemd: Cannot add dependency job for unit > lvm2-lvmetad.socket, ignoring: Unit is masked. > Jan 12 16:52:36 cultivar0 systemd: Started oVirt Hosted Engine High > Availability Communications Broker. > Jan 12 16:52:36 cultivar0 systemd: Starting oVirt Hosted Engine High > Availability Communications Broker... > Jan 12 16:52:37 cultivar0 journal: vdsm storage.TaskManager.Task ERROR > (Task='bc7af1e2-0ab2-4164-ae88-d2bee03500f9') Unexpected > error#012Traceback (most recent call last):#012 File > "/usr/lib/python2.7/site-packages/vdsm/storage/task.py", line 882, in > _run#012return fn(*args, **kargs)#012 File "", line 2, in > prepareImage#012 File "/usr/lib/python2.7/site-packages/vdsm/common/api.py", > line 48, in method#012ret = func(*args, **kwargs)#012 File > "/usr/lib/python2.7/site-packages/vdsm/storage/hsm.py", line 3162, in > prepareImage#012raise > se.VolumeDoesNotExist(leafUUID)#012VolumeDoesNotExist: > Volume does not exist: (u'8582bdfc-ef54-47af-9f1e-f5b7ec1f1cf8',) > Jan 12 16:52:37 cultivar0 journal: vdsm storage.Dispatcher ERROR FINISH > prepareImage error=Volume does not exist: (u'8582bdfc-ef54-47af-9f1e- > f5b7ec1f1cf8',) > Jan 12 16:52:37 cultivar0 python: detected unhandled Python exception in > '/usr/share/ovirt-hosted-engine-ha/ovirt-ha-broker' > Jan 12 16:52:38 cultivar0 abrt-server: Not saving repeating crash in > '/usr/share/ovirt-hosted-engine-ha/ovirt-ha-broker' > Jan 12 16:52:38 cultivar0 systemd: ovirt-ha-broker.service: main process > exited, code=exited, status=1/FAILURE > Jan 12 16:52:38 cultivar0 systemd: Unit ovirt-ha-broker.service entered > failed state. > Jan 12 16:52:38 cultivar0 systemd: ovirt-ha-broker.service failed. > Jan 12 16:52:38 cultivar0 systemd: ovirt-ha-broker.servic
Re: [ovirt-users] hosted-engine unknow stale-data
Hello Artem, Can you check if glusterd service is running on host1 and all the peers are in connected state ? If yes, can you restart ovirt-ha-agent and broker services and check if things are working fine ? Thanks kasturi On Sat, Jan 13, 2018 at 12:33 AM, Artem Tambovskiy < artem.tambovs...@gmail.com> wrote: > Explored logs on both hosts. > broker.log shows no errors. > > agent.log looking not good: > > on host1 (which running hosted engine) : > > MainThread::ERROR::2018-01-12 21:51:03,883::agent::205:: > ovirt_hosted_engine_ha.agent.agent.Agent::(_run_agent) Traceback (most > recent call last): > File > "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/agent/agent.py", > line 191, in _run_agent > return action(he) > File > "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/agent/agent.py", > line 64, in action_proper > return he.start_monitoring() > File > "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/agent/hosted_engine.py", > line 411, in start_monitoring > self._initialize_sanlock() > File > "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/agent/hosted_engine.py", > line 749, in _initialize_sanlock > "Failed to initialize sanlock, the number of errors has" > SanlockInitializationError: Failed to initialize sanlock, the number of > errors has exceeded the limit > > MainThread::ERROR::2018-01-12 21:51:03,884::agent::206:: > ovirt_hosted_engine_ha.agent.agent.Agent::(_run_agent) Trying to restart > agent > MainThread::WARNING::2018-01-12 21:51:08,889::agent::209:: > ovirt_hosted_engine_ha.agent.agent.Agent::(_run_agent) Restarting agent, > attempt '1' > MainThread::INFO::2018-01-12 21:51:08,919::hosted_engine:: > 242::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(_get_hostname) > Found certificate common name: ovirt1.telia.ru > MainThread::INFO::2018-01-12 21:51:08,921::hosted_engine:: > 604::ovirt_hosted_engine_ha.agent.hosted_engine. > HostedEngine::(_initialize_vdsm) Initializing VDSM > MainThread::INFO::2018-01-12 21:51:11,398::hosted_engine:: > 630::ovirt_hosted_engine_ha.agent.hosted_engine. > HostedEngine::(_initialize_storage_images) Connecting the storage > MainThread::INFO::2018-01-12 21:51:11,399::storage_server:: > 220::ovirt_hosted_engine_ha.lib.storage_server.StorageServer::(validate_storage_server) > Validating storage server > MainThread::INFO::2018-01-12 21:51:13,725::storage_server:: > 239::ovirt_hosted_engine_ha.lib.storage_server.StorageServer::(connect_storage_server) > Connecting storage server > MainThread::INFO::2018-01-12 21:51:18,390::storage_server:: > 246::ovirt_hosted_engine_ha.lib.storage_server.StorageServer::(connect_storage_server) > Connecting storage server > MainThread::INFO::2018-01-12 21:51:18,423::storage_server:: > 253::ovirt_hosted_engine_ha.lib.storage_server.StorageServer::(connect_storage_server) > Refreshing the storage domain > MainThread::INFO::2018-01-12 21:51:18,689::hosted_engine:: > 663::ovirt_hosted_engine_ha.agent.hosted_engine. > HostedEngine::(_initialize_storage_images) Preparing images > MainThread::INFO::2018-01-12 21:51:18,690::image::126:: > ovirt_hosted_engine_ha.lib.image.Image::(prepare_images) Preparing images > MainThread::INFO::2018-01-12 21:51:21,895::hosted_engine:: > 666::ovirt_hosted_engine_ha.agent.hosted_engine. > HostedEngine::(_initialize_storage_images) Refreshing vm.conf > MainThread::INFO::2018-01-12 21:51:21,895::config::493:: > ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine.config::(refresh_vm_conf) > Reloading vm.conf from the shared storage domain > MainThread::INFO::2018-01-12 21:51:21,896::config::416:: > ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine. > config::(_get_vm_conf_content_from_ovf_store) Trying to get a fresher > copy of vm configuration from the OVF_STORE > MainThread::INFO::2018-01-12 21:51:21,896::ovf_store::132:: > ovirt_hosted_engine_ha.lib.ovf.ovf_store.OVFStore::(getEngineVMOVF) > Extracting Engine VM OVF from the OVF_STORE > MainThread::INFO::2018-01-12 21:51:21,897::ovf_store::134:: > ovirt_hosted_engine_ha.lib.ovf.ovf_store.OVFStore::(getEngineVMOVF) > OVF_STORE volume path: /var/run/vdsm/storage/4a7f8717-9bb0-4d80-8016- > 498fa4b88162/5cabd8e1-5f4b-469e-becc-227469e03f5c/8048cbd7-77e2-4805-9af4- > d109fa36dfcf > MainThread::INFO::2018-01-12 21:51:21,915::config::435:: > ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine. > config::(_get_vm_conf_content_from_ovf_store) Found an OVF for HE VM, > trying to convert > MainThread::INFO::2018-01-12 21:51:21,918::config::440:: > ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine. > config::(_get_vm_conf_content_from_ovf_store) Got vm.conf from OVF_STORE > MainThread::INFO::2018-01-12 21:51:21,919::hosted_engine:: > 509::ovirt_hosted_engine_ha.agent.hosted_engine. > HostedEngine::(_initialize_broker) Initializing ha-broker connection > MainThread::INFO::2018-01-12 21:51:21,919::brokerlink::130: > :ovirt_hosted_engine_ha.lib.brokerlink.BrokerLink::(s
Re: [ovirt-users] (no subject)
Hello, Can you attach ovirt-ha-agent and ovirt-ha-broker logs ? Thanks kasturi On Fri, Jan 12, 2018 at 9:38 PM, Artem Tambovskiy < artem.tambovs...@gmail.com> wrote: > Trying to fix one thing I broke another :( > > I fixed mnt_options for hosted engine storage domain and installed latest > security patches to my hosts and hosted engine. All VM's up and running, > but hosted_engine --vm-status reports about issues: > > [root@ovirt1 ~]# hosted-engine --vm-status > > > --== Host 1 status ==-- > > conf_on_shared_storage : True > Status up-to-date : False > Hostname : ovirt2 > Host ID: 1 > Engine status : unknown stale-data > Score : 0 > stopped: False > Local maintenance : False > crc32 : 193164b8 > local_conf_timestamp : 8350 > Host timestamp : 8350 > Extra metadata (valid at timestamp): > metadata_parse_version=1 > metadata_feature_version=1 > timestamp=8350 (Fri Jan 12 19:03:54 2018) > host-id=1 > score=0 > vm_conf_refresh_time=8350 (Fri Jan 12 19:03:54 2018) > conf_on_shared_storage=True > maintenance=False > state=EngineUnexpectedlyDown > stopped=False > timeout=Thu Jan 1 05:24:43 1970 > > > --== Host 2 status ==-- > > conf_on_shared_storage : True > Status up-to-date : False > Hostname : ovirt1.telia.ru > Host ID: 2 > Engine status : unknown stale-data > Score : 0 > stopped: True > Local maintenance : False > crc32 : c7037c03 > local_conf_timestamp : 7530 > Host timestamp : 7530 > Extra metadata (valid at timestamp): > metadata_parse_version=1 > metadata_feature_version=1 > timestamp=7530 (Fri Jan 12 16:10:12 2018) > host-id=2 > score=0 > vm_conf_refresh_time=7530 (Fri Jan 12 16:10:12 2018) > conf_on_shared_storage=True > maintenance=False > state=AgentStopped > stopped=True > [root@ovirt1 ~]# > > > > from second host situation looks a bit different: > > > [root@ovirt2 ~]# hosted-engine --vm-status > > > --== Host 1 status ==-- > > conf_on_shared_storage : True > Status up-to-date : True > Hostname : ovirt2 > 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 : 78eabdb6 > local_conf_timestamp : 8403 > Host timestamp : 8402 > Extra metadata (valid at timestamp): > metadata_parse_version=1 > metadata_feature_version=1 > timestamp=8402 (Fri Jan 12 19:04:47 2018) > host-id=1 > score=0 > vm_conf_refresh_time=8403 (Fri Jan 12 19:04:47 2018) > conf_on_shared_storage=True > maintenance=False > state=EngineUnexpectedlyDown > stopped=False > timeout=Thu Jan 1 05:24:43 1970 > > > --== Host 2 status ==-- > > conf_on_shared_storage : True > Status up-to-date : False > Hostname : ovirt1.telia.ru > Host ID: 2 > Engine status : unknown stale-data > Score : 0 > stopped: True > Local maintenance : False > crc32 : c7037c03 > local_conf_timestamp : 7530 > Host timestamp : 7530 > Extra metadata (valid at timestamp): > metadata_parse_version=1 > metadata_feature_version=1 > timestamp=7530 (Fri Jan 12 16:10:12 2018) > host-id=2 > score=0 > vm_conf_refresh_time=7530 (Fri Jan 12 16:10:12 2018) > conf_on_shared_storage=True > maintenance=False > state=AgentStopped > stopped=True > > > WebGUI shows that engine running on host ovirt1. > Gluster looks fine > [root@ovirt1 ~]# gluster volume status engine > Status of volume: engine > Gluster process TCP Port RDMA Port Online > Pid > > -- > Brick ovirt1.telia.ru:/oVirt/engine 49169 0 Y > 3244 > Brick ovirt2.telia.ru:/oVirt/engine 49179 0 Y > 20372 > Brick ovirt3.telia.ru:/oVirt/engine 49206 0 Y >
Re: [ovirt-users] oVirt Node 4.1.8 -> 4.2 upgrade
On Thu, Jan 11, 2018 at 2:31 PM, Ryan Barry wrote: > Note that, in the case of Node, the ovirt-release RPM should not be > installed. Mostly because it automatically enables a number of per-package > updates (such as vdsm) instead of installing a single image. > > Trimming the repo files so they look like what is shipped in Node > (IgnorePkgs and OnlyPkgs) will pull ovirt-node-ng-image-update.rpm, which > is the only package needing an update. > > Hi, i'm upgrading ovirt-node too. I found out that installing ovirt-release file and running yum upgrade wants to upgrade everything. Instead, if i make yum upgrade ovirt-node-ng-image* I get the new image downloaded. So which is the right procedure to upgrade a node? Maybe providing a single command alternative to yum (let's say ovirt-node-upgrade) for upgrading would be better and avoid issues when doing such operation. 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.l...@gmail.com> ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users