from:"Nathanaël Blanchet"


Le 21/02/2022 à 17:15, Klaas Demter a écrit :
Ansible is now being shipped as part of appstream in rhel8.6/centos 
stream repos. Not sure how this will be solved for ovirt/rhv :) But 
the most likely answer for a workaround is you need to exclude 
ansible-core in appstream repository. Or via cli something along the 
lines of "dnf update -x ansible-core"
Thank you, it is ok now but... we are faced to the first side effects of 
an upstream distribution that continuously ships newer packages and 
finally breaks dependencies (at least repos) into a stable ovirt realease.



Greetings

Klaas


On 2/21/22 16:43, Nathanaël Blanchet wrote:


Le 21/02/2022 à 16:28, Yedidyah Bar David a écrit :

sudo dnf reinstall --disablerepo='*'
https://resources.ovirt.org/pub/yum-repo/ovirt-release44.rpm


It partially solves  the issue:

Error:
 Problem: package ansible-runner-service-1.0.7-1.el8.noarch requires 
ansible, but none of the providers can be installed
  - package ansible-2.9.27-2.el8.noarch conflicts with ansible-core > 
2.11.0 provided by ansible-core-2.12.2-2.el8.x86_64
  - package ansible-core-2.12.2-2.el8.x86_64 obsoletes ansible < 
2.10.0 provided by ansible-2.9.27-2.el8.noarch


It seems that 4.4.10 upgrades ansible from 2.9 branch to 2.12


___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/OANKECW6C4SM6USKJP7DJIAHUN5RALFI/


--
Nathanaël Blanchet

Supervision réseau
SIRE
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
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/PJ5I2OBSKW75RJ5V7IDIZL2PO6KS24EP/

[ovirt-users] Re: Unable to update self hosted Engine due to missing mirrors


In fact, the repo is (for any reason) not installed at all, so simply do:

sudo dnf install --disablerepo='*' 
https://resources.ovirt.org/pub/yum-repo/ovirt-release44.rpm


Le 21/02/2022 à 16:39, Yannick Barone a écrit :

Please find below the result :

# dnf reinstall --disablerepo='*' 
https://resources.ovirt.org/pub/yum-repo/ovirt-release44.rpm
ovirt-release44.rpm 

   48 kB/s |  21 kB 00:00
Package ovirt-release44-4.4.10.1-1.el8.noarch not installed, cannot reinstall 
it.
No match for argument: 
/var/cache/dnf/commandline-a76fe31ae310b0c7/packages/ovirt-release44.rpm
Error: No packages marked for reinstall.
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/5C32SPWQ6DNL7MSU44FEVTCF7GFOOHBR/


--
Nathanaël Blanchet

Supervision réseau
SIRE
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
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/KTVOGPHLXWCMH6ZVOXUFTV5ICQNGIN5L/

[ovirt-users] Re: Unable to update self hosted Engine due to missing mirrors



Le 21/02/2022 à 16:28, Yedidyah Bar David a écrit :

sudo dnf reinstall --disablerepo='*'
https://resources.ovirt.org/pub/yum-repo/ovirt-release44.rpm


It partially solves  the issue:

Error:
 Problem: package ansible-runner-service-1.0.7-1.el8.noarch requires 
ansible, but none of the providers can be installed
  - package ansible-2.9.27-2.el8.noarch conflicts with ansible-core > 
2.11.0 provided by ansible-core-2.12.2-2.el8.x86_64
  - package ansible-core-2.12.2-2.el8.x86_64 obsoletes ansible < 2.10.0 
provided by ansible-2.9.27-2.el8.noarch


It seems that 4.4.10 upgrades ansible from 2.9 branch to 2.12....

--
Nathanaël Blanchet

Supervision réseau
SIRE
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
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/MY6OOROPEZ2GDDG7WEURJQBYOJPCBP4C/

[ovirt-users] Re: Unable to update self hosted Engine due to missing mirrors


The same issue for me, on engine and ovirt-node hosts

Le 21/02/2022 à 13:37, yannick.bar...@carandache.com a écrit :

Hi,

I wanted to update my oVirt Engine Host and Hosts servers this morning, but I 
encouter the same error :

engine-upgrade-check or dnf update :

FAIL: Failed to download metadata for repo 'ovirt-4.4-centos-gluster8': Cannot 
prepare internal mirrorlist: No URLs in mirrorlist

The Engine and the Hosts are running Centos Stream with oVirt 4.4.9.
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/YJLQSYSAUZULKZS7LWWSPWTEEYMHYFW4/


--
Nathanaël Blanchet

Supervision réseau
SIRE
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
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/OGOXKVN452PXSRXPO2MXI6V3UFVVG5FS/

[ovirt-users] Re: ansible ovirt_template: follow as replacement of nested_attributes

Okay, the issue came from ovirt.ovirt 1.6.5 collection, upgrading to 
1.6.6 manage to fetch the cluster name as follow:


    -  ovirt_template_info:
    auth: "{{ ovirt_auth }}"
    pattern: name=centos8-stream.x
        follows: ['cluster']
       # fetch_nested: yes
   # nested_attributes: ['name']

    - debug:
    msg: "{{result.ovirt_templates|map(attribute='cluster.name')}}"

Le 16/02/2022 à 16:35, Nathanaël Blanchet a écrit :

Hello,

I was familiar with the ansible fetch_nested/nested_attributes to get 
additionnal information from API.


Recently it has been deprecated in order to be replaced by the 
"follow(s)" verb.


I understand it will follow the links into the schema definition of 
the object like:


href="/ovirt-engine/api/templates/e020281a-f5f0-4d98-91e3-4f3a9fc069b1/permissions" 
rel="permissions"/>
href="/ovirt-engine/api/templates/e020281a-f5f0-4d98-91e3-4f3a9fc069b1/tags" 
rel="tags"/>
href="/ovirt-engine/api/templates/e020281a-f5f0-4d98-91e3-4f3a9fc069b1/cdroms" 
rel="cdroms"/>
href="/ovirt-engine/api/templates/e020281a-f5f0-4d98-91e3-4f3a9fc069b1/nics" 
rel="nics"/>
href="/ovirt-engine/api/templates/e020281a-f5f0-4d98-91e3-4f3a9fc069b1/watchdogs" 
rel="watchdogs"/>
href="/ovirt-engine/api/templates/e020281a-f5f0-4d98-91e3-4f3a9fc069b1/diskattachments" 
rel="diskattachments"/>
href="/ovirt-engine/api/templates/e020281a-f5f0-4d98-91e3-4f3a9fc069b1/graphicsconsoles" 
rel="graphicsconsoles"/>


but I can't get fetch nested (name of cluster) of :

href="/ovirt-engine/api/clusters/bbeb38a4-79f0-11ec-86cb-00163e6d6a50" 
id="bbeb38a4-79f0-11ec-86cb-00163e6d6a50"/>


I was used to do this query with:

fetch_nested: yes
nested_attribute:
    - name

Is it possible to do the same with "follow(s)"?


--
Nathanaël Blanchet

Supervision réseau
SIRE
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
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/DGUAWXYNOA6HGRZKYFDF4D3Z3T5ATACI/

[ovirt-users] Re: oVirt alternatives

Le 21 févr. 2022 08:31, Sandro Bonazzola  a écrit :Il giorno dom 20 feb 2022 alle ore 22:47 Nathanaël Blanchet <blanc...@abes.fr> ha scritto:Hello, Is okd/openshift virtualization designed to be a full replacement of ovirt/redhat by embedding the same level of advancedoVirt is a very mature project, integrated with most of the Red Hat ecosystem, mostly being maintained without any new big features.It has live-snapshot, live-storage-migration, memory overcommit management, passthrough of a very specific PCI device on a particular host, a VM portal, OpenShift IPI.It lacks integrated container management.OKD Virtualization is being very actively developed quickly closing gaps.It has integrated container management, ability to leverage the k8s distributed architecture/infrastructure and to leverage k8s assets like exclusive CPU placements.It currently lacks live-snapshot, live-storage-migration, memory overcommit management, passthrough of a very specific PCI device on a particular host, VM portal (OKD UI is more similar to Admin portal), thin-provisioning (of VMs on top of templates), hot (un)plug (disk/memory/NIC), high availability with VM leases, incremental backup, VDI features like template versions, sealing (virt-sysprep).So OKD is not feature complete replacement for oVirt yet.So okd virtualization aims to be a replacement in the next years when all ovirt features will be achivied for kubvirt, that's why ovirt continue to be maintained for the moment, great new! Openshift IPI being also maintained is a great new because bare metal okd installation is not as easy as ovirt is (even I know we need bare metal to consume okd virtualization). Can you confirm we can merge bare metal and virtualized core is hosts? Is nested virtualization available?-- Sandro BonazzolaMANAGER, SOFTWARE ENGINEERING, EMEA R RHVRed Hat EMEAsbona...@redhat.com   Red Hat respects your work life balance. Therefore there is no need to answer this email out of your office hours.
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/ILMHSVVLZPQIOHDPNONEZOL3ZNX4UVHI/

[ovirt-users] Re: oVirt alternatives

2022-02-20 Thread Nathanaël Blanchet

Hello, Is okd/openshift virtualization designed to be a full replacement of 
ovirt/redhat by embedding the same level of advanced

Il giorno dom 6 feb 2022 alle ore 14:06 Wesley Stewart 
ha scritto:

> Has anyone tried the open shift upstream old?  Looks like they support
> virtualization now.  Which I'm guessing is the upstream for openshift
> virtualization?
>
> https://docs.okd.io/latest/virt/about-virt.html
>

I gave a presentation about it 2 days ago at FOSDEM:
https://fosdem.org/2022/schedule/event/vai_intro_okd/
but looks like recordings are not yet available at
https://video.fosdem.org/2022/
Slides are here:
https://fosdem.org/2022/schedule/event/vai_intro_okd/attachments/slides/4843/export/events/attachments/vai_intro_okd/slides/4843/OKD_Virtualization_Community.pdf




