- Users - oVirt List Archives

oVirt maintence "best practices"
by Jim Kusznir 11 Feb '17

11 Feb '17

hello: Now that I've had my ovirt cluster running for about a month and a half, I am realizing I don't necessarily know the best practices for keeping it up. I've been seeing the notices in the ovirt hosts screen showing that there are updates waiting for the hosts, and I'll put them in maintence mode one at a time and apply the updates. What about the engine itself? Is it recommended/safe to log into the engine and just run "yum update"? Is there other procedures I should be doing? My oVirt cluster is a 3 node cluster with gluster, running on each node. Thanks! --Jim

2 1

Re: [ovirt-users] Error attempting to upload an ISO image
by Yaniv Kaul 10 Feb '17

10 Feb '17

On Feb 10, 2017 9:07 PM, "Berger, Sandy" <SBERGER(a)qg.com> wrote: I originally installed a hosted engine on oVirt 4.0.x. Since then I’ve updated to 4.1. engine-upgrade-check shows no updates available: [root@waovccm1 ~]# engine-upgrade-check VERB: queue package ovirt-engine-setup for update VERB: Building transaction VERB: Empty transaction VERB: Transaction Summary: No upgrade However, “yum update” shows several updates available (see below) including python-ovirt-engine-sdk4 x86_64 4.1.0-1.el7.centos. The installed version of that RPM is currently 4.0.4-1.el7.centos.x86_64. Is it safe to run a yum update on the hosted engine? Why wouldn’t engine-upgrade-check show a necessary update like that? Should be OK to run. I'm not sure but I think the ISO uploader should depend on a newer pyhton-ovirt-sdk. Y. Thanks much for your assistance! [root@waovccm1 ~]# yum update Loaded plugins: fastestmirror, versionlock Loading mirror speeds from cached hostfile * base: repos.forethought.net * extras: centos.mbni.med.umich.edu * ovirt-4.1: mirrors.ibiblio.org * ovirt-4.1-epel: mirror.steadfast.net * updates: mirror.atlanticmetro.net Resolving Dependencies --> Running transaction check ---> Package NetworkManager.x86_64 1:1.4.0-13.el7_3 will be updated ---> Package NetworkManager.x86_64 1:1.4.0-14.el7_3 will be an update ---> Package NetworkManager-libnm.x86_64 1:1.4.0-13.el7_3 will be updated ---> Package NetworkManager-libnm.x86_64 1:1.4.0-14.el7_3 will be an update ---> Package NetworkManager-team.x86_64 1:1.4.0-13.el7_3 will be updated ---> Package NetworkManager-team.x86_64 1:1.4.0-14.el7_3 will be an update ---> Package NetworkManager-tui.x86_64 1:1.4.0-13.el7_3 will be updated ---> Package NetworkManager-tui.x86_64 1:1.4.0-14.el7_3 will be an update ---> Package NetworkManager-wifi.x86_64 1:1.4.0-13.el7_3 will be updated ---> Package NetworkManager-wifi.x86_64 1:1.4.0-14.el7_3 will be an update ---> Package antlr-tool.noarch 0:2.7.7-30.el7 will be updated ---> Package antlr-tool.noarch 0:2.7.7-35.el7 will be an update ---> Package bind-libs.x86_64 32:9.9.4-38.el7_3 will be updated ---> Package bind-libs.x86_64 32:9.9.4-38.el7_3.1 will be an update ---> Package bind-libs-lite.x86_64 32:9.9.4-38.el7_3 will be updated ---> Package bind-libs-lite.x86_64 32:9.9.4-38.el7_3.1 will be an update ---> Package bind-license.noarch 32:9.9.4-38.el7_3 will be updated ---> Package bind-license.noarch 32:9.9.4-38.el7_3.1 will be an update ---> Package bind-utils.x86_64 32:9.9.4-38.el7_3 will be updated ---> Package bind-utils.x86_64 32:9.9.4-38.el7_3.1 will be an update ---> Package device-mapper.x86_64 7:1.02.135-1.el7_3.1 will be updated ---> Package device-mapper.x86_64 7:1.02.135-1.el7_3.2 will be an update ---> Package device-mapper-libs.x86_64 7:1.02.135-1.el7_3.1 will be updated ---> Package device-mapper-libs.x86_64 7:1.02.135-1.el7_3.2 will be an update ---> Package firewalld.noarch 0:0.4.3.2-8.el7 will be updated ---> Package firewalld.noarch 0:0.4.3.2-8.1.el7_3 will be an update ---> Package firewalld-filesystem.noarch 0:0.4.3.2-8.el7 will be updated ---> Package firewalld-filesystem.noarch 0:0.4.3.2-8.1.el7_3 will be an update ---> Package java-1.8.0-openjdk.x86_64 1:1.8.0.111-2.b15.el7_3 will be updated ---> Package java-1.8.0-openjdk.x86_64 1:1.8.0.121-0.b13.el7_3 will be an update ---> Package java-1.8.0-openjdk-devel.x86_64 1:1.8.0.111-2.b15.el7_3 will be updated ---> Package java-1.8.0-openjdk-devel.x86_64 1:1.8.0.121-0.b13.el7_3 will be an update ---> Package java-1.8.0-openjdk-headless.x86_64 1:1.8.0.111-2.b15.el7_3 will be updated ---> Package java-1.8.0-openjdk-headless.x86_64 1:1.8.0.121-0.b13.el7_3 will be an update ---> Package kernel.x86_64 0:3.10.0-514.6.1.el7 will be installed ---> Package kernel-tools.x86_64 0:3.10.0-514.2.2.el7 will be updated ---> Package kernel-tools.x86_64 0:3.10.0-514.6.1.el7 will be an update ---> Package kernel-tools-libs.x86_64 0:3.10.0-514.2.2.el7 will be updated ---> Package kernel-tools-libs.x86_64 0:3.10.0-514.6.1.el7 will be an update ---> Package kpartx.x86_64 0:0.4.9-99.el7 will be updated ---> Package kpartx.x86_64 0:0.4.9-99.el7_3.1 will be an update ---> Package libnl3.x86_64 0:3.2.28-2.el7 will be updated ---> Package libnl3.x86_64 0:3.2.28-3.el7_3 will be an update ---> Package libnl3-cli.x86_64 0:3.2.28-2.el7 will be updated ---> Package libnl3-cli.x86_64 0:3.2.28-3.el7_3 will be an update ---> Package libpciaccess.x86_64 0:0.13.4-2.el7 will be updated ---> Package libpciaccess.x86_64 0:0.13.4-3.el7_3 will be an update ---> Package libsemanage.x86_64 0:2.5-4.el7 will be updated ---> Package libsemanage.x86_64 0:2.5-5.1.el7_3 will be an update ---> Package libsemanage-python.x86_64 0:2.5-4.el7 will be updated ---> Package libsemanage-python.x86_64 0:2.5-5.1.el7_3 will be an update ---> Package libtiff.x86_64 0:4.0.3-25.el7_2 will be updated ---> Package libtiff.x86_64 0:4.0.3-27.el7_3 will be an update ---> Package ntp.x86_64 0:4.2.6p5-25.el7.centos will be updated ---> Package ntp.x86_64 0:4.2.6p5-25.el7.centos.1 will be an update ---> Package ntpdate.x86_64 0:4.2.6p5-25.el7.centos will be updated ---> Package ntpdate.x86_64 0:4.2.6p5-25.el7.centos.1 will be an update ---> Package openssh.x86_64 0:6.6.1p1-31.el7 will be updated ---> Package openssh.x86_64 0:6.6.1p1-33.el7_3 will be an update ---> Package openssh-clients.x86_64 0:6.6.1p1-31.el7 will be updated ---> Package openssh-clients.x86_64 0:6.6.1p1-33.el7_3 will be an update ---> Package openssh-server.x86_64 0:6.6.1p1-31.el7 will be updated ---> Package openssh-server.x86_64 0:6.6.1p1-33.el7_3 will be an update ---> Package ovirt-guest-agent-common.noarch 0:1.0.12-4.el7 will be updated ---> Package ovirt-guest-agent-common.noarch 0:1.0.13-1.20161220085008.git165fff1.el7.centos will be an update ---> Package ovirt-imageio-common.noarch 0:0.4.0-1.el7 will be updated ---> Package ovirt-imageio-common.noarch 0:1.0.0-1.el7 will be an update ---> Package ovirt-imageio-proxy.noarch 0:0.4.0-0.201608310602.gita9b573b.el7.centos will be updated ---> Package ovirt-imageio-proxy.noarch 0:1.0.0-0.201701151456.git89ae3b4.el7.centos will be an update ---> Package ovirt-setup-lib.noarch 0:1.0.2-1.el7.centos will be updated ---> Package ovirt-setup-lib.noarch 0:1.1.0-1.el7.centos will be an update ---> Package policycoreutils.x86_64 0:2.5-9.el7 will be updated ---> Package policycoreutils.x86_64 0:2.5-11.el7_3 will be an update ---> Package policycoreutils-python.x86_64 0:2.5-9.el7 will be updated ---> Package policycoreutils-python.x86_64 0:2.5-11.el7_3 will be an update ---> Package python-firewall.noarch 0:0.4.3.2-8.el7 will be updated ---> Package python-firewall.noarch 0:0.4.3.2-8.1.el7_3 will be an update ---> Package python-ovirt-engine-sdk4.x86_64 0:4.0.4-1.el7.centos will be updated ---> Package python-ovirt-engine-sdk4.x86_64 0:4.1.0-1.el7.centos will be an update ---> Package python-perf.x86_64 0:3.10.0-514.2.2.el7 will be updated ---> Package python-perf.x86_64 0:3.10.0-514.6.1.el7 will be an update ---> Package python2-crypto.x86_64 0:2.6.1-10.el7 will be updated ---> Package python2-crypto.x86_64 0:2.6.1-13.el7 will be an update ---> Package python2-paramiko.noarch 0:1.16.1-1.el7 will be updated ---> Package python2-paramiko.noarch 0:1.16.1-2.el7 will be an update ---> Package selinux-policy.noarch 0:3.13.1-102.el7_3.7 will be updated ---> Package selinux-policy.noarch 0:3.13.1-102.el7_3.13 will be an update ---> Package selinux-policy-targeted.noarch 0:3.13.1-102.el7_3.7 will be updated ---> Package selinux-policy-targeted.noarch 0:3.13.1-102.el7_3.13 will be an update ---> Package unboundid-ldapsdk.noarch 0:3.0.0-1.el7 will be updated ---> Package unboundid-ldapsdk.noarch 0:3.2.0-1.el7 will be an update ---> Package xfsprogs.x86_64 0:4.5.0-8.el7 will be updated ---> Package xfsprogs.x86_64 0:4.5.0-9.el7_3 will be an update --> Finished Dependency Resolution Dependencies Resolved ============================================================ ==================== Package Arch Version Repository Size ============================================================ ==================== Installing: kernel x86_64 3.10.0-514.6.1.el7 updates 37 M Updating: NetworkManager x86_64 1:1.4.0-14.el7_3 updates 2.5 M NetworkManager-libnm x86_64 1:1.4.0-14.el7_3 updates 442 k NetworkManager-team x86_64 1:1.4.0-14.el7_3 updates 146 k NetworkManager-tui x86_64 1:1.4.0-14.el7_3 updates 222 k NetworkManager-wifi x86_64 1:1.4.0-14.el7_3 updates 175 k antlr-tool noarch 2.7.7-35.el7 centos-ovirt-common-candidate 357 k bind-libs x86_64 32:9.9.4-38.el7_3.1 updates 1.0 M bind-libs-lite x86_64 32:9.9.4-38.el7_3.1 updates 729 k bind-license noarch 32:9.9.4-38.el7_3.1 updates 83 k bind-utils x86_64 32:9.9.4-38.el7_3.1 updates 202 k device-mapper x86_64 7:1.02.135-1.el7_3.2 updates 269 k device-mapper-libs x86_64 7:1.02.135-1.el7_3.2 updates 333 k firewalld noarch 0.4.3.2-8.1.el7_3 updates 386 k firewalld-filesystem noarch 0.4.3.2-8.1.el7_3 updates 44 k java-1.8.0-openjdk x86_64 1:1.8.0.121-0.b13.el7_3 updates 232 k java-1.8.0-openjdk-devel x86_64 1:1.8.0.121-0.b13.el7_3 updates 9.7 M java-1.8.0-openjdk-headless x86_64 1:1.8.0.121-0.b13.el7_3 updates 31 M kernel-tools x86_64 3.10.0-514.6.1.el7 updates 4.0 M kernel-tools-libs x86_64 3.10.0-514.6.1.el7 updates 3.9 M kpartx x86_64 0.4.9-99.el7_3.1 updates 67 k libnl3 x86_64 3.2.28-3.el7_3 updates 278 k libnl3-cli x86_64 3.2.28-3.el7_3 updates 160 k libpciaccess x86_64 0.13.4-3.el7_3 updates 26 k libsemanage x86_64 2.5-5.1.el7_3 updates 144 k libsemanage-python x86_64 2.5-5.1.el7_3 updates 104 k libtiff x86_64 4.0.3-27.el7_3 updates 170 k ntp x86_64 4.2.6p5-25.el7.centos.1 updates 547 k ntpdate x86_64 4.2.6p5-25.el7.centos.1 updates 85 k openssh x86_64 6.6.1p1-33.el7_3 updates 438 k openssh-clients x86_64 6.6.1p1-33.el7_3 updates 642 k openssh-server x86_64 6.6.1p1-33.el7_3 updates 440 k ovirt-guest-agent-common noarch 1.0.13-1.20161220085008. git165fff1.el7.centos ovirt-4.1 67 k ovirt-imageio-common noarch 1.0.0-1.el7 centos-ovirt41-candidate 22 k ovirt-imageio-proxy noarch 1.0.0-0.201701151456.git89ae3b4.el7.centos ovirt-4.1 41 k ovirt-setup-lib noarch 1.1.0-1.el7.centos ovirt-4.1 19 k policycoreutils x86_64 2.5-11.el7_3 updates 841 k policycoreutils-python x86_64 2.5-11.el7_3 updates 445 k python-firewall noarch 0.4.3.2-8.1.el7_3 updates 301 k python-ovirt-engine-sdk4 x86_64 4.1.0-1.el7.centos ovirt-4.1 406 k python-perf x86_64 3.10.0-514.6.1.el7 updates 4.0 M python2-crypto x86_64 2.6.1-13.el7 ovirt-4.1-epel 476 k python2-paramiko noarch 1.16.1-2.el7 ovirt-4.1-epel 258 k selinux-policy noarch 3.13.1-102.el7_3.13 updates 414 k selinux-policy-targeted noarch 3.13.1-102.el7_3.13 updates 6.4 M unboundid-ldapsdk noarch 3.2.0-1.el7 centos-ovirt41-candidate 1.9 M xfsprogs x86_64 4.5.0-9.el7_3 updates 895 k Transaction Summary ============================================================ ==================== Install 1 Package Upgrade 46 Packages Total download size: 113 M Is this ok [y/d/N]: n Exiting on user command Your transaction was saved, rerun it with: yum load-transaction /tmp/yum_save_tx.2017-02-10.13-02.zcwZWT.yumtx *From:* Yaniv Kaul [mailto:ykaul@redhat.com] *Sent:* Friday, February 10, 2017 12:55 PM *To:* Berger, Sandy <SBERGER(a)qg.com> *Cc:* Ovirt Users <users(a)ovirt.org> *Subject:* Re: [ovirt-users] Error attempting to upload an ISO image On Feb 10, 2017 6:47 PM, "Berger, Sandy" <SBERGER(a)qg.com> wrote: After the 4.1 upgrade, I’m getting the following results attempting to upload an ISO image: [root@waovccm1 ~]# ovirt-iso-uploader --iso-domain=waISOLibrary upload slb.iso Please provide the REST API password for the admin@internal oVirt Engine user (CTRL+D to abort): ERROR: v4 is not a valid StorageFormat Can you ensure the 4.1 python SDK is installed? I think it is 4.1.24 and above that has it. Y. INFO: Use the -h option to see usage. I was able to manually copy the file to the correct directory on the NFS server but can’t get the utility to work properly. *Sandy Berger * *IT - EUX* Quad/Graphics *Performance* through *Innovation* Sussex, Wisconsin 414.566.2123 <(414)%20566-2123> phone 414.566.4010 <(414)%20566-4010>/2123 pager/PIN sandy.berger(a)qg.com www.QG.com <http://www.qg.com/> Follow Us: Facebook <http://www.qg.com/social1> | Twitter <http://www.qg.com/social2> | LinkedIn <http://www.qg.com/social3> | YouTube <http://www.qg.com/social4> _______________________________________________ Users mailing list Users(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/users

