- Users - oVirt List Archives

engine upgrade 3.2.2 --> 3.2.3 Database rename failed
by Neil 22 May '14

22 May '14

Hi guys, I'm trying to upgrade from Dreyou to the official repo, I've installed the official 3.2 repo (I'll do the 3.3 update once this works). I've updated to ovirt-engine-setup.noarch 0:3.2.3-1.el6 and when I run engine upgrade it bombs out when trying to rename my database with the following error... [root@engine01 /]# cat /var/log/ovirt-engine/ovirt-engine-upgrade_2014_05_20_16_34_21.log 2014-05-20 16:34:21::DEBUG::common_utils::804::root:: found existing pgpass file /etc/ovirt-engine/.pgpass, fetching DB host value 2014-05-20 16:34:21::DEBUG::common_utils::804::root:: found existing pgpass file /etc/ovirt-engine/.pgpass, fetching DB port value 2014-05-20 16:34:21::DEBUG::common_utils::804::root:: found existing pgpass file /etc/ovirt-engine/.pgpass, fetching DB user value 2014-05-20 16:34:21::DEBUG::common_utils::332::root:: YUM: VERB: Loaded plugins: refresh-packagekit, versionlock 2014-05-20 16:34:21::INFO::engine-upgrade::969::root:: Info: /etc/ovirt-engine/.pgpass file found. Continue. 2014-05-20 16:34:21::DEBUG::common_utils::804::root:: found existing pgpass file /etc/ovirt-engine/.pgpass, fetching DB admin value 2014-05-20 16:34:21::DEBUG::common_utils::804::root:: found existing pgpass file /etc/ovirt-engine/.pgpass, fetching DB host value 2014-05-20 16:34:21::DEBUG::common_utils::804::root:: found existing pgpass file /etc/ovirt-engine/.pgpass, fetching DB port value 2014-05-20 16:34:21::DEBUG::common_utils::481::root:: running sql query 'SELECT pg_database_size('engine')' on db server: 'localhost'. 2014-05-20 16:34:21::DEBUG::common_utils::434::root:: Executing command --> '/usr/bin/psql -h localhost -p 5432 -U postgres -d postgres -c SELECT pg_database_size('engine')' 2014-05-20 16:34:21::DEBUG::common_utils::472::root:: output = pg_database_size ------------------ 11976708 (1 row) 2014-05-20 16:34:21::DEBUG::common_utils::473::root:: stderr = 2014-05-20 16:34:21::DEBUG::common_utils::474::root:: retcode = 0 2014-05-20 16:34:21::DEBUG::common_utils::1567::root:: Found mount point of '/var/cache/yum' at '/' 2014-05-20 16:34:21::DEBUG::common_utils::663::root:: Checking available space on /var/cache/yum 2014-05-20 16:34:21::DEBUG::common_utils::668::root:: Available space on /var/cache/yum is 172329 2014-05-20 16:34:21::DEBUG::common_utils::1567::root:: Found mount point of '/var/lib/ovirt-engine/backups' at '/' 2014-05-20 16:34:21::DEBUG::common_utils::663::root:: Checking available space on /var/lib/ovirt-engine/backups 2014-05-20 16:34:21::DEBUG::common_utils::668::root:: Available space on /var/lib/ovirt-engine/backups is 172329 2014-05-20 16:34:21::DEBUG::common_utils::1567::root:: Found mount point of '/usr/share' at '/' 2014-05-20 16:34:21::DEBUG::common_utils::663::root:: Checking available space on /usr/share 2014-05-20 16:34:21::DEBUG::common_utils::668::root:: Available space on /usr/share is 172329 2014-05-20 16:34:21::DEBUG::common_utils::1590::root:: Mount points are: {'/': {'required': 1511, 'free': 172329}} 2014-05-20 16:34:21::DEBUG::common_utils::1599::root:: Comparing free space 172329 MB with required 1511 MB 2014-05-20 16:34:21::DEBUG::common_utils::481::root:: running sql query 'SELECT compatibility_version FROM storage_pool;' on db server: 'localhost'. 2014-05-20 16:34:21::DEBUG::common_utils::434::root:: Executing command --> '/usr/bin/psql -h localhost -p 5432 -U engine -d engine -c SELECT compatibility_version FROM storage_pool;' 2014-05-20 16:34:21::DEBUG::common_utils::472::root:: output = compatibility_version ----------------------- 3.2 (1 row) 2014-05-20 16:34:21::DEBUG::common_utils::473::root:: stderr = 2014-05-20 16:34:21::DEBUG::common_utils::474::root:: retcode = 0 2014-05-20 16:34:21::DEBUG::common_utils::481::root:: running sql query 'SELECT compatibility_version FROM vds_groups;' on db server: 'localhost'. 2014-05-20 16:34:21::DEBUG::common_utils::434::root:: Executing command --> '/usr/bin/psql -h localhost -p 5432 -U engine -d engine -c SELECT compatibility_version FROM vds_groups;' 2014-05-20 16:34:21::DEBUG::common_utils::472::root:: output = compatibility_version ----------------------- 3.2 (1 row) 2014-05-20 16:34:21::DEBUG::common_utils::473::root:: stderr = 2014-05-20 16:34:21::DEBUG::common_utils::474::root:: retcode = 0 2014-05-20 16:34:21::DEBUG::engine-upgrade::280::root:: Yum unlock started 2014-05-20 16:34:21::DEBUG::engine-upgrade::292::root:: Yum unlock completed successfully 2014-05-20 16:34:22::DEBUG::common_utils::332::root:: YUM: VERB: Downloading: repomdu5SB03tmp.xml (0%) 2014-05-20 16:34:22::DEBUG::common_utils::332::root:: YUM: VERB: Downloading: repomdu5SB03tmp.xml 3.7 k(100%) 2014-05-20 16:34:30::DEBUG::common_utils::332::root:: YUM: VERB: Downloading: repomdf3Wi70tmp.xml (0%) 2014-05-20 16:34:30::DEBUG::common_utils::332::root:: YUM: VERB: Downloading: repomdf3Wi70tmp.xml 2.9 k(100%) 2014-05-20 16:34:30::DEBUG::common_utils::332::root:: YUM: VERB: Downloading: repomdf3Wi70tmp.xml 2.9 k(100%) 2014-05-20 16:34:31::DEBUG::common_utils::332::root:: YUM: VERB: Downloading: repomdHz6Ctstmp.xml (0%) 2014-05-20 16:34:31::DEBUG::common_utils::332::root:: YUM: VERB: Downloading: repomdHz6Ctstmp.xml 3.4 k(100%) 2014-05-20 16:34:37::DEBUG::common_utils::332::root:: YUM: VERB: Downloading: repomdyHOcNQtmp.xml (0%) 2014-05-20 16:34:37::DEBUG::common_utils::332::root:: YUM: VERB: Downloading: repomdyHOcNQtmp.xml 2.9 k(100%) 2014-05-20 16:34:38::DEBUG::common_utils::332::root:: YUM: VERB: Downloading: repomdTvp5RWtmp.xml (0%) 2014-05-20 16:34:39::DEBUG::common_utils::332::root:: YUM: VERB: Downloading: repomdTvp5RWtmp.xml 2.9 k(100%) 2014-05-20 16:34:40::DEBUG::common_utils::332::root:: YUM: VERB: Downloading: repomdpoFiQgtmp.xml (0%) 2014-05-20 16:34:40::DEBUG::common_utils::332::root:: YUM: VERB: Downloading: repomdpoFiQgtmp.xml 3.4 k(100%) 2014-05-20 16:34:41::DEBUG::common_utils::332::root:: YUM: VERB: Downloading: repomddmRA9ttmp.xml (0%) 2014-05-20 16:34:41::DEBUG::common_utils::332::root:: YUM: VERB: Downloading: repomddmRA9ttmp.xml 951 (100%) 2014-05-20 16:34:41::DEBUG::common_utils::332::root:: YUM: VERB: queue package ovirt-engine for update 2014-05-20 16:34:42::DEBUG::common_utils::332::root:: YUM: VERB: package ovirt-engine queued 2014-05-20 16:34:42::DEBUG::common_utils::332::root:: YUM: VERB: Building transaction 2014-05-20 16:34:44::DEBUG::common_utils::332::root:: YUM: VERB: Transaction built 2014-05-20 16:34:44::DEBUG::engine-upgrade::314::root:: Transaction Summary: 2014-05-20 16:34:44::DEBUG::engine-upgrade::318::root:: update - ovirt-engine-3.2.3-1.el6.noarch 2014-05-20 16:34:44::DEBUG::engine-upgrade::318::root:: update - ovirt-engine-backend-3.2.3-1.el6.noarch 2014-05-20 16:34:44::DEBUG::engine-upgrade::318::root:: update - ovirt-engine-dbscripts-3.2.3-1.el6.noarch 2014-05-20 16:34:44::DEBUG::engine-upgrade::318::root:: update - ovirt-engine-genericapi-3.2.3-1.el6.noarch 2014-05-20 16:34:44::DEBUG::engine-upgrade::318::root:: update - ovirt-engine-restapi-3.2.3-1.el6.noarch 2014-05-20 16:34:44::DEBUG::engine-upgrade::318::root:: update - ovirt-engine-tools-3.2.3-1.el6.noarch 2014-05-20 16:34:44::DEBUG::engine-upgrade::318::root:: update - ovirt-engine-userportal-3.2.3-1.el6.noarch 2014-05-20 16:34:44::DEBUG::engine-upgrade::318::root:: update - ovirt-engine-webadmin-portal-3.2.3-1.el6.noarch 2014-05-20 16:34:44::DEBUG::engine-upgrade::329::root:: Yum rollback-avail started 2014-05-20 16:34:44::DEBUG::engine-upgrade::335::root:: Checking package ovirt-engine-3.2.2-1.1.43.el6.noarch 2014-05-20 16:34:44::DEBUG::engine-upgrade::335::root:: Checking package ovirt-engine-backend-3.2.2-1.1.43.el6.noarch 2014-05-20 16:34:45::DEBUG::engine-upgrade::335::root:: Checking package ovirt-engine-dbscripts-3.2.2-1.1.43.el6.noarch 2014-05-20 16:34:45::DEBUG::engine-upgrade::335::root:: Checking package ovirt-engine-genericapi-3.2.2-1.1.43.el6.noarch 2014-05-20 16:34:46::DEBUG::engine-upgrade::335::root:: Checking package ovirt-engine-restapi-3.2.2-1.1.43.el6.noarch 2014-05-20 16:34:46::DEBUG::engine-upgrade::335::root:: Checking package ovirt-engine-tools-3.2.2-1.1.43.el6.noarch 2014-05-20 16:34:47::DEBUG::engine-upgrade::335::root:: Checking package ovirt-engine-userportal-3.2.2-1.1.43.el6.noarch 2014-05-20 16:34:47::DEBUG::engine-upgrade::335::root:: Checking package ovirt-engine-webadmin-portal-3.2.2-1.1.43.el6.noarch 2014-05-20 16:34:48::DEBUG::engine-upgrade::340::root:: Yum rollback-avail completed successfully 2014-05-20 16:34:48::DEBUG::engine-upgrade::1045::root:: related to database package ovirt-engine-backend 2014-05-20 16:34:48::DEBUG::engine-upgrade::1045::root:: related to database package ovirt-engine-dbscripts 2014-05-20 16:34:48::DEBUG::engine-upgrade::200::root:: checking the status of ovirt-engine service 2014-05-20 16:34:48::DEBUG::common_utils::434::root:: Executing command --> '/sbin/service ovirt-engine status' 2014-05-20 16:34:48::DEBUG::common_utils::472::root:: output = The engine is not running. 2014-05-20 16:34:48::DEBUG::common_utils::473::root:: stderr = 2014-05-20 16:34:48::DEBUG::common_utils::474::root:: retcode = 3 2014-05-20 16:34:48::DEBUG::engine-upgrade::595::root:: stopping ovirt-engine service. 2014-05-20 16:34:48::DEBUG::common_utils::434::root:: Executing command --> '/sbin/service ovirt-engine stop' 2014-05-20 16:34:48::DEBUG::common_utils::472::root:: output = Stopping engine-service: [ OK ] 2014-05-20 16:34:48::DEBUG::common_utils::473::root:: stderr = 2014-05-20 16:34:48::DEBUG::common_utils::474::root:: retcode = 0 2014-05-20 16:34:48::DEBUG::common_utils::1289::root:: getting status for engine-notifierd 2014-05-20 16:34:48::DEBUG::common_utils::1298::root:: executing action engine-notifierd on service status 2014-05-20 16:34:48::DEBUG::common_utils::434::root:: Executing command --> '/sbin/service engine-notifierd status' 2014-05-20 16:34:49::DEBUG::common_utils::472::root:: output = /etc/init.d/engine-notifierd is stopped 2014-05-20 16:34:49::DEBUG::common_utils::473::root:: stderr = 2014-05-20 16:34:49::DEBUG::common_utils::474::root:: retcode = 1 2014-05-20 16:34:49::DEBUG::engine-upgrade::840::root:: Checking active system tasks 2014-05-20 16:34:49::DEBUG::common_utils::434::root:: Executing command --> '/usr/bin/psql -U engine -f /usr/share/ovirt-engine/scripts/add_fn_db_get_async_tasks_function.sql -d engine' 2014-05-20 16:34:49::DEBUG::common_utils::472::root:: output = DROP TYPE CREATE TYPE CREATE FUNCTION 2014-05-20 16:34:49::DEBUG::common_utils::473::root:: stderr = psql:/usr/share/ovirt-engine/scripts/add_fn_db_get_async_tasks_function.sql:18: NOTICE: drop cascades to function fn_db_get_async_tasks() 2014-05-20 16:34:49::DEBUG::common_utils::474::root:: retcode = 0 2014-05-20 16:34:49::DEBUG::common_utils::481::root:: running sql query 'select * from fn_db_get_async_tasks();' on db server: 'localhost'. 2014-05-20 16:34:49::DEBUG::common_utils::434::root:: Executing command --> '/usr/bin/psql -h localhost -p 5432 -U engine -d engine -c select * from fn_db_get_async_tasks();' 2014-05-20 16:34:49::DEBUG::common_utils::472::root:: output = dc_id | dc_name | spm_host_id | spm_host_name | task_count -------+---------+-------------+---------------+------------ (0 rows) 2014-05-20 16:34:49::DEBUG::common_utils::473::root:: stderr = 2014-05-20 16:34:49::DEBUG::common_utils::474::root:: retcode = 0 2014-05-20 16:34:49::DEBUG::common_utils::481::root:: running sql query 'select command_type, entity_type from business_entity_snapshot;' on db server: 'localhost'. 2014-05-20 16:34:49::DEBUG::common_utils::434::root:: Executing command --> '/usr/bin/psql -h localhost -p 5432 -U engine -d engine -c select command_type, entity_type from business_entity_snapshot;' 2014-05-20 16:34:49::DEBUG::common_utils::472::root:: output = command_type | entity_type --------------+------------- (0 rows) 2014-05-20 16:34:49::DEBUG::common_utils::473::root:: stderr = 2014-05-20 16:34:49::DEBUG::common_utils::474::root:: retcode = 0 2014-05-20 16:34:49::DEBUG::common_utils::481::root:: running sql query 'copy (select vds_id, vds_name, host_name, vds_unique_id, status from vds) to stdout with csv header;' on db server: 'localhost'. 2014-05-20 16:34:49::DEBUG::common_utils::434::root:: Executing command --> '/usr/bin/psql -h localhost -p 5432 -U engine -d engine -c copy (select vds_id, vds_name, host_name, vds_unique_id, status from vds) to stdout with csv header;' 2014-05-20 16:34:49::DEBUG::common_utils::472::root:: output = vds_id,vds_name,host_name,vds_unique_id,status b108549c-1700-11e2-b936-9f5243b8ce13,node01.ukdm.gov.za,10.251.193.8,4C4C4544-0056-5910-8048-B7C04F43354A,3 322cbee8-16e6-11e2-9d38-6388c61dd004,node02.ukdm.gov.za,10.251.193.9,4C4C4544-0056-5910-8048-C4C04F43354A,3 2014-05-20 16:34:49::DEBUG::common_utils::473::root:: stderr = 2014-05-20 16:34:49::DEBUG::common_utils::474::root:: retcode = 0 2014-05-20 16:34:49::DEBUG::engine-upgrade::358::root:: DB Backup started 2014-05-20 16:34:49::DEBUG::common_utils::434::root:: Executing command --> '/usr/bin/pg_dump -C -E UTF8 --disable-dollar-quoting --disable-triggers -U engine -h localhost -p 5432 --format=p -f /var/lib/ovirt-engine/backups/ovirt-engine_db_backup_2014_05_20_16_34_21.sql engine' 2014-05-20 16:34:51::DEBUG::common_utils::472::root:: output = 2014-05-20 16:34:51::DEBUG::common_utils::473::root:: stderr = 2014-05-20 16:34:51::DEBUG::common_utils::474::root:: retcode = 0 2014-05-20 16:34:51::DEBUG::engine-upgrade::374::root:: DB Backup completed successfully 2014-05-20 16:34:51::DEBUG::common_utils::481::root:: running sql query 'ALTER DATABASE engine RENAME TO engine_2014_05_20_16_34_21' on db server: 'localhost'. 2014-05-20 16:34:51::DEBUG::common_utils::434::root:: Executing command --> '/usr/bin/psql -h localhost -p 5432 -U engine -d template1 -c ALTER DATABASE engine RENAME TO engine_2014_05_20_16_34_21' 2014-05-20 16:34:51::DEBUG::common_utils::472::root:: output = 2014-05-20 16:34:51::DEBUG::common_utils::473::root:: stderr = ERROR: must be owner of database engine 2014-05-20 16:34:51::DEBUG::common_utils::474::root:: retcode = 1 2014-05-20 16:34:51::DEBUG::common_utils::332::root:: YUM: VERB: Performing rollback 2014-05-20 16:34:51::DEBUG::common_utils::1377::root:: Locking rpms in yum-version-lock 2014-05-20 16:34:51::ERROR::engine-upgrade::1159::root:: Traceback (most recent call last): File "/usr/bin/engine-upgrade", line 1152, in <module> main(options) File "/usr/bin/engine-upgrade", line 1079, in main runFunc([[db.rename, DB_NAME_TEMP]], MSG_INFO_RENAME_DB) File "/usr/bin/engine-upgrade", line 621, in runFunc func[0](*func[1:]) File "/usr/bin/engine-upgrade", line 447, in rename utils.execRemoteSqlCommand(SERVER_ADMIN, SERVER_NAME, SERVER_PORT, basedefs.DB_TEMPLATE, query, True, MSG_ERROR_RENAME_DB) File "/usr/share/ovirt-engine/scripts/common_utils.py", line 490, in execRemoteSqlCommand return execCmd(cmdList=cmd, failOnError=failOnError, msg=errMsg, envDict=getPgPassEnv()) File "/usr/share/ovirt-engine/scripts/common_utils.py", line 477, in execCmd raise Exception(msg) Exception: Error: Database rename failed. Check that there are no active connections to the DB and try again. I'm guessing it's probably something simple, but I'm not much of a postgres user, so it's unfortunately a bit beyond me to resolve. Please could someone point me in the right direction. Thank you. Regards Neil Wilson.

2 3

1009100 likely be be fixed for 3.5.0?
by Paul Jansen 22 May '14

22 May '14

--1060583355-420566928-1400730682=:1403 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello.=0AThere are a few bugs that are related to live snapshots/storage mi= grations not working.=0Ahttps://bugzilla.redhat.com/show_bug.cgi?id=3D10091= 00 is one of them and is targeted for 3.5.0.=0AAccording to the bug there i= s some engine work still required.=0A=0AI understand that with EL6 based ho= sts live storage migration will still not work (due to a too old QEMU versi= on), but it should work with F20/21 hosts (and EL7 hosts when that comes on= line).=0AAm I correct in assuming that in a cluster with both EL6 hosts and= new hosts (described above) that ovirt will allow live storage migration o= n hosts that support it and prevent the option from appearing on hosts that= do not?=0A=0AThe possibility of getting a newer QEMU on EL6 appears to be = tied up in the Centos virt SIG and their proposed repository, which appears= to be moving quite slowly.=0A=0A=0AI'm looking forward to ovirt closing th= e gap to vmware vcenter in regard to live storage migrations.=0A --1060583355-420566928-1400730682=:1403 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <html><body><div style=3D"color:#000; background-color:#fff; font-family:He= lveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, Sans-Serif;fo= nt-size:12pt"><div style=3D"" class=3D"">Hello.</div><div style=3D"" class= =3D""><span style=3D"" class=3D"">There are a few bugs that are related to = live snapshots/storage migrations not working.</span></div><div class=3D"" = style=3D"color: rgb(0, 0, 0); font-size: 16px; font-family: HelveticaNeue,H= elvetica Neue,Helvetica,Arial,Lucida Grande,Sans-Serif; background-color: t= ransparent; font-style: normal;"><span style=3D"" class=3D"">https://bugzil= la.redhat.com/show_bug.cgi?id=3D1009100 is one of them and is targeted for = 3.5.0.</span></div><div class=3D"" style=3D"color: rgb(0, 0, 0); font-size:= 16px; font-family: HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Gra= nde,Sans-Serif; background-color: transparent; font-style: normal;">Accordi= ng to the bug there is some engine work still required.</div><div class=3D"= " style=3D"color: rgb(0, 0, 0); font-size: 16px; font-family: HelveticaNeue,Helvetica Neue,Helvetic= a,Arial,Lucida Grande,Sans-Serif; background-color: transparent; font-style= : normal;"><br></div><div class=3D"" style=3D"color: rgb(0, 0, 0); font-siz= e: 16px; font-family: HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida G= rande,Sans-Serif; background-color: transparent; font-style: normal;">I und= erstand that with EL6 based hosts live storage migration will still not wor= k (due to a too old QEMU version), but it should work with F20/21 hosts (an= d EL7 hosts when that comes online).</div><div class=3D"" style=3D"color: r= gb(0, 0, 0); font-size: 16px; font-family: HelveticaNeue,Helvetica Neue,Hel= vetica,Arial,Lucida Grande,Sans-Serif; background-color: transparent; font-= style: normal;">Am I correct in assuming that in a cluster with both EL6 ho= sts and new hosts (described above) that ovirt will allow live storage migr= ation on hosts that support it and prevent the option from appearing on hosts that do not?</div><div class=3D"" style=3D"color: rgb(0, 0, 0); font= -size: 16px; font-family: HelveticaNeue,Helvetica Neue,Helvetica,Arial,Luci= da Grande,Sans-Serif; background-color: transparent; font-style: normal;"><= br></div><div class=3D"" style=3D"color: rgb(0, 0, 0); font-size: 16px; fon= t-family: HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Grande,Sans-S= erif; background-color: transparent; font-style: normal;">The possibility o= f getting a newer QEMU on EL6 appears to be tied up in the Centos virt SIG = and their proposed repository, which appears to be moving quite slowly.<br>= </div><div class=3D"" style=3D"color: rgb(0, 0, 0); font-size: 16px; font-f= amily: HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Grande,Sans-Seri= f; background-color: transparent; font-style: normal;"><br></div><div class= =3D"" style=3D"color: rgb(0, 0, 0); font-size: 16px; font-family: Helvetica= Neue,Helvetica Neue,Helvetica,Arial,Lucida Grande,Sans-Serif; background-co= lor: transparent; font-style: normal;">I'm looking forward to ovirt closing the= gap to vmware vcenter in regard to live storage migrations.</div><div clas= s=3D"" style=3D"color: rgb(0, 0, 0); font-size: 16px; font-family: Helvetic= aNeue,Helvetica Neue,Helvetica,Arial,Lucida Grande,Sans-Serif; background-c= olor: transparent; font-style: normal;"><br><span style=3D"" class=3D""></s= pan></div></div></body></html> --1060583355-420566928-1400730682=:1403--

1 0

Re: [ovirt-users] Ovirt WebAdmin Portal
by Karli Sjöberg 22 May '14

22 May '14

--_000_5F9E965F5A80BC468BE5F40576769F0979FBE79Bexchange21_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpEZW4gMjEgbWFqIDIwMTQgMjI6MTggc2tyZXYgQ2FybG9zIENhc3RpbGxvIDxjYXJsb3MuY2Fz dGlsbG9AZ2xvYmFsci5uZXQ+Og0KPg0KPiByZWdhcmRzLA0KPg0KPiBNeSBOYW1lIGlzIENhcmxv cyBhbmQgSSdtIGEgSTpUIEFkbWluLiBJIHJlY2VudGx5IG5vdGljZWQgdGhhdCBteSBvVmlydCBX ZWIgQWRtaW4gcG9ydGFsIHNob3dzIDAlIG1lbW9yeSB1c2FnZSBmb3IgYWxsIG15IHZpcnR1YWwg bWFjaGluZXMsIGEgc2l0dWF0aW9uIHRoYXQgZG9lcyBub3Qgc2VlbSByaWdodCB0byBtZS4NCj4N Cj4gSSBoYXZlIHRyaWVkIHRvIHNlYXJjaCBmb3IgaW5mb3JtYXRpb24gYWJvdXQgd2h5IGl0IG1h eSBiZSBoYXBwZW5pbmcgdGhhdCwgYnV0IEkgaGF2ZSBub3QgZm91bmQgYW55dGhpbmcgdXNlZnVs LCBzbyBJIGdvIHRvIHRoaXMgbGlzdCBsb29raW5nIGZvciBpZGVhcz8NCg0KWW91IG5lZWQgdG8g aW5zdGFsbCB0aGUgIm92aXJ0LWd1ZXN0LWFnZW50IiBpbiBhbGwgVk0ncyBmb3IgdGhhdCB0byBz aG93LiBZb3Ugd2lsbCBhbHNvIGdldCB0aGUgVk3igJlzIElQLCBmcWRuLCBzb21lIGluc3RhbGxl ZCBwYWNrYWdlcyBhbmQgd2hv4oCZcyBjdXJyZW50bHkgbG9nZ2VkIGludG8gaXQsIGFtb25nIG90 aGVyIHRoaW5ncy4NCg0KL0sNCg0KPg0KPiBNeSBvVmlydCBFbmdpbmUgVmVyc2lvbjogMy4zLjEt Mi5lbDYsDQo+IE8uUy4gQ2VudE9TIHJlbGVhc2UgNi40IChGaW5hbCkNCj4NCj4NCj4gLS0NCj4g Q2FybG9zIEouIENhc3RpbGxvDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gSW5nZW5p ZXJvIGRlIFNvbHVjaW9uZXMgZGUgVEkNCj4gKzU4IDQyNiAyNTQyMzEzDQo+IEBEcjRnMG5LbjFn aHQNCj4NCg== --_000_5F9E965F5A80BC468BE5F40576769F0979FBE79Bexchange21_ Content-Type: text/html; charset="utf-8" Content-ID: <410BBA8BDEF0134AA1B2906E41753CA1(a)ad.slu.se> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KPHAgZGlyPSJsdHIi Pjxicj4NCkRlbiAyMSBtYWogMjAxNCAyMjoxOCBza3JldiBDYXJsb3MgQ2FzdGlsbG8gJmx0O2Nh cmxvcy5jYXN0aWxsb0BnbG9iYWxyLm5ldCZndDs6PGJyPg0KJmd0Ozxicj4NCiZndDsgcmVnYXJk cywmbmJzcDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBNeSBOYW1lIGlzIENhcmxvcyBhbmQgSSdtIGEg STpUIEFkbWluLiBJIHJlY2VudGx5IG5vdGljZWQgdGhhdCBteSBvVmlydCBXZWIgQWRtaW4gcG9y dGFsIHNob3dzIDAlIG1lbW9yeSB1c2FnZSBmb3IgYWxsIG15IHZpcnR1YWwgbWFjaGluZXMsIGEg c2l0dWF0aW9uIHRoYXQgZG9lcyBub3Qgc2VlbSByaWdodCB0byBtZS48YnI+DQomZ3Q7PGJyPg0K Jmd0OyBJIGhhdmUgdHJpZWQgdG8gc2VhcmNoIGZvciBpbmZvcm1hdGlvbiBhYm91dCB3aHkgaXQg bWF5IGJlIGhhcHBlbmluZyB0aGF0LCBidXQgSSBoYXZlIG5vdCBmb3VuZCBhbnl0aGluZyB1c2Vm dWwsIHNvIEkgZ28gdG8gdGhpcyBsaXN0IGxvb2tpbmcgZm9yIGlkZWFzPzwvcD4NCjxwIGRpcj0i bHRyIj5Zb3UgbmVlZCB0byBpbnN0YWxsIHRoZSAmcXVvdDtvdmlydC1ndWVzdC1hZ2VudCZxdW90 OyBpbiBhbGwgVk0ncyBmb3IgdGhhdCB0byBzaG93LiBZb3Ugd2lsbCBhbHNvIGdldCB0aGUgVk3i gJlzIElQLCBmcWRuLCBzb21lIGluc3RhbGxlZCBwYWNrYWdlcyBhbmQgd2hv4oCZcyBjdXJyZW50 bHkgbG9nZ2VkIGludG8gaXQsIGFtb25nIG90aGVyIHRoaW5ncy48L3A+DQo8cCBkaXI9Imx0ciI+ L0s8L3A+DQo8cCBkaXI9Imx0ciI+Jmd0Ozxicj4NCiZndDsgTXkgb1ZpcnQgRW5naW5lIFZlcnNp b246IDMuMy4xLTIuZWw2LDxicj4NCiZndDsgTy5TLiBDZW50T1MgcmVsZWFzZSA2LjQgKEZpbmFs KTxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyAtLSA8YnI+DQomZ3Q7IENhcmxvcyBKLiBD YXN0aWxsbzxicj4NCiZndDsgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCiZndDsgSW5n ZW5pZXJvIGRlIFNvbHVjaW9uZXMgZGUgVEk8YnI+DQomZ3Q7ICYjNDM7NTggNDI2IDI1NDIzMTM8 YnI+DQomZ3Q7IEBEcjRnMG5LbjFnaHQ8YnI+DQomZ3Q7PGJyPg0KPC9wPg0KPC9ib2R5Pg0KPC9o dG1sPg0K --_000_5F9E965F5A80BC468BE5F40576769F0979FBE79Bexchange21_--

2 1

Ovirt WebAdmin Portal
by Carlos Castillo 22 May '14

22 May '14

regards, My Name is Carlos and I'm a I:T Admin. I recently noticed that my oVirt Web Admin portal shows 0% memory usage for all my virtual machines, a situation that does not seem right to me. I have tried to search for information about why it may be happening that, but I have not found anything useful, so I go to this list looking for ideas? My oVirt Engine Version: 3.3.1-2.el6, O.S. CentOS release 6.4 (Final) -- Carlos J. Castillo ---------------------------------------------------------------------------------- Ingeniero de Soluciones de TI +58 426 2542313 @Dr4g0nKn1ght

2 1

Fwd: [Users] Ovirt 3.4 EqualLogic multipath Bug 953343
by Gary Lloyd 21 May '14

21 May '14

Hi I was just wondering if ISCSI Multipathing is supported yet on Direct Lun ? I have deployed 3.4.0.1 but i can only see the option for ISCSI multipathing on storage domains. We will be glad if it could be, as it saves us having to inject new code into our vdsm nodes with each new version. Thanks *Gary Lloyd* ---------------------------------- IT Services Keele University ----------------------------------- Guys, Please, pay attention that this feature currently may not work. I resolved several bugs related to this feature but some of my patches are still waiting for merge. Regards, Sergey ----- Original Message ----- > From: "Maor Lipchuk" <mlipchuk(a)redhat.com> > To: "Gary Lloyd" <g.lloyd(a)keele.ac.uk>, users(a)ovirt.org, "Sergey Gotliv" < sgotliv(a)redhat.com> > Sent: Thursday, March 27, 2014 6:50:10 PM > Subject: Re: [Users] Ovirt 3.4 EqualLogic multipath Bug 953343 > > IIRC it should also support direct luns as well. > Sergey? > > regards, > Maor > > On 03/27/2014 06:25 PM, Gary Lloyd wrote: > > Hi I have just had a look at this thanks. Whilst it seemed promising we > > are in a situation where we use Direct Lun for all our production VM's > > in order to take advantage of being able to individually replicate and > > restore vm volumes using the SAN tools. Is multipath supported for > > Direct Luns or only data domains ? > > > > Thanks > > > > /Gary Lloyd/ > > ---------------------------------- > > IT Services > > Keele University > > ----------------------------------- > > > > > > On 27 March 2014 16:02, Maor Lipchuk <mlipchuk(a)redhat.com > > <mailto:mlipchuk@redhat.com>> wrote: > > > > Hi Gary, > > > > Please take a look at > > http://www.ovirt.org/Feature/iSCSI-Multipath#User_Experience > > > > Regards, > > Maor > > > > On 03/27/2014 05:59 PM, Gary Lloyd wrote: > > > Hello > > > > > > I have just deployed Ovirt 3.4 on our test environment. Does > > anyone know > > > how the ISCSI multipath issue is resolved ? At the moment it is > > behaving > > > as before and only opening one session per lun ( we bodged vdsm > > > python > > > code in previous releases to get it to work). > > > > > > The Planning sheet shows that its fixed but I am not sure what to do > > > next: > > https://docs.google.com/spreadsheet/ccc?key=0AuAtmJW_VMCRdHJ6N1M3d1F1UTJTS1… > > > > > > > > > Thanks > > > > > > /Gary Lloyd/ > > > ---------------------------------- > > > IT Services > > > Keele University > > > ----------------------------------- > > > > > > > > > _______________________________________________ > > > Users mailing list > > > Users(a)ovirt.org <mailto:Users@ovirt.org> > > > http://lists.ovirt.org/mailman/listinfo/users > > > > > > > > > _______________________________________________ Users mailing list Users(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/users -- Martin Goldstone IT Systems Administrator - Finance & IT Keele University, Keele, Staffordshire, United Kingdom, ST5 5BG Telephone: +44 1782 734457 G+: http://google.com/+MartinGoldstoneKeele

1 0

oVirt Weekly Meeting Minutes: May 21, 2014
by Brian Proffitt 21 May '14

21 May '14

Minutes: http://ovirt.org/meetings/ovirt/2014/ovirt.2014-05-21-14.02.html Minutes (text): http://ovirt.org/meetings/ovirt/2014/ovirt.2014-05-21-14.02.txt Log: http://ovirt.org/meetings/ovirt/2014/ovirt.2014-05-21-14.02.log.html ========================= #ovirt: oVirt Weekly Sync ========================= Meeting started by bkp at 14:02:03 UTC. The full logs are available at http://ovirt.org/meetings/ovirt/2014/ovirt.2014-05-21-14.02.log.html . Meeting summary --------------- * Agenda and Roll Call (bkp, 14:02:19) * infra updates (bkp, 14:02:42) * 3.4.z updates (bkp, 14:02:42) * 3.5 planning (bkp, 14:02:42) * conferences and workshops (bkp, 14:02:42) * other topics (bkp, 14:02:42) * infra updates (bkp, 14:03:01) * infra os1 issues solved, will add new slaves in the following days (bkp, 14:06:28) * 3.4.z updates (bkp, 14:08:05) * 3.4.z updates 3.4.2: RC scheduled for 2014-05-27 (bkp, 14:11:53) * 3.4.z updates SvenKieske sent a list of proposed blockers to be reviewed: http://lists.ovirt.org/pipermail/users/2014-May/024518.html (bkp, 14:11:53) * 3.4.z updates Bug 1037663 status: ovirt-log-collector: conflicts with file from package sos >= 3.0, sbonazzo working with sos maintainer for coordinating oVirt 3.4.2 release. Not a blocker. (bkp, 14:11:53) * 3.4.z updates Discussion is ongoing on mailing list for other bugs (bkp, 14:11:54) * 3.5 planning (bkp, 14:12:20) * 3.5 planning UX Phase one of patternfly is in, and the sorting infra (bkp, 14:14:53) * 3.5 planning UX Issues fixed as they are reported. (bkp, 14:14:53) * 3.5 planning SLA All planned 3.5 features will be ready on time, fingers crossed :) (bkp, 14:18:22) * 3.5 planning SLA NUMA feature: APIs (GUI and RESTful) still missing. (bkp, 14:18:22) * 3.5 planning SLA optaplanner: in advanced development state. (bkp, 14:18:22) * 3.5 planning SLA Limits (blkio and cpu, incluiding disk and cpu profile, including refactoring current network qos and vnic profile to suit new sla/profiles infra): we are working on them nowadays (no real issues there) (bkp, 14:18:22) * 3.5 planning SLA Scheduling RESTful API: developed now - patch this evening (bkp, 14:18:22) * LINK: http://www.ovirt.org/Features/Self_Hosted_Engine_iSCSI_Support all patches have been pushed and under review (sbonazzo, 14:20:07) * LINK: http://www.ovirt.org/Features/oVirt_Windows_Guest_Tools (sbonazzo, 14:20:55) * 3.5 planning integration ovirt 3.5.0 alpha released yesterday (bkp, 14:22:47) * 3.5 planning integration ovirt live iso uploaded this afternoon (bkp, 14:22:47) * 3.5 planning integration ovirt node iso will follow (bkp, 14:22:47) * 3.5 planning integration 3.5.0 Second Alpha scheduled for May 30 for Feature Freeze (bkp, 14:22:47) * 3.5 planning integration http://www.ovirt.org/Features/Self_Hosted_Engine_iSCSI_Support all patches have been pushed and under review (bkp, 14:22:47) * 3.5 planning integration There's an issue on additional host setup, but should be fixed easily. Patch pushed an under review. (bkp, 14:22:49) * 3.5 planning integration F20 support started for ovirt-engine, hopefully ready for alpha 2 (bkp, 14:22:52) * 3.5 planning virt Unfinished features are closer to completition... but nothing got in yet. (bkp, 14:29:06) * 3.5 planning virt Last week spent fixing major bugs. (bkp, 14:29:06) * 3.5 planning Gluster Volume capacity - vdsm dependency on libgfapi-python needs to be added (bkp, 14:34:31) * 3.5 planning Gluster Volume profile - review comments on patches incorporated and submitted, need final review and approval (bkp, 14:34:31) * 3.5 planning Gluster REST API in progress (bkp, 14:34:31) * 3.5 planning node All features are in progress. (bkp, 14:37:59) * 3.5 planning node Two features up for review (generic registration and hosted engine plugin) (bkp, 14:37:59) * 3.5 planning node Appliances can also be built, now all needs to be reviewed and tested. (bkp, 14:37:59) * 3.5 planning node ETA for a node with the bits in place by early next week. (bkp, 14:37:59) * 3.5 planning network All Neutron appliance oVirt code is merged. Feature now depends on some OpenStack repository processes that are async with oVirt releases. oVirt side completed. (bkp, 14:42:17) * 3.5 planning network The two MAC pool features are in a tough review, so they're in danger even for the new deadline of end of May. (bkp, 14:42:17) * 3.5 planning network Progress with the RHEL bug on which bridge_opts depends upon is unknown. danken adds that it is not a blocker for 3.5 (bkp, 14:42:17) * 3.5 planning network [UPDATE] Progress with the RHEL bug on which bridge_opts depends upon done (with an asterisk). (bkp, 14:43:34) * 3.5 planning storage Store OVF on any domains - merged (bkp, 14:49:12) * 3.5 planning storage Disk alias recycling in web-admin portal - merged (bkp, 14:49:13) * 3.5 planning storage [RFE] Snapshot overview in webadmin portal - merged (bkp, 14:49:13) * 3.5 planning storage import existing data domain - phase one was revised yesterday, should be reviewed today and tommorow, and hopefully be merged by end of week (bkp, 14:49:13) * 3.5 planning storage Sanlock fencing seems this will slip 3.5.0 after (infra required a late redesign) (bkp, 14:49:13) * 3.5 planning storage live merge (delete snapshot) - in progress. Three patches upstream (engine side), one is going to be merged soon (today hopefully), the other two under review. (bkp, 14:49:14) * 3.5 infra Working hard on 3.5 features, and hope everything will make it on time. (bkp, 14:49:53) * 3.5 infra The current status is in the planning wiki. (bkp, 14:49:53) * 3.5 infra If infra-related questions pop up then just email them, and ovedo will answer them this evening/tomorrow. (bkp, 14:49:53) * conferences and workshops (bkp, 14:50:22) * Conferences OpenStack Israel is still on for June 2. (bkp, 14:51:50) * Conferences FrOSCON CfP closes May 23 (bkp, 14:51:50) * Conferences OSCON Open Cloud Day CfP closes May 27 (bkp, 14:51:50) * ACTION: More conference participation is needed for 2014. See bkp for help planning/submitting presentations. (bkp, 14:51:50) * other topics (bkp, 14:53:04) Meeting ended at 14:56:14 UTC. Action Items ------------ * More conference participation is needed for 2014. See bkp for help planning/submitting presentations. Action Items, by person ----------------------- * bkp * More conference participation is needed for 2014. See bkp for help planning/submitting presentations. People Present (lines said) --------------------------- * bkp (115) * sbonazzo (32) * lvernia (14) * gchaplik (12) * nsoffer (11) * fabiand (9) * mskrivanek (8) * danken (5) * awels (4) * dcaro (3) * sahina (3) * ovirtbot (3) * jb_badpenny (1) * SvenKieske (1) * fsimonce (1) * mburns (1) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot -- Brian Proffitt oVirt Community Manager Project Atomic Community Lead Open Source and Standards, Red Hat - http://community.redhat.com Phone: +1 574 383 9BKP IRC: bkp @ OFTC

1 0

sanlock + gluster recovery -- RFE
by Ted Miller 21 May '14

21 May '14

--------------050904040002030300050808 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Itamar, I am addressing this to you because one of your assignments seems to be to coordinate other oVirt contributors when dealing with issues that are raised on the ovirt-users email list. As you are aware, there is an ongoing split-brain problem with running sanlock on replicated gluster storage. Personally, I believe that this is the 5th time that I have been bitten by this sanlock+gluster problem. I believe that the following are true (if not, my entire request is probably off base). * ovirt uses sanlock in such a way that when the sanlock storage is on a replicated gluster file system, very small storage disruptions can result in a gluster split-brain on the sanlock space o gluster is aware of the problem, and is working on a different way of replicating data, which will reduce these problems. * most (maybe all) of the sanlock locks have a short duration, measured in seconds * there are only a couple of things that a user can safely do from the command line when a file is in split-brain o delete the file o rename (mv) the file * x _How did I get into this mess?_ had 3 hosts running ovirt 3.3 each hosted VMs gluster replica 3 storage engine was external to cluster upgraded 3 hosts from ovirt 3.3 to 3.4 hosted-engine deploy used new gluster volume (accessed via nfs) for storage storage was accessed using localhost:engVM1 link (localhost was probably a poor choice) created new engine on VM (did not transfer any data from old engine) added 3 hosts to new engine via web-gui ran above setup for 3 days shut entire system down before I left on vacation (holiday) came back from vacation powered on hosts found that iptables did not have rules for gluster access (a continuing problem if host installation is allowed to set up firewall) added rules for gluster glusterfs now up and running added storage manually tried "hosted-engine --vm-start" vm did not start logs show sanlock errors "gluster volume heal engVM1full: "gluster volume heal engVM1 info split-brain" showed 6 files in split-brain all 5 prefixed by /rhev/data-center/mnt/localhost\:_engVM1 UUID/dom_md/ids UUID/images/UUID/UUID (VM hard disk) UUID/images/UUID/UUID.lease UUID/ha_agent/hosted-engine.lockspace UUID/ha_agent/hosted-engine.metadata I copied each of the above files off of each of the three bricks to a safe place (15 files copied) I renamed the 5 files on /rhev/.... I copied the 5 files from one of the bricks to /rhev/ files can now be read OK (e.g. cat ids) sanlock.log shows error sets like these: 2014-05-20 03:23:39-0400 36199 [2843]: s3358 lockspace 5ebb3b40-a394-405b-bbac-4c0e21ccd659:1:/rhev/data-center/mnt/localhost:_engVM1/5ebb3b40-a394-405b-bbac-4c0e21ccd659/dom_md/ids:0 2014-05-20 03:23:39-0400 36199 [18873]: open error -5 /rhev/data-center/mnt/localhost:_engVM1/5ebb3b40-a394-405b-bbac-4c0e21ccd659/dom_md/ids 2014-05-20 03:23:39-0400 36199 [18873]: s3358 open_disk /rhev/data-center/mnt/localhost:_engVM1/5ebb3b40-a394-405b-bbac-4c0e21ccd659/dom_md/ids error -5 2014-05-20 03:23:40-0400 36200 [2843]: s3358 add_lockspace fail result -19 I am now stuck What I would like to see in ovirt to help me (and others like me). Alternates listed in order from most desirable (automatic) to least desirable (set of commands to type, with lots of variables to figure out). 1. automagic recovery * When a host is not able to access sanlock, it writes a small "problem" text file into the shared storage o the host-ID as part of the name (so only one host ever accesses that file) o a status number for the error causing problems o time stamp o time stamp when last sanlock lease will expire o if sanlock is able to access the file, the "problem" file is deleted * when time passes for its last sanlock lease to be expired, highest number host does a survey o did all other hosts create "problem" files? o do all "problem" files show same (or compatible) error codes related to file access problems? o are all hosts communicating by network? o if yes to all above * delete all sanlock storage space * initialize sanlock from scratch * restart whatever may have given up because of sanlock * restart VM if necessary 2. recovery subcommand * add "hosted-engine --lock-initialize" command that would delete sanlock, start over from scratch 3. script * publish a script (in ovirt packages or available on web) which, when run, does all (or most) of the recovery process needed. 4. commands * publish on the web a "recipe" for dealing with files that commonly go split-brain o ids o *.lease o *.lockspace Any chance of any help on any of the above levels? Ted Miller Elkhart, IN, USA --------------050904040002030300050808 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit <html> <head> <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"> </head> <body text="#000000" bgcolor="#FFFFFF"> Itamar, I am addressing this to you because one of your assignments seems to be to coordinate other oVirt contributors when dealing with issues that are raised on the ovirt-users email list.<br> <br> As you are aware, there is an ongoing split-brain problem with running sanlock on replicated gluster storage.  Personally, I believe that this is the 5th time that I have been bitten by this sanlock+gluster problem.<br> <br> I believe that the following are true (if not, my entire request is probably off base).<br> <ul> <li>ovirt uses sanlock in such a way that when the sanlock storage is on a replicated gluster file system, very small storage disruptions can result in a gluster split-brain on the sanlock space</li> <ul> <li>gluster is aware of the problem, and is working on a different way of replicating data, which will reduce these problems.</li> </ul> <li>most (maybe all) of the sanlock locks have a short duration, measured in seconds</li> <li>there are only a couple of things that a user can safely do from the command line when a file is in split-brain</li> <ul> <li>delete the file</li> <li>rename (mv) the file<br> </li> </ul> <li>x</li> </ul> <u>How did I get into this mess?</u><br> <br> had 3 hosts running ovirt 3.3<br>     each hosted VMs<br>     gluster replica 3 storage<br>     engine was external to cluster<br> upgraded 3 hosts from ovirt 3.3 to 3.4<br> hosted-engine deploy<br>     used new gluster volume (accessed via nfs) for storage<br>         storage was accessed using localhost:engVM1 link (localhost was probably a poor choice)<br>     created new engine on VM (did not transfer any data from old engine)<br> added 3 hosts to new engine via web-gui<br> ran above setup for 3 days<br> shut entire system down before I left on vacation (holiday)<br> came back from vacation<br> powered on hosts<br> found that iptables did not have rules for gluster access<br>     (a continuing problem if host installation is allowed to set up firewall)<br> added rules for gluster<br> glusterfs now up and running<br> added storage manually<br> tried "hosted-engine --vm-start"<br> vm did not start<br> logs show sanlock errors<br> "gluster volume heal engVM1full:<br> "gluster volume heal engVM1 info split-brain" showed 6 files in split-brain<br>         all 5 prefixed by /rhev/data-center/mnt/localhost\:_engVM1<br>     UUID/dom_md/ids<br>     UUID/images/UUID/UUID (VM hard disk)<br>     UUID/images/UUID/UUID.lease<br>     UUID/ha_agent/hosted-engine.lockspace<br>     UUID/ha_agent/hosted-engine.metadata<br> I copied each of the above files off of each of the three bricks to a safe place (15 files copied)<br> I renamed the 5 files on /rhev/....<br> I copied the 5 files from one of the bricks to /rhev/<br>     files can now be read OK (e.g. cat ids)<br> sanlock.log shows error sets like these:<br> <pre>2014-05-20 03:23:39-0400 36199 [2843]: s3358 lockspace 5ebb3b40-a394-405b-bbac-4c0e21ccd659:1:/rhev/data-center/mnt/localhost:_engVM1/5ebb3b40-a394-405b-bbac-4c0e21ccd659/dom_md/ids:0 2014-05-20 03:23:39-0400 36199 [18873]: open error -5 /rhev/data-center/mnt/localhost:_engVM1/5ebb3b40-a394-405b-bbac-4c0e21ccd659/dom_md/ids 2014-05-20 03:23:39-0400 36199 [18873]: s3358 open_disk /rhev/data-center/mnt/localhost:_engVM1/5ebb3b40-a394-405b-bbac-4c0e21ccd659/dom_md/ids error -5 2014-05-20 03:23:40-0400 36200 [2843]: s3358 add_lockspace fail result -19</pre> I am now stuck<br> <br> What I would like to see in ovirt to help me (and others like me).  Alternates listed in order from most desirable (automatic) to least desirable (set of commands to type, with lots of variables to figure out).<br> <br> 1. automagic recovery<br> <ul> <li> When a host is not able to access sanlock, it writes a small "problem" text file into the shared storage</li> <ul> <li>the host-ID as part of the name (so only one host ever accesses that file)</li> <li>a status number for the error causing problems</li> <li>time stamp</li> <li>time stamp when last sanlock lease will expire</li> <li>if sanlock is able to access the file, the "problem" file is deleted</li> </ul> <li>when time passes for its last sanlock lease to be expired, highest number host does a survey</li> <ul> <li>did all other hosts create "problem" files?</li> <li>do all "problem" files show same (or compatible) error codes related to file access problems?</li> <li>are all hosts communicating by network?</li> <li>if yes to all above</li> </ul> <li>delete all sanlock storage space<br> </li> <li>initialize sanlock from scratch</li> <li>restart whatever may have given up because of sanlock</li> <li>restart VM if necessary</li> </ul> <p>2. recovery subcommand<br> </p> <ul> <li>add "hosted-engine --lock-initialize" command that would delete sanlock, start over from scratch</li> </ul> <p>3. script<br> </p> <ul> <li>publish a script (in ovirt packages or available on web) which, when run, does all (or most) of the recovery process needed.</li> </ul> <p>4. commands<br> </p> <ul> <li>publish on the web a "recipe" for dealing with files that commonly go split-brain</li> <ul> <li>ids</li> <li>*.lease</li> <li>*.lockspace</li> </ul> </ul> <p>Any chance of any help on any of the above levels?<br> </p> <p>Ted Miller<br> Elkhart, IN, USA<br> <br> </p> </body> </html> --------------050904040002030300050808--

3 2

[QE][ACTION NEEDED] oVirt 3.4.2 RC status
by Sandro Bonazzola 21 May '14

21 May '14

Hi, We're going to start composing oVirt 3.4.2 RC on *2014-05-27 08:00 UTC* from 3.4 branches. The bug tracker [1] shows no blocking bugs for the release There are still 71 bugs [2] targeted to 3.4.2. Excluding node and documentation bugs we still have 39 bugs [3] targeted to 3.4.2. Maintainers / Assignee: - Please add the bugs to the tracker if you think that 3.4.2 should not be released without them fixed. - Please update the target to any next release for bugs that won't be in 3.4.2: it will ease gathering the blocking bugs for next releases. - Please fill release notes, the page has been created here [4] - If you need to rebuild packages, please build them before *2014-05-26 15:00 UTC*. Otherwise we'll take last 3.4 snapshot available. Community: - If you're going to test this release, please add yourself to the test page [5] [1] http://bugzilla.redhat.com/1095370 [2] http://red.ht/1oqLLlr [3] http://red.ht/1nIAZXO [4] http://www.ovirt.org/OVirt_3.4.2_Release_Notes [5] http://www.ovirt.org/Testing/oVirt_3.4.2_Testing Thanks, -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

3 3

[QE][ACTION NEEDED] oVirt 3.5.0 Alpha status
by Sandro Bonazzola 21 May '14

21 May '14

Hi, We released oVirt 3.5.0 Alpha on *2014-05-20* and we're now preparing for feature freeze scheduled for 2014-05-30. We're going to compose a second Alpha on Firday *2014-05-30 08:00 UTC*. Maintainers: - Please be sure that master snapshot allow to create VMs before *2014-05-29 15:00 UTC* The bug tracker [1] shows the following proposed blockers to be reviewed: Bug ID Whiteboard Status Summary 1001100 integration NEW Add log gathering for a new ovirt module (External scheduler) 1073944 integration ASSIGNED Add log gathering for a new ovirt module (External scheduler) 1060198 integration NEW [RFE] add support for Fedora 20 1099432 virt NEW noVNC client doesn't work: Server disconnected (code: 1006) Feature freeze has been postponed to 2014-05-30 and the following features should be testable in 3.5.0 Alpha according to Features Status Table [2] Group oVirt BZ Title gluster 1096713 Monitoring (UI plugin) Dashboard (Integrated with Nagios monitoring) infra 1090530 [RFE] Please add host count and guest count columns to "Clusters" tab in webadmin infra 1054778 [RFE] Allow to perform fence operations from a host in another DC infra 1090803 [RFE] Change the "Slot" field to "Service Profile" when cisco_ucs is selected as the fencing type infra 1090511 [RFE] Improve fencing robustness by retrying failed attempts infra 1090794 [RFE] Search VMs based on MAC address from web-admin portal infra 1090793 consider the event type while printing events to engine.log infra 1090796 [RFE] Re-work engine ovirt-node host-deploy sequence infra 1090798 [RFE] Admin GUI - Add host uptime information to the "General" tab infra 1090808 [RFE] Ability to dismiss alerts and events from web-admin portal infra-api 1090797 [RFE] RESTAPI: Add /tags sub-collection for Template resource infra-dwh 1091686 prevent OutOfMemoryError after starting the dwh service. network 1078836 Add a warning when adding display network network 1079719 Display of NIC Slave/Bond fault on Event Log network 1080987 Support ethtool_opts functionality within oVirt storage 1054241 Store OVF on any domains storage 1083312 Disk alias recycling in web-admin portal ux 1064543 oVirt new look and feel [PatternFly adoption] - phase #1 virt 1058832 Allow to clone a (down) VM without snapshot/template virt 1031040 can't set different keymap for vnc via runonce option virt 1043471 oVirt guest agent for SLES virt 1083049 add progress bar for vm migration virt 1083065 EL 7 guest compatibility virt 1083059 "Instance types (new template handling) - adding flavours" virt Allow guest serial number to be configurable virt 1047624 [RFE] support BIOS boot device menu virt 1083129 allows setting netbios name, locale, language and keyboard settings for windows vm's virt 1038632 spice-html5 button to show debug console/output window virt 1080002 [RFE] Enable user defined Windows Sysprep file done Some more features may be included since they were near to be completed on last sync meeting. The table will be updated on next sync meeting scheduled for 2014-05-21. There are still 382 bugs [3] targeted to 3.5.0. Excluding node and documentation bugs we still have 319 bugs [4] targeted to 3.5.0. Maintainers / Assignee: - Please remember to rebuild your packages before *2014-05-29 15:00 UTC* if needed, otherwise nightly snapshot will be taken. - Please be sure that master snapshot allow to create VMs before *2014-05-29 15:00 UTC* - If you find a blocker bug please remember to add it to the tracker [1] - Please start filling release notes, the page has been created here [5] Community: - You're welcome to join us testing this alpha release and getting involved in oVirt Quality Assurance[6]! [1] http://bugzilla.redhat.com/1073943 [2] http://bit.ly/17qBn6F [3] http://red.ht/1pVEk7H [4] http://red.ht/1rLCJwF [5] http://www.ovirt.org/OVirt_3.5_Release_Notes [6] http://www.ovirt.org/OVirt_Quality_Assurance Thanks, -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

1 0

Jpackage down
by Neil 21 May '14

21 May '14

Hi guys, I'm doing an urgent ovirt upgrade from 3.2(dreyou) to 3.4 (official) but I see that www.jpackage.org is down. I've managed to install jboss-as-7.1.1-11.el6.x86_64 from another location, however I'm not sure if this will be compatible with 3.4, as per the instructions from "http://wiki.dreyou.org/dokuwiki/doku.php?id=ovirt_rpm_start33" I've tested browsing to the site on two different internet links, as well as from the remote server but I'm just getting... RepoError: Cannot retrieve repository metadata (repomd.xml) for repository: ovirt-jpackage-6.0-generic. Please verify its path and try again Can I go ahead and attempt the upgrade using 7.1.1-11? Thanks! Regards. Neil Wilson.

4 6