>
>
>
> On Sat, Feb 5, 2022, 10:34 PM Alex McWhirter  wrote:
>
>> Oh i have spent years looking.
>>
>> ProxMox is probably the closest option, but has no multi-clustering
>> support. The clusters are more or less isolated from each other, and
>> would need another layer if you needed the ability to migrate between
>> them.
>>
>> XCP-ng, cool. No spice support. No UI for managing clustered storage
>> that is open source.
>>
>> Harvester, probably the closest / newest contender. Needs a lot more
>> attention / work.
>>
>> OpenNebula, more like a DIY AWS than anything else, but was functional
>> last i played with it.
>>
>>
>>
>> Has anyone actually played with OpenShift virtualization (replaces RHV)?
>> Wonder if OKD supports it with a similar model?
>>
>> On 2022-02-05 07:40, Thomas Hoberg wrote:
>> > There is unfortunately no formal announcement on the fate of oVirt,
>> > but with RHGS and RHV having a known end-of-life, oVirt may well shut
>> > down in Q2.
>> >
>> > So it's time to hunt for an alternative for those of us to came to
>> > oVirt because they had already rejected vSAN or Nutanix.
>> >
>> > Let's post what we find here in this thread.
>> > ___
>> > Users mailing list -- users@ovirt.org
>> > To unsubscribe send an email to users-le...@ovirt.org
>> > Privacy Statement: https://www.ovirt.org/privacy-policy.html
>> > oVirt Code of Conduct:
>> > https://www.ovirt.org/community/about/community-guidelines/
>> > List Archives:
>> >
>> https://lists.ovirt.org/archives/list/users@ovirt.org/message/R4YFNNCTW5VVVRKSV2OORQ2UWZ2MTUDD/
>> ___
>> Users mailing list -- users@ovirt.org
>> To unsubscribe send an email to users-le...@ovirt.org
>> Privacy Statement: https://www.ovirt.org/privacy-policy.html
>> oVirt Code of Conduct:
>> https://www.ovirt.org/community/about/community-guidelines/
>> List Archives:
>> https://lists.ovirt.org/archives/list/users@ovirt.org/message/EYPC6QXF55UCQPMQL5LDU6XMAF2CZOEG/
>>
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/privacy-policy.html
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/Z6JTGNYABYPZHHZ3F5Y75KF3KYDWV5OC/
>


-- 

Sandro Bonazzola

MANAGER, SOFTWARE ENGINEERING, EMEA R RHV

Red Hat EMEA 

sbona...@redhat.com


*Red Hat respects your work life balance. Therefore there is no need to
answer this email out of your office hours.*


___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/JSNPCQPTN32WIFEDI3LR6X63ELE57GMM/
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/QZKA2VEMG6B3MOJL2RV6RS5W6XSHNQDB/

[ovirt-users] ansible ovirt_template: follow as replacement of nested_attributes

2022-02-16 Thread Nathanaël Blanchet


Hello,

I was familiar with the ansible fetch_nested/nested_attributes to get 
additionnal information from API.


Recently it has been deprecated in order to be replaced by the 
"follow(s)" verb.


I understand it will follow the links into the schema definition of the 
object like:


href="/ovirt-engine/api/templates/e020281a-f5f0-4d98-91e3-4f3a9fc069b1/permissions" 
rel="permissions"/>
href="/ovirt-engine/api/templates/e020281a-f5f0-4d98-91e3-4f3a9fc069b1/tags" 
rel="tags"/>
href="/ovirt-engine/api/templates/e020281a-f5f0-4d98-91e3-4f3a9fc069b1/cdroms" 
rel="cdroms"/>
href="/ovirt-engine/api/templates/e020281a-f5f0-4d98-91e3-4f3a9fc069b1/nics" 
rel="nics"/>
href="/ovirt-engine/api/templates/e020281a-f5f0-4d98-91e3-4f3a9fc069b1/watchdogs" 
rel="watchdogs"/>
href="/ovirt-engine/api/templates/e020281a-f5f0-4d98-91e3-4f3a9fc069b1/diskattachments" 
rel="diskattachments"/>
href="/ovirt-engine/api/templates/e020281a-f5f0-4d98-91e3-4f3a9fc069b1/graphicsconsoles" 
rel="graphicsconsoles"/>


but I can't get fetch nested (name of cluster) of :

href="/ovirt-engine/api/clusters/bbeb38a4-79f0-11ec-86cb-00163e6d6a50" 
id="bbeb38a4-79f0-11ec-86cb-00163e6d6a50"/>


I was used to do this query with:

fetch_nested: yes
nested_attribute:
    - name

Is it possible to do the same with "follow(s)"?

--
Nathanaël Blanchet

Supervision réseau
SIRE
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
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/A2UW7JJUP6P5T7U3NTHXAF2HSSCNAGGZ/

[ovirt-users] Re: vm seal

2022-02-16 Thread Nathanaël Blanchet



Le 15/02/2022 à 15:01, Arik Hadas a écrit :



On Tue, Feb 15, 2022 at 12:26 PM Nathanaël Blanchet  
wrote:



Le 15/02/2022 à 10:32, Arik Hadas a écrit :



On Mon, Feb 14, 2022 at 11:29 PM Nathanaël Blanchet
 wrote:



Le 14 févr. 2022 21:09, Arik Hadas  a écrit :



On Mon, Feb 14, 2022 at 8:44 PM Nathanaël Blanchet
 wrote:


Le 14/02/2022 à 17:45, Arik Hadas a écrit :



On Mon, Feb 14, 2022 at 4:52 PM Nathanaël
Blanchet  wrote:

Hello,

I noticed that a vm created from a "sealed"
template is initially mount
on one host with libguestfs, with a
virt-sysprep process, before getting
ready to be used.

This should be unuseful given that the
template is already sealed. Is
there a reason to that?


Yes, we do this in order to produce different LVM
IDs and machine IDs for the provisioned VMs, see:
https://gerrit.ovirt.org/c/ovirt-engine/+/115009

okay, but, I modified  the
/usr/lib/python3.6/site-packages/vdsm/virtsysprep.py
file like following:

args = ['--hostname', 'localhost',
''--selinux-relabel', '--update', '--network']"

in order to update packages on  template creation.

The template creation still works and the template is
checked as sealed and os is updated, but now the vm
creation never ends up and I have to manually kill
the virt-sysprep process to stop the infinite process
creation.

I believed it was a good workaround to get updated
templates, but I had to rollback to default
virt-sysprep args configuration, unless there is
trick do to so?

If you create the VM from the webadmin, you can uncheck
the 'sealed' option in the new-vm dialog to skip the
second execution of virt-sysprep on the VM
If you create it from REST-API (or the VM portal), you
might want to change the configuration of the template in
the database:
update vm_static set is_template_sealed='f' where
vm_name='';

Thanks for this useful tip, but as you said if second seal
has been designed it is to produce different VM IDs... So
what will happen if I skip this process?


It was that way (i.e., without sysprep-ing the vm volumes) for
years - if that worked well for you, you shouldn't notice a
difference

Secondly I'd like to know if there is a way to skip the
second seal from the template with oVirt VM ansible module(
don't seem to be), it is safer than modifying the DB.


Ansible is in the second category (since it is based on
oVirt's REST-API) so yeah, I don't see a different way you can
achieve this at the moment
And you're right, it's not recommended to modify the DB directly
but the same goes for changing the VDSM source files ;)
Anyway, that is_template_sealed field only affects the UI
(presenting whether the template is sealed) and this
functionality (deciding whether virt-sysprep should be executed
on the vm volumes) - so changing it should be safe.


Thank you it works as expected now.

But giving that my templates are auto-created, is there a way to
set is_template_sealed to false at template creation rather than
manually doing it in a second time?

We change the database via Ansible during the deployment of hosted 
engine [1], maybe you can do it in a similar way..


Filed https://bugzilla.redhat.com/show_bug.cgi?id=2054681 for adding 
the configuration we have at the webadmin to the API

thanks for the bugzilla, ansible module via API is indeed the best practice


[1] 
https://github.com/oVirt/ovirt-ansible-collection/blob/1.6.6-1/roles/hosted_engine_setup/tasks/create_target_vm/02_engine_vm_configuration.yml#L11-L15

- name: Unseal "{{survey_template}}" template at DB level
command: >-
psql -d engine -c
"UPDATE vm_static SET is_template_sealed='f' WHERE
vm_name = '{{survey_template}}'"
become: true
become_user: postgres
become_method: sudo
changed_when: true
register: db_vm_update
delegate_to: "{{server}}"

works like a charm, never done this such a thing before but I keep it in 
mind for future non native module.






    -- 
Nathanaël Blanchet


Supervision réseau
SIRE
227 avenue Professeur-Jean-Louis-Viala
34193 MONTPELL

[ovirt-users] Re: vm seal

2022-02-15 Thread Nathanaël Blanchet



Le 15/02/2022 à 10:32, Arik Hadas a écrit :



On Mon, Feb 14, 2022 at 11:29 PM Nathanaël Blanchet  
wrote:




Le 14 févr. 2022 21:09, Arik Hadas  a écrit :



On Mon, Feb 14, 2022 at 8:44 PM Nathanaël Blanchet
 wrote:


Le 14/02/2022 à 17:45, Arik Hadas a écrit :



On Mon, Feb 14, 2022 at 4:52 PM Nathanaël Blanchet
 wrote:

Hello,

I noticed that a vm created from a "sealed"
template is initially mount
on one host with libguestfs, with a virt-sysprep
process, before getting
ready to be used.

This should be unuseful given that the template is
already sealed. Is
there a reason to that?


Yes, we do this in order to produce different LVM IDs
and machine IDs for the provisioned VMs, see:
https://gerrit.ovirt.org/c/ovirt-engine/+/115009

okay, but, I modified  the
/usr/lib/python3.6/site-packages/vdsm/virtsysprep.py file
like following:

args = ['--hostname', 'localhost', ''--selinux-relabel',
'--update', '--network']"

in order to update packages on template creation.

The template creation still works and the template is
checked as sealed and os is updated, but now the vm
creation never ends up and I have to manually kill the
virt-sysprep process to stop the infinite process creation.

I believed it was a good workaround to get updated
templates, but I had to rollback to default virt-sysprep
args configuration, unless there is trick do to so?

If you create the VM from the webadmin, you can uncheck the
'sealed' option in the new-vm dialog to skip the second
execution of virt-sysprep on the VM
If you create it from REST-API (or the VM portal), you might
want to change the configuration of the template in the database:
update vm_static set is_template_sealed='f' where
vm_name='';

Thanks for this useful tip, but as you said if second seal has
been designed it is to produce different VM IDs... So what will
happen if I skip this process?


It was that way (i.e., without sysprep-ing the vm volumes) for years - 
if that worked well for you, you shouldn't notice a difference


Secondly I'd like to know if there is a way to skip the second
seal from the template with oVirt VM ansible module( don't seem to
be), it is safer than modifying the DB.


Ansible is in the second category (since it is based on 
oVirt's REST-API) so yeah, I don't see a different way you can 
achieve this at the moment
And you're right, it's not recommended to modify the DB directly but 
the same goes for changing the VDSM source files ;)
Anyway, that is_template_sealed field only affects the UI (presenting 
whether the template is sealed) and this functionality (deciding 
whether virt-sysprep should be executed on the vm volumes) - so 
changing it should be safe.


Thank you it works as expected now.

But giving that my templates are auto-created, is there a way to set 
is_template_sealed to false at template creation rather than manually 
doing it in a second time?






-- 
    Nathanaël Blanchet


Supervision réseau
SIRE
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
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement:
https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct:
https://www.ovirt.org/community/about/community-guidelines/
List Archives:

https://lists.ovirt.org/archives/list/users@ovirt.org/message/7VSOFV3TFSMKPEZBI2ERRVUCTFGJALQT/

-- 
    Nathanaël Blanchet


Supervision réseau
SIRE
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



--
Nathanaël Blanchet

Supervision réseau
SIRE
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
To unsubscribe send an email to users-le...@ovirt.org
Pr

[ovirt-users] Re: Xcp-ng, first impressions as an oVirt HCI alternative

e able to use it for free.

The current beta release only supports replicated mode and only up to four
nodes. But it seems to work reliably. Write amplification is 4x, so bandwidth
drops to 25% and is limited to the network speed, but reads will go to the
local node at storage hardware bandwidths.

The 2, 3 and 4 node replicated setup works today with the scripts they provide.
That's not quite as efficient as the 2R+1A setup in oVirt, but seems rock solid
and just works, which was never that easy in oVirt.

Hyperconverged is very attractive at 3 nodes, because good fault resilience
can't be done any cheaper. But the industry agrees that it tends to lose
financial attraction when you grow to dozens of machines and nobody in is right
mind would operate a real cloud using HCI. But going from 3 to say two dozen
should be doable and easy: it never was for oVirt.

XCP-ng or rather LINSTOR won't support any number or storage nodes or easy
linear increases like Gluster could (in theory).
So far it's only much, much better at getting things going.

Forum and community:
The documentation is rather good, but can be lighter on things which are "native
Xen", as that would repeat a lot of the effort already expended by Citrix. It's good
that I've been around the block a couple of times already since VM/370, but there are
holes or missing details when you need to ask questions.

The community isn't giant, but comfortably big enough. The forum's user
interface is vastly better than this one, but then I've never seen something as
slow as ovirt.org for a long time.

Technical questions are answered extremely quickly and mostly by the staff from
the small French company themselves. But mostly it's much easier to find
answers to questions already asked, which is the most typical case.

The general impression is that there are much fewer moving parts and things
things that can go wrong. There is no Ansible, not a single daemon on the
nodes, a management engine that seems very light and with minimal state that
doesn't need a DBA to hold and manage it. The Xen hypervisor seems much smarter
than KVM on its own and the Xoa has both a rich API to do things, but also
offers an API to next-level management.

It may have less overall features than oVirt, but I haven't found anything that
I really missed. It's much easier and quicker to install and operate with
nothing but GUI which is a godsent: I want to use the farm, not spend my time
managing it.

Motivational rant originally at the top... tl;dr

My original priorities for chosing oVirt were:
1. CentOS as RHEL downstream -> stable platform, full vendor vulnerability
management included, big benefit in compliance
2. Integrated HCI -> Just slap a couple (3/6/9) of leftover servers together
for something fault resilient, no other components required, quick start out of
the box solution with a few clicks in a GUI
3. Fully open source (& logs), can always read the source to understand what's
going on, better than your typical support engineer
4. No support or license contract, unless you want/need it, but the ability to
switch that on when it paid for itself

The more famous competitors, vSphere and Nutanix didn't offer any of that.

(Citrix) Xen I excluded, because a) Xen seemd "old school+niche" compared to KVM b) Citrix reduced
"free" to "useless"

I fell in love with Gluster from its design: it felt like a really smart
solution.
I fell out with Gluster from its operation and performance: I can't count how many times
I had to restart daemons and issue "gluster heal" commands to resettle things
after little more than a node update.

I rediscovered Xcp-ng when I discovered that HCI and RHV had ben EOLd.
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct:
https://www.ovirt.org/community/about/community-guidelines/
List Archives:
https://lists.ovirt.org/archives/list/users@ovirt.org/message/H4O4MHM5MVTHKR7ARO3APAT7SMBMYZN6/

--
Nathanaël Blanchet

[ovirt-users] Re: vm seal

Le 14 févr. 2022 21:09, Arik Hadas  a écrit :On Mon, Feb 14, 2022 at 8:44 PM Nathanaël Blanchet <blanc...@abes.fr> wrote:
  

  
  


Le 14/02/2022 à 17:45, Arik Hadas a
  écrit :


  
  




  On Mon, Feb 14, 2022 at 4:52
    PM Nathanaël Blanchet <blanc...@abes.fr>
wrote:
  
  Hello,

I noticed that a vm created from a "sealed" template is
initially mount 
on one host with libguestfs, with a virt-sysprep process,
before getting 
ready to be used.

This should be unuseful given that the template is already
sealed. Is 
there a reason to that?
  
  
  
  Yes, we do this in order to produce different LVM IDs and
machine IDs for the provisioned VMs, see: https://gerrit.ovirt.org/c/ovirt-engine/+/115009

  

okay, but, I modified  the
  /usr/lib/python3.6/site-packages/vdsm/virtsysprep.py file like
  following:
args = ['--hostname', 'localhost', ''--selinux-relabel',
  '--update', '--network']"
in order to update packages on  template creation.
The template creation still works and the template is checked as
  sealed and os is updated, but now the vm creation never ends up
  and I have to manually kill the virt-sysprep process to stop the
  infinite process creation.
I believed it was a good workaround to get updated templates, but
  I had to rollback to default virt-sysprep args configuration,
  unless there is trick do to so?If you create the VM from the webadmin, you can uncheck the 'sealed' option in the new-vm dialog to skip the second execution of virt-sysprep on the VMIf you create it from REST-API (or the VM portal), you might want to change the configuration of the template in the database:update vm_static set is_template_sealed='f' where vm_name='';Thanks for this useful tip, but as you said if second seal has been designed it is to produce different VM IDs... So what will happen if I skip this process?Secondly I'd like to know if there is a way to skip the second seal from the template with oVirt VM ansible module( don't seem to be), it is safer than modifying the DB. 


  

  
  
  

    -- 
    Nathanaël Blanchet

Supervision réseau
SIRE
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
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/
List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/7VSOFV3TFSMKPEZBI2ERRVUCTFGJALQT/
  
    
      

-- 
Nathanaël Blanchet

Supervision réseau
SIRE
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
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/3BDZO7UUPYFDRBR3DNWH7EWKEV5BMYFE/

[ovirt-users] Re: vm seal



Le 14/02/2022 à 17:45, Arik Hadas a écrit :



On Mon, Feb 14, 2022 at 4:52 PM Nathanaël Blanchet  
wrote:


Hello,

I noticed that a vm created from a "sealed" template is initially
mount
on one host with libguestfs, with a virt-sysprep process, before
getting
ready to be used.

This should be unuseful given that the template is already sealed. Is
there a reason to that?


Yes, we do this in order to produce different LVM IDs and machine IDs 
for the provisioned VMs, see: 
https://gerrit.ovirt.org/c/ovirt-engine/+/115009


okay, but, I modified  the 
/usr/lib/python3.6/site-packages/vdsm/virtsysprep.py file like following:


args = ['--hostname', 'localhost', ''--selinux-relabel', '--update', 
'--network']"


in order to update packages on  template creation.

The template creation still works and the template is checked as sealed 
and os is updated, but now the vm creation never ends up and I have to 
manually kill the virt-sysprep process to stop the infinite process 
creation.


I believed it was a good workaround to get updated templates, but I had 
to rollback to default virt-sysprep args configuration, unless there is 
trick do to so?





-- 
Nathanaël Blanchet


Supervision réseau
SIRE
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
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct:
https://www.ovirt.org/community/about/community-guidelines/
List Archives:

https://lists.ovirt.org/archives/list/users@ovirt.org/message/7VSOFV3TFSMKPEZBI2ERRVUCTFGJALQT/


--
Nathanaël Blanchet

Supervision réseau
SIRE
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
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/AHM6OCSBE6DYWRJGUT3ZQLKEMXNQE7S2/

[ovirt-users] vm seal


Hello,

I noticed that a vm created from a "sealed" template is initially mount 
on one host with libguestfs, with a virt-sysprep process, before getting 
ready to be used.


This should be unuseful given that the template is already sealed. Is 
there a reason to that?


--
Nathanaël Blanchet

Supervision réseau
SIRE
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
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/7VSOFV3TFSMKPEZBI2ERRVUCTFGJALQT/

[ovirt-users] Re: RHGS and RHV closing down: could you please put that on the home page?

2022-02-05 Thread Nathanaël Blanchet

Can anybody from redhat confirm what is supposed here, all my staff depends on
the future of ovirt. How can we help to maintain this project alive if redhat
dev are not implicated anymore? I may donate some hardware or is it unuseful?
Le 5 févr. 2022 11:31, Thomas Hoberg a écrit :

Please have a look here:
https://access.redhat.com/support/policy/updates/rhev/

