September 2019 - Devel - oVirt List Archives

Outage Notification: Jenkins and Resources Are Not Accessible
by Anton Marchukov 26 Sep '19

26 Sep '19

Hello All. Please note that oVirt services hosted at PHX datacenter are not accessible. Main services running there are: jenkins.ovirt.org resources.ovirt.org This looks to be network related and we are working with the relevant teams to resolve it. Anton. -- Anton Marchukov Associate Manager - RHV DevOps - Red Hat

1 1

PROBLEM: Unable to retrieve value for MTU when default is used
by james.holohan＠oracle.com 26 Sep '19

26 Sep '19

I'm trying to automate a test which checks that the default values are being set correctly when adding a network to a host. When I create a network without specifying a value for the MTU, I can see from the web UI that the default value (1500) is being used. When I try to retrieve this MTU value from the SDK to ensure it is set correctly, the value returned is '0'. The same issue is not occurring if I explicitly set the MTU value when creating the network. When the MTU value is assigned, instead of using the default value, it is possible to retrieve it from the SDK correctly. Is there any way I can retrieve the value for MTU from the SDK when the default is used?

3 4

[ACTION REQUIRED] unicode patches merged, update otopi
by Yedidyah Bar David 26 Sep '19

26 Sep '19

Hi all, I now merged my pending patches to make otopi use unicode strings for "everything" (well, partially, for now) instead of "str" in python2. There were two stacks of patches - one for the engine and one for otopi. So if you git pull from the engine and it breaks, try to update otopi and see if it helps. If not, ping me :-) Best regards, -- Didi

1 1

planned Jenkins restart
by Evgheni Dereveanchin 25 Sep '19

25 Sep '19

Hi everyone, I'll be performing a planned Jenkins restart within the next hour. No new jobs will be scheduled during this maintenance period. I will inform you once it is back online. -- Regards, Evgheni Dereveanchin

1 1

CI is not triggered for pushed gerrit updates
by Amit Bawer 25 Sep '19

25 Sep '19

CI has stopped from being triggered for pushed gerrit updates. Example at: https://gerrit.ovirt.org/#/c/103320/ last PS did not trigger CI tests. Please advise.

3 3

PROBLEM: Issue has been detected with gerrit trigger.
by Ehud Yonasi 25 Sep '19

25 Sep '19

Hey everyone, A problem was identified that causes the CI not working with gerrit patches. We are working on fixing the automatic triggering and bringing it online asap. We are sorry for the inconvenience at the moment. If you want to run the CI for your patch atm you can use the manual gerrit trigger job: https://jenkins.ovirt.org/gerrit_manual_trigger/ Regards, Ehud.

1 2

vdsm has been tagged (v4.30.33)
by Milan Zamazal 24 Sep '19

24 Sep '19

1 0

ovirt-engine has been tagged (ovirt-engine-4.3.5.6)
by Tal Nisan 24 Sep '19

24 Sep '19

1 0

unicode sandwich in otopi/engine-setup
by Yedidyah Bar David 24 Sep '19

24 Sep '19

Hi all, This is in a sense a continuation of the thread "Why filetransaction needs to encode the content to utf-8?", but I decided that a new thread is better. I started to systematically convert the code to use a unicode sandwich. I admit it was harder than I expected, and made me think somewhat differently about the move to python3, and about how reasonable (or not) it is to develop in the common subset of python2 and python3 vs ditching python2 and moving fully to python3. It seems like at least parts of our (integration team) code will still have to run in python2 also in oVirt 4.4, so I guess we'll not have much choice :-) Current patches are only for otopi and engine-setup, and are by no means thorough - I didn't check each and every open() call and similar ones. But it's enough for getting engine-setup finish successfully on both python2 and python3 (EL7 and Fedora 29), with some utf-8 inserted in relevant places of the input (for the plugins already handled). I didn't bother trying non-utf-8 encodings. Perhaps I should, but it's not completely clear to me what's the best approach [2]. Currently, you must have both otopi and engine updated to get things working. If there is demand, I might spend some time splitting/rebasing/etc to make it possible to update just one of them and only later the other, but not sure it's worth it. I don't mind splitting/squashing if it makes reviews simpler, but I think the patches are ok as-is. These are the bottom patches of each stack: otopi: https://gerrit.ovirt.org/102085 engine-setup: https://gerrit.ovirt.org/102934 [1] http://python-future.org/unicode_literals.html [2] https://stackoverflow.com/questions/4012571/python-which-encoding-is-used-f… Thanks and best regards, -- Didi

