[ovirt-users] Re: Self Hosted Engine disk increase

[Yedidyah Bar David]

On Wed, Oct 6, 2021 at 7:58 PM Paulo Silva  wrote:
>
> Hi,
>
> Is there any official procedure to increase the disk size of a self-hosted 
> engine?

None that I know of.

The only official way is to use backup/restore (to a new SD).

The default disk size should be enough for most needs. Are you sure
you can't clean it up a bit?

Best regards,
-- 
Didi
___
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/BOGIGGYH6K2KXUOEBFPRGUDIE4ZIWWEE/

[ovirt-users] Re: Important changes to the oVirt Terraform Provider

[Janos Bonic]

Hello Marek,

Thank you for your feedback, VM and NIC management will be covered. I will
add your issue as a test case and I will notify you on the issue when you
can give it a go.

Your point about transition documentation is also noted, I will add a guide
outlining the changes you need to make to your code. (This will actually
come in handy for us internally too, so double thanks for the suggestion!)

Janos


On Wed, Oct 6, 2021, 5:52 PM marek  wrote:

> hi,
>
>
>
> *Which resources are the most important to you? *
>
> VM, nic
>
>
> *How does this change impact you? *
>
> rewrite current code
>
>
> *Can we make the transition smoother for you? *
>
> some transition guide/tips
>
> *Would you do anything differently in the light of the issues described
> above?*
>
> no
>
>
> p.s. thank you for terraform provider and publishing it to the terraform
> registry!
>
> p.s.2 any chance that 2.0 solve this problem ?
> https://github.com/oVirt/terraform-provider-ovirt/issues/217   ;)
>
> Marek
>
>
> Dne 06/10/2021 v 12:53 Janos Bonic napsal(a):
>
> Dear oVirt community,
>
> We are making sweeping and backwards-incompatible changes to the oVirt
> Terraform provider. *We want your feedback before we make these changes.*
>
> Here’s the short list what we would like to change, please read the
> details below.
>
>1. The current master branch will be renamed to legacy. The usage of
>this provider will be phased out within Red Hat around the end / beginning
>of next year. If you want to create a fork, we are happy to add a link to
>your fork to the readme.
>2. A new main branch will be created and a *new Terraform provider*
>written from scratch on the basis of go-ovirt-client
>. (Preview here
>) This
>provider will only have limited functionality in its first release.
>3. This new provider will be released to the Terraform registry, and
>will have full test coverage and documentation. This provider will be
>released as version v2.0.0 when ready to signal that it is built on the
>Terraform SDK v2.
>4. A copy of this new Terraform provider will be kept in the v1 branch
>and backported to the Terraform SDK v1 for the benefit of the OpenShift
>Installer . We will not tag
>any releases, and we will not release this backported version in binary
>form.
>5. We are hosting a *community call* on the 14th of October at 13:00
>UTC on this link . Please join
>to provide feedback and suggest changes to this plan.
>
> Why are we doing this?
>
> The original Terraform provider
>  for oVirt was
> written four years ago by @Maigard  at
> EMSL-MSC . The oVirt
> fork of this provider is about 2 years old and went through rapid
> expansion, adding a large number of features.
>
> Unfortunately, this continuous rapid growth came at a price: the original
> test infrastructure deteriorated and certain resources, especially the
> virtual machine creation ballooned to a size we feel has become
> unmaintainable.
>
> If you tried to contribute to the Terraform provider recently, you may
> have noticed that our review process has become extremely slow. We can no
> longer run the original tests, and our end to end test suite is not
> integrated outside of the OpenShift CI system. Every change to the provider
> requires one of only 3 people to review the code and also run a manual test
> suite that is currently only runable on one computer.
>
> We also noticed an increasing number of bugs reported on OpenShift on
> oVirt/RHV related to the Terraform provider.
>
> Our original plan was that we would fix the test infrastructure and then
> subsequently slowly transition API calls to go-ovirt-client, but that
> resulted in a PR that is over 5000 lines in code
>  and cannot
> in good conscience be merged in a single piece. Splitting it up is
> difficult, and would likely result in broken functionality where test
> coverage is not present.
> What are we changing for you, the users?
>
> First of all, documentation. You can already preview the documentation
> here
> .
> You will notice that the provider currently only supports a small set of
> features. You can find the full list of features
> 
> we are planning for the first release on GitHub. However, if you are using
> resources like cluster creation, etc. these will currently not work and we
> recommend sticking to the old provider for the time being.
>
> The second big change will be how resources are 