1 0

Error attempting to upload an ISO image
by Berger, Sandy 10 Feb '17

10 Feb '17

--_000_DM5PR05MB3161E920F37BD052F9CC85A4D5440DM5PR05MB3161namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable After the 4.1 upgrade, I'm getting the following results attempting to uplo= ad an ISO image: [root@waovccm1 ~]# ovirt-iso-uploader --iso-domain=3DwaISOLibrary upload sl= b.iso Please provide the REST API password for the admin@internal oVirt Engine us= er (CTRL+D to abort): ERROR: v4 is not a valid StorageFormat INFO: Use the -h option to see usage. I was able to manually copy the file to the correct directory on the NFS se= rver but can't get the utility to work properly. Sandy Berger IT - EUX Quad/Graphics Performance through Innovation Sussex, Wisconsin 414.566.2123 phone 414.566.4010/2123 pager/PIN sandy.berger(a)qg.com<mailto:sandy.berger@qg.com> www.QG.com<http://www.qg.com/> Follow Us: Facebook<http://www.qg.com/social1> | Twitter<http://www.qg.com/= social2> | LinkedIn<http://www.qg.com/social3> | YouTube<http://www.qg.com/= social4> --_000_DM5PR05MB3161E920F37BD052F9CC85A4D5440DM5PR05MB3161namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > <meta name=3D"Generator" content=3D"Microsoft Word 15 (filtered medium)"> <style></style> </head> <body lang=3D"EN-US" link=3D"#0563C1" vlink=3D"#954F72"> <div class=3D"WordSection1"> After the 4.1 upgrade, I’m getting the followi= ng results attempting to upload an ISO image:<o:p></o:p> <o:p> </o:p> = [root@waovccm1 ~]# ovirt-iso-uploader --iso-domain=3DwaISOLibrary upload sl= b.iso<o:p></o:p> = Please provide the REST API password for the admin@internal oVirt Engine us= er (CTRL+D to abort):<o:p></o:p> = ERROR: v4 is not a valid StorageFormat<o:p></o:p> = INFO: Use the -h option to see usage.<o:p></o:p> <o:p> </o:p> I was able to manually copy the file to the correct = directory on the NFS server but can’t get the utility to work properl= y.<o:p></o:p> <o:p> </o:p> Sandy Berger <o:p></o:p> IT - EUX<o:p= ></o:p>  <o:p></o:p> Quad/Graphics<o:p><= /o:p> Performance&nb= sp;through Innovation<o:= p></o:p>  <o:p></o:p></= span> Sussex, Wisconsin<o= :p></o:p> 414.566.2123 phone<= o:p></o:p> 414.566.4010/2123 pager/PIN<span= style=3D"font-size:10.5pt;font-family:"Arial",sans-serif;color:#= 444444"><o:p></o:p>  <= /span><o:p></o:p> <a href=3D"mailto:sandy.berger@qg.com"><s= pan style=3D"color:blue">sandy.berger(a)qg.com</a><o:p></o:p> <a href=3D"http://www.qg.com/">www.QG.com</a><o:p></o:p></span= > <o:p> </o:p> </div> Follow Us: <a href=3D"http://www.qg.com/social1">Facebook</a> | <a href=3D"= http://www.qg.com/social2"> Twitter</a> | <a href=3D"http://www.qg.com/social3">LinkedIn</a> | <a href= =3D"http://www.qg.com/social4"> YouTube</a> </body> </html> --_000_DM5PR05MB3161E920F37BD052F9CC85A4D5440DM5PR05MB3161namp_--

3 3

Re: [ovirt-users] Manually starting VMs via vdsClient (HE offline)
by Yaniv Kaul 10 Feb '17

10 Feb '17