2 5

ovirt-engine has been tagged (ovirt-engine-4.3.6.6)
by Tal Nisan 23 Sep '19

23 Sep '19

1 0

Re: Certificate checking on TLS migrations to an IP address
by Milan Zamazal 23 Sep '19

23 Sep '19

Daniel P. Berrangé <berrange(a)redhat.com> writes: > On Wed, Sep 04, 2019 at 03:38:25PM +0200, Milan Zamazal wrote: >> Hi, I'm trying to add TLS migrations to oVirt, but I've hit a problem >> with certificate checking. > >> >> oVirt uses the destination host IP address, rather than the host name, >> in the migration URI passed to virDomainMigrateToURI3. One reason for >> doing that is that a separate migration network may be used for >> migrations, while the host name resolves to the management network >> interface. >> >> But it causes a problem with certificate checking. The destination IP >> address is checked against the name, which is a host name, given in the >> destination certificate. That means there is mismatch and the migration >> fails. I don't think it'd be a very good idea to avoid the problem by >> putting IP addresses into server certificates. > > In fact that is *exactly* what you should be doing. > > Traditionally certificates were created with the 'common name' field > holding the fully qualified DNS based hostname for the server. > > This was long known to be a problem because it is very common for > servers to have multiple DNS names, or for clients to use the > unqualified hostname, or use the IP address(es). The problem with putting IP addresses into certificates is that the certificate must be updated each time an IP address changes, is added or is removed. Doing this in oVirt would be complicated and error-prone. While host names are stable, host networks and the related IP addresses may change. > Thus, the "Subject alt name" extension was created. This allows > certificates to be created containing multiple hostnames and > multiple IP addresses. The certificate will be validated correctly > if any one of those data items matches. When 'subject alt name' is > present in a certificate, the 'common name' field should be completely > ignored by compliant TLS clients, so you are free to put whatever > you want in the common name - hostname or IP address or blah... We can switch to using Subject Alt Name and we have a patch for that now based on your advice, but it doesn't solve the problem with tracking IP address changes and updating the corresponding certificates whenever a change occurs. > If you look at our docs, we updated them to illustrate how to > issue certs containing hostnames + IP addresses: > > https://libvirt.org/remote.html#Remote_TLS_server_certificates > >> >> Is there any way to make TLS migrations working under these >> circumstances? For instance, SPICE remote-viewer allows the client to >> specify the certificate subject to expect on the host when connecting to >> it using an IP address. Can (or could) libvirt do something similar? Would it be possible? We have host names in the certificates under our control and we know which host name to expect in the certificate regardless the IP address used for the given connection. Checking the certificate against a given host name would solve the problem easily and robustly for us. >> Or is there any other mechanism to handle this problem? Thanks, Milan

2 4

Not getting desired output for ovirt backup script.
by smidhunraj＠gmail.com 23 Sep '19

23 Sep '19

I am trying to run the code of https://github.com/wefixit-AT/oVirtBackup/blob/master/backup.py I am getting output as ovirtsdk.infrastructure.brokers.VMSnapshot object at 0x7fe9e59371d0 for the snippet print vm.snapshots.list(config.get_snapshot_description()) Is this the expected output. When i run the whole code .. The log i get is ... 2019-09-23 12:34:47,263: Start backup for: test2-sep20__vm25-183 2019-09-23 12:34:48,978: Snapshot creation started ... 2019-09-23 12:34:48,978: Snapshot created 2019-09-23 12:34:59,926: !!! No snapshot found !!! 2019-09-23 12:34:59,926: All backups done 2019-09-23 12:34:59,926: Backup failured for: 2019-09-23 12:34:59,927: test2-sep20__vm25-183 2019-09-23 12:34:59,927: Some errors occured during the backup, please check the log file Could you guys please help me.

1 0

vdsm has been tagged (v4.30.32)
by Milan Zamazal 23 Sep '19

23 Sep '19

1 0