[ovirt-users] Re: qemu-guest-agent not reporting IP address on boot?

[Schreuders, Cliffe]

Following up on this, for the benefit of anyone else who faces the same 
problem, I'm happy to say we have VMs reporting IP addresses with latest Kali 
now.

I've not managed to fix the fact that it is taking Kali a lot longer to report 
IP address (compared to the last version that shipped with ovirt-guest-agent, 
which reports IP addresses almost instantly on boot), but I extended the time 
out to give a lot more time for the VM to get an IP address (it is taking 
around 5 minutes), and also needed to add exception handling to the Vagrant 
oVirt plugin, around accessing the nics_service, which was throwing an oVirt 
error after a few minutes "Can't send request: Failed sending data to the 
peer", after allowing those errors to be ignored during the wait for an IP to 
be reported, it does eventually report the IP address, and other guest 
information. VMs are now reliably building again (albeit taking a little 
longer).

Thanks.

Cheers,
Cliffe.
To view the terms under which this email is distributed, please go to:-
https://leedsbeckett.ac.uk/disclaimer/email
___
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/TBPVAJ463T2X2Z4BJ6E7IWP3E2XLNXC7/

[ovirt-users] Re: qemu-guest-agent not reporting IP address on boot?

[Schreuders, Cliffe]

>> Thank you. It does look like that bug could be related.

> Is the problem just with the IP addresses? Do you see other guest
information or are those missing too?
>Tomas

I've just been testing this further, as pinning the old package introduced some 
dependency problems with other software. I would like to avoid manually 
compiling or editing dependancies in packages, etc.

Some other live guest information does seem to partly populate correctly, most 
obvious being free memory. However, the Guest Info tab in oVirt admin panel is 
showing "Unknown" for Type, Architecture, etc. However, I've just checked a 
Kali VM that has managed to report it's IP address to oVirt and that Guest Info 
is still showing as Unknown.

I'm really hoping to find an action on the client that can force the 
information to populate. It seemed as though connecting to the console and 
running "service qemu restart; service networking restart" often does the trick 
when run manually, but my hackish approach of having those happen at boot in 
the template don't seem to fix the issue of the IP address being picked up 
automatically on boot.

Can you suggest any commands we could run on the client that could encourage 
the agent to report the IP address?

Thank you.

Cheers,
Cliffe.

To view the terms under which this email is distributed, please go to:-
https://leedsbeckett.ac.uk/disclaimer/email
___
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/TAKSLG4TSXJO72ZJSQIBD7FCJ34W3NVO/

[ovirt-users] Self Hosted Engine disk increase

[Paulo Silva]

Hi,

Is there any official procedure to increase the disk size of a self-hosted 
engine?

Regards
___
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/224X7QXC462VYQVCSN57OEEMCGX7YBNM/

[ovirt-users] Re: Important changes to the oVirt Terraform Provider

[marek]

hi,

*
*

*Which resources are the most important to you?
*

VM, nic*
*

*How does this change impact you?
*

rewrite current code
**

*Can we make the transition smoother for you?
*

some transition guide/tips
**

*Would you do anything differently in the light of the issues described 
above?*


no


p.s. thank you for terraform provider and publishing it to the terraform 
registry!


p.s.2 any chance that 2.0 solve this problem ? 
https://github.com/oVirt/terraform-provider-ovirt/issues/217   ;)


Marek


Dne 06/10/2021 v 12:53 Janos Bonic napsal(a):


Dear oVirt community,

We are making sweeping and backwards-incompatible changes to the oVirt 
Terraform provider. *We want your feedback before we make these changes.*


Here’s the short list what we would like to change, please read the 
details below.


 1. The current |master| branch will be renamed to |legacy|. The usage
of this provider will be phased out within Red Hat around the end
/ beginning of next year. If you want to create a fork, we are
happy to add a link to your fork to the readme.
 2. A new |main| branch will be created and a *new Terraform provider*
written from scratch on the basis of go-ovirt-client
. (Preview here
)
This provider will only have limited functionality in its first
release.
 3. This new provider will be released to the Terraform registry, and