Without a commercial product to pay the vast majority of the developers, there
is just no chance oVirt can survive (unless you're ready to take over). RHV 4.4
full support ends this August and that very likely means that oVirt won't
receive updates past July (judging by how things happened with 4.3).

And those will be CI tested against the Stream Beta not EL8 including RHEL.

Only with a RHV support contract ($) you will receive service until 2024 and
with extended support ($$$) until 2026.

oVirt is dead already. They have known since October. They should have told us
last year.
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct:
https://www.ovirt.org/community/about/community-guidelines/
List Archives:
https://lists.ovirt.org/archives/list/users@ovirt.org/message/ZPQ7DO75CVINFKDWXTSH6D2KM67L5FI4/
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct:
https://www.ovirt.org/community/about/community-guidelines/
List Archives:
https://lists.ovirt.org/archives/list/users@ovirt.org/message/DDYD27NS5QB5LIJJ3UQXKVKLLN3MYBYB/

[ovirt-users] Re: no snaphot but engines complains there is one when trying to remove disk



Le 31/01/2022 à 17:38, Benny Zlotnik a écrit :

does their vm_snapshot_id exists in the snapshots table?

do they exist on the storage? I suggest running
   $ vdsm-tool dump-volume-chain 


it doesn't seem to exist:


   image:    ba2efe1a-8b83-4406-8711-7120b4bd11d0

 - 08966754-0bb6-4c88-9ad6-35d6242fa380
   status: OK, voltype: LEAF, format: RAW, legality: LEGAL, 
type: PREALLOCATED, capacity: 219982856192, truesize: 219982856192


And checking what the chain looks like there.

In theory it's possible to remove them from the database, but the
relationships between the images would need to be fixed as well, as
both images you mentioned have children

okay, tell me how to remove them from the DB please.


On Mon, Jan 31, 2022 at 5:46 PM Nathanaël Blanchet  wrote:

Engine complains about 60087f63-6237-4419-a5dd-9a48c84c1c43 and
109fac1e-c2e3-4ba6-9867-5d1c94d3a447

Le 31/01/2022 à 16:26, Benny Zlotnik a écrit :

I see all images have a vm_snapshot_id that's not null, do you know
which image it complains about?
It is possible that there is no corresponding entry in the snapshots
table, since I see there is foreign key


On Mon, Jan 31, 2022 at 4:56 PM Nathanaël Blanchet  wrote:

engine=# select * from images where
image_group_id='ba2efe1a-8b83-4406-8711-7120b4bd11d0';
-[ RECORD 1 ]-+-
image_guid| 0bf72cb1-d90d-4b3d-bbfe-1e1c58a6ce46
creation_date | 2022-01-31 10:03:29.958+01
size  | 219902115840
it_guid   | ----
parentid  | 08966754-0bb6-4c88-9ad6-35d6242fa380
imagestatus   | 1
lastmodified  | 2022-01-31 10:04:35.519+01
vm_snapshot_id| 623d7b5a-b90d-48b6-8db9-a86ed739ad71
volume_type   | 2
volume_format | 4
image_group_id| ba2efe1a-8b83-4406-8711-7120b4bd11d0
_create_date  | 2022-01-31 10:03:30.067155+01
_update_date  | 2022-01-31 10:04:35.519545+01
active| f
volume_classification | 1
qcow_compat   | 0
-[ RECORD 2 ]-+-
image_guid| ad3205a5-823d-4997-adc8-df769780fa3b
creation_date | 2022-01-31 10:08:11.749+01
size  | 219902115840
it_guid   | ----
parentid  | 733b1d36-d107-4adc-9ac0-a0c800c2c22c
imagestatus   | 1
lastmodified  | 2022-01-31 10:10:36.54+01
vm_snapshot_id| c2fb7dbf-5ea9-46f9-8735-e2532193219d
volume_type   | 2
volume_format | 4
image_group_id| ba2efe1a-8b83-4406-8711-7120b4bd11d0
_create_date  | 2022-01-31 10:08:11.841814+01
_update_date  | 2022-01-31 10:10:36.540134+01
active| f
volume_classification | 1
qcow_compat   | 0
-[ RECORD 3 ]-+-
image_guid| 70c4877a-1649-4882-9cca-38cc40bd7d5a
creation_date | 2022-01-31 10:12:50.02+01
size  | 219902115840
it_guid   | ----
parentid  | a8b0087c-e975-4b8a-b137-0ea1c9107db6
imagestatus   | 1
lastmodified  | 2022-01-31 10:15:35.55+01
vm_snapshot_id| e0df180f-f728-44c3-8d61-d53f0cace1c4
volume_type   | 2
volume_format | 4
image_group_id| ba2efe1a-8b83-4406-8711-7120b4bd11d0
_create_date  | 2022-01-31 10:12:50.120438+01
_update_date  | 2022-01-31 10:15:35.550984+01
active| f
volume_classification | 1
qcow_compat   | 0
-[ RECORD 4 ]-+-
image_guid| 20585d25-a90d-4ef5-a9bb-2205f79c99d8
creation_date | 2022-01-31 10:04:35.419+01
size  | 219902115840
it_guid   | ----
parentid  | 0bf72cb1-d90d-4b3d-bbfe-1e1c58a6ce46
imagestatus   | 1
lastmodified  | 2022-01-31 10:06:15.902+01
vm_snapshot_id| 93aa0faa-9d51-4550-87ca-801de8d4ad40
volume_type   | 2
volume_format | 4
image_group_id| ba2efe1a-8b83-4406-8711-7120b4bd11d0
_create_date  | 2022-01-31 10:04:35.519545+01
_update_date  | 2022-01-31 10:06:15.903055+01
active| f
volume_classification | 1
qcow_compat   | 0
-[ RECORD 5 ]-+-
image_guid| 733b1d36-d107-4adc-9ac0-a0c800c2c22c
creation_date | 2022-01-31 10:06:15.78+01
size  | 219902115840
it_guid   | ----
parentid  | 20585d25-a90d-4ef5-a9bb-2205f79c99d8
imagestatus   | 1
lastmodified  | 2022-01-31 10:08:11.841+01
vm_snapshot_id| 70717bc6-d018-4229-88d2-0a6b31ad0153
volume_type   | 2
volume_format | 4
image_group_id| ba2efe1a-8b83-4406-8711-7120b4bd11d0
_create_date  | 2022

[ovirt-users] Re: no snaphot but engines complains there is one when trying to remove disk

Engine complains about 60087f63-6237-4419-a5dd-9a48c84c1c43 and 
109fac1e-c2e3-4ba6-9867-5d1c94d3a447


Le 31/01/2022 à 16:26, Benny Zlotnik a écrit :

I see all images have a vm_snapshot_id that's not null, do you know
which image it complains about?
It is possible that there is no corresponding entry in the snapshots
table, since I see there is foreign key


On Mon, Jan 31, 2022 at 4:56 PM Nathanaël Blanchet  wrote:

engine=# select * from images where
image_group_id='ba2efe1a-8b83-4406-8711-7120b4bd11d0';
-[ RECORD 1 ]-+-
image_guid| 0bf72cb1-d90d-4b3d-bbfe-1e1c58a6ce46
creation_date | 2022-01-31 10:03:29.958+01
size  | 219902115840
it_guid   | ----
parentid  | 08966754-0bb6-4c88-9ad6-35d6242fa380
imagestatus   | 1
lastmodified  | 2022-01-31 10:04:35.519+01
vm_snapshot_id| 623d7b5a-b90d-48b6-8db9-a86ed739ad71
volume_type   | 2
volume_format | 4
image_group_id| ba2efe1a-8b83-4406-8711-7120b4bd11d0
_create_date  | 2022-01-31 10:03:30.067155+01
_update_date  | 2022-01-31 10:04:35.519545+01
active| f
volume_classification | 1
qcow_compat   | 0
-[ RECORD 2 ]-+-
image_guid| ad3205a5-823d-4997-adc8-df769780fa3b
creation_date | 2022-01-31 10:08:11.749+01
size  | 219902115840
it_guid   | ----
parentid  | 733b1d36-d107-4adc-9ac0-a0c800c2c22c
imagestatus   | 1
lastmodified  | 2022-01-31 10:10:36.54+01
vm_snapshot_id| c2fb7dbf-5ea9-46f9-8735-e2532193219d
volume_type   | 2
volume_format | 4
image_group_id| ba2efe1a-8b83-4406-8711-7120b4bd11d0
_create_date  | 2022-01-31 10:08:11.841814+01
_update_date  | 2022-01-31 10:10:36.540134+01
active| f
volume_classification | 1
qcow_compat   | 0
-[ RECORD 3 ]-+-
image_guid| 70c4877a-1649-4882-9cca-38cc40bd7d5a
creation_date | 2022-01-31 10:12:50.02+01
size  | 219902115840
it_guid   | ----
parentid  | a8b0087c-e975-4b8a-b137-0ea1c9107db6
imagestatus   | 1
lastmodified  | 2022-01-31 10:15:35.55+01
vm_snapshot_id| e0df180f-f728-44c3-8d61-d53f0cace1c4
volume_type   | 2
volume_format | 4
image_group_id| ba2efe1a-8b83-4406-8711-7120b4bd11d0
_create_date  | 2022-01-31 10:12:50.120438+01
_update_date  | 2022-01-31 10:15:35.550984+01
active| f
volume_classification | 1
qcow_compat   | 0
-[ RECORD 4 ]-+-
image_guid| 20585d25-a90d-4ef5-a9bb-2205f79c99d8
creation_date | 2022-01-31 10:04:35.419+01
size  | 219902115840
it_guid   | ----
parentid  | 0bf72cb1-d90d-4b3d-bbfe-1e1c58a6ce46
imagestatus   | 1
lastmodified  | 2022-01-31 10:06:15.902+01
vm_snapshot_id| 93aa0faa-9d51-4550-87ca-801de8d4ad40
volume_type   | 2
volume_format | 4
image_group_id| ba2efe1a-8b83-4406-8711-7120b4bd11d0
_create_date  | 2022-01-31 10:04:35.519545+01
_update_date  | 2022-01-31 10:06:15.903055+01
active| f
volume_classification | 1
qcow_compat   | 0
-[ RECORD 5 ]-+-
image_guid| 733b1d36-d107-4adc-9ac0-a0c800c2c22c
creation_date | 2022-01-31 10:06:15.78+01
size  | 219902115840
it_guid   | ----
parentid  | 20585d25-a90d-4ef5-a9bb-2205f79c99d8
imagestatus   | 1
lastmodified  | 2022-01-31 10:08:11.841+01
vm_snapshot_id| 70717bc6-d018-4229-88d2-0a6b31ad0153
volume_type   | 2
volume_format | 4
image_group_id| ba2efe1a-8b83-4406-8711-7120b4bd11d0
_create_date  | 2022-01-31 10:06:15.903055+01
_update_date  | 2022-01-31 10:08:11.841814+01
active| f
volume_classification | 1
qcow_compat   | 0
-[ RECORD 6 ]-+-
image_guid| a8b0087c-e975-4b8a-b137-0ea1c9107db6
creation_date | 2022-01-31 10:10:36.419+01
size  | 219902115840
it_guid   | ----
parentid  | ad3205a5-823d-4997-adc8-df769780fa3b
imagestatus   | 1
lastmodified  | 2022-01-31 10:12:50.12+01
vm_snapshot_id| 5de5b2ee-0ca4-476f-963d-7bf9b3601817
volume_type   | 2
volume_format | 4
image_group_id| ba2efe1a-8b83-4406-8711-7120b4bd11d0
_create_date  | 2022-01-31 10:10:36.540134+01

[ovirt-users] Re: no snaphot but engines complains there is one when trying to remove disk


Hello

Le 31/01/2022 à 14:41, Gianluca Cecchi a écrit :
On Mon, Jan 31, 2022 at 2:29 PM Nathanaël Blanchet  
wrote:


Hi all,

A colleague launched this morning a snapshot creation, there was
no error message but he wasn't able to start the vm anymore, with
this issue : VM PSI-SYB-DEV is down with error. Exit message:
Unable to get volume size for domain
a5be6cae-f0c8-452f-b7cd-70d0e5eed710 volume
109fac1e-c2e3-4ba6-9867-5d1c94d3a447..



No direct help, but you had better specify the exact version of 
components and if the snapshot was directly executed inside web admin 
gui or via rest/API or with any kind of external sw.

Possibly anything could have had different effects depending on versions

He executed with webui engine 4.4.9


Gianluca


--
Nathanaël Blanchet

Supervision réseau
SIRE
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
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/2WQ4Q6ITMRPA3G6DW23QZG4AE5NDQ55J/

[ovirt-users] Re: no snaphot but engines complains there is one when trying to remove disk

  | 60087f63-6237-4419-a5dd-9a48c84c1c43
imagestatus   | 1
lastmodified  | 2022-01-31 14:58:30.263+01
vm_snapshot_id    | c05d9174-4338-40a1-9040-f75bdbc3903c
volume_type   | 2
volume_format | 4
image_group_id    | ba2efe1a-8b83-4406-8711-7120b4bd11d0
_create_date  | 2022-01-31 11:14:41.055894+01
_update_date  | 2022-01-31 14:58:30.26388+01
active    | f
volume_classification | 1
qcow_compat   | 0
-[ RECORD 8 ]-+-
image_guid    | 7f95b43c-6007-48de-b107-fad3520c2fa6
creation_date | 2022-01-31 10:15:35.436+01
size  | 219902115840
it_guid   | ----
parentid  | 70c4877a-1649-4882-9cca-38cc40bd7d5a
imagestatus   | 1
lastmodified  | 2022-01-31 10:17:09.272+01
vm_snapshot_id    | f0a391a0-e129-4f6e-afc7-304ca2dda4d1
volume_type   | 2
volume_format | 4
image_group_id    | ba2efe1a-8b83-4406-8711-7120b4bd11d0
_create_date  | 2022-01-31 10:15:35.550984+01
_update_date  | 2022-01-31 10:17:09.272314+01
active    | f
volume_classification | 1
qcow_compat   | 0
-[ RECORD 9 ]-+-
image_guid    | 68db1cb9-6227-4ab2-af77-0c336488abbc
creation_date | 2022-01-31 14:58:30.139+01
size  | 219902115840
it_guid   | ----
parentid  | 109fac1e-c2e3-4ba6-9867-5d1c94d3a447
imagestatus   | 1
lastmodified  | 2022-01-31 14:58:30.139+01
vm_snapshot_id    | dad5a7ec-804d-4351-bb97-5ddc24b2072e
volume_type   | 2
volume_format | 4
image_group_id    | ba2efe1a-8b83-4406-8711-7120b4bd11d0
_create_date  | 2022-01-31 14:58:30.26388+01
_update_date  |
active    | t
volume_classification | 0
qcow_compat   | 0
-[ RECORD 10 ]+-
image_guid    | 379db97c-bfe1-4804-9b1f-576050efdcd3
creation_date | 2022-01-31 10:17:09.148+01
size  | 219902115840
it_guid   | ----
parentid  | 7f95b43c-6007-48de-b107-fad3520c2fa6
imagestatus   | 1
lastmodified  | 2022-01-31 10:27:58.556+01
vm_snapshot_id    | 89c331f6-4799-4f03-888d-d9b680f1a4c6
volume_type   | 2
volume_format | 4
image_group_id    | ba2efe1a-8b83-4406-8711-7120b4bd11d0
_create_date  | 2022-01-31 10:17:09.272314+01
_update_date  | 2022-01-31 10:27:58.557011+01
active    | f
volume_classification | 1
qcow_compat   | 0
-[ RECORD 11 ]+-
image_guid    | 60087f63-6237-4419-a5dd-9a48c84c1c43
creation_date | 2022-01-31 10:27:58.444+01
size  | 219902115840
it_guid   | ----
parentid  | 379db97c-bfe1-4804-9b1f-576050efdcd3
imagestatus   | 1
lastmodified  | 2022-01-31 11:14:41.055+01
vm_snapshot_id    | 979b7cfd-4b38-4e95-92e6-ed77f5320e73
volume_type   | 2
volume_format | 4
image_group_id    | ba2efe1a-8b83-4406-8711-7120b4bd11d0
_create_date  | 2022-01-31 10:27:58.557011+01
_update_date  | 2022-01-31 11:14:41.055894+01
active    | f
volume_classification | 1
qcow_compat   | 0
-[ RECORD 12 ]+-
image_guid    | 08966754-0bb6-4c88-9ad6-35d6242fa380
creation_date | 2018-11-15 10:08:56+01
size  | 219902115840
it_guid   | ----
parentid  | ----
imagestatus   | 1
lastmodified  | 2022-01-31 10:03:30.067+01
vm_snapshot_id    | adedebd6-c342-4bcd-9a6c-54b9abec3a7b
volume_type   | 1
volume_format | 5
image_group_id    | ba2efe1a-8b83-4406-8711-7120b4bd11d0
_create_date  | 2018-11-15 10:11:10.302763+01
_update_date  | 2022-01-31 10:03:30.067155+01
active    | f
volume_classification | 1
qcow_compat   | 0

Le 31/01/2022 à 14:40, Benny Zlotnik a écrit :

-c "select * from images where
image_group_id = ''"


--
Nathanaël Blanchet

Supervision réseau
SIRE
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
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/U5VLTMZBG7AEX3YIBYRZLIBZ3XSNEYLR/

[ovirt-users] no snaphot but engines complains there is one when trying to remove disk

Hi all,

A colleague launched this morning a snapshot creation, there was no
error message but he wasn't able to start the vm anymore, with this
issue : VM PSI-SYB-DEV is down with error. Exit message: Unable to get
volume size for domain a5be6cae-f0c8-452f-b7cd-70d0e5eed710 volume
109fac1e-c2e3-4ba6-9867-5d1c94d3a447..

I tried many things but nothing works: it is impossible to remove this
disk, or copy it, or clone the vm :

Cannot detach Virtual Disk. The disk is already configured in a
snapshot. In order to detach it, remove the disk's snapshots.

There is no snaphost listed into webui or api (so not snapshot id),
while disk_snapshots exists into the associated storage domain.

So I tried to remove disks snapshot direvctly with API followind the
DELETE method

|DELETE /api/storagedomains/{storage_id}/disksnapshots/{image_id}|

[Cannot remove Disk Snapshot. VM\'s Snapshot does not exist.]

In conclusion: vm_disks can't be removed because of the non existent
associated vm's snapshot id.

I tried to remove vm_snapshots disks references directly into the
postgres DB but I didn't find the correct table.

What can I do now?

Your precious help is welcome.

--
Nathanaël Blanchet

[ovirt-users] Re: CentOS Stream Guest OS 9 support

2022-01-18 Thread Nathanaël Blanchet


Why not? I'm running several instances without specific issues.

Le 18/01/2022 à 16:49, Gangi Reddy a écrit :

Can we create CentOS Stream 9 guest OS VM in Ovirt? Do you have any link that i 
refer?

Ovirt:
Software Version:4.4.7.6-1.el8

Host:
OS Version: RHEL - 8.4.2105.0 - 3.el8
OS Description: oVirt Node 4.4.8
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/XZHHWKAOQ6ZIIKMEU3RB353ZBIHSHOPN/


--
Nathanaël Blanchet

Supervision réseau
SIRE
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
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/F4PRUMBTNP7EUU43IOIXCILL34LZR5MN/

[ovirt-users] Re: give cloud-init the VM name

2022-01-17 Thread Nathanaël Blanchet


Hello,

Two ways of thinking:

1. the vdsm hook could be very easy to write so as to make what you
   desire (ovirtsdk4 is presinstalled on ovirt node):
   importovirtsdk4 assdk
   importovirtsdk4.types astypes
   fromvdsm.hook importhooking
   # Get the vm name from xml definition:
   domxml= hooking.read_domxml()
   vm_name= domxml.getElementsByTagName('name')[0].firstChild.nodeValue
   print(vm_name)
   connection= sdk.Connection(
   url='https://engine.example.com/ovirt-engine/api',
   username='admin@internal',
   password='password',
   ca_file='ca.pem',
   )
   # Find the virtual machine:
   vms_service= connection.system_service().vms_service()
   vm= vms_service.list(search= vm_name)[0]
   # Find the service that manages the virtual machine:
   vm_service= vms_service.vm_service(vm.id)
   # Start the virtual machine enabling cloud-init and providing the
   # password for the `root` user and the hostname:
   vm_service.start(
   use_cloud_init=True,
   vm=types.Vm(
   initialization=types.Initialization(
   user_name='root',
   root_password='password',
   host_name= vm_name+ 'example.com'
   )
   )
   )
   # Close the connection to the server:
   connection.close()
   Then place it as executable in
   /usr/libexec/vdsm/hooks/before_vm_start on each host that should be
   able to run the pool vms.

2. As the web UI already auto fills the VM hostname cloud-init field
   with the vm name (or fqdn), the VM Hostname should do the same with
   vm pool, but it doesn't. You could open a RFE for this, it shouldn't
   be very complicated to patch it.

Le 17/01/2022 à 12:34, Luca Contessa a écrit :

I thought that:- you know the name of the future VM

I will try to clarify: I'm trying to obtain from the oVirt engine the name of 
the VM created inside the pool.
For example if the VM in pool LinuxPool is called LinuxMachine-1 I want the 
cloud-init to know that the VM is called LinuxMachine-1 and with this info add 
the suffix using the method you described.
Again, thank you a lot for the response.
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/GKIRUVQ7R65MH6QU73XVDF5GCQCKDZTK/


--
Nathanaël Blanchet

Supervision réseau
SIRE
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
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/PZUVWBBNAJFZRD2VTLOJKNDOEUABHQSR/

[ovirt-users] Re: using stop_reason as a vdsm hook trigger into the UI

2021-12-22 Thread Nathanaël Blanchet



Le 22/12/2021 à 15:49, Nathanaël Blanchet a écrit :



Le 22/12/2021 à 14:56, John Taylor a écrit :

Maybe use the events api and search for the shutdown and reason in there?

api/events;from={event_id}?search={query}" rel="events/search"/>

-John


Exact! that's precisely the workaround I already tested this morning 
as well :)


and it works because the event contains the stop_reason in the 
description field before vm is in the stopped status!


Unfortunately, after some additionnal tests, I am in the same situation 
as initially with stop_reason element in api/vm, i.e. the new event 
containing the stop reason is writed to the API only after the hook 
script has exited.


So I  am never able to test this variable to determine the action to do...

P.S: For those who are interested: to make that case work, I proceeded 
at the opposite: rather than testing the variable condition in the hook 
itsself, I only use the hook to curl a job_template in AWX. By this way, 
the hook exits, and the ovirt_vm_info returns the expected stop_reason 
value and so on for following actions...




On Tue, Dec 21, 2021 at 9:00 AM Nathanaël Blanchet <mailto:blanc...@abes.fr>> wrote:


Thanks for responding,

Le 20/12/2021 à 21:42, Nir Soffer a écrit :

On Mon, Dec 20, 2021 at 9:59 PM Nathanaël Blanchet  
<mailto:blanc...@abes.fr>  wrote:

Adding the devel list since question is more about extending oVirt
...

The idea is to use the stop_reason element into the vm xml definition. But 
after hours, I realized that this element is writed to the vm definition file 
only after the VM has been destroyed.

So you want to run the clean hook only if stop reason == "clean"?

I think the way to integrate hooks is to define a custom property
in the vm, and check if the property was defined in the hook.

For example how the localdisk hook is triggered:

def main():
 backend = os.environ.get('localdisk')
 if backend is None:
 return
 if backend not in [BACKEND_LVM, BACKEND_LVM_THIN]:
 hooking.log("localdisk-hook: unsupported backend: %r" % backend)
 return
 ...

The hook runs only if the environment variable "localdisk" is defined
and configured properly.

vdsm defines the custom properties as environment variables.

On the engine side, you need to add a user defined property:

  engine-config -s UserDefinedVMProperties='localdisk=^(lvm|lvmthin)$'

And configure a custom property with one of the allowed values, like:

 localdisk=lvm

See vdsm_hooks/localdisk/README for more info.

If you want to control the cleanup, by adding a "clean" stop reason only 
when
needed, this will not help, and vdsm hook is probably not the right way
to integrate this.

Sure

If your intent is to clean a vm in some special events, but you want
to integrate
this in engine, maybe you should write an engine ui plugin?

The plugin can show the running vms, and provide a clean button that will
shut down the vm and run your custom code.

too complex for doing what I want

But maybe you don't need to integrate this in engine, and having a simple
script using ovirt engine API/SDK to shutdown the vm and run the cleanup
code.

My playbook/scripts work already fine, but this is not my goal.

Nir


I will sum up my initial question: *Is there any way to get the
value of "stop_reason" (value of the field in the UI) so as to
reuse this variable into a vdsm hook?*

Thank you


-- 
Nathanaël Blanchet


Supervision réseau
SIRE
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  <mailto:blanc...@abes.fr>

___
Users mailing list -- users@ovirt.org <mailto:users@ovirt.org>
To unsubscribe send an email to users-le...@ovirt.org
<mailto:users-le...@ovirt.org>
Privacy Statement: https://www.ovirt.org/privacy-policy.html
<https://www.ovirt.org/privacy-policy.html>
oVirt Code of Conduct:
https://www.ovirt.org/community/about/community-guidelines/
<https://www.ovirt.org/community/about/community-guidelines/>
List Archives:

https://lists.ovirt.org/archives/list/users@ovirt.org/message/OSM572SLKKAFOWZWT6OTNSFZED5JX5RC/

<https://lists.ovirt.org/archives/list/users@ovirt.org/message/OSM572SLKKAFOWZWT6OTNSFZED5JX5RC/>


--
Nathanaël Blanchet

Supervision réseau
SIRE
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
To unsubscribe send an email to users-le...@ovirt.o

[ovirt-users] Re: using stop_reason as a vdsm hook trigger into the UI

2021-12-22 Thread Nathanaël Blanchet



Le 22/12/2021 à 14:56, John Taylor a écrit :

Maybe use the events api and search for the shutdown and reason in there?

api/events;from={event_id}?search={query}" rel="events/search"/>

-John


Exact! that's precisely the workaround I already tested this morning as 
well :)