On Feb 10, 2017 3:21 PM, "Nathanaël Blanchet" <blanchet(a)abes.fr> wrote: Le 09/02/2017 à 19:48, Yaniv Kaul a écrit : On Thu, Feb 9, 2017 at 6:00 PM, Doug Ingham <dougti(a)gmail.com> wrote: > > > On 9 February 2017 at 12:03, Dan Yasny <dyasny(a)gmail.com> wrote: > >> >> On Thu, Feb 9, 2017 at 9:55 AM, Doug Ingham <dougti(a)gmail.com> wrote: >> >>> Hi Dan, >>> >>> On 8 February 2017 at 18:26, Dan Yasny <dyasny(a)gmail.com> wrote: >>>> >>>> >>>> But seriously, above all, I'd recommend you backup the engine (it comes >>>> with a utility) often and well. I do it via cron every hour in production, >>>> keeping a rotation of hourly and daily backups, just in case. It doesn't >>>> take much space or resources, but it's more than just best practice - that >>>> database is the summary of the entire setup. >>>> >>>> >>> If you don't mind, may I ask what process you use for backing up your >>> engine? If you use HE, do you keep one server dedicated to just that VM? >>> I've not had that particular issue in the restore process yet, however I >>> read that it's recommended the HE host is free of virtual load before the >>> backup takes place. And as they need to be done frequently, I'm reading >>> that as a dedicated host... >>> >>> >> If you use a dedicated host, you might as well abandon self hosted. HE is >> nice for small setups with the HA built in for extra fun, but once you >> scale, it might not be able to cope and you'll need real hardware. You're >> running a heavy-ish java engine plus two databases after all. >> > I'd be interested to know what type of scale needs a real hardware for engine, rather 100 vms or 1000 vms? it may be about the hosts number? It depends on many factors. Just saw someone who is running the engine as a VM on a hefty hardware, and his setup had 50 hosts and 2500 VMs. I don't know all the details and specifically what I'd be interested to know is the underlying storage performance and how it's connected. In any case, as you scale up the system you will need more vCPUs and memory. Lastly, in 4.1 we've made various improvements to the engine and its database usage, so I expect somewhat improved performance and scale. Y. >> So as I said, all I do is add the engine-backup command to cron on the >> engine, and then my backup server comes in and pulls out the files via scp, >> also through cron. Nothing fancy really, but it lets me sleep at night >> > > This particular project has 10 new maxed out servers to back it, and I > don't see it outgrowing that for at least a year or so. It's hardly a full > DC. > I presume the DB will become the heaviest part of the load, and I'm > already planning a separate high I/O environment for dedicated HA DB hosts. > > See the top section of this page: > http://www.ovirt.org/documentation/self-hosted/chap-Backing_ > up_and_Restoring_an_EL-Based_Self-Hosted_Environment > > It seems that I'll always have to keep at least one host free to be able > to avoid restore problems. If not, and I were to keep hourly backups, then > migrating VMs off the host every hour would just be a pain. > I don't see the point in an hourly backup. Of what? The DB? The VM? What storage will it be based on? I suggest revising the strategy. > > > -- > Doug > > _______________________________________________ > Users mailing list > Users(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/users > > _______________________________________________ Users mailing listUsers@ovirt.orghttp://lists.ovirt.org/mailman/listinfo/users -- Nathanaël Blanchet Supervision réseau Pôle Infrastrutures Informatiques 227 avenue Professeur-Jean-Louis-Viala 34193 MONTPELLIER CEDEX 5 Tél. 33 (0)4 67 54 84 55 Fax 33 (0)4 67 54 84 14blanchet(a)abes.fr _______________________________________________ Users mailing list Users(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/users

1 0

libvirtError: Cannot get interface MTU
by Tyson Landon 10 Feb '17

10 Feb '17

I am new to Ovirt and have a test cluster running with 2 hosts. I have errors when live migrating that started after I installed a new NIC in one host. Live migrate was working fine before the changes. The vdsm log shows the errors below depending on if i am migrating from host1 or host2. Running ovs-vsctl list-br shows that the bridge exists. Ip a shows the interface is down. I do not know what a vdsm bridge is for or if the server just needs to restart a service to get things in order again. Have any of you seen this error before and were able to fix it? HOST 1 libvirtError: Cannot get interface MTU on 'vdsmbr_TK4cSEjh': No such device HOST 2 libvirtError: Cannot get interface MTU on 'vdsmbr_vqqOTlrR': No such device HOST 1 ovs-vsctl list-br vdsmbr_3fDBsCCF vdsmbr_TK4cSEjh vdsmbr_VWhs9soF HOST2 ovs-vsctl list-br vdsmbr_YBtJDFGg vdsmbr_qf3gXZdq vdsmbr_vqqOTlrR Thanks Tyson

2 4

Manually starting VMs via vdsClient (HE offline)
by Doug Ingham 10 Feb '17

10 Feb '17

Hi Guys, My Hosted-Engine has failed & it looks like the easiest solution will be to install a new one. Now before I try to re-add the old hosts (still running the guest VMs) & import the storage domain into the new engine, in case things don't go to plan, I want to make sure I'm able to bring up the guests on the hosts manually. The problem is vdsClient is giving me an "Unexpected exception", without much more info as to why it's failing. Any idea? [root@v0 ~]# vdsClient -s 0 list table | grep georep 9d1c3fef-498e-4c20-b124-01364d4d45a8 30455 georep-proxy Down [root@v0 ~]# vdsClient -s 0 continue 9d1c3fef-498e-4c20-b124-01364d4d45a8 Unexpected exception /var/log/vdsm/vdsm.log periodic/1063::WARNING::2017-02-08 17:57:52,532::periodic::276::virt.periodic.VmDispatcher::(__call__) could not run <class 'vdsm.virt.periodic.DriveWatermarkMonitor'> on ['65c9807c-7216-40b3-927c-5fd93bbd42ba', u'9d1c3fef-498e-4c20-b124-01364d4d45a8'] Cheers, -- Doug

4 12

Best way to shutdown and restart hypervisor?
by Gianluca Cecchi 10 Feb '17

10 Feb '17

Hello, what is considered the best way to shutdown and restart an hypervisor, supposing plain CentOS 7 host? For example to cover these scenarios: 1) update host from 4.0 to 4.1 2) planned maintenance to the cabinet where the server is located and take the opportunity to update also OS packages My supposed workflow: - put host into maintenance - yum update on host - shutdown os from inside host (because from power mgmt it is brutal power off / power on) --> should I get any warning from web admin gui in this case, even if the host was in maintenance mode? - power mgmt -> start from webadmin gui (or power on button/virtual button at host side?) Would be advisable to put inside power mgmt functionality some logic about os mgmt, so for example, if action is restart, first try to shutdown OS and only in case of failure power off/power on? Thanks in advance, Gianluca

4 6

Getting error while trying to add VmPool using ovirtsdk4 version of the python api
by Manuel Luis Aznar 10 Feb '17

10 Feb '17

Hello there, I am trying to add a VmPool to oVirt using the python ovirtSDK4 with following lines: I am omitting the import packages lines and connection lines. system_service = connection.system_service() vm_pools_service = system_service.vm_pools_service() templates_service = system_service.templates_service() clusters_service = system_service.clusters_service() tplist = templates_service.list(search='name=prueba') tpl=None biggest=-1 for t in tplist: ver = t.version if ver.version_number > biggest: biggest = ver.version_number tid = t.id tpl = t c = None for cluster in clusters_service.list(): if cluster.name == 'Pruebacluster': c = cluster pool = ovirtsdk4.types.VmPool(name='PRUEBA',size=1,type =ovirtsdk4.types.VmPoolType('manual'),template=tpl,cluster=c) vm_pools_service.add(pool=pool) I am getting the following error: Fault reason is "Request syntactically incorrect.". Fault detail is "For correct usage, see: https://ovirt.example.com/ovirt-engine/api/v4/model#services/vm-pools/metho…". HTTP response code is 400. I am a newbie in using this version of the API, suppose this is quite easy problem. Thanks for all the answers to come, Manuel

2 1

VDAgent
by Fernando Fuentes 10 Feb '17

10 Feb '17

Team, After a host update on my cluster, All of my Windows vm's running the vdagent from the ovirt tools are running at 100% CPU utilization. Any ideas why would this happen? Regards, -- Fernando Fuentes ffuentes(a)txweather.org http://www.txweather.org

2 8

How to change disk from thin to pre allocated
by ovirt＠timmi.org 10 Feb '17

10 Feb '17

Hi oVirt List, I'm trying to change the disk allocation policy of a VM disk and I'm not able to perform this task via the oVirt front-end. Is someone able to tell me how I can do that? Best regards and thank you Christoph

2 5

Importing existing (dirty) storage domains
by Doug Ingham 09 Feb '17

09 Feb '17

Hi All, My original HE died & was proving too much of a hassle to restore, so I've setup a new HE on a new host & now want to import my previous data storage domain with my VMs. The problem is when I try to attach the new domain to the datacenter, it hangs for a minute and then comes back with, "Failed to attach Storage Domain data2 to Data Center Default" It's a gluster volume, and I'm able to mount & write to it via the CLI on the host, without issue. It's also using the same gluster volume options as the initialized master domain. I get this in sanlock.log: 2017-02-09 14:54:57-0300 1698758 [9303]: s10:r12 resource 60455567-ad30-42e3-a9df-62fe86c7fd25:SDM:/rhev/data-center/mnt/glusterSD/localhost:data2/60455567-ad30-42e3-a9df-62fe86c7fd25/dom_md/leases:1048576 for 3,15,12533 2017-02-09 14:54:57-0300 1698758 [9303]: open error -5 /rhev/data-center/mnt/glusterSD/localhost:data2/60455567-ad30-42e3-a9df-62fe86c7fd25/dom_md/leases 2017-02-09 14:54:57-0300 1698758 [9303]: r12 acquire_token open error -5 2017-02-09 14:54:57-0300 1698758 [9303]: r12 cmd_acquire 3,15,12533 acquire_token -5 Any ideas? -- Doug

1 0

Host DNS
by Todd Punderson 09 Feb '17

09 Feb '17

I changed my DNS servers since installing my hosted engine and hosts. I've manually set my /etc/resolv.conf to have the correct nameserver entries. But I found when I rebooted that it was being overwritten. I did some googling and found that in /var/lib/vdsm/persistence/netconf/nets/ovirtmgmt (My management network name) there is a nameservers config that gets applied when vdsm starts which updated my ifcfg files. I edited that file to include my correct name servers. Now, if I choose a host, go to the network interfaces tab, then click "Setup Host Network" when I exit out with the "Save" checkbox checked, the file in the vdsm directory is being changed back to my old nameserver entry. I searched all over the hosted engine UI and I can't find where that's old entry is coming from. Where do I go to change this? Thanks

2 2

Info on oVirt 4.1 and qcow2 v3 format
by Gianluca Cecchi 09 Feb '17

09 Feb '17

Hello, after upgrading to oVirt 4.1 and setting cluster/datacenter to version 4, new images and snapshots should be created in qcow2 v3 format, based on bugzilla included in release notes: https://bugzilla.redhat.com/827529 Correct? What about existing disks? Is there any way to convert? What in case I have an old disk, I create a snapshot in 4.1 and then delete the snapshot? Will the live merged disk be in v3 format or v2? Thanks, Gianluca

3 2

[ANN] oVirt 4.1.1 Test compose
by Sandro Bonazzola 09 Feb '17

09 Feb '17

The oVirt Project is pleased to announce the availability of the First Test Compose of oVirt 4.1.1 for testing, as of February 9th, 2017 This is pre-release software. Please take a look at our community page[1] to know how to ask questions and interact with developers and users. All issues or bugs should be reported via oVirt Bugzilla[2]. This pre-release should not to be used in production. This update is a test compose allowing to test fixes included in ovirt-4.1.1 since 4.1.0 release. See the release notes [3] for installation / upgrade instructions and a list of new features and bugs fixed. This release is available now for: * Fedora 24 (tech preview) * Red Hat Enterprise Linux 7.3 or later * CentOS Linux (or similar) 7.3 or later This release supports Hypervisor Hosts running: * Red Hat Enterprise Linux 7.3 or later * CentOS Linux (or similar) 7.3 or later * Fedora 24 (tech preview) See the release notes draft [3] for installation / upgrade instructions and a list of new features and bugs fixed. Notes: - oVirt Live, oVirt Node and oVirt Engine appliance has not been built for this test compose Additional Resources: * Read more about the oVirt 4.1.1 release highlights: http://www.ovirt.org/release/4.1.1/ * Get more oVirt Project updates on Twitter: https://twitter.com/ovirt * Check out the latest project news on the oVirt blog: http://www.ovirt.org/blog/ [1] https://www.ovirt.org/community/ [2] https://bugzilla.redhat.com/enter_bug.cgi?classification=oVirt [3] http://www.ovirt.org/release/4.1.1/ -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