will have full test coverage and documentation. This provider will
be released as version v2.0.0 when ready to signal that it is
built on the Terraform SDK v2.
 4. A copy of this new Terraform provider will be kept in the |v1|
branch and backported to the Terraform SDK v1 for the benefit of
the OpenShift Installer .
We will not tag any releases, and we will not release this
backported version in binary form.
 5. We are hosting a *community call* on the 14th of October at 13:00
UTC on this link . Please
join to provide feedback and suggest changes to this plan.


Why are we doing this?

The original Terraform provider 
 for oVirt was 
written four years ago by @Maigard  at 
EMSL-MSC . The 
oVirt fork of this provider is about 2 years old and went through 
rapid expansion, adding a large number of features.


Unfortunately, this continuous rapid growth came at a price: the 
original test infrastructure deteriorated and certain resources, 
especially the virtual machine creation ballooned to a size we feel 
has become unmaintainable.


If you tried to contribute to the Terraform provider recently, you may 
have noticed that our review process has become extremely slow. We can 
no longer run the original tests, and our end to end test suite is not 
integrated outside of the OpenShift CI system. Every change to the 
provider requires one of only 3 people to review the code and also run 
a manual test suite that is currently only runable on one computer.


We also noticed an increasing number of bugs reported on OpenShift on 
oVirt/RHV related to the Terraform provider.


Our original plan was that we would fix the test infrastructure and 
then subsequently slowly transition API calls to go-ovirt-client, but 
that resulted in a PR that is over 5000 lines in code 
 and 
cannot in good conscience be merged in a single piece. Splitting it up 
is difficult, and would likely result in broken functionality where 
test coverage is not present.



What are we changing for you, the users?

First of all, documentation. You can already preview the documentation 
here 
. 
You will notice that the provider currently only supports a small set 
of features. You can find the full list of features 
 
we are planning for the first release on GitHub. However, if you are 
using resources like cluster creation, etc. these will currently not 
work and we recommend sticking to the old provider for the time being.


The second big change will be how resources are treated. Instead of 
creating large resources that need to call several of the oVirt APIs 
to create, we will create resources that are only calling one API. 
This will lead to fewer bugs. For example:


  * |ovirt_vm| will create the VM, but not attach any disks or network
interfaces to it.
  * |ovirt_disk_attachment| or |ovirt_disk_attachments| will attach a
disk to the VM.
  * |ovirt_nic| will create a network interface.
  * |ovirt_vm_start| will start the virtual machine when provisioned,
stop it when deprovisioned.

You can use the 

[ovirt-users] Re: API how to increase extend resize disk VM

[Vojtech Juranek]

On Wednesday, 6 October 2021 15:14:10 CEST ovirt@nevim.eu wrote:
> ovirt.domain.com: Software Version:4.3.4.3-1.el7
> ovirt2.domain.com: Software Version:4.3.10.4-1.el7
> 
> I test everything on the server ovirt2.domains.com.
> 
> No i try #1:
> GET
> https://ovirt2.domain.com/ovirt-engine/api/disks/f770c0d1-dd0d-40a8-a69a-a6
> 3d8db5c2cc
 
> Result #2:
>  id="1e0a39c1-08d5-41b1-8e4e-5174597c59c9">
 
> false
> 107374182400
> qcow2_v3
> false
> true
> ok
> image
> 20090257408
> ...
> 
> 
> No i try #2:
> PUT
> https://ovirt2.domain.com/ovirt-engine/api/disks/f770c0d1-dd0d-40a8-a69a-a6
> 3d8db5c2cc
 
>   30737418240
> 
> 
> Result #2:   
> "content": " standalone=\"yes\"?>\n\nUpdating disk attributes other
> than QCOW version is permitted only for disk-attachments, which reside
> under VMs.\nOperation Failed\n\n",
> "msg": "Status code was 409 and not [200]: HTTP Error 409: Conflict",
> "url":
> "https://ovirt2.domain.com/ovirt-engine/api/disks/f770c0d1-dd0d-40a8-a69a-a
> 63d8db5c2cc", 
> So version 4.3 really has no way to adjust the disk size via the API? The
> only way is to upgrade to 4.4?