master CQ: random failures for add_master_storage_domain
by Dusan Fodor 20 Sep '19

20 Sep '19

Hello all, lately i witnessed multiple failures for add_master_storage_domain test, which were not related to changes themselves, nor any infra issue. One example can be found here [1]. After investigation with huge help of Milan, issue is that Host falls from up state to whatever-but-not-up suddenly. 1. add_storage_domain picks a random host that is in up state 2. meantime engine starts fence action for it, so probably something gone bad with the host; the fence action fails with: *[org.ovirt.engine.core.bll.pm.FenceProxyLocator] (EE-ManagedThreadFactory-engineScheduled-Thread-38) [6692895f] Can not run fence action on host 'lago-basic-suite-master-host-0', no suitable proxy host was found.* 3. test fails on not being able to attach the domain to non-up host: *[org.ovirt.engine.api.restapi.resource.AbstractBackendResource] (default task-1) [] Operation Failed: [Cannot add storage server connection when Host status is not up]* For better orientation in failed job's engine log [1], fence action for host fails at :46:12,842-04 engine learns it cannot connect storage to host at :46:16,105-04 The test itself add_master_storage_domain starts at ~ :46:13,753 (according to lago log). Could you please check this? Thanks [1] https://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/15829 [2] https://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/15829/artifa…

3 6

FYI: RAM needed to compile the engine
by Fedor Gavrilov 19 Sep '19

19 Sep '19

Hi, This is all out of curiosity and just FYI. I noticed that most recent engine master on CentOS 7.7 now requires about 8 GB of memory to compile. Otherwise it will fail during GWT part. 6 GB - not good enough. Strange thing is about a month ago it worked perfectly fine for me on 4 GB. Also, I am running it on VM, so old rule applies: it is 8 gigs starting memory, not max memory. I wonder if someone had similar experience. Fedor

1 0

CentOS 7.7 has been released: note it's not supported for oVirt 4.2
by Sandro Bonazzola 19 Sep '19

19 Sep '19

CentOS 7.7 has been released this week. Please note that CentOS 7.7 is not supported for oVirt 4.2 and older releases. If you want to upgrade to CentOS 7.7 please upgrade to oVirt 4.3 too. If you don't plan to upgrade to oVirt 4.3 please be sure your yum repo files points to http://mirror.centos.org/centos/7.6.1810/ instead of http://mirror.centos.org/centos/7/. The http://mirror.centos.org/centos/7/ URL is now pointing to http://mirror.centos.org/centos/7.7.1908/ so yum upgrade will bring you 7.7 content which may break your 4.2 installation. Thanks, -- Sandro Bonazzola MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV Red Hat EMEA <https://www.redhat.com/> sbonazzo(a)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.*

2 1

Removing big (hc-* and metrics) suits from OST's check-patch (How to make OST faster in CI)
by Barak Korren 19 Sep '19

19 Sep '19