1 0

web admin gui timeout changes in 4.1
by Gianluca Cecchi 09 Feb '17

09 Feb '17

Hello, while in 4.0.6 it seemed perhaps too short and you got logged out, in 4.1 it seems very relaxed Did the default values changed? In which measures? Any way to tweak? Thanks, Gianluca

3 5

Re: [ovirt-users] USB 2.0 compatibility -- RESOLVED!
by Jonathan Woytek 09 Feb '17

09 Feb '17

I was finally able to resolve this. So that maybe other users can find how to fix this if they run into the same issues: tl;dr: Edit the virtual machine in question, go under Console, make sure SPICE is chosen for graphics, and under "USB Redirection" choose "Native." When you reboot the VM, it will have both UHCI and EHCI (2.0) controllers. Now, any USB 2.0 devices that you attach will work correctly. Long version: I struggled with this for quite a while. While doing some additional research, I found a note in the 4.1.0 release notes referencing BZ 1373223. This particular note was for ppc64 architecture systems, but it curiously said that enabling USB Redirection under SPICE would change the USB controllers available on the host. I dug a little deeper into the bug thread and found a couple of references that seemed to indicate that x86/x86_64 exhibited the same behavior. Apparently, UHCI (1.1) is the default because it supports SmartCards, but the EHCI (2.0) controller does not. So, turning on USB Redirection under SPICE settings for the console enables an EHCI controller, thereby enabling devices that require USB 2.0. Personal opinion: This is really obfuscated. It would be great if this switch lived somewhere more obvious. Even if that doesn't happen, this should exist in a document somewhere. Maybe it does and I couldn't find it, but I tried! jonathan -- Jonathan Woytek http://www.dryrose.com KB3HOZ PGP: 462C 5F50 144D 6B09 3B65 FCE8 C1DC DEC4 E8B6 AABC

2 3

some mismatch in mom versions in the repository
by Arman Khalatyan 09 Feb '17

09 Feb '17

Hi, I just upgraded 4.0.6 to 4.1. The 4.0 repository still there but after upgrade everything is ok except the mom The mom version in the 4.0 is higher than in 4.1 therefore it is not upgraded from 4.1: yum provides /usr/sbin/momd mom-0.5.8-0.0.master.el7.centos.noarch : Dynamically manage system resources on virtualization hosts Repo : ovirt-4.1 Matched from: Filename : /usr/sbin/momd mom-0.5.8-1.el7.noarch : Dynamically manage system resources on virtualization hosts Repo : centos-ovirt-common-candidate Matched from: Filename : /usr/sbin/momd mom-0.5.8-1.el7.noarch : Dynamically manage system resources on virtualization hosts Repo : centos-ovirt40-release Matched from: Filename : /usr/sbin/momd mom-0.5.8-1.el7.centos.noarch : Dynamically manage system resources on virtualization hosts Repo : ovirt-4.0 Matched from: Filename : /usr/sbin/momd mom-0.5.8-1.el7.centos.noarch : Dynamically manage system resources on virtualization hosts Repo : @ovirt-4.0 Matched from: Filename : /usr/sbin/momd

3 2

About H.264 encode in ovirt
by 张余歌 09 Feb '17

09 Feb '17

--_000_DM5PR11MB193063C3225CAD6EC0EB902C90450DM5PR11MB1930namp_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 aGVsbG8sbXkgZnJpZW5kLGkgd2FudCB0byBiZSBzdXJlIHdoZXRoZXIgb3ZpcnQgc3VwcG9ydCBo LjI2NCBlbmNvZGU/RGlkIGFueW9uZSBrbm93IGl0P3RoYW5rcw0K --_000_DM5PR11MB193063C3225CAD6EC0EB902C90450DM5PR11MB1930namp_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable <html> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dgb2312"> <style type=3D"text/css" style=3D"display:none;"></style> </head> <body dir=3D"ltr"> <div id=3D"divtagdefaultwrapper" style=3D"font-size:12pt;color:#000000;font= -family:Calibri,Arial,Helvetica,sans-serif;" dir=3D"ltr"> hello,my friend,i want to be sure whether ovirt support h.264 encode?Did an= yone know it?thanks</div> </body> </html> --_000_DM5PR11MB193063C3225CAD6EC0EB902C90450DM5PR11MB1930namp_--

2 1

Re: [ovirt-users] problem after rebooting the node
by Edward Haas 09 Feb '17

09 Feb '17