It does, but the disk has t be attached to a VM (Vm don't has to be running).
Example XML (extend.xml):


  
2147483648
  


Example command using this XML:

curl --insecure -X PUT --header "Accept: application/xml" --header 
"Content-Type: application/xml" --user "admin@internal:ovirt" -T extend.xml 
https://engine-test.local/ovirt-engine/api/vms/651faf06-9dd3-41a5-94f6-ef126a933923/diskattachments/69f96ba5-df7b-46d7-93c1-93e4adf0404b

signature.asc
Description: This is a digitally signed message part.
___
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/L6YNAFWU5AQEGCQQ76BFY2OXBNEOJEDX/

[ovirt-users] adding new node to host engine is getting failed - engine version latest 4.4.8

[dhanaraj.ramesh--- via Users]

Hi Team

when I try to add a new node to the cluster, the installation getting failed 
with below error 
Host beclovkvma04.bec.lab installation failed. Task Run PKI enroll request for 
vdsm and QEMU failed to execute. Please check logs for more details: 
/var/log/ovirt-engine/host-deploy/ovirt-host-deploy-ansible-20211006191147-beclovkvma04.bec.lab-e9351609-1bf4-4a8e-adcc-af459f8b25a0.log.

log shows as below 
oR4K1dI9NIaH1jSEtBnIC0Qycxz1i9", 
"/knKXJLDKeuRsY2holB/BYbMECe4dpseRO+SJPnoqLbK0S6lEf/F6rIcowcg4KbS", 
"TYjL8g8P6/mM", "-END CERTIFICATE REQUEST-" ],
"stderr_lines" : [ "Generating a RSA private key", 
"...+", "+", 
"writing new private
key to '/tmp/ansible.wjc0hdouvdsm'", "-" ],
"failed" : false,
"item" : {
  "changed" : true,
  "path" : "/tmp/ansible.wjc0hdouvdsm",
  "uid" : 0,
  "gid" : 0,
  "owner" : "root",
  "group" : "root",
  "mode" : "0600",
  "state" : "file",
  "secontext" : "unconfined_u:object_r:user_tmp_t:s0",
  "size" : 0,
  "invocation" : {
"module_args" : {
  "state" : "file",
  "suffix" : "vdsm",
  "prefix" : "ansible.",
  "path" : null
}
  },
  "failed" : false,
  "item" : {
"suffix" : "vdsm",
"pending_file" : "keys/vdsmkey.pending.pem",
"req_dir" : "requests"
  },
  "ansible_loop_var" : "item"
},
"ansible_loop_var" : "item"
  }
}, {
  "diff" : [ ],
  "dest" : 
"/etc/pki/ovirt-engine/requests-qemu/beclovkvma04.bec.lab.req",
  "src" : 
"/var/lib/ovirt-engine/.ansible/tmp/ansible-tmp-1633527734.1252306-38395-243978746272048/source",
  "md5sum" : "76137d8fb7063ee3ecce0a1637e991e9",
  "checksum" : "37c73f4ac229f1837a9b5f4a84162426547de18e",
  "changed" : true,


"cmd" : [ "/usr/share/ovirt-engine/bin/pki-enroll-request.sh", 
"--name=beclovkvma04.bec.lab", "--subject=/O=bec.lab
/CN=beclovkvma04.bec.lab", "--san=DNS:beclovkvma04.bec.lab", "--days=398", 
"--timeout=30", "--ca-file=ca", "--cert-dir=certs"
, "--req-dir=requests" ],
  "stdout" : "",
  "stderr" : "Using configuration from openssl.conf\nunable to load 
number from serial.txt\nerror while loading serial 
number\n139654062544704:error:
0D066096:asn1 encoding routines:a2i_ASN1_INTEGER:short 
line:crypto/asn1/f_int.c:140:\nCannot sign certificate",
  "rc" : 1,
  "start" : "2021-10-06 19:12:14.648053",
  "end" : "2021-10-06 19:12:14.673708",
  "delta" : "0:00:00.025655",
  "changed" : true,
  "failed" : true,
  "invocation" : {
"module_args" : {
  "_raw_params" : 
"\"/usr/share/ovirt-engine/bin/pki-enroll-request.sh\"\n\"--name=beclovkvma04.bec.lab\"\n\"--subject=/O=bec.bsn
lab.broadcom.net/CN=beclovkvma04.bec.lab\"\n\"--san=DNS:beclovkvma04.bec.bsnlab.broadcom.net\"\n\"--days=398\"\n\"--timeout=30\"\n\"--ca-file
=ca\"\n\"--cert-dir=certs\"\n\"--req-dir=requests\"\n",
  "warn" : true,
  "_uses_shell" : false,
  "stdin_add_newline" : true,
  "strip_empty_ends" : true,
  "argv" : null,
  "chdir" : null,
  "executable" : null,
  "creates" : null,
  "removes" : null,
  "stdin" : null
}
  },
___
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/BOYU2VWWIM4UPAEHMP6DVRVHEJTIQPUZ/

[ovirt-users] adding new node to host engine is getting failed - engine version latest 4.4.8

[dhanaraj.ramesh--- via Users]

Hi Team

when I try to add a new node to the cluster, the installation getting failed 
with below error 
Host beclovkvma04.bec.lab installation failed. Task Run PKI enroll request for 
vdsm and QEMU failed to execute. Please check logs for more details: 
/var/log/ovirt-engine/host-deploy/ovirt-host-deploy-ansible-20211006191147-beclovkvma04.bec.lab-e9351609-1bf4-4a8e-adcc-af459f8b25a0.log.

log shows as below 
oR4K1dI9NIaH1jSEtBnIC0Qycxz1i9", 
"/knKXJLDKeuRsY2holB/BYbMECe4dpseRO+SJPnoqLbK0S6lEf/F6rIcowcg4KbS", 
"TYjL8g8P6/mM", "-END CERTIFICATE REQUEST-" ],
"stderr_lines" : [ "Generating a RSA private key", 
"...+", "+", 
"writing new private
key to '/tmp/ansible.wjc0hdouvdsm'", "-" ],
"failed" : false,
"item" : {
  "changed" : true,
  "path" : "/tmp/ansible.wjc0hdouvdsm",
  "uid" : 0,
  "gid" : 0,
  "owner" : "root",
  "group" : "root",
  "mode" : "0600",
  "state" : "file",
  "secontext" : "unconfined_u:object_r:user_tmp_t:s0",
  "size" : 0,
  "invocation" : {
"module_args" : {
  "state" : "file",
  "suffix" : "vdsm",
  "prefix" : "ansible.",
  "path" : null
}
  },
  "failed" : false,
  "item" : {
"suffix" : "vdsm",
"pending_file" : "keys/vdsmkey.pending.pem",
"req_dir" : "requests"
  },
  "ansible_loop_var" : "item"
},
"ansible_loop_var" : "item"
  }
}, {
  "diff" : [ ],
  "dest" : 
"/etc/pki/ovirt-engine/requests-qemu/beclovkvma04.bec.lab.req",
  "src" : 
"/var/lib/ovirt-engine/.ansible/tmp/ansible-tmp-1633527734.1252306-38395-243978746272048/source",
  "md5sum" : "76137d8fb7063ee3ecce0a1637e991e9",
  "checksum" : "37c73f4ac229f1837a9b5f4a84162426547de18e",
  "changed" : true,


"cmd" : [ "/usr/share/ovirt-engine/bin/pki-enroll-request.sh", 
"--name=beclovkvma04.bec.lab", "--subject=/O=bec.lab
/CN=beclovkvma04.bec.lab", "--san=DNS:beclovkvma04.bec.lab", "--days=398", 
"--timeout=30", "--ca-file=ca", "--cert-dir=certs"
, "--req-dir=requests" ],
  "stdout" : "",
  "stderr" : "Using configuration from openssl.conf\nunable to load 
number from serial.txt\nerror while loading serial 
number\n139654062544704:error:
0D066096:asn1 encoding routines:a2i_ASN1_INTEGER:short 
line:crypto/asn1/f_int.c:140:\nCannot sign certificate",
  "rc" : 1,
  "start" : "2021-10-06 19:12:14.648053",
  "end" : "2021-10-06 19:12:14.673708",
  "delta" : "0:00:00.025655",
  "changed" : true,
  "failed" : true,
  "invocation" : {
"module_args" : {
  "_raw_params" : 
"\"/usr/share/ovirt-engine/bin/pki-enroll-request.sh\"\n\"--name=beclovkvma04.bec.lab\"\n\"--subject=/O=bec.bsn
lab.broadcom.net/CN=beclovkvma04.bec.lab\"\n\"--san=DNS:beclovkvma04.bec.bsnlab.broadcom.net\"\n\"--days=398\"\n\"--timeout=30\"\n\"--ca-file
=ca\"\n\"--cert-dir=certs\"\n\"--req-dir=requests\"\n",
  "warn" : true,
  "_uses_shell" : false,
  "stdin_add_newline" : true,
  "strip_empty_ends" : true,
  "argv" : null,
  "chdir" : null,
  "executable" : null,
  "creates" : null,
  "removes" : null,
  "stdin" : null
}
  },
___
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/PMROMRVNN2RW3WKQAIBSGBWWX5BW4LEE/

[ovirt-users] Re: API how to increase extend resize disk VM

[ovirt . org]

ovirt.domain.com: Software Version:4.3.4.3-1.el7
ovirt2.domain.com: Software Version:4.3.10.4-1.el7

I test everything on the server ovirt2.domains.com.

No i try #1:
GET 
https://ovirt2.domain.com/ovirt-engine/api/disks/f770c0d1-dd0d-40a8-a69a-a63d8db5c2cc

Result #2:


false
107374182400
qcow2_v3
false
true
ok
image
20090257408
...


No i try #2:
PUT 
https://ovirt2.domain.com/ovirt-engine/api/disks/f770c0d1-dd0d-40a8-a69a-a63d8db5c2cc

30737418240


Result #2:   
"content": "\n\nUpdating disk attributes other than 
QCOW version is permitted only for disk-attachments, which reside under 
VMs.\nOperation Failed\n\n",
"msg": "Status code was 409 and not [200]: HTTP Error 409: Conflict",
"url": 
"https://ovirt2.domain.com/ovirt-engine/api/disks/f770c0d1-dd0d-40a8-a69a-a63d8db5c2cc;,

So version 4.3 really has no way to adjust the disk size via the API? The only 
way is to upgrade to 4.4?
___
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/IHYRZE4HJIFL7L7CUTFEMZD2VZJVSVWW/

[ovirt-users] Re: API how to increase extend resize disk VM

[Shani Leviim]

Hi,
The ability to update a disk and its size was upgraded in 4.4
http://ovirt.github.io/ovirt-engine-api-model/4.4/#services/disk/methods/update
That way, you can edit floating disk parameters, such as extend its size,
without attaching the disk to a VM.

On version 4.3, as already mentioned, the disk should be attached to the VM.
In your case, you can see the disk's size with the following request:
GET
https://ovirt.domain.com/ovirt-engine/api/disks/f770c0d1-dd0d-40a8-a69a-a63d8db5c2cc

Is there some more info on the engine log?


*Regards,*

*Shani Leviim*


On Tue, Oct 5, 2021 at 10:05 PM  wrote:

> I try this: PUT
> https://ovirt.domain.com/ovirt-engine/api/vms/678faf6f-fa5f-4785-a365-e1b85925575f/diskattachments/f770c0d1-dd0d-40a8-a69a-a63d8db5c2cc
>
> 
>   true
>   true
>   
> 30737418240
>   
> 
>
> I recieve: Request syntactically incorrect.
> Status code was 400 and not [200]: HTTP Error 400: Bad Request
> ___
> 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/PUFVAU7GGOZ4ZMFMUNDWATAPPSXMKOTE/
>
___
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/3OHDOVP276OGTR6OAZ2ZS64ZOKRWTNOY/

[ovirt-users] Important changes to the oVirt Terraform Provider

[Janos Bonic]

Dear oVirt community,

We are making sweeping and backwards-incompatible changes to the oVirt
Terraform provider. *We want your feedback before we make these changes.*

Here’s the short list what we would like to change, please read the details
below.

   1. The current master branch will be renamed to legacy. The usage of
   this provider will be phased out within Red Hat around the end / beginning
   of next year. If you want to create a fork, we are happy to add a link to
   your fork to the readme.
   2. A new main branch will be created and a *new Terraform provider*
   written from scratch on the basis of go-ovirt-client
   . (Preview here
   ) This
   provider will only have limited functionality in its first release.
   3. This new provider will be released to the Terraform registry, and
   will have full test coverage and documentation. This provider will be
   released as version v2.0.0 when ready to signal that it is built on the
   Terraform SDK v2.
   4. A copy of this new Terraform provider will be kept in the v1 branch
   and backported to the Terraform SDK v1 for the benefit of the OpenShift
   Installer . We will not tag any
   releases, and we will not release this backported version in binary form.
   5. We are hosting a *community call* on the 14th of October at 13:00 UTC
   on this link . Please join to
   provide feedback and suggest changes to this plan.

Why are we doing this?

The original Terraform provider
 for oVirt was
written four years ago by @Maigard  at EMSL-MSC
. The oVirt fork of
this provider is about 2 years old and went through rapid expansion, adding
a large number of features.

Unfortunately, this continuous rapid growth came at a price: the original
test infrastructure deteriorated and certain resources, especially the
virtual machine creation ballooned to a size we feel has become
unmaintainable.

If you tried to contribute to the Terraform provider recently, you may have
noticed that our review process has become extremely slow. We can no longer
run the original tests, and our end to end test suite is not integrated
outside of the OpenShift CI system. Every change to the provider requires
one of only 3 people to review the code and also run a manual test suite
that is currently only runable on one computer.

We also noticed an increasing number of bugs reported on OpenShift on
oVirt/RHV related to the Terraform provider.

Our original plan was that we would fix the test infrastructure and then
subsequently slowly transition API calls to go-ovirt-client, but that
resulted in a PR that is over 5000 lines in code
 and cannot in
good conscience be merged in a single piece. Splitting it up is difficult,
and would likely result in broken functionality where test coverage is not
present.
What are we changing for you, the users?

First of all, documentation. You can already preview the documentation here
.
You will notice that the provider currently only supports a small set of
features. You can find the full list of features

we are planning for the first release on GitHub. However, if you are using
resources like cluster creation, etc. these will currently not work and we
recommend sticking to the old provider for the time being.

The second big change will be how resources are treated. Instead of
creating large resources that need to call several of the oVirt APIs to
create, we will create resources that are only calling one API. This will
lead to fewer bugs. For example:

   - ovirt_vm will create the VM, but not attach any disks or network
   interfaces to it.
   - ovirt_disk_attachment or ovirt_disk_attachments will attach a disk to
   the VM.
   - ovirt_nic will create a network interface.
   - ovirt_vm_start will start the virtual machine when provisioned, stop
   it when deprovisioned.

You can use the depends_on

meta-argument to make sure disks and network interfaces are attached before
you start the VM. Alternatively, you can hot-plug network interfaces later.
For example:

resource "ovirt_vm" "test" {
cluster_id  = "some-cluster-id"
template_id = "some-template-id"
}

resource "ovirt_disk" "test" {
storagedomain_id = "some-storage-domain-id"
format   = "cow"
size = 512
alias= "test"
sparse   = true
}

resource "ovirt_disk_attachment" "test" {
vm_id  = ovirt_vm.test.id
disk_id= 

[ovirt-users] Re: Import ISCSI target as data domain, cannot see old data

[Shani Leviim]

Hi,
After importing the storage domain, you can access it and import the
unregistered entities:
On the UI, once accessing the imported storage domain, you should have tabs
as 'VM import', 'Disk import' and 'Template import',
so you'll be able to register those existing entities back to your current
ovirt.


*Regards,*

*Shani Leviim*


On Wed, Oct 6, 2021 at 8:49 AM  wrote:

> Hi Team,
> Hope you are doing well.
>
> I had a standalone Ovirt Engine with 2 hosts, one 2TB ISCSI data domain
> (dell equallogic). Today the Ovirt Engine machine crashed so we have to
> bring up a new one, setup is good and when I try to import ISCSI data
> domain I can see volumes/Luns, but after import, Ovirt shows the volume is
> empty - 2TB free (so all old data on the ISCSI volume is not presenting).
> However when I login to the ISCSI target machine, it shows the old data
> (around 400GB) is in use.  Seems like the new Ovirt Engine cannot detect
> the old ISCSI data domain disk content.
>
> Thank you,
> Sincerely,
> SYZhao
> ___
> 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/Y75HHRCIUVNIL7QTX2I5SZG5EQYOSBLP/
>
___
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/JYEZ5BWTGMMLMI6WFMPTVL6TSPIM52UT/

[ovirt-users] Re: qemu-guest-agent not reporting IP address on boot?

[Tomáš Golembiovský]

On Mon, Oct 04, 2021 at 01:03:10PM +, Schreuders, Cliffe wrote:
> Thank you. It does look like that bug could be related.

Is the problem just with the IP addresses? Do you see other guest
information or are those missing too?

Tomas

> 
> I had an earlier version of the VM template which continued to work 
> correctly, and an updated version (via apt-get dist-upgrade) that did not 
> report IP addresses correctly.
> 
> I suspected that it might be related to the new ovirt/qemu user agent, so I 
> hold/pinned "ovirt-guest-agent" on the older template before re-running the 
> software updates.
> 
> This worked to create an updated Kali VM that reports it's IP address (albeit 
> more-or-less stuck with whatever dependencies the last ovirt-guest-agent has) 
> so it seems this is indeed an issue with qemu-guest-agent vs 
> ovirt-guest-agent.
> 
> Cheers,
> Cliffe.
> 
> From: Arik Hadas 
> Sent: 03 October 2021 12:04
> To: Schreuders, Cliffe 
> Cc: users ; Tomas Golembiovsky 
> Subject: Re: [ovirt-users] qemu-guest-agent not reporting IP address on boot?
> 
> 
> Caution External Mail: Do not click any links or open any attachments unless 
> you trust the sender and know that the content is safe.
> 
> 
> On Fri, Oct 1, 2021 at 5:51 PM 
> mailto:c.schreud...@leedsbeckett.ac.uk>> 
> wrote:
> Hi folks,
> 
> Kali Linux repos (based on Debian) no longer ship ovirt-guest-agent, and 
> instead package qemu-guest-agent. However, since this upgrade VMs based on 
> Kali no longer report their IP address to oVirt (and therefore timeout during 
> provisioning). If I interact with the VM console, the VM does have an IP 
> address, and the agent is running, yet oVirt reports N/A IP address. I've 
> tried restarting the agent, but that does not help. If I load the console and 
> use the VM it seems to increase the chances the IP address will eventually 
> makes it's way to oVirt, although I can't seem to reproduce an update, or get 
> it to provide the IP address on boot so that provisioning works reliably.
> 
> Any suggestions would be really appreciated.
> 
> Might be the same as/related to 
> https://bugzilla.redhat.com/show_bug.cgi?id=1981946
>  which is still being investigated
> 
> 
> Thank you.
> 
> Cheers,
> Cliffe.
> ___
> 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/FFINLLXPBRKYHNTBEI5GKZY53C3KX2OD/
> To view the terms under which this email is distributed, please go to:-
> https://leedsbeckett.ac.uk/disclaimer/email

-- 
Tomáš Golembiovský 
___
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/S5NEZD5KKFMQJ57FKHHUJ23FOCJBGQ4X/

[ovirt-users] Re: Hosted Engine ansible runner artifacts cleanup

[Martin Perina]

On Wed, Oct 6, 2021 at 7:50 AM Yedidyah Bar David  wrote:

> On Tue, Oct 5, 2021 at 8:50 PM Erez Zarum  wrote:
> >
> > Hey,
> > No, i am talking about the ansible-runner artifacts, when the
> ovirt-engine runs a playbook (which is a task in the webui for example), it
> creates a folder in /usr/share/ovirt-engine/ansible-runner/artifacts for
> each run.
>
> Thanks for the clarification. I don't have
> /usr/share/ovirt-engine/ansible-runner/artifacts on my engine machine.
> Which version do you use? Perhaps file a bug in bugzilla and attach a
> sosreport.
>

Periodic artifact clean up has been added to ansible-runner-service 1.0.6:

https://github.com/ansible/ansible-runner-service/releases

But I highly recommend to upgrade to the latest version 1.0.7

>
> >
> > There's a config.yml in /etc/ansible-runner-service but for some reason
> it does not affect anything.
>
> What do you mean by that? Did you try changing it and saw that this
> does not affect it at all? Or a specific setting? Something else?
>
> Thanks and best regards,
> --
> Didi
> ___
> 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/RUTJT53TQWJD4CCMCVWXXFQHCKKSLIQN/
>


-- 
Martin Perina
Manager, Software Engineering
Red Hat Czech s.r.o.
___
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/3LUCZOXMZWRJHZNUIE2FX4ISX7AGAYIZ/