and it works because the event contains the stop_reason in the 
description field before vm is in the stopped status!




On Tue, Dec 21, 2021 at 9:00 AM Nathanaël Blanchet <mailto:blanc...@abes.fr>> wrote:


Thanks for responding,

Le 20/12/2021 à 21:42, Nir Soffer a écrit :

On Mon, Dec 20, 2021 at 9:59 PM Nathanaël Blanchet  
<mailto:blanc...@abes.fr>  wrote:

Adding the devel list since question is more about extending oVirt
...

The idea is to use the stop_reason element into the vm xml definition. But 
after hours, I realized that this element is writed to the vm definition file 
only after the VM has been destroyed.

So you want to run the clean hook only if stop reason == "clean"?

I think the way to integrate hooks is to define a custom property
in the vm, and check if the property was defined in the hook.

For example how the localdisk hook is triggered:

def main():
 backend = os.environ.get('localdisk')
 if backend is None:
 return
 if backend not in [BACKEND_LVM, BACKEND_LVM_THIN]:
 hooking.log("localdisk-hook: unsupported backend: %r" % backend)
 return
 ...

The hook runs only if the environment variable "localdisk" is defined
and configured properly.

vdsm defines the custom properties as environment variables.

On the engine side, you need to add a user defined property:

  engine-config -s UserDefinedVMProperties='localdisk=^(lvm|lvmthin)$'