Based on what I can see, you used OVS as the switch type and it seems ovs (openvswitch) is not properly installed on your host. Make sure that you have ovs operational by issuing "ovs-vsctl show". You should note that OVS network support is not an official release feature, and you should use it on 4.1 and up versions. Fixes will be probably submitted to master (appearing in nightly builds). Next time please include the mailing-list in your replies and attach the log files, it is less spamming. Thanks, Edy. On Fri, Feb 3, 2017 at 5:07 AM, Shalabh Goel <shalabhgoel13(a)gmail.com> wrote: > log from messages > > Feb 3 08:27:53 ovirtnode3 ovs-vsctl: ovs|00001|db_ctl_base|ERR| > unix:/var/run/openvswitch/db.sock: database connection failed (No such > file or directory) > Feb 3 08:27:53 ovirtnode3 journal: vdsm vds ERROR Executing commands > failed: ovs-vsctl: unix:/var/run/openvswitch/db.sock: database connection > failed (No su > ch file or directory)#012Traceback (most recent call last):#012 File > "/usr/share/vdsm/API.py", line 1531, in setupNetworks#012 > supervdsm.getProxy().setup > Networks(networks, bondings, options)#012 File "/usr/lib/python2.7/site-packages/vdsm/supervdsm.py", > line 53, in __call__#012 return callMethod()#012 Fi > le "/usr/lib/python2.7/site-packages/vdsm/supervdsm.py", line 51, in > <lambda>#012 **kwargs)#012 File "<string>", line 2, in > setupNetworks#012 File "/usr > /lib64/python2.7/multiprocessing/managers.py", line 773, in > _callmethod#012 raise convert_to_error(kind, > result)#012ConfigNetworkError: (21, 'Executing co > mmands failed: ovs-vsctl: unix:/var/run/openvswitch/db.sock: database > connection failed (No such file or directory)') > > Log from vdsm.log > > Reactor thread::INFO::2017-02-03 08:32:24,638::protocoldetector::72:: > ProtocolDetector.AcceptorImpl::(handle_accept) Accepted connection from > ::1:53082 > Reactor thread::DEBUG::2017-02-03 08:32:24,643::protocoldetector::91:: > ProtocolDetector.Detector::(__init__) Using required_size=11 > Reactor thread::INFO::2017-02-03 08:32:24,643::protocoldetector::127:: > ProtocolDetector.Detector::(handle_read) Detected protocol xml from > ::1:53082 > Reactor thread::DEBUG::2017-02-03 08:32:24,643::bindingxmlrpc:: > 1317::XmlDetector::(handle_socket) xml over http detected from ('::1', > 53082) > BindingXMLRPC::INFO::2017-02-03 08:32:24,643::xmlrpc::73::vds.XMLRPCServer::(handle_request) > Starting request handler for ::1:53082 > Thread-20::INFO::2017-02-03 08:32:24,644::xmlrpc::83::vds. > XMLRPCServer::(_process_requests) Request handler for ::1:53082 started > Thread-20::DEBUG::2017-02-03 08:32:24,644::bindingxmlrpc::1263::vds::(wrapper) > client [::1]::call getAllVmStats with () {} > Thread-20::DEBUG::2017-02-03 08:32:24,644::bindingxmlrpc::1270::vds::(wrapper) > return getAllVmStats with {'status': {'message': 'Done', 'code': 0}, > 'statsLis > t': (suppressed)} > Thread-20::INFO::2017-02-03 08:32:24,644::bindingxmlrpc::1297::vds::(wrapper) > RPC call getAllVmStats finished (code=0) in 0.00 seconds > Thread-20::INFO::2017-02-03 08:32:24,645::xmlrpc::91::vds. > XMLRPCServer::(_process_requests) Request handler for ::1:53082 stopped > periodic/0::DEBUG::2017-02-03 08:32:24,907::sampling::508:: > virt.sampling.VMBulkSampler::(__call__) sampled timestamp 4347942.15 > elapsed 0.010 acquired True d > omains all > periodic/2::DEBUG::2017-02-03 08:32:24,908::task::599:: > storage.TaskManager.Task::(_updateState) (Task='bb07f89c-6165-42bc-902f-1b7701b813fa') > moving from sta > te init -> state preparing > periodic/2::INFO::2017-02-03 08:32:24,908::logUtils::49::dispatcher::(wrapper) > Run and protect: repoStats(options=None) > periodic/2::INFO::2017-02-03 08:32:24,908::logUtils::52::dispatcher::(wrapper) > Run and protect: repoStats, Return response: {} > periodic/2::DEBUG::2017-02-03 08:32:24,909::task::1195:: > storage.TaskManager.Task::(prepare) (Task='bb07f89c-6165-42bc-902f-1b7701b813fa') > finished: {} > periodic/2::DEBUG::2017-02-03 08:32:24,909::task::599:: > storage.TaskManager.Task::(_updateState) (Task='bb07f89c-6165-42bc-902f-1b7701b813fa') > moving from sta > te preparing -> state finished > periodic/2::DEBUG::2017-02-03 08:32:24,909::resourceManager: > :910::storage.ResourceManager.Owner::(releaseAll) Owner.releaseAll > requests {} resources {} > periodic/2::DEBUG::2017-02-03 08:32:24,909::resourceManager: > :947::storage.ResourceManager.Owner::(cancelAll) Owner.cancelAll requests > {} > periodic/2::DEBUG::2017-02-03 08:32:24,909::task::997:: > storage.TaskManager.Task::(_decref) (Task='bb07f89c-6165-42bc-902f-1b7701b813fa') > ref 0 aborting False > jsonrpc/4::DEBUG::2017-02-03 08:32:26,653::__init__::532:: > jsonrpc.JsonRpcServer::(_handle_request) Calling 'Host.getAllVmStats' in > bridge with {} > jsonrpc/4::DEBUG::2017-02-03 08:32:26,653::__init__::557:: > jsonrpc.JsonRpcServer::(_handle_request) Return 'Host.getAllVmStats' in > bridge with (suppressed) > jsonrpc/4::INFO::2017-02-03 08:32:26,653::__init__::515:: > jsonrpc.JsonRpcServer::(_serveRequest) RPC call Host.getAllVmStats > succeeded in 0.00 seconds > jsonrpc/6::DEBUG::2017-02-03 08:32:27,706::__init__::532:: > jsonrpc.JsonRpcServer::(_handle_request) Calling 'Host.getStats' in > bridge with {} > jsonrpc/6::DEBUG::2017-02-03 08:32:27,706::__init__::532:: > jsonrpc.JsonRpcServer::(_handle_request) Calling 'Host.getStats' in > bridge with {} > jsonrpc/6::DEBUG::2017-02-03 08:32:27,707::task::599:: > storage.TaskManager.Task::(_updateState) (Task='9285329e-485b-4165-8bdc-4f411f394356') > moving from state init -> state preparing > jsonrpc/6::INFO::2017-02-03 08:32:27,707::logUtils::49::dispatcher::(wrapper) > Run and protect: repoStats(options=None) > jsonrpc/6::INFO::2017-02-03 08:32:27,707::logUtils::52::dispatcher::(wrapper) > Run and protect: repoStats, Return response: {} > jsonrpc/6::DEBUG::2017-02-03 08:32:27,707::task::1195:: > storage.TaskManager.Task::(prepare) (Task='9285329e-485b-4165-8bdc-4f411f394356') > finished: {} > jsonrpc/6::DEBUG::2017-02-03 08:32:27,707::task::599:: > storage.TaskManager.Task::(_updateState) (Task='9285329e-485b-4165-8bdc-4f411f394356') > moving from state preparing -> state finished > jsonrpc/6::DEBUG::2017-02-03 08:32:27,708::resourceManager: > :910::storage.ResourceManager.Owner::(releaseAll) Owner.releaseAll > requests {} resources {} > jsonrpc/6::DEBUG::2017-02-03 08:32:27,708::resourceManager: > :947::storage.ResourceManager.Owner::(cancelAll) Owner.cancelAll requests > {} > jsonrpc/6::DEBUG::2017-02-03 08:32:27,708::task::997:: > storage.TaskManager.Task::(_decref) (Task='9285329e-485b-4165-8bdc-4f411f394356') > ref 0 aborting False > jsonrpc/6::DEBUG::2017-02-03 08:32:27,712::__init__::557:: > jsonrpc.JsonRpcServer::(_handle_request) Return 'Host.getStats' in bridge > with {'cpuStatistics': {'28': {'cpuUser': '0.13', 'nodeIndex': 0, 'cpuSys': > '0.00', 'cpuIdle': '99.87'}, '29': {'cpuUser': '0.00', 'nodeIndex': 0, > 'cpuSys': '0.00', 'cpuIdle': '100.00'}, '24': {'cpuUser': '0.00', > 'nodeIndex': 0, 'cpuSys': '0.00', 'cpuIdle': '100.00'}, '25': {'cpuUser': > '0.13', 'nodeIndex': 0, 'cpuSys': '0.07', 'cpuIdle': '99.80'}, '26': > {'cpuUser': '0.00', 'nodeIndex': 0, 'cpuSys': '0.00', 'cpuIdle': '100.00'}, > '27': {'cpuUser': '0.00', 'nodeIndex': 0, 'cpuSys': '0.00', 'cpuIdle': > '100.00'}, '20': {'cpuUser': '0.00', 'nodeIndex': 1, 'cpuSys': '0.00', > 'cpuIdle': '100.00'}, '21': {'cpuUser': '0.00', 'nodeIndex': 1, 'cpuSys': > '0.00', 'cpuIdle': '100.00'}, '22': {'cpuUser': '0.00', 'nodeIndex': 1, > 'cpuSys': '0.00', 'cpuIdle': '100.00'}, '23': {'cpuUser': '0.00', > 'nodeIndex': 1, 'cpuSys': '0.00', 'cpuIdle': '100.00'}, '46': {'cpuUser': > '0.00', 'nodeIndex': 1, 'cpuSys': '0.00', 'cpuIdle': '100.00'}, '47': > {'cpuUser': '0.00', 'nodeIndex': 1, 'cpuSys': '0.00', 'cpuIdle': '100.00'}, > '44': {'cpuUser': '0.00', 'nodeIndex': 1, 'cpuSys': '0.00', 'cpuIdle': > '100.00'}, '45': {'cpuUser': '0.00', 'nodeIndex': 1, 'cpuSys': '0.00', > 'cpuIdle': '100.00'}, '42': {'cpuUser': '0.00', 'nodeIndex': 1, 'cpuSys': > '0.00', 'cpuIdle': '100.00'}, '43': {'cpuUser': '0.00', 'nodeIndex': 1, > 'cpuSys': '0.00', 'cpuIdle': '100.00'}, '40': {'cpuUser': '0.00', > 'nodeIndex': 1, 'cpuSys': '0.00', 'cpuIdle': '100.00'}, '41': {'cpuUser': > '0.00', 'nodeIndex': 1, 'cpuSys': '0.00', 'cpuIdle': '100.00'}, '1': > {'cpuUser': '0.13', 'nodeIndex': 0, 'cpuSys': '0.07', 'cpuIdle': '99.80'}, > '0': {'cpuUser': '0.00', 'nodeIndex': 0, 'cpuSys': '0.00', 'cpuIdle': > '100.00'}, '3': {'cpuUser': '0.07', 'nodeIndex': 0, 'cpuSys': '0.07', > 'cpuIdle': '99.86'}, '2': {'cpuUser': '0.07', 'nodeIndex': 0, 'cpuSys': > '0.00', 'cpuIdle': '99.93'}, '5': {'cpuUser': '0.00', 'nodeIndex': 0, > 'cpuSys': '0.00', 'cpuIdle': '100.00'}, '4': {'cpuUser': '0.00', > 'nodeIndex': 0, 'cpuSys': '0.07', 'cpuIdle': '99.93'}, '7': {'cpuUser': > '0.00', 'nodeIndex': 0, 'cpuSys': '0.00', 'cpuIdle': '100.00'}, '6': > {'cpuUser': '0.20', 'nodeIndex': 0, 'cpuSys': '0.00', 'cpuIdle': '99.80'}, > '9': {'cpuUser': '0.00', 'nodeIndex': 0, 'cpuSys': '0.00', 'cpuIdle': > '100.00'}, '8': {'cpuUser': '0.00', 'nodeIndex': 0, 'cpuSys': '0.00', > 'cpuIdle': '100.00'}, '39': {'cpuUser': '0.00', 'nodeIndex': 1, 'cpuSys': > '0.00', 'cpuIdle': '100.00'}, '38': {'cpuUser': '0.00', 'nodeIndex': 1, > 'cpuSys': '0.00', 'cpuIdle': '100.00'}, '11': {'cpuUser': '0.00', > 'nodeIndex': 0, 'cpuSys': '0.00', 'cpuIdle': '100.00'}, '10': {'cpuUser': > '0.00', 'nodeIndex': 0, 'cpuSys': '0.00', 'cpuIdle': '100.00'}, '13': > {'cpuUser': '0.00', 'nodeIndex': 1, 'cpuSys': '0.00', 'cpuIdle': '100.00'}, > '12': {'cpuUser': '0.00', 'nodeIndex': 1, 'cpuSys': '0.00', 'cpuIdle': > '100.00'}, '15': {'cpuUser': '0.00', 'nodeIndex': 1, 'cpuSys': '0.00', > 'cpuIdle': '100.00'}, '14': {'cpuUser': '0.00', 'nodeIndex': 1, 'cpuSys': > '0.00', 'cpuIdle': '100.00'}, '17': {'cpuUser': '0.00', 'nodeIndex': 1, > 'cpuSys': '0.00', 'cpuIdle': '100.00'}, '16': {'cpuUser': '0.00', > 'nodeIndex': 1, 'cpuSys': '0.00', 'cpuIdle': '100.00'}, '19': {'cpuUser': > '0.00', 'nodeIndex': 1, 'cpuSys': '0.00', 'cpuIdle': '100.00'}, '18': > {'cpuUser': '0.00', 'nodeIndex': 1, 'cpuSys': '0.00', 'cpuIdle': '100.00'}, > '31': {'cpuUser': '0.00', 'nodeIndex': 0, 'cpuSys': '0.00', 'cpuIdle': > '100.00'}, '30': {'cpuUser': '0.00', 'nodeIndex': 0, 'cpuSys': '0.00', > 'cpuIdle': '100.00'}, '37': {'cpuUser': '0.00', 'nodeIndex': 1, 'cpuSys': > '0.00', 'cpuIdle': '100.00'}, '36': {'cpuUser': '0.00', 'nodeIndex': 1, > 'cpuSys': '0.00', 'cpuIdle': '100.00'}, '35': {'cpuUser': '0.00', > 'nodeIndex': 0, 'cpuSys': '0.00', 'cpuIdle': '100.00'}, '34': {'cpuUser': > '0.00', 'nodeIndex': 0, 'cpuSys': '0.00', 'cpuIdle': '100.00'}, '33': > {'cpuUser': '0.00', 'nodeIndex': 0, 'cpuSys': '0.00', 'cpuIdle': '100.00'}, > '32': {'cpuUser': '0.00', 'nodeIndex': 0, 'cpuSys': '0.00', 'cpuIdle': > '100.00'}}, 'numaNodeMemFree': {'1': {'memPercent': 3, 'memFree': '63780'}, > '0': {'memPercent': 4, 'memFree': '63426'}}, 'memShared': 0, 'thpState': > 'always', 'ksmMergeAcrossNodes': True, 'vmCount': 0, 'memUsed': '2', > 'storageDomains': {}, 'incomingVmMigrations': 0, 'network': {'ib0': > {'txErrors': '0', 'state': 'down', 'sampleTime': 1486090944.903051, 'name': > 'ib0', 'tx': '0', 'txDropped': '0', 'rx': '0', 'rxErrors': '0', 'speed': > '1000', 'rxDropped': '0'}, 'lo': {'txErrors': '0', 'state': 'up', > 'sampleTime': 1486090944.903051, 'name': 'lo', 'tx': '56174388', > 'txDropped': '0', 'rx': '56174388', 'rxErrors': '0', 'speed': '1000', > 'rxDropped': '0'}, 'eno2': {'txErrors': '0', 'state': 'down', 'sampleTime': > 1486090944.903051, 'name': 'eno2', 'tx': '0', 'txDropped': '0', 'rx': '0', > 'rxErrors': '0', 'speed': '1000', 'rxDropped': '0'}, 'eno1': {'txErrors': > '0', 'state': 'up', 'sampleTime': 1486090944.903051, 'name': 'eno1', 'tx': > '26032823', 'txDropped': '0', 'rx': '174722400', 'rxErrors': '0', 'speed': > '1000', 'rxDropped': '5624'}, ';vdsmdummy;': {'txErrors': '0', 'state': > 'down', 'sampleTime': 1486090944.903051, 'name': ';vdsmdummy;', 'tx': '0', > 'txDropped': '0', 'rx': '0', 'rxErrors': '0', 'speed': '1000', 'rxDropped': > '0'}}, 'txDropped': '0', 'anonHugePages': '34', 'ksmPages': 100, > 'elapsedTime': '287.81', 'cpuLoad': '0.07', 'cpuSys': '0.00', 'diskStats': > {'/var/log': {'free': '15072'}, '/var/log/core': {'free': '15072'}, > '/var/run/vdsm/': {'free': '64418'}, '/tmp': {'free': '914756'}}, > 'cpuUserVdsmd': '0.13', 'netConfigDirty': 'True', 'memCommitted': 0, > 'ksmState': False, 'vmMigrating': 0, 'ksmCpu': 0, 'memAvailable': 127200, > 'bootTime': '1486037670', 'haStats': {'active': False, 'configured': False, > 'score': 0, 'localMaintenance': False, 'globalMaintenance': False}, > 'momStatus': 'active', 'rxDropped': '5624', 'outgoingVmMigrations': 0, > 'swapTotal': 4095, 'swapFree': 4095, 'dateTime': '2017-02-03T03:02:27 GMT', > 'cpuUser': '0.02', 'memFree': 127456, 'cpuIdle': '99.98', 'vmActive': 0, > 'v2vJobs': {}, 'cpuSysVdsmd': '0.07'} > jsonrpc/6::INFO::2017-02-03 08:32:27,713::__init__::515:: > jsonrpc.JsonRpcServer::(_serveRequest) RPC call Host.getStats succeeded > in 0.00 seconds > Reactor thread::INFO::2017-02-03 08:32:39,661::protocoldetector::72:: > ProtocolDetector.AcceptorImpl::(handle_accept) Accepted connection from > ::1:53084 > > supervdsm.log > > > File "/usr/share/vdsm/supervdsmServer", line 95, in wrapper > res = func(*args, **kwargs) > File "/usr/share/vdsm/supervdsmServer", line 143, in umount > timeout=timeout) > File "/usr/lib/python2.7/site-packages/vdsm/storage/mount.py", line > 281, in _umount > _runcmd(cmd, timeout) > File "/usr/lib/python2.7/site-packages/vdsm/storage/mount.py", line > 297, in _runcmd > raise MountError(rc, ";".join((out, err))) > MountError: (32, ';umount: /rhev/data-center/mnt/10.1.235.6:_iso: > mountpoint not found\n') > MainProcess|jsonrpc/5::DEBUG::2017-02-03 08:26:59,495::supervdsmServer: > :93::SuperVdsm.ServerCallback::(wrapper) call hbaRescan with () {} > MainProcess|jsonrpc/5::DEBUG::2017-02-03 08:26:59,495::commands::69::storage.HBA::(execCmd) > /usr/bin/taskset --cpu-list 0-47 /usr/libexec/vdsm/fc-scan (cwd N > one) > MainProcess|jsonrpc/5::DEBUG::2017-02-03 08:26:59,579::supervdsmServer: > :100::SuperVdsm.ServerCallback::(wrapper) return hbaRescan with None > MainThread::DEBUG::2017-02-03 08:27:26,367::supervdsmServer::311::SuperVdsm.Server::(main) > Terminated normally > MainThread::DEBUG::2017-02-03 08:27:36,148::__init__::47:: > blivet::(register_device_format) registered device format class > DeviceFormat as None > MainThread::DEBUG::2017-02-03 08:27:36,149::__init__::47:: > blivet::(register_device_format) registered device format class BIOSBoot > as biosboot > MainThread::DEBUG::2017-02-03 08:27:36,150::__init__::47:: > blivet::(register_device_format) registered device format class DiskLabel > as disklabel > MainThread::DEBUG::2017-02-03 08:27:36,150::__init__::47:: > blivet::(register_device_format) registered device format class > DMRaidMember as dmraidmember > MainThread::DEBUG::2017-02-03 08:27:36,151::__init__::47:: > blivet::(register_device_format) registered device format class Ext2FS as > ext2 > MainThread::DEBUG::2017-02-03 08:27:36,152::__init__::47:: > blivet::(register_device_format) registered device format class Ext3FS as > ext3 > MainThread::DEBUG::2017-02-03 08:27:36,152::__init__::47:: > blivet::(register_device_format) registered device format class Ext4FS as > ext4 > MainThread::DEBUG::2017-02-03 08:27:36,152::__init__::47:: > blivet::(register_device_format) registered device format class FATFS as > vfat > MainThread::DEBUG::2017-02-03 08:27:36,152::__init__::47:: > blivet::(register_device_format) registered device format class EFIFS as > efi > MainThread::DEBUG::2017-02-03 08:27:36,152::__init__::47:: > blivet::(register_device_format) registered device format class BTRFS as > btrfs > MainThread::DEBUG::2017-02-03 08:27:36,153::__init__::47:: > blivet::(register_device_format) registered device format class GFS2 as > gfs2 > MainThread::DEBUG::2017-02-03 08:27:36,153::__init__::47:: > blivet::(register_device_format) registered device format class JFS as jfs > MainThread::DEBUG::2017-02-03 08:27:36,153::__init__::47:: > blivet::(register_device_format) registered device format class ReiserFS > as reiserfs > MainThread::DEBUG::2017-02-03 08:27:36,153::__init__::47:: > blivet::(register_device_format) registered device format class XFS as xfs > MainThread::DEBUG::2017-02-03 08:27:36,153::__init__::47:: > blivet::(register_device_format) registered device format class HFS as hfs > MainThread::DEBUG::2017-02-03 08:27:36,153::__init__::47:: > blivet::(register_device_format) registered device format class > AppleBootstrapFS as appleboot > MainThread::DEBUG::2017-02-03 08:27:36,154::__init__::47:: > blivet::(register_device_format) registered device format class HFSPlus > as hfs+ > MainThread::DEBUG::2017-02-03 08:27:36,154::__init__::47:: > blivet::(register_device_format) registered device format class MacEFIFS > as macefi > MainThread::DEBUG::2017-02-03 08:27:36,154::__init__::47:: > blivet::(register_device_format) registered device format class NTFS as > ntfs > MainThread::DEBUG::2017-02-03 08:27:36,154::__init__::47:: > blivet::(register_device_format) registered device format class NFS as nfs > MainThread::DEBUG::2017-02-03 08:27:36,154::__init__::47:: > blivet::(register_device_format) registered device format class NFSv4 as > nfs4 > MainThread::DEBUG::2017-02-03 08:27:36,154::__init__::47:: > blivet::(register_device_format) registered device format class Iso9660FS > as iso9660 > MainThread::DEBUG::2017-02-03 08:27:36,154::__init__::47:: > blivet::(register_device_format) registered device format class NoDevFS > as nodev > MainThread::DEBUG::2017-02-03 08:27:36,155::__init__::47:: > blivet::(register_device_format) registered device format class DevPtsFS > as devpts > MainThread::DEBUG::2017-02-03 08:27:36,155::__init__::47:: > blivet::(register_device_format) registered device format class ProcFS as > proc > MainThread::DEBUG::2017-02-03 08:27:36,155::__init__::47:: > blivet::(register_device_format) registered device format class SysFS as > sysfs > MainThread::DEBUG::2017-02-03 08:27:36,155::__init__::47:: > blivet::(register_device_format) registered device format class TmpFS as > tmpfs > MainThread::DEBUG::2017-02-03 08:27:36,155::__init__::47:: > blivet::(register_device_format) registered device format class BindFS as > bind > MainThread::DEBUG::2017-02-03 08:27:36,155::__init__::47:: > blivet::(register_device_format) registered device format class SELinuxFS > as selinuxfs > MainThread::DEBUG::2017-02-03 08:27:36,155::__init__::47:: > blivet::(register_device_format) registered device format class USBFS as > usbfs > MainThread::DEBUG::2017-02-03 08:27:36,155::__init__::47:: > blivet::(register_device_format) registered device format class EFIVarFS > as efivarfs > MainThread::DEBUG::2017-02-03 08:27:36,179::__init__::47:: > blivet::(register_device_format) registered device format class LUKS as > luks > MainThread::DEBUG::2017-02-03 08:27:36,181::__init__::47:: > blivet::(register_device_format) registered device format class > LVMPhysicalVolume as lvmpv > MainThread::DEBUG::2017-02-03 08:27:36,181::__init__::47:: > blivet::(register_device_format) registered device format class > MDRaidMember as mdmember > MainThread::DEBUG::2017-02-03 08:27:36,181::__init__::47:: > blivet::(register_device_format) registered device format class > MultipathMember as multipath_member > MainThread::DEBUG::2017-02-03 08:27:36,181::__init__::47:: > blivet::(register_device_format) registered device format class > PPCPRePBoot as prepboot > MainThread::DEBUG::2017-02-03 08:27:36,182::__init__::47:: > blivet::(register_device_format) registered device format class SwapSpace > as swap > MainThread::DEBUG::2017-02-03 08:27:36,216::storage_log::69::blivet::(log_exception_info) > IGNORED: Caught exception, continuing. > MainThread::DEBUG::2017-02-03 08:27:36,216::storage_log::72::blivet::(log_exception_info) > IGNORED: Problem description: failed to get initiator name from > iscsi firmware > MainThread::DEBUG::2017-02-03 08:27:36,216::storage_log::73::blivet::(log_exception_info) > IGNORED: Begin exception details. > MainThread::DEBUG::2017-02-03 08:27:36,216::storage_log::76::blivet::(log_exception_info) > IGNORED: Traceback (most recent call last): > MainThread::DEBUG::2017-02-03 08:27:36,216::storage_log::76::blivet::(log_exception_info) > IGNORED: File "/usr/lib/python2.7/site-packages/blivet > /iscsi.py", line 146, in __init__ > MainThread::DEBUG::2017-02-03 08:27:36,216::storage_log::76::blivet::(log_exception_info) > IGNORED: initiatorname = libiscsi.get_firmware_initi > ator_name() > MainThread::DEBUG::2017-02-03 08:27:36,216::storage_log::76::blivet::(log_exception_info) > IGNORED: IOError: Unknown error > MainThread::DEBUG::2017-02-03 08:27:36,216::storage_log::77::blivet::(log_exception_info) > IGNORED: End exception details. > MainThread::DEBUG::2017-02-03 08:27:36,227::supervdsmServer::271::SuperVdsm.Server::(main) > Making sure I'm root - SuperVdsm > MainThread::DEBUG::2017-02-03 08:27:36,227::supervdsmServer::280::SuperVdsm.Server::(main) > Parsing cmd args > MainThread::DEBUG::2017-02-03 08:27:36,227::supervdsmServer::283::SuperVdsm.Server::(main) > Cleaning old socket /var/run/vdsm/svdsm.sock > MainThread::DEBUG::2017-02-03 08:27:36,227::supervdsmServer::287::SuperVdsm.Server::(main) > Setting up keep alive thread > MainThread::DEBUG::2017-02-03 08:27:36,228::supervdsmServer::293::SuperVdsm.Server::(main) > Creating remote object manager > MainThread::DEBUG::2017-02-03 08:27:36,228::fileUtils::246::storage.fileUtils::(chown) > Changing owner for /var/run/vdsm/svdsm.sock, to (36:36) > MainThread::DEBUG::2017-02-03 08:27:36,228::supervdsmServer::303::SuperVdsm.Server::(main) > Started serving super vdsm object > sourceRoute::DEBUG::2017-02-03 08:27:36,229:: > sourceroutethread::79::root::(_subscribeToInotifyLoop) sourceRouteThread.subscribeToInotifyLoop > started > restore-net::INFO::2017-02-03 08:27:37,160::vdsm-restore- > net-config::465::root::(restore) networks already restored. doing nothing. > MainProcess|hsm/init::DEBUG::2017-02-03 08:27:39,601::supervdsmServer: > :93::SuperVdsm.ServerCallback::(wrapper) call hbaRescan with () {} > MainProcess|hsm/init::DEBUG::2017-02-03 08:27:39,602::commands::69::storage.HBA::(execCmd) > /usr/bin/taskset --cpu-list 0-47 /usr/libexec/vdsm/fc-scan (cwd No > ne) > MainProcess|hsm/init::DEBUG::2017-02-03 08:27:39,691::supervdsmServer: > :100::SuperVdsm.ServerCallback::(wrapper) return hbaRescan with None > MainProcess|jsonrpc/4::DEBUG::2017-02-03 08:27:48,355::supervdsmServer: > :93::SuperVdsm.ServerCallback::(wrapper) call network_caps with () {} > MainProcess|jsonrpc/4::DEBUG::2017-02-03 08:27:48,360::commands::69::root::(execCmd) > /usr/bin/taskset --cpu-list 0-47 /sbin/ip route show to 0.0.0.0/0 table > main (cwd None) > MainProcess|jsonrpc/4::DEBUG::2017-02-03 08:27:48,364::commands::93::root::(execCmd) > SUCCESS: <err> = ''; <rc> = 0 > MainProcess|jsonrpc/4::DEBUG::2017-02-03 08:27:48,408:: > libvirtconnection::160::root::(get) trying to connect libvirt > MainProcess|jsonrpc/4::DEBUG::2017-02-03 08:27:48,450::commands::69::root::(execCmd) > /usr/bin/taskset --cpu-list 0-47 /usr/sbin/tc qdisc show (cwd None) > MainProcess|jsonrpc/4::DEBUG::2017-02-03 08:27:48,453::commands::93::root::(execCmd) > SUCCESS: <err> = ''; <rc> = 0 > MainProcess|jsonrpc/4::DEBUG::2017-02-03 08:27:48,454::commands::69::root::(execCmd) > /usr/bin/taskset --cpu-list 0-47 /bin/systemctl --no-pager list-unit-fil > es (cwd None) > MainProcess|jsonrpc/4::DEBUG::2017-02-03 08:27:48,530::commands::93::root::(execCmd) > SUCCESS: <err> = ''; <rc> = 0 > MainProcess|jsonrpc/4::DEBUG::2017-02-03 08:27:48,530::commands::69::root::(execCmd) > /usr/bin/taskset --cpu-list 0-47 /bin/systemctl status openvswitch.servi > ce (cwd None) > MainProcess|jsonrpc/4::DEBUG::2017-02-03 08:27:48,561::commands::93::root::(execCmd) > FAILED: <err> = ''; <rc> = 3 > MainProcess|jsonrpc/4::DEBUG::2017-02-03 08:27:48,561::supervdsmServer: > :100::SuperVdsm.ServerCallback::(wrapper) return network_caps with > {'bridges': {}, 'bo > ndings': {}, 'nameservers': ['10.1.1.8'], 'nics': {'ib0': {'ipv6autoconf': > True, 'addr': '', 'ipv6gateway': '::', 'dhcpv6': False, 'ipv6addrs': [], > 'mtu': '4 > 092', 'dhcpv4': False, 'netmask': '', 'ipv4defaultroute': False, > 'ipv4addrs': [], 'hwaddr': '80:00:02:08:fe:80:00:00:00: > 00:00:00:0c:c4:7a:ff:ff:0f:d8:85', 's > peed': 0, 'gateway': ''}, 'eno1': {'ipv6autoconf': False, 'addr': > '10.1.235.5', 'ipv6gateway': '::', 'dhcpv6': False, 'ipv6addrs': [], 'mtu': > '1500', 'dhcpv4 > ': False, 'netmask': '255.255.0.0', 'ipv4defaultroute': True, 'ipv4addrs': > ['10.1.235.5/16'], 'hwaddr': '0c:c4:7a:0f:6b:2a', 'speed': 1000, > 'gateway': '10.1. > 0.1'}, 'eno2': {'ipv6autoconf': True, 'addr': '', 'ipv6gateway': '::', > 'dhcpv6': False, 'ipv6addrs': [], 'mtu': '1500', 'dhcpv4': False, > 'netmask': '', 'ipv4 > defaultroute': False, 'ipv4addrs': [], 'hwaddr': '0c:c4:7a:0f:6b:2b', > 'speed': 0, 'gateway': ''}}, 'supportsIPv6': True, 'vlans': {}, 'networks': > {}} > MainProcess|jsonrpc/5::DEBUG::2017-02-03 08:27:53,690::supervdsmServer: > :93::SuperVdsm.ServerCallback::(wrapper) call setupNetworks with ({}, > {u'connectivityC > heck': u'true', u'connectivityTimeout': 120}) {} > MainProcess|jsonrpc/5::DEBUG::2017-02-03 08:27:53,691::api::247::root::(setupNetworks) > Setting up network according to configuration: networks:{u'ovirtmgmt': > {u'ipv6autoconf': False, u'nic': u'eno1', u'ipaddr': u'10.1.235.5', > u'netmask': u'255.255.0.0', u'mtu': 1500, u'switch': u'ovs', u'dhcpv6': > False, u'STP': u'no', u'bridged': u'true', u'gateway': u'10.1.0.1', > u'defaultRoute': True}}, bondings:{}, options:{u'connectivityCheck': > u'true', u'connectivityTimeout': 120} > MainProcess|jsonrpc/5::DEBUG::2017-02-03 08:27:53,691::api::252::root::(setupNetworks) > Validating configuration > MainProcess|jsonrpc/5::DEBUG::2017-02-03 08:27:53,694::commands::69::root::(execCmd) > /usr/bin/taskset --cpu-list 0-47 /sbin/ip route show to 0.0.0.0/0 table > main (cwd None) > MainProcess|jsonrpc/5::DEBUG::2017-02-03 08:27:53,698::commands::93::root::(execCmd) > SUCCESS: <err> = ''; <rc> = 0 > MainProcess|jsonrpc/5::DEBUG::2017-02-03 08:27:53,771::commands::69::root::(execCmd) > /usr/bin/taskset --cpu-list 0-47 /usr/sbin/tc qdisc show (cwd None) > MainProcess|jsonrpc/5::DEBUG::2017-02-03 08:27:53,774::commands::93::root::(execCmd) > SUCCESS: <err> = ''; <rc> = 0 > MainProcess|jsonrpc/5::DEBUG::2017-02-03 08:27:53,774::vsctl::57::root::(commit) > Executing commands: /usr/bin/ovs-vsctl --oneline --format=json -- list > Bridge -- list Port -- list Interface > MainProcess|jsonrpc/5::DEBUG::2017-02-03 08:27:53,774::commands::69::root::(execCmd) > /usr/bin/taskset --cpu-list 0-47 /usr/bin/ovs-vsctl --oneline --format=json > -- list Bridge -- list Port -- list Interface (cwd None) > MainProcess|jsonrpc/5::DEBUG::2017-02-03 08:27:53,807::commands::93::root::(execCmd) > FAILED: <err> = 'ovs-vsctl: unix:/var/run/openvswitch/db.sock: database > connection failed (No such file or directory)\n'; <rc> = 1 > MainProcess|jsonrpc/5::ERROR::2017-02-03 08:27:53,808::supervdsmServer: > :97::SuperVdsm.ServerCallback::(wrapper) Error in setupNetworks > Traceback (most recent call last): > File "/usr/share/vdsm/supervdsmServer", line 95, in wrapper > res = func(*args, **kwargs) > File "/usr/lib/python2.7/site-packages/vdsm/network/api.py", line 254, > in setupNetworks > netswitch.validate(networks, bondings) > File "/usr/lib/python2.7/site-packages/vdsm/network/netswitch.py", line > 121, in validate > ovs_switch.validate_network_setup(ovs_nets, ovs_bonds) > File "/usr/lib/python2.7/site-packages/vdsm/network/ovs/switch.py", > line 40, in validate_network_setup > ovs_networks = info.create_netinfo(info.OvsInfo())['networks'] > File "/usr/lib/python2.7/site-packages/vdsm/network/ovs/info.py", line > 73, in __init__ > ovs_db = OvsDB(driver.create()) > File "/usr/lib/python2.7/site-packages/vdsm/network/ovs/info.py", line > 64, in __init__ > transaction.add(ifaces_command) > File "/usr/lib/python2.7/site-packages/vdsm/network/ovs/driver/__init__.py", > line 54, in __exit__ > self.result = self.commit() > File "/usr/lib/python2.7/site-packages/vdsm/network/ovs/driver/vsctl.py", > line 63, in commit > 'Executing commands failed: %s' % '\n'.join(err)) > ConfigNetworkError: (21, 'Executing commands failed: ovs-vsctl: > unix:/var/run/openvswitch/db.sock: database connection failed (No such > file or directory)') > MainProcess|Thread-2::DEBUG::2017-02-03 08:27:54,440::supervdsmServer: > :93::SuperVdsm.ServerCallback::(wrapper) call ksmTune with () {} > MainProcess|Thread-2::DEBUG::2017-02-03 08:27:54,440::supervdsmServer: > :100::SuperVdsm.ServerCallback::(wrapper) return ksmTune with None > MainProcess|jsonrpc/0::DEBUG::2017-02-03 08:30:00,918::supervdsmServer: > :93::SuperVdsm.ServerCallback::(wrapper) call network_caps with () {} > MainProcess|jsonrpc/0::DEBUG::2017-02-03 08:30:00,922::commands::69::root::(execCmd) > /usr/bin/taskset --cpu-list 0-47 /sbin/ip route show to 0.0.0.0/0 table > main (cwd None) > MainProcess|jsonrpc/0::DEBUG::2017-02-03 08:30:00,927::commands::93::root::(execCmd) > SUCCESS: <err> = ''; <rc> = 0 > MainProcess|jsonrpc/0::DEBUG::2017-02-03 08:30:01,013::commands::69::root::(execCmd) > /usr/bin/taskset --cpu-list 0-47 /usr/sbin/tc qdisc show (cwd None) > MainProcess|jsonrpc/0::DEBUG::2017-02-03 08:30:01,016::commands::93::root::(execCmd) > SUCCESS: <err> = ''; <rc> = 0 > MainProcess|jsonrpc/0::DEBUG::2017-02-03 08:30:01,017::supervdsmServer: > :100::SuperVdsm.ServerCallback::(wrapper) return network_caps with > {'bridges': {}, 'bondings': {}, 'nameservers': ['10.1.1.8'], 'nics': > {'ib0': {'ipv6autoconf': True, 'addr': '', 'ipv6gateway': '::', 'dhcpv6': > False, 'ipv6addrs': [], 'mtu': '4092', 'dhcpv4': False, 'netmask': '', > 'ipv4defaultroute': False, 'ipv4addrs': [], 'hwaddr': > '80:00:02:08:fe:80:00:00:00:00:00:00:0c:c4:7a:ff:ff:0f:d8:85', 'speed': > 0, 'gateway': ''}, 'eno1': {'ipv6autoconf': False, 'addr': '10.1.235.5', > 'ipv6gateway': '::', 'dhcpv6': False, 'ipv6addrs': [], 'mtu': '1500', > 'dhcpv4': False, 'netmask': '255.255.0.0', 'ipv4defaultroute': True, > 'ipv4addrs': ['10.1.235.5/16'], 'hwaddr': '0c:c4:7a:0f:6b:2a', 'speed': > 1000, 'gateway': '10.1.0.1'}, 'eno2': {'ipv6autoconf': True, 'addr': '', > 'ipv6gateway': '::', 'dhcpv6': False, 'ipv6addrs': [], 'mtu': '1500', > 'dhcpv4': False, 'netmask': '', 'ipv4defaultroute': False, 'ipv4addrs': [], > 'hwaddr': '0c:c4:7a:0f:6b:2b', 'speed': 0, 'gateway': ''}}, 'supportsIPv6': > True, 'vlans': {}, 'networks': {}} > MainProcess|jsonrpc/1::DEBUG::2017-02-03 08:30:01,036::supervdsmServer: > :93::SuperVdsm.ServerCallback::(wrapper) call getHardwareInfo with () {} > MainProcess|jsonrpc/1::DEBUG::2017-02-03 08:30:01,066::supervdsmServer: > :100::SuperVdsm.ServerCallback::(wrapper) return getHardwareInfo with > {'systemProductName': 'X9DRT', 'systemSerialNumber': '0123456789', > 'systemFamily': 'To be filled by O.E.M.', 'systemVersion': '0123456789', > 'systemUUID': '00000000-0000-0000-0000-0CC47A0F6B2A', > 'systemManufacturer': 'Supermicro'} > (END) > > > > On Fri, Feb 3, 2017 at 12:05 AM, Edward Haas <ehaas(a)redhat.com> wrote: > >> Hello Shalabh, >> >> Please provide the logs from your node: >> - messages >> - vdsm/vdsm.log, vdsm/supervdsm.log >> >> It may be that you are missing openvswitch installed, although VDSM >> should not require it for its operation. >> >> Thanks, >> Edy. >> >> >> On Thu, Feb 2, 2017 at 2:10 PM, Shalabh Goel <shalabhgoel13(a)gmail.com> >> wrote: >> >>> HI, >>> >>> I am getting the following error on my node after rebooting it. >>> >>> VDSM ovirtnode2 command HostSetupNetworksVDS failed: Executing commands >>> failed: ovs-vsctl: unix:/var/run/openvswitch/db.sock: database >>> connection failed (No such file or directory) >>> >>> >>> To solve this, I am trying to restart ovsdb-server using the following >>> command, >>> >>> ovsdb-server --remote=punix:*/var/run/openvswitch/db.sock* >>> --remote=db:Open_vSwitch,Open_vSwitch,manager_options >>> --private-key=db:Open_vSwitch,SSL,private_key--certificate=db:Open_vSwitch,SSL,certificate >>> --bootstrap-ca-cert=db:Open_vSwitch,SSL,ca_cert --pidfile --detach >>> >>> But I am getting the following error. >>> >>> ovsdb-server: /var/run/openvswitch/ovsdb-server.pid.tmp: create failed >>> (No such file or directory) >>> >>> How to restart the ovsdb-server?? Also ovirtmgmt network is missing from >>> my node. It happened after I rebooted my node after it got upgraded to >>> Ovirt 4.1 >>> >>> -- >>> Shalabh Goel >>> >>> _______________________________________________ >>> Users mailing list >>> Users(a)ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/users >>> >>> >> > > > -- > Shalabh Goel >