If you have been using or monitoring any OST suits recently, you may have noticed we've been suffering from long delays in allocating CI hardware resources for running OST suits. I'd like to briefly discuss the reasons behind this, what are planning to do to resolve this and the implication of those actions for big suit owners. As you might know, we have moved a while ago from running OST suits each on its own dedicated server to running them inside containers managed by OpenShift. That had allowed us to run multiple OST suits on the same bare-metal host which in turn increased our overall capacity by 50% while still allowing us to free up hardware for accommodating the kubevirt project on our CI hardware. Our infrastructure is currently built in a way where we use the exact same POD specification (and therefore resource settings) for all suits. Making it more flexible at this point would require significant code changes we are not likely to make. What this means is that we need to make sure our PODs have enough resources to run the most demanding suits. It also means we waste some resources when running less demanding ones. Given the set of OST suits we have ATM, we sized our PODs to allocate 32Gibs of RAM. Given the servers we have, this means we can run 15 suits at a time in parallel. This was sufficient for a while, but given increasing demand, and the expectation for it to increase further once we introduce the patch gating features we've been working on, we must find a way to significantly increase our suit running capacity. We have measured the amount of RAM required by each suit and came to the conclusion that for the vast majority of suits, we could settle for PODs that allocate only 14Gibs of RAM. If we make that change, we would be able to run a total of 40 suits at a time, almost tripling our current capacity. The downside of making this change is that our STDCI V2 infrastructure will no longer be able to run suits that require more then 14Gib of RAM. This effectively means it would no longer be possible to run these suits from OST's check-patch job or from the OST manual job. The list of relevant suits that would be affected follows, the suit owners, as documented in the CI configuration, have be added as "to" recipients to the message: - hc-basic-suite-4.3 - hc-basic-suite-master - metrics-suite-4.3 Since we're aware people would still like to be able to work with the bigger suits, we will leverage the nightly suit invocation jobs to enable then to be run in the CI infra. We will support the following use cases: - *Periodically running the suit on the latest oVirt packages* - this will be done by the nightly job like it is done today - *Running the suit to test changes to the suit`s code* - while currently this is done automatically by check-patch, this would have to be done manually in the future by manually triggering the nightly job and setting the REFSPEC parameter to point to the examined patch - *Triggering the suit manually* - This would be done by triggering the suit-specific nightly job (as opposed to the general OST manual job) The patches listed below implement the changes outlined above: - 102757 <https://gerrit.ovirt.org/102757> nightly-system-tests: big suits -> big containers - 102771 <https://gerrit.ovirt.org/102771>: stdci: Drop `big` suits from check-patch We know that making the changes we presented will make things a little less convenient for users and maintainers of the big suits, but we believe the benefits of having vastly increased execution capacity for all other suits outweigh those shortcomings. We would like to hear all relevant comment and questions from the quite owners and other interested parties, especially is you think we should not carry out the changes we propose. Please take the time to respond on this thread, or on the linked patches. Thanks, -- Barak Korren RHV DevOps team , RHCE, RHCi Red Hat EMEA redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted

2 4

OST fails
by Vojtech Juranek 19 Sep '19

19 Sep '19

Hi, OST has started to fail during today, fails with unsatisfied rpm dependencies, e.g. + yum install --nogpgcheck --downloaddir=/dev/shm -y ntp net-snmp ovirt-engine ovirt-log-collector 'ovirt-engine-extension-aaa-ldap*' otopi-debug-plugins cronie Error: Package: rsyslog-mmjsonparse-8.24.0-38.el7.x86_64 (alocalsync) Requires: rsyslog = 8.24.0-38.el7 Installed: rsyslog-8.24.0-34.el7.x86_64 (installed) rsyslog = 8.24.0-34.el7 and many more, see [1] for more details. Any idea what's wrong? Thanks Vojta [1] https://jenkins.ovirt.org/job/ovirt-system-tests_manual/5601/console

2 3

[User is not authorized to perform this action.]
by smidhunraj＠gmail.com 19 Sep '19

19 Sep '19

I am getting error as User is not authorized to perform this action.I am using oVirt api to manually attach a disk and snapshot to another virtual machine.This the code i used.The API i followed is '<disk_attachment> <active>true</active> <bootable>false</bootable> <interface>virtio</interface> <disk id="a94106b7-d348-4088-aaa1-5dfc46dc094e"> <snapshot id="6ecbb953-c4fb-4294-9988-e7cd2bd9b038"/> <description>My disk</description> <format>cow</format> <name>mydisk</name> </disk> </disk_attachment> ============================== The php code i have tried is ... public function attachSnapshotandActivateDisk( ) { $data = array(); $xmlStr = '<disk_attachment> <active>true</active> <bootable>false</bootable> <interface>virtio</interface> <disk id="a94106b7-d348-4088-aaa1-5dfc46dc094e"> <snapshot id="6ecbb953-c4fb-4294-9988-e7cd2bd9b038"/> <description>My disk</description> <format>cow</format> <name>mydisk</name> </disk> </disk_attachment> '; $curlParam = array( "url" => "vms/74a1a99f-87d1-4444-b394-f90e4f29f51f/diskattachments", "method" => "POST", "data" => $xmlStr ); // $text = print_r($curlParam, true); //echo "<script>console.log( 'curl Parameter".json_encode($text)."');</script>"; $data = $this->processCurlRequest($curlParam, "vm-create"); // if instance update failed if ($data['status'] != 'success') { Common::ovirtLog(array( "requestParam" => $curlParam, "responseParam" => $data, )); } // show the output of print_r function as a string // $text = print_r($data, true); echo $data['message']; die; echo "<script type='text/javascript'> console.log('checking the attach snapshot activate disk function diskid=" . json_encode($data) . "') </script>"; //Detach the disk // $this->detachSnapshotDisk() ; return $data; } Please help me.