And configure a custom property with one of the allowed values, like:

 localdisk=lvm

See vdsm_hooks/localdisk/README for more info.

If you want to control the cleanup, by adding a "clean" stop reason only 
when
needed, this will not help, and vdsm hook is probably not the right way
to integrate this.

Sure

If your intent is to clean a vm in some special events, but you want
to integrate
this in engine, maybe you should write an engine ui plugin?

The plugin can show the running vms, and provide a clean button that will
shut down the vm and run your custom code.

too complex for doing what I want

But maybe you don't need to integrate this in engine, and having a simple
script using ovirt engine API/SDK to shutdown the vm and run the cleanup
code.

My playbook/scripts work already fine, but this is not my goal.

Nir


I will sum up my initial question: *Is there any way to get the
value of "stop_reason" (value of the field in the UI) so as to
reuse this variable into a vdsm hook?*

Thank you


-- 
Nathanaël Blanchet


Supervision réseau
SIRE
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  <mailto:blanc...@abes.fr>

___
Users mailing list -- users@ovirt.org <mailto:users@ovirt.org>
To unsubscribe send an email to users-le...@ovirt.org
<mailto:users-le...@ovirt.org>
Privacy Statement: https://www.ovirt.org/privacy-policy.html
<https://www.ovirt.org/privacy-policy.html>
oVirt Code of Conduct:
https://www.ovirt.org/community/about/community-guidelines/
<https://www.ovirt.org/community/about/community-guidelines/>
List Archives:

https://lists.ovirt.org/archives/list/users@ovirt.org/message/OSM572SLKKAFOWZWT6OTNSFZED5JX5RC/

<https://lists.ovirt.org/archives/list/users@ovirt.org/message/OSM572SLKKAFOWZWT6OTNSFZED5JX5RC/>


--
Nathanaël Blanchet

Supervision réseau
SIRE
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
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/3O3BKLSJ5PTHFWFZWSVGQ5PJ5EPVPUC5/

[ovirt-users] Re: using stop_reason as a vdsm hook trigger into the UI

2021-12-21 Thread Nathanaël Blanchet


Thanks for responding,

Le 20/12/2021 à 21:42, Nir Soffer a écrit :

On Mon, Dec 20, 2021 at 9:59 PM Nathanaël Blanchet  wrote:

Adding the devel list since question is more about extending oVirt
...

The idea is to use the stop_reason element into the vm xml definition. But 
after hours, I realized that this element is writed to the vm definition file 
only after the VM has been destroyed.

So you want to run the clean hook only if stop reason == "clean"?

I think the way to integrate hooks is to define a custom property
in the vm, and check if the property was defined in the hook.

For example how the localdisk hook is triggered:

def main():
 backend = os.environ.get('localdisk')
 if backend is None:
 return
 if backend not in [BACKEND_LVM, BACKEND_LVM_THIN]:
 hooking.log("localdisk-hook: unsupported backend: %r" % backend)
 return
 ...

The hook runs only if the environment variable "localdisk" is defined
and configured properly.

vdsm defines the custom properties as environment variables.

On the engine side, you need to add a user defined property:

  engine-config -s UserDefinedVMProperties='localdisk=^(lvm|lvmthin)$'

And configure a custom property with one of the allowed values, like:

 localdisk=lvm

See vdsm_hooks/localdisk/README for more info.

If you want to control the cleanup, by adding a "clean" stop reason only when
needed, this will not help, and vdsm hook is probably not the right way
to integrate this.

Sure


If your intent is to clean a vm in some special events, but you want
to integrate
this in engine, maybe you should write an engine ui plugin?

The plugin can show the running vms, and provide a clean button that will
shut down the vm and run your custom code.

too complex for doing what I want


But maybe you don't need to integrate this in engine, and having a simple
script using ovirt engine API/SDK to shutdown the vm and run the cleanup
code.

My playbook/scripts work already fine, but this is not my goal.

Nir

I will sum up my initial question: *Is there any way to get the value of 
"stop_reason" (value of the field in the UI) so as to reuse this 
variable into a vdsm hook?*


Thank you


--
Nathanaël Blanchet

Supervision réseau
SIRE
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
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/OSM572SLKKAFOWZWT6OTNSFZED5JX5RC/

[ovirt-users] using stop_reason as a vdsm hook trigger into the UI

2021-12-20 Thread Nathanaël Blanchet

rc=1 err=b'Traceback (most recent call last):\n  File 
"/usr/libexec/vdsm/hooks/after_vm_destroy/clean_vm_dependencies_2.py", 
line 84, in \n    print(status.text, 
stop_reason.text)\nAttributeError: \'NoneType\' object has no attribute 
\'text\'\n' (hooks:122)




So I'm deducing I'm not able to accomplish my initial goal to use 
stop_reason as a trigger with after_vm_destroy event.


I searched an other way to do: I thought of replacing querying ovirt API 
with getting the value coming from the UI, but I can't find the suitable 
database query. Is there a way to do such a thing? Does engine hooks 
exist for stopped vm??


Thank you for your help.

PS: I'm already able to do this from ansible/AWX, but I have to do it 
from UI/vdsm for any reason.


--
Nathanaël Blanchet

Supervision réseau
SIRE
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
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/S42J27JTR57YUEDH56B2H6AWUJS4BQFR/

[ovirt-users] Re: Oauth token lifetime

2021-12-20 Thread Nathanaël Blanchet



Le 17/12/2021 à 18:07, Sandro Bonazzola a écrit :



Il giorno gio 16 dic 2021 alle ore 23:08 Nathanaël Blanchet 
mailto:blanc...@abes.fr>> ha scritto:


Hello there is not a lot informations about Oauth token except I
found they expire after 30 minuts of inactivity. I'd like to
change this value if possible to a dedicate lifetime. Usually this
kind of change is done with engine-config but no such item is
currently available. Is it possible?


engine-config is still there:
# rpm -qf /usr/bin/engine-config
ovirt-engine-tools-4.5.0-0.2.master.20211215083937.gitafa2fd24e6.el8.noarch


It is not about the engine-config command itsself but about the way to 
configure the oauth2 token lifetime. I mean, we usually use the 
engine-config for this kind of thing, but it seems there is currently no 
way to do this with engine-config.


Where can I configure this?




--

Sandro Bonazzola

MANAGER, SOFTWARE ENGINEERING, EMEA R RHV

Red Hat EMEA <https://www.redhat.com/>

sbona...@redhat.com <mailto:sbona...@redhat.com>

<https://www.redhat.com/> 

*Red Hat respects your work life balance. Therefore there is no need 
to answer this email out of your office hours.

*
*

*


--
Nathanaël Blanchet

Supervision réseau
SIRE
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
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/TBDYPUHDVU5ID5TG373JFTSXLTHKIIKK/

[ovirt-users] Oauth token lifetime

2021-12-16 Thread Nathanaël Blanchet

Hello there is not a lot informations about Oauth token except I found they expire after 30 minuts of inactivity. I'd like to change this value if possible to a dedicate lifetime. Usually this kind of change is done with engine-config but no such item is currently available. Is it possible?___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/7XF4N3ND7YTRBE57G6XFOCKZ6Y5HOOU2/

[ovirt-users] Re: Upgrading 4.3.7 -> 4.4.9 :: Can't migrate vm from old to new host

2021-12-10 Thread Nathanaël Blanchet


Hi,

Is your migration network provisionned by DHCP?

If so, there is a known bug that prevents NetworkManager to set ip rule 
table for your migration network, and it won't be fixed before 4.5 release.


As a workaround, you can set the protocol to static or manually assign 
rule table to 0 as folowing on all on your hosts:


nmcli connection mod migration ipv4.route-table 0 && nmcli con up migration

Le 10/12/2021 à 17:07, Niklas Larsson via Users a écrit :

Hi,

we are trying to upgrade 4.3.7 -> 4.4.9 (Ovirt-Node, hosted engine). 
And things looks good until we try to migrate VM from 4.3.7 host to 
the 4.4.9 host, it fails with an generic error - and in below is from 
the vsdm.log from the 4.3.7 host.


Migrating VM from 4.4.9 host -> 4.3.7 host works.

Upgraded the 4.3.7 to 4.3.10 - did not solve it

Log from the 4.3 host:
2021-12-10 16:18:22,829+0100 INFO  (jsonrpc/1) [api.virt] START 
migrate(params={u'incomingLimit': 2, u'src': 
u'kvm22.shg.mgn.weblink.se', u'dstqemu': u'10.1.2.111', 
u'autoConverge': u'true', u'tunneled': u'false', u'enableGuestEvents': T
rue, u'dst': u'kvm21.shg.mgn.weblink.se:54321', 
u'convergenceSchedule': {u'init': [{u'params': [u'100'], u'name': 
u'setDowntime'}], u'stalling': [{u'action': {u'params': [u'150'], 
u'name': u'setDowntime'}, u'limit': 1}, {u'action': {u'params': 
[u'200'], u'name': u'setDowntime'}, u'limit': 2}, {u'action': 
{u'params': [u'300'], u'name': u'setDowntime'}, u'limit': 3}, 
{u'action': {u'params': [u'400'], u'name': u'setDowntime'}, u'limit': 
4}, {u'action': {u'params': [u'500'], u'name': u'setDowntime'}, 
u'limit': 6}, {u'action': {u'params': [], u'name': u'abort'}, 
u'limit': -1}]}, u'vmId': u'11f3a2aa-7951-4064-92f9-bb8ab515373b', 
u'abortOnError': u'true', u'outgoingLimit': 2, u'compressed': 
u'false', u'maxBandwidth': 62, u'method': u'online'}) 
from=:::10.1.2.51,46546, 
flow_id=03aca28c-00c9-4b58-a1e8-3aa355e162c2, 
vmId=11f3a2aa-7951-4064-92f9-bb8ab515373b (api:48)
2021-12-10 16:18:22,831+0100 INFO  (jsonrpc/1) [api.virt] FINISH 
migrate return={'status': {'message': 'Migration in progress', 'code': 
0}, 'progress': 0} from=:::10.1.2.51,46546, 
flow_id=03aca28c-00c9-4b58-a1e8-3aa355e162c2, 
vmId=11f3a2aa-7951-4064-92f9-bb8ab515373b (api:54)
2021-12-10 16:18:22,831+0100 INFO  (jsonrpc/1) [jsonrpc.JsonRpcServer] 
RPC call VM.migrate succeeded in 0.01 seconds (__init__:312)
2021-12-10 16:18:22,873+0100 ERROR (migsrc/11f3a2aa) [virt.vm] 
(vmId='11f3a2aa-7951-4064-92f9-bb8ab515373b') [Errno -2] Name or 
service not known (migration:282)
2021-12-10 16:18:22,875+0100 ERROR (migsrc/11f3a2aa) [virt.vm] 
(vmId='11f3a2aa-7951-4064-92f9-bb8ab515373b') Failed to migrate 
(migration:450)

Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/vdsm/virt/migration.py", line 
402, in _regular_run

    self._setupVdsConnection()
  File "/usr/lib/python2.7/site-packages/vdsm/virt/migration.py", line 
239, in _setupVdsConnection

    client = self._createClient(port)
  File "/usr/lib/python2.7/site-packages/vdsm/virt/migration.py", line 
227, in _createClient
    client_socket = utils.create_connected_socket(host, int(port), 
sslctx)
  File "/usr/lib/python2.7/site-packages/vdsm/utils.py", line 435, in 
create_connected_socket

    socket.AF_UNSPEC, socket.SOCK_STREAM)