3 6

Hosted engine errors after 4.1 upgrade.
by Todd Punderson 09 Feb '17

09 Feb '17

Seeing issues with my hosted engine, it seems it's unable to extract vm.conf from storage. My ovirt-hosted-engine-ha/agent.log is full of this repeating over and over. This is happening on all 3 of my hosts. My storage is glusterfs on the hosts themselves. Hopefully this is enough info to get started. Thanks! MainThread::INFO::2017-02-07 19:27:33,063::hosted_engine::612::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(_initialize_vdsm) Initializing VDSM MainThread::INFO::2017-02-07 19:27:35,455::hosted_engine::639::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(_initialize_storage_images) Connecting the storage MainThread::INFO::2017-02-07 19:27:35,456::storage_server::219::ovirt_hosted_engine_ha.lib.storage_server.StorageServer::(connect_storage_server) Connecting storage server MainThread::INFO::2017-02-07 19:27:40,169::storage_server::226::ovirt_hosted_engine_ha.lib.storage_server.StorageServer::(connect_storage_server) Connecting storage server MainThread::INFO::2017-02-07 19:27:40,202::storage_server::233::ovirt_hosted_engine_ha.lib.storage_server.StorageServer::(connect_storage_server) Refreshing the storage domain MainThread::INFO::2017-02-07 19:27:40,418::hosted_engine::666::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(_initialize_storage_images) Preparing images MainThread::INFO::2017-02-07 19:27:40,419::image::126::ovirt_hosted_engine_ha.lib.image.Image::(prepare_images) Preparing images MainThread::INFO::2017-02-07 19:27:43,370::hosted_engine::669::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(_initialize_storage_images) Reloading vm.conf from the shared storage domain MainThread::INFO::2017-02-07 19:27:43,371::config::206::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine.config::(refresh_local_conf_file) Trying to get a fresher copy of vm configuration from the OVF_STORE MainThread::INFO::2017-02-07 19:27:45,968::ovf_store::103::ovirt_hosted_engine_ha.lib.ovf.ovf_store.OVFStore::(scan) Found OVF_STORE: imgUUID:3e14c1b5-5ade-4827-aad4-66c59824acd2, volUUID:3cbeeb3b-f755-4d42-a654-8dab34213792 MainThread::INFO::2017-02-07 19:27:46,257::ovf_store::103::ovirt_hosted_engine_ha.lib.ovf.ovf_store.OVFStore::(scan) Found OVF_STORE: imgUUID:9b49968b-5a62-4ab2-a2c5-b94bc0b2d3ce, volUUID:8f4d69c5-73a7-4e8c-a58f-909b55efec7d MainThread::INFO::2017-02-07 19:27:46,355::ovf_store::112::ovirt_hosted_engine_ha.lib.ovf.ovf_store.OVFStore::(getEngineVMOVF) Extracting Engine VM OVF from the OVF_STORE MainThread::INFO::2017-02-07 19:27:46,366::ovf_store::119::ovirt_hosted_engine_ha.lib.ovf.ovf_store.OVFStore::(getEngineVMOVF) OVF_STORE volume path: /rhev/data-center/mnt/glusterSD/ovirt01-gluster.doonga.org: _engine/536cd721-4396-4029-b1ea-8ce84738137e/images/9b49968b-5a62-4ab2-a2c5-b94bc0b2d3ce/8f4d69c5-73a7-4e8c-a58f-909b55efec7d MainThread::ERROR::2017-02-07 19:27:46,389::ovf_store::124::ovirt_hosted_engine_ha.lib.ovf.ovf_store.OVFStore::(getEngineVMOVF) Unable to extract HEVM OVF MainThread::ERROR::2017-02-07 19:27:46,390::config::235::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine.config::(refresh_local_conf_file) Unable to get vm.conf from OVF_STORE, falling back to initial vm.conf