2 1

vdsm has been tagged (v4.30.31)
by Milan Zamazal 19 Sep '19

19 Sep '19

4 5

how to login into ovirts particular virtualmachine from a remote client
by smidhunraj＠gmail.com 19 Sep '19

19 Sep '19

Is there any way i can login into the virtual machine in ovirt from my local machine.Please help me.

1 0

how to login into ovirts particular virtualmachine from a remote client
by smidhunraj＠gmail.com 19 Sep '19

19 Sep '19

Is there any way i can login into the virtual machine in ovirt from my local machine.Please help me.

1 0

How to use ovirt-imageio api for downloading snapshot to our localmachine.
by smidhunraj＠gmail.com 19 Sep '19

19 Sep '19

CAn anyone give me a working example of api on how to download snapshot to our local machine using ovirt using ovirt-imageio using api.Do we need to setup some certificate at our ovirt engine side.Please help me

1 0

[User is not authorized to perform this action.]
by smidhunraj＠gmail.com 18 Sep '19

18 Sep '19

I am getting error as User is not authorized to perform this action.I am using oVirt api to manually attach a disk and snapshot to another virtual machine.This the code i used.The API i followed is '<disk_attachment> <active>true</active> <bootable>false</bootable> <interface>virtio</interface> <disk id="a94106b7-d348-4088-aaa1-5dfc46dc094e"> <snapshot id="6ecbb953-c4fb-4294-9988-e7cd2bd9b038"/> <description>My disk</description> <format>cow</format> <name>mydisk</name> </disk> </disk_attachment> ============================== The php code i have tried is ... public function attachSnapshotandActivateDisk( ) { $data = array(); $xmlStr = '<disk_attachment> <active>true</active> <bootable>false</bootable> <interface>virtio</interface> <disk id="a94106b7-d348-4088-aaa1-5dfc46dc094e"> <snapshot id="6ecbb953-c4fb-4294-9988-e7cd2bd9b038"/> <description>My disk</description> <format>cow</format> <name>mydisk</name> </disk> </disk_attachment> '; $curlParam = array( "url" => "vms/74a1a99f-87d1-4444-b394-f90e4f29f51f/diskattachments", "method" => "POST", "data" => $xmlStr ); // $text = print_r($curlParam, true); //echo "<script>console.log( 'curl Parameter".json_encode($text)."');</script>"; $data = $this->processCurlRequest($curlParam, "vm-create"); // if instance update failed if ($data['status'] != 'success') { Common::ovirtLog(array( "requestParam" => $curlParam, "responseParam" => $data, )); } // show the output of print_r function as a string // $text = print_r($data, true); echo $data['message']; die; echo "<script type='text/javascript'> console.log('checking the attach snapshot activate disk function diskid=" . json_encode($data) . "') </script>"; //Detach the disk // $this->detachSnapshotDisk() ; return $data; } Please help me.

1 0

ovirt-release43-pre is not install able
by Dominik Holler 17 Sep '19

17 Sep '19

Hello, please note that yum install -y https://resources.ovirt.org/pub/yum-repo/ovirt-release43-pre.rpm yum install -y ovirt-host is currently failing with Error: Package: vdsm-4.30.30-1.el7.x86_64 (ovirt-4.3-pre) Requires: sanlock-python >= 3.7.3 Installing: sanlock-python-3.6.0-1.el7.x86_64 (base) sanlock-python = 3.6.0-1.el7 Error: Package: ovirt-hosted-engine-ha-2.3.5-1.el7.noarch (ovirt-4.3-pre) Requires: sanlock-python >= 3.7.3 Installing: sanlock-python-3.6.0-1.el7.x86_64 (base) sanlock-python = 3.6.0-1.el7 Error: Package: ovirt-hosted-engine-ha-2.3.5-1.el7.noarch (ovirt-4.3-pre) Requires: sanlock >= 3.7.3 Installing: sanlock-3.6.0-1.el7.x86_64 (base) sanlock = 3.6.0-1.el7 Is someone already fixing this? Dominik

2 1