gaierror: [Errno -2] Name or service not known
2021-12-10 16:18:22,888+0100 INFO  (jsonrpc/7) [api.virt] START 
getMigrationStatus() from=:::10.1.2.51,46546, 
vmId=11f3a2aa-7951-4064-92f9-bb8ab515373b (api:48)
2021-12-10 16:18:22,888+0100 INFO  (jsonrpc/7) [api.virt] FINISH 
getMigrationStatus return={'status': {'message': 'Done', 'code': 0}, 
'migrationStats': {'status': {'message': 'Fatal error during 
migration', 'code': 12}, 'progress': 0}} from=:::10.1.2.51,46546, 
vmId=11f3a2aa-7951-4064-92f9-bb8ab515373b (api:54)
2021-12-10 16:18:22,889+0100 INFO  (jsonrpc/7) [jsonrpc.JsonRpcServer] 
RPC call VM.getMigrationStatus succeeded in 0.00 seconds (__init__:312)
2021-12-10 16:18:23,431+0100 INFO  (jsonrpc/3) [jsonrpc.JsonRpcServer] 
RPC call Host.ping2 succeeded in 0.00 seconds (__init__:312)


Any ideas?

/niklas
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/BWSVMZGNRNK5MBLJH3HSKZPRBCITL5XL/


--
Nathanaël Blanchet

Supervision réseau
SIRE
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
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Con

[ovirt-users] ovirt 4.4.x series

2021-12-08 Thread Nathanaël Blanchet


Hello,

I found some informations about an upcoming  ovirt 4.5 release based on 
centos stream 9. Considering that Centos stream 9 will not be stable 
before  months, can we expect new 4.4.x releases following 4.4.9?


--
Nathanaël Blanchet

Supervision réseau
SIRE
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
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/JHHNKPSQDB4QKDRSQ5RLIILR24ZC4BAH/

[ovirt-users] Re: routing table and wrong ip rule attribution on hosts

Le 30 nov. 2021 13:18, Nathanaël Blanchet  a écrit :
Le 30/11/2021 à 12:00, Ales Musil a
  écrit :


  
  




  On Tue, Nov 30, 2021 at
11:16 AM Nathanaël Blanchet <blanc...@abes.fr>
wrote:
  
  

  

  Le 30 nov. 2021 10:31, Ales
Musil <amu...@redhat.com>
a écrit :

  




  On Tue, Nov 30, 2021 at 10:08
    AM Nathanaël Blanchet <blanc...@abes.fr>
wrote:
  
  

  Le 30/11/2021 à 07:25, Ales Musil a
écrit :
  
  

  
  
  
  
On Mon, Nov 29, 2021
  at 11:47 PM Nathanaël Blanchet
  <blanc...@abes.fr>
  wrote:

Hi
  all,



Hi,

 

  
  I 've finished migration from
  4.4.4 to 4.4.9 and I'm facing a
  strange 
  issue with routing table on my
  hosts: all IP addressed interfaces
  (and 
  in particular gluster and
  migration ones that requiere an
  IP) are not 
  part of the "254" or "0" usual ip
  rule.



Only network with default route
  role will be in the default table
  (254). This has been the case for
  quite a while.
What has changed in 4.4.8 is
  that now NetworkManager is aware
  of that, before the routes were
  managed outside of
NM and it might have caused
  some issues.

 

  
  for instance:
  
  [root@fuego ~]# nmcli con sh
  gluster |grep ipv4.route-table
ipv4.route-table:   202179335
  
  [root@fuego ~]# nmcli con sh
  migration |grep ipv4.route-table
ipv4.route-table:   316605387
  
  but ovirtmgmt:
  
  [root@fuego ~]# nmcli con sh
  ovirtmgmt |grep ipv4.route-table
ipv4.route-table:   254 (main)
  
  and obviously the main route table
  is empty:
  
  [root@ ~]# ip ro
  default via 10.34.100.65 dev
  ovirtmgmt proto dhcp metric 425
  10.34.100.0/24
  dev ovirtmgmt proto kernel scope
  link src 10.34.100.116

[ovirt-users] Re: routing table and wrong ip rule attribution on hosts


Le 30/11/2021 à 12:00, Ales Musil a écrit :



On Tue, Nov 30, 2021 at 11:16 AM Nathanaël Blanchet <mailto:blanc...@abes.fr>> wrote:




Le 30 nov. 2021 10:31, Ales Musil mailto:amu...@redhat.com>> a écrit :



On Tue, Nov 30, 2021 at 10:08 AM Nathanaël Blanchet
mailto:blanc...@abes.fr>> wrote:

Le 30/11/2021 à 07:25, Ales Musil a écrit :



On Mon, Nov 29, 2021 at 11:47 PM Nathanaël Blanchet
mailto:blanc...@abes.fr>> wrote:

Hi all,


Hi,


I 've finished migration from 4.4.4 to 4.4.9 and
I'm facing a strange
issue with routing table on my hosts: all IP
addressed interfaces (and
in particular gluster and migration ones that
requiere an IP) are not
part of the "254" or "0" usual ip rule.


Only network with default route role will be in the
default table (254). This has been the case for quite
a while.
What has changed in 4.4.8 is that now NetworkManager
is aware of that, before the routes were managed
outside of
NM and it might have caused some issues.


for instance:

[root@fuego ~]# nmcli con sh gluster |grep
ipv4.route-table
ipv4.route-table:   202179335

[root@fuego ~]# nmcli con sh migration |grep
ipv4.route-table
ipv4.route-table:   316605387

but ovirtmgmt:

[root@fuego ~]# nmcli con sh ovirtmgmt |grep
ipv4.route-table
ipv4.route-table:   254 (main)

and obviously the main route table is empty:

[root@ ~]# ip ro
default via 10.34.100.65 dev ovirtmgmt proto dhcp
metric 425
10.34.100.0/24 <http://10.34.100.0/24> dev
ovirtmgmt proto kernel scope link src 10.34.100.116
metric 425


Well the main table should contain only the default
route gateway.
You can take a look at other routes by:
ip route show table all

Indeed, other routes exists

[root@fuego ~]# ip ro sh table all
10.34.101.0/24 <http://10.34.101.0/24> dev gluster table
202179335 proto kernel scope link src 10.34.101.140 metric
426
10.34.106.0/23 <http://10.34.106.0/23> dev admin table
100729354 proto kernel scope link src 10.34.106.72 metric 425
10.34.108.0/23 <http://10.34.108.0/23> dev migration table
316605387 proto kernel scope link src 10.34.108.56 metric 427

but don't seem to be used by kernel like they should be by
the main table.


None of the concerned hosts can ping each other on
such interface, and
live migrations systematically fail.


That might be a different issue related to BZ#2022354
<https://bugzilla.redhat.com/2022354>. To check if
that's really the case
please take a look into oVirt engine and there you
should see all affected networks out-of-sync.
On the BZ there are two possible workarounds.

Not seems to be that BZ because there is no out of sync
network in my case, but the issue could be from the same
root cause, because of NM routing table integration.


This behaviour is new with 4.4.9 and I don't know
if it is a new (and
not achevied) network feature introduced with
centos stream to deal
network filtering packets.


A simple workaround would be "nmcli connection mod
migration
ipv4.route-table 0 && nmcli con up migration", but
I'd like to
understand why such  strange (and unuseful ?) rule
table are now
randomly attributed?


I would highly suggest against that because the
default route in the default table should be only one,
with exception to some backup scenarios.

Notice that this command doesn't add additionnal default
route in addition to the main one, but only source route
of the defined networks that allow hosts to be reachabled
on that networ

[ovirt-users] Re: routing table and wrong ip rule attribution on hosts

Le 30 nov. 2021 10:31, Ales Musil  a écrit :On Tue, Nov 30, 2021 at 10:08 AM Nathanaël Blanchet <blanc...@abes.fr> wrote:
  

  
  
Le 30/11/2021 à 07:25, Ales Musil a
  écrit :


  
  




  On Mon, Nov 29, 2021 at
11:47 PM Nathanaël Blanchet <blanc...@abes.fr> wrote:
  
  Hi all,
  
  
  
  Hi,
  
   
   
I 've finished migration from 4.4.4 to 4.4.9 and I'm facing
a strange 
issue with routing table on my hosts: all IP addressed
interfaces (and 
in particular gluster and migration ones that requiere an
IP) are not 
part of the "254" or "0" usual ip rule.
  
  
  
  Only network with default route role will be in the
default table (254). This has been the case for quite a
while.
  What has changed in 4.4.8 is that now NetworkManager is
aware of that, before the routes were managed outside of
  NM and it might have caused some issues.
  
   
   
for instance:

[root@fuego ~]# nmcli con sh gluster |grep ipv4.route-table
ipv4.route-table:   202179335

[root@fuego ~]# nmcli con sh migration |grep
ipv4.route-table
ipv4.route-table:   316605387

but ovirtmgmt:

[root@fuego ~]# nmcli con sh ovirtmgmt |grep
ipv4.route-table
ipv4.route-table:   254 (main)

and obviously the main route table is empty:

[root@ ~]# ip ro
default via 10.34.100.65 dev ovirtmgmt proto dhcp metric 425
10.34.100.0/24
dev ovirtmgmt proto kernel scope link src 10.34.100.116 
metric 425
  
  
  
  Well the main table should contain only the default route
gateway. 
  
  You can take a look at other routes by:
  ip route show table all
  

  

Indeed, other routes exists

  

   
   

  

[root@fuego ~]# ip ro sh table all
10.34.101.0/24 dev gluster table 202179335 proto kernel scope link
src 10.34.101.140 metric 426 
10.34.106.0/23 dev admin table 100729354 proto kernel scope link src
10.34.106.72 metric 425
10.34.108.0/23 dev migration table 316605387 proto kernel scope link
src 10.34.108.56 metric 427 
but don't seem to be used by kernel like they should be by the
  main table.


  

   
None of the concerned hosts can ping each other on such
interface, and 
live migrations systematically fail.
  
  
  
  That might be a different issue related to BZ#2022354.
  To check if that's really the case
  please take a look into oVirt
  engine and there you should see all affected networks
  out-of-sync. 

  On the BZ there are two possible
  workarounds.


  

Not seems to be that BZ because there is no out of sync network in
my case, but the issue could be from the same root cause, because of
NM routing table integration.

  

   
   
This behaviour is new with 4.4.9 and I don't know if it is a
new (and 
not achevied) network feature introduced with centos stream
to deal 
network filtering packets.
  
   
A simple workaround would be "nmcli connection mod migration

ipv4.route-table 0 && nmcli con up migration", but
I'd like to 
understand why such  strange (and unuseful ?) rule table are
now 
randomly attributed?
  
  
  
  I would highly suggest against that because the default
route in the default table should be only one, with
exception to some backup scenarios. 
  

  

Notice that this command doesn't add additionnal default route in
  addition to the main one, but only source route of the defined
  networks that allow hosts to be reachabled on that networks.

[root@fuego ~]# ip ro
  default via 10.34.100.65 dev ovirtmgmt proto dhcp metric 425 
  10.34.100.0/24 dev ovirtmgmt proto kernel scope link src
  10.34.100.116 metric 425 
  10.34.106.0/23 dev admin proto kernel scope link src 10.34.107.76
  metric 450 
  10.34.108.0/23 dev migrati

[ovirt-users] Re: routing table and wrong ip rule attribution on hosts