3 3

Ovirt console ticket time threshold and password
by rightkicktech.gmail.com 08 Feb '17

08 Feb '17

------BKFKJ8HFVSAML87AJHD1T3RNOSRSVF Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Hi all, Is there any standard recommended way to alter the default value of 120 secs set on spice console? Also, can the password be disabled if needed? There are several hacks floating arround, but none seems clean. Thanx, Alex -- Sent from my Android device with K-9 Mail. Please excuse my brevity. ------BKFKJ8HFVSAML87AJHD1T3RNOSRSVF Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Hi all, Is there any standard recommended way to alter the default value of 120 secs set on spice console? Also, can the password be disabled if needed? There are several hacks floating arround, but none seems clean. Thanx, Alex -- Sent from my Android device with K-9 Mail. Please excuse my brevity. ------BKFKJ8HFVSAML87AJHD1T3RNOSRSVF--

2 3

Invitation: Deep Dive: Ansible modules for oVirt @ Tue Feb 14, 2017 4pm - 5pm (CET) (users@ovirt.org)
by omachace＠redhat.com 08 Feb '17

08 Feb '17

You have been invited to the following event. Title: Deep Dive: Ansible modules for oVirt In this presentation will do a short introduction to Ansible. Then we will focus how to use Ansible with oVirt. Ansible 2.3 ships many oVirt modules, which can help you orchestrate your oVirt infrastructure. We will show a demo how to use them. Ansible 2.3 also ships dynamic inventory for oVirt, we will show how to use it as well. Stream: https://www.youtube.com/watch?v=BgohrQ1itzM Slides: https://redhat.slides.com/omachace/ansbile-modules-for-ovirt Docs: http://www.ovirt.org/develop/release-management/features/infra/ansible_modu… http://docs.ansible.com/ansible/list_of_cloud_modules.html#ovirt When: Tue Feb 14, 2017 4pm – 5pm Central European Time - Prague Calendar: users(a)ovirt.org Who: (Guest list is too large to display) Event details: https://www.google.com/calendar/event?action=VIEW&eid=cTJpaWdkaWpuc2lkbmhnc… Invitation from Google Calendar: https://www.google.com/calendar/ You are receiving this courtesy email at the account users(a)ovirt.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://www.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to modify your RSVP response. Learn more at https://support.google.com/calendar/answer/37135#forwarding

1 0

Re: [ovirt-users] How to update ovirt ng nodes
by Massimo Mad 08 Feb '17

08 Feb '17

Hi David, I try to use yum update but i have this error : yum update Loaded plugins: fastestmirror, imgbased-warning Warning: yum operations are not persisted across upgrades! The problem is that on the server i have this repository: ovirt-4.0.repo ovirt-4.0-dependencies.repo With this repository it's possible upgrade ovirt only only between minor releases for example from 4.0.1 to 4.0.6, i want to upgrade the host from 4.0 to 4.1. Regards Massimo

3 2

ovirt-engine is participating in openjdk's adoption group for jdk9
by Roy Golan 08 Feb '17

08 Feb '17

ovirt-engine is now listed in openjdk's adoption group in order to help and supply feedback on jdk9. https://wiki.openjdk.java.net/display/quality/Quality+Outreach I'm working on creating a ci job to just run compilation, that would be travis or our jenkins.

1 0

ovirt-engine-notifier tuning?
by Nicolás 08 Feb '17

08 Feb '17

Hi, Is there a way to configure the frequency on which the ovirt-engine-notifier notifies about the same issue? We've recently had a Domain Storage with low space and an email was sent cca. every 15 minutes. Is there a way to increase this notification time? This is oVirt 4.0.4-4. Thanks.

2 1