Re: [Users] Deep Dive Into Host Power Management - Slides Recording link
Dne 30.7.2013 00:19, Eli Mesika napsal(a): Hi Attached please find the presentation slides This session was recorded. To view the recording, please click the link below: https://sas.elluminate.com/p.jnlp?psid=2013-07-29.0638.M.0095240B0C736D2B11BF860A1F0376.vcrsid=819 ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users Thank you for sharing. :-) ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] invalid vgs
Hi Eduardo, Can u please also add the engine log and the full VDSM log (if you have other hosts then please add their vdsm.log as well) Thanks. Maor On 07/29/2013 11:10 PM, Eduardo Ramos wrote: Hi all! My SPM has logging such a strange message on vdsm.log. I tries to get information from a VG that doesn't exist. In fact, I don't know where it got the id 0226b818-59a6-41bc-8590-91f520aa7859. The log of vdsm can be read here: http://pastebin.com/mZcSLzxi Could anybody help me? Thanks. ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] oVirt 3.2 - Migration failed due to error: migrateerr
On 07/29/2013 06:06 PM, Nicholas Kesick wrote: Date: Mon, 29 Jul 2013 09:56:30 +0200 From: mklet...@redhat.com To: dan...@redhat.com CC: cybertimber2...@hotmail.com; users@ovirt.org Subject: Re: [Users] oVirt 3.2 - Migration failed due to error: migrateerr On 07/27/2013 09:50 PM, Dan Kenigsberg wrote: On Fri, Jul 26, 2013 at 02:03:28PM -0400, Nicholas Kesick wrote: Date: Fri, 26 Jul 2013 05:52:44 +0300 From: ih...@redhat.com To: cybertimber2...@hotmail.com CC: dan...@redhat.com; users@ovirt.org Subject: Re: [Users] oVirt 3.2 - Migration failed due to error: migrateerr On 07/26/2013 05:40 AM, Nicholas Kesick wrote: Replies inline. Date: Thu, 25 Jul 2013 22:27:17 +0300 From: dan...@redhat.com To: cybertimber2...@hotmail.com CC: users@ovirt.org Subject: Re: [Users] oVirt 3.2 - Migration failed due to error: migrateerr On Thu, Jul 25, 2013 at 11:54:40AM -0400, Nicholas Kesick wrote: When I try to migrate a VM, any VM, between my two hosts, I receive an error that says Migration failed due to error: migrateerr. Looking in the log I don't see any thing that jumps out other than the final message VDSGenericException: VDSErrorException: Failed to MigrateStatusVDS, error = Fatal error during migration Ovirt-engine is version 3.2.2-1.1.fc18.noarch, firewalld is disabled, and selinux is permissive. Please do not say this in public, you're hurting Dan Walsh's feelings ;-) I recall seeing his blog posts, and I agree. Not sure when I set it to permissive... maybe to get the 3.2 install w/ Firewalld setup to complete? I remember that was fixed in 3.2.1. I'll set it back to enforcing. ovirt-node version is 2.6.1 on both hosts. Any suggestions would be welcome! I'd love to see /etc/vdsm/vdsm.log from source and destination. The intersting parts start with vmMigrate at the source and with vmMigrationCreate at the destination. Hmm, I probably should have pulled that sooner. So, I cleared the active VDSM (while nothing was running) and libvirtd.log, booted one vm, and tried to migrate it. Attached are the logs. It looks like it boils down to (from the source): Traceback (most recent call last): File /usr/share/vdsm/vm.py, line 271, in run File /usr/share/vdsm/libvirtvm.py, line 505, in _startUnderlyingMigration File /usr/share/vdsm/libvirtvm.py, line 541, in f File /usr/lib64/python2.7/site-packages/vdsm/libvirtconnection.py, line 111, in wrapper File /usr/lib64/python2.7/site-packages/libvirt.py, line 1178, in migrateToURI2 libvirtError: internal error Attempt to migrate guest to the same host localhost Does this mean my UUIDs are the same? http://vaunaspada.babel.it/blog/?p=613 As far as the destination, I'm really not understanding what's going on on the destination between Destination VM creation succeeded and :destroy Called that would lead to it failing, except for what's after the traceback: Traceback (most recent call last): File /usr/share/vdsm/vm.py, line 696, in _startUnderlyingVm File /usr/share/vdsm/libvirtvm.py, line 1907, in _waitForIncomingMigrationFinish File /usr/lib64/python2.7/site-packages/vdsm/libvirtconnection.py, line 111, in wrapper File /usr/lib64/python2.7/site-packages/libvirt.py, line 2822, in lookupByUUIDString libvirtError: Domain not found: no domain with matching uuid '50171e1b-cf21-41d8-80f3-88ab1b980091' But that is the ID of the VM by the looks of it. Sorry Itamar, nothing was written to libvirtd.log after I cleared it. It could be that libvirtd is still writing to the files that you removed from the filesystem. To make sure libvirtd writes to your new file, restart the service. There may be clues there on why libvirt thinks that the source and destination are one and the same. When clearing the logs, it should be enough to do ' /path/to/libvirtd.log' (in bash). Just checked and it seems some things were logged in there during my testing on Friday. I'll attach those. Thread-800::ERROR::2013-07-26 01:57:16,198::vm::198::vm.Vm::(_recover) vmId=`50171e1b-cf21-41d8-80f3-88ab1b980091`::internal error Attempt to migrate guest to the same host localhost Thread-800::ERROR::2013-07-26 01:57:16,377::vm::286::vm.Vm::(run) vmId=`50171e1b-cf21-41d8-80f3-88ab1b980091`::Failed to migrate Traceback (most recent call last): File /usr/share/vdsm/vm.py, line 271, in run File /usr/share/vdsm/libvirtvm.py, line 505, in _startUnderlyingMigration File /usr/share/vdsm/libvirtvm.py, line 541, in f File /usr/lib64/python2.7/site-packages/vdsm/libvirtconnection.py, line 111, in wrapper File /usr/lib64/python2.7/site-packages/libvirt.py, line 1178, in migrateToURI2 libvirtError: internal error Attempt to migrate guest to the same host localhost what are your hostnames? host001 on 192.168.0.103 and host002 on 192.168.0.104 Even tried changing it, no luck. Are they resolving properly on
Re: [Users] upgrade to latest master not working
Thanks. So this leads me further to the upgrade procedure which may have fail, thus not completing the DB upgrade. Can you please check the upgrade logs to see if something matches this flow? - Original Message - | From: Dead Horse deadhorseconsult...@gmail.com | To: Doron Fediuck dfedi...@redhat.com | Cc: Alon Bar-Lev alo...@redhat.com, users users@ovirt.org, Dave Chen wei.d.c...@intel.com, Eli Mesika | emes...@redhat.com | Sent: Tuesday, July 30, 2013 6:37:55 AM | Subject: Re: [Users] upgrade to latest master not working | | The engine version I am attempting to upgrade from was built from: | --- | commit: dbc3d31110ce372a1fa7e06f64c4a5c64544c679 | tree: ee9ee41c3e855c26f491c77fda9622c05af3fc54 | parent: 82644cae97f3c546ee631ae79c925c91e7bed836 | | userportal,webadmin: Change remove message | Change-Id: Ia934e33d1a975e0235e1a1ffae0c8a4a7af66f10 | Signed-off-by: Alexander Wels aw...@redhat.com | --- | Thus it is version 3.3 and not 3.2. The upgrade (built from this master | this AM) was attempted ovirt a fresh install of the packages built from the | above commit. I also confirmed the install was fully functional. | | - DHC | | | | On Mon, Jul 29, 2013 at 4:08 PM, Doron Fediuck dfedi...@redhat.com wrote: | | | | - Original Message - | | From: Alon Bar-Lev alo...@redhat.com | | To: Doron Fediuck dfedi...@redhat.com | | Cc: Dead Horse deadhorseconsult...@gmail.com, users | users@ovirt.org, Dave Chen wei.d.c...@intel.com, Eli | | Mesika emes...@redhat.com | | Sent: Monday, July 29, 2013 11:51:35 PM | | Subject: Re: [Users] upgrade to latest master not working | | | | | | | | - Original Message - | | From: Doron Fediuck dfedi...@redhat.com | | To: Alon Bar-Lev alo...@redhat.com | | Cc: Dead Horse deadhorseconsult...@gmail.com, users | | users@ovirt.org, Dave Chen wei.d.c...@intel.com, Eli | | Mesika emes...@redhat.com | | Sent: Monday, July 29, 2013 11:43:46 PM | | Subject: Re: [Users] upgrade to latest master not working | | | | | | | | - Original Message - | | | From: Alon Bar-Lev alo...@redhat.com | | | To: Doron Fediuck dfedi...@redhat.com | | | Cc: Dead Horse deadhorseconsult...@gmail.com, users | | | users@ovirt.org, Dave Chen wei.d.c...@intel.com, Eli | | | Mesika emes...@redhat.com | | | Sent: Monday, July 29, 2013 11:31:42 PM | | | Subject: Re: [Users] upgrade to latest master not working | | | | | | | | | | | | - Original Message - | | | From: Doron Fediuck dfedi...@redhat.com | | | To: Alon Bar-Lev alo...@redhat.com | | | Cc: Dead Horse deadhorseconsult...@gmail.com, users | | | users@ovirt.org, Dave Chen wei.d.c...@intel.com, Eli | | | Mesika emes...@redhat.com | | | Sent: Monday, July 29, 2013 11:27:41 PM | | | Subject: Re: [Users] upgrade to latest master not working | | | | | | | | | | | | - Original Message - | | | | From: Alon Bar-Lev alo...@redhat.com | | | | To: Dead Horse deadhorseconsult...@gmail.com | | | | Cc: users users@ovirt.org, Doron Fediuck | dfedi...@redhat.com, | | | | Dave | | | | Chen wei.d.c...@intel.com, Eli | | | | Mesika emes...@redhat.com | | | | Sent: Monday, July 29, 2013 10:47:01 PM | | | | Subject: Re: [Users] upgrade to latest master not working | | | | | | | | | | | | | | | | - Original Message - | | | | From: Dead Horse deadhorseconsult...@gmail.com | | | | To: Alon Bar-Lev alo...@redhat.com | | | | Cc: users users@ovirt.org | | | | Sent: Monday, July 29, 2013 10:41:34 PM | | | | Subject: Re: [Users] upgrade to latest master not working | | | | | | | | server.log attached | | | | | | | | Thanks! | | | | | | | | My guess is that I8ce3448a[1] broke master. | | | | | | | | [1] http://gerrit.ovirt.org/#/c/14605/ | | | | | | | | | | Works perfectly on my Gentoo with master. | | | | | | | | | I doubt you are upgrading from 3.2 :) | | | | | | | Just did: | | | | $ git checkout origin/engine_3.2 | | $ cd backend/manager/dbscripts/ | | $ ./create_db.sh -d upgrade32-test -u engine | | ~/dev/ovirt/ovirt-engine/backend/manager/dbscripts | | ~/dev/ovirt/ovirt-engine/backend/manager/dbscripts | | Creating the database: upgrade32-test | | dropdb: database removal failed: ERROR: database upgrade32-test | does not | | exist | | user name is: engine | | Creating tables... | | Creating functions... | | Creating common functions... | | Inserting data ... | | Inserting pre-defined roles ... | | Running upgrade scripts... | | upgrade script detected a change in Config, View or Stored Procedure... | | Running upgrade sql script upgrade/pre_upgrade/_config.sql ... | | | | ... | | | | Creating stored procedures from vm_templates_sp.sql ... | | Running upgrade sql script | | upgrade/post_upgrade/0010_add_object_column_white_list_table.sql ... | |
[Users] local repo for Fedora 18 based nodes
Hi, we currently run F18 based nodes as oVirt 3.2.1 HVs. For installation it was necessary to have internet access for the nodes during the triggered setup from engine server. Which repo does the engine/HV need to make an offline installation possible: http://resources.ovirt.org/releases/stable/rpm/Fedora/18/ ? I wanted to setup a small repo server for the HVs on the engine itself (although need this for OSMA), do I need any custom configuration on the engine server therefore or is it sufficient to populate the repo file on the HVs? Thanks in advance! Best, Sven. Sven Knohsalla | System Administration Office +49 631 68036 433 | Fax +49 631 68036 111 |E-Mail s.knohsa...@netbiscuits.com | Skype: netbiscuits.admin Netbiscuits GmbH | Europaallee 10 | 67657 | GERMANY [https://my.netbiscuits.com/image/image_gallery?uuid=3a1a9d19-c305-4032-8cef-00b03c3d4c79groupId=10211t=1361534926402]http://www.netbiscuits.com/ [https://my.netbiscuits.com/image/image_gallery?uuid=9e553e7b-3e7d-4784-b274-15aa1dfb48e2groupId=10211t=1361533377340] https://www.netbiscuits.com/news [https://my.netbiscuits.com/image/image_gallery?uuid=1d1a5e29-ceda-4ab1-9353-67a1e838364dgroupId=10211t=1347281040591] https://twitter.com/netbiscuits [https://my.netbiscuits.com/image/image_gallery?uuid=c99bf866-be25-4236-a0ee-dca68ec828a5groupId=10211t=1347280983848] http://www.linkedin.com/company/netbiscuits [https://my.netbiscuits.com/image/image_gallery?uuid=d62ba951-14dc-450d-b5f1-be33884225e3groupId=10211t=1347280983872] http://www.xing.com/companies/netbiscuitsgmbh [https://my.netbiscuits.com/image/image_gallery?uuid=7b28f500-f415-40bb-851f-0cd55beeaf45groupId=10211t=1347280983791] https://www.facebook.com/Netbiscuits [https://my.netbiscuits.com/image/image_gallery?uuid=cc8764d0-a5ac-4623-bb63-da3ca7c97f94groupId=10211t=1347280983836] https://plus.google.com/u/0/112410769451962733032 [https://my.netbiscuits.com/image/image_gallery?uuid=a15e871c-a11b-419c-acca-da5a0ebd5856groupId=10211t=1347281040599] http://www.youtube.com/user/netbiscuits Register Court: Local Court Kaiserslautern | Commercial Register ID: HR B 3604 Management Board: Guido Moggert, Michael Neidhöfer, Christian Reitz, Martin Süß This message and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. It may also be privileged or otherwise protected by work product immunity or other legal rules. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. Warning: Although Netbiscuits has taken reasonable precautions to ensure no viruses are present in this email, the company cannot accept responsibility for any loss or damage arising from the use of this email or attachments. [http://www.netbiscuits.com/image/image_gallery?uuid=0ba7711a-a277-4ea0-acb0-17fe13c3089dgroupId=10211t=1348560850164]Please consider the environment before printing ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
[Users] RFE: sorting and searching in Disks/Direct LUN
Hi All, Because of discussion on IRC I'll make a RFE for the following: When you have lots (25) ISCSI LUN's where your ovirt hosts have access to then the selection window gets really messy because there is no apparent sorting on LUN ids or a searching possibility on part of the id. Scanning by eye of such a list is getting very boring and error prone. Talking about this part of the webui: Add Virtual Disk/External (Direct LUN), would be nice if the column Target Name would be sortable Joop ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
[Users] Nic names : always start by eth0
Hello, I have an ovirt cluster which runs CentOS VM. I have a template to create VM. On this template, there are two interfaces, eth0 and eth1. When I create a VM using this template, the new interfaces are named eth2 and eth3. It can be pretty annoying and I would like to know if it would be possible to always start by eth0 ? If I remember the discussion on IRC, it would be necessary to clean old udev rules (in centos it seems to be /etc/udev/rules.d/70-persistent-net.rules) Thanks, Regards, Grégoire ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] Nic names : always start by eth0
Hi You have toremove HWADDR value from theifcfg-ethX and rules string from /etc/udev/rules.d/70-persistent-net.rules files. It'll work fine if you have only one NIC per machine. -- Best regards, Pavel Zhukov Software Maintenance Engineer RHCE, RHCVA Tel: +420.532294671 mailto:pzhu...@redhat.com On Tue, 30 Jul 2013, gregoire.le...@retenodus.net wrote: | Hello, | | I have an ovirt cluster which runs CentOS VM. I have a template to | create VM. On this template, there are two interfaces, eth0 and | eth1. | When I create a VM using this template, the new interfaces are named | eth2 and eth3. It can be pretty annoying and I would like to know if | it would be possible to always start by eth0 ? | | If I remember the discussion on IRC, it would be necessary to clean | old udev rules (in centos it seems to be | /etc/udev/rules.d/70-persistent-net.rules) | | Thanks, | Regards, | Grégoire | ___ | Users mailing list | Users@ovirt.org | http://lists.ovirt.org/mailman/listinfo/users ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] [Feedback required][host-deploy] Fedora-19 misses tar at minimal setup
Hello All, Starting the discussion again... I would like to receive feedback regarding how we should cope with a state presented to use by Fedora. Fedora-19 minimal setup does not install tar utility which is required to deploy files during the host-deploy process (Hosts-Add Host). I guess because of 2.8M in size (including translations) -- a standard commonly used utility was removed. There are three alternatives : 1. Instruct users who are using minimal installations to manually install tar utility just like they configure repository, dns, etc.. Benefit: simplicity. Benefit: use standard tools. Benefit: lower payload to transmit. Drawback: require tar at destination machine. 2. Do not use tar but self extracting python script, a patch is ready[1]. Benefit: ability to deploy environment in which tar is missing. Drawback: non standard tool at destination machine. Drawback: complexity within our code. 3. Do not use tar but cpio, a patch is ready[2]. Benefit: simplicity. Benefit: use standard tools. Benefit: lower payload to transmit. Benefit: ability to use Fedora-19 minimal. Drawback: cpio is even less common than tar, even if it exists in Fedora-19 it can be removed without anyone notice. Drawback: most other distributions will not have cpio in their minimal installation. [[[ There was 4rd alternative, using python tar module to deploy tar. However, there is a bug in that module when processing last block if empty. This is edge condition but happened to at least one of the users and I could reproduce it. ]]] What option do you prefer? Regards, Alon Bar-Lev [1] http://gerrit.ovirt.org/#/c/17295/ [2] http://gerrit.ovirt.org/#/c/17396/ ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] Nic names : always start by eth0
Hi, The easiest way is to remove 70-persistent-net.rules in your master-vm, remove HWADDR-strings from ifcfg-eth* friles, shut it down and create the template. Btw, also remove your ssh-keys in your template to create unique ones for each vm... Regards, René On Tue, 2013-07-30 at 14:59 +0200, gregoire.le...@retenodus.net wrote: Hello, I have an ovirt cluster which runs CentOS VM. I have a template to create VM. On this template, there are two interfaces, eth0 and eth1. When I create a VM using this template, the new interfaces are named eth2 and eth3. It can be pretty annoying and I would like to know if it would be possible to always start by eth0 ? If I remember the discussion on IRC, it would be necessary to clean old udev rules (in centos it seems to be /etc/udev/rules.d/70-persistent-net.rules) Thanks, Regards, Grégoire ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] local repo for Fedora 18 based nodes
On Tue, 2013-07-30 at 08:01 -0400, Sven Knohsalla wrote: Hi, we currently run F18 based nodes as oVirt 3.2.1 HVs. For installation it was necessary to have internet access for the nodes during the triggered setup from engine server. Which repo does the engine/HV need to make an offline installation possible: http://resources.ovirt.org/releases/stable/rpm/Fedora/18/ ? Hi Sven, yes, that's the right one... I wanted to setup a small repo server for the HVs on the engine itself (although need this for OSMA), do I need any custom configuration on the engine server therefore or is it sufficient to populate the repo file on the HVs? All you have to do is to change the URL of ovirt.repo to point to your repo-server... Btw, you can also have a look at Spacewalk, but if you only want a repo-server it may be an overkill: https://fedorahosted.org/spacewalk/ Regards, René Thanks in advance! Best, Sven. Sven Knohsalla | System Administration Office +49 631 68036 433 | Fax +49 631 68036 111 |E-Mail s.knohsa...@netbiscuits.com | Skype: netbiscuits.admin Netbiscuits GmbH | Europaallee 10 | 67657 | GERMANY https://my.netbiscuits.com/image/image_gallery?uuid=3a1a9d19-c305-4032-8cef-00b03c3d4c79groupId=10211t=1361534926402 https://my.netbiscuits.com/image/image_gallery?uuid=3031deca-7e56-4417-9822-3d6d72f71ef0groupId=10211t=1347280983812 https://my.netbiscuits.com/image/image_gallery?uuid=1d1a5e29-ceda-4ab1-9353-67a1e838364dgroupId=10211t=1347281040591 https://my.netbiscuits.com/image/image_gallery?uuid=c99bf866-be25-4236-a0ee-dca68ec828a5groupId=10211t=1347280983848 https://my.netbiscuits.com/image/image_gallery?uuid=d62ba951-14dc-450d-b5f1-be33884225e3groupId=10211t=1347280983872 https://my.netbiscuits.com/image/image_gallery?uuid=7b28f500-f415-40bb-851f-0cd55beeaf45groupId=10211t=1347280983791 https://my.netbiscuits.com/image/image_gallery?uuid=cc8764d0-a5ac-4623-bb63-da3ca7c97f94groupId=10211t=1347280983836 https://my.netbiscuits.com/image/image_gallery?uuid=a15e871c-a11b-419c-acca-da5a0ebd5856groupId=10211t=1347281040599 Register Court: Local Court Kaiserslautern | Commercial Register ID: HR B 3604 Management Board: Guido Moggert, Michael Neidhöfer, Christian Reitz, Martin Süß This message and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. It may also be privileged or otherwise protected by work product immunity or other legal rules. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. Warning: Although Netbiscuits has taken reasonable precautions to ensure no viruses are present in this email, the company cannot accept responsibility for any loss or damage arising from the use of this email or attachments. Beschreibung: Beschreibung: http://www.netbiscuits.com/image/image_gallery?uuid=0ba7711a-a277-4ea0-acb0-17fe13c3089dgroupId=10211t=1348560850164Please consider the environment before printing ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] RFE: sorting and searching in Disks/Direct LUN
Hi Joop, sounds great. Can u please just send an update of the BZ number which was opened,just to have it scrubbed more quickly. Thanks, Maor On 07/30/2013 03:00 PM, noc wrote: Hi All, Because of discussion on IRC I'll make a RFE for the following: When you have lots (25) ISCSI LUN's where your ovirt hosts have access to then the selection window gets really messy because there is no apparent sorting on LUN ids or a searching possibility on part of the id. Scanning by eye of such a list is getting very boring and error prone. Talking about this part of the webui: Add Virtual Disk/External (Direct LUN), would be nice if the column Target Name would be sortable Joop ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] RFE: sorting and searching in Disks/Direct LUN
Hi, there's already an RFE for supporting column sorting in main/sub tab grids: https://bugzilla.redhat.com/893999 The above mentioned RFE could be generalized to support all grids, including the ones found in dialogs, such as Add Virtual Disk dialog. However, we need to distinguish between two different kinds of grids: ones that display page-able data (such as main/tab grids) and ones that display non-page-able data (such as grids in dialogs). For the latter, we could simply implement client-side sorting. Quick alternative (workaround) is to add some sort LUNs by ID checkbox in the dialog, what do you think guys? Vojtech - Original Message - From: noc n...@nieuwland.nl To: users users@ovirt.org Sent: Tuesday, July 30, 2013 2:00:22 PM Subject: [Users] RFE: sorting and searching in Disks/Direct LUN Hi All, Because of discussion on IRC I'll make a RFE for the following: When you have lots (25) ISCSI LUN's where your ovirt hosts have access to then the selection window gets really messy because there is no apparent sorting on LUN ids or a searching possibility on part of the id. Scanning by eye of such a list is getting very boring and error prone. Talking about this part of the webui: Add Virtual Disk/External (Direct LUN), would be nice if the column Target Name would be sortable Joop ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] Nic names : always start by eth0
Hi AFAIK This is more a CentOS- than an oVirt-issue. CentOS behaves identically on vSphere. If I remember correctly, this is due to the fact that the MAC-address of the virtual NIC has to change, when you create a VM from a template. CentOS however keeps the MAC address of the template and just adds the new MAC, which then of course becomes eth1. --SMG - Original Message - From: gregoire leroy gregoire.le...@retenodus.net To: users@ovirt.org Sent: Tuesday, July 30, 2013 7:59:35 AM Subject: [Users] Nic names : always start by eth0 Hello, I have an ovirt cluster which runs CentOS VM. I have a template to create VM. On this template, there are two interfaces, eth0 and eth1. When I create a VM using this template, the new interfaces are named eth2 and eth3. It can be pretty annoying and I would like to know if it would be possible to always start by eth0 ? If I remember the discussion on IRC, it would be necessary to clean old udev rules (in centos it seems to be /etc/udev/rules.d/70-persistent-net.rules) Thanks, Regards, Grégoire ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] Bonding - VMs Network performance problem
Good afternoon,
In attachment the result of vdsClient -s 0 getVdsCaps during problem and
after problem resolved.
Best regards,
Ricardo Esteves.
-Original Message-
From: Mike Kolesnik mkole...@redhat.com
To: Ricardo Esteves maverick...@gmail.com
Cc: Users@ovirt.org, Itamar Heim ih...@redhat.com
Subject: Re: [Users] Bonding - VMs Network performance problem
Date: Tue, 16 Jul 2013 10:01:31 -0400 (EDT)
- Original Message -
On 07/16/2013 04:09 PM, Ricardo Esteves wrote:
Hi,
Not really.
I can resolve temporally, unconfiguring the bond and then configure it
again.
But when i reboot the server the problem comes back.
can you compare the network configuration before and after you change it
the setup network?
Perhaps you can send pastebin of a 'vdsClient 0 getVdsCaps' (or 'vdsClient -s 0
getVdsCaps' if the first doesn't work)
from the host when the bond is slow, and one after you break and create it
again?
if you don't have vdsClient command you can 'yum install vdsm-cli' and it
should be available.
-Original Message-
*From*: Itamar Heim ih...@redhat.com
mailto:itamar%20heim%20%3cih...@redhat.com%3e
*To*: Ricardo Esteves maverick...@gmail.com
mailto:ricardo%20esteves%20%3cmaverick...@gmail.com%3e
*Subject*: Re: [Users] Bonding - VMs Network performance problem
*Date*: Tue, 16 Jul 2013 15:38:10 +0300
On 07/01/2013 03:12 PM, Ricardo Esteves wrote:
Hi,
Yes, i'm still experiencing this problem, in fact just happened a few
minutes ago. :)
All MTUs are 1500.
was this resolved?
-Original Message-
*From*: Livnat Peer lp...@redhat.com mailto:lp...@redhat.com
mailto:livnat%20peer%20%3clp...@redhat.com%3e
*To*: Ricardo Esteves maverick...@gmail.com
mailto:maverick...@gmail.com
mailto:ricardo%20esteves%20%3cmaverick...@gmail.com%3e
*Subject*: Re: [Users] Bonding - VMs Network performance problem
*Date*: Sun, 23 Jun 2013 11:33:58 +0300
Hi Ricardo,
Are you still experiencing the problem described below?
Are you configuring MTU (to something other than default or 1500) for
one of the networks on the bond?
Thanks, Livnat
On 06/18/2013 05:36 PM, Ricardo Esteves wrote:
Good afternoon,
Yes, the Save network configuration is checked, configurations are
persistent across boots.
The problem is not the persistence of the configurations, the problem is
that after a reboot the network performance on the VMs is very bad, and
to fix it i need to remove the bonding and add it again.
In attachment, the screenshots of my network configuration.
Best regards,
Ricardo Esteves.
-Original Message-
*From*: Mike Kolesnik mkole...@redhat.com mailto:mkole...@redhat.com
mailto:mkole...@redhat.com
mailto:mike%20kolesnik%20%3cmkole...@redhat.com%3e
*To*: Ricardo Esteves maverick...@gmail.com
mailto:maverick...@gmail.com mailto:maverick...@gmail.com
mailto:ricardo%20esteves%20%3cmaverick...@gmail.com%3e
*Cc*:Users@ovirt.org mailto:Users@ovirt.org mailto:Users@ovirt.org
mailto:Users@ovirt.org
*Subject*: Re: [Users] Bonding - VMs Network performance problem
*Date*: Sun, 26 May 2013 04:57:43 -0400 (EDT)
Hi,
I've got ovirt installed on 2 HP BL460c G6 blades, and my VMs have
very poor network performance (around 7,01K/s).
On the servers itselfs there is no problem, i can download a file
with wget at around 99 M/s.
Then i go to ovirt network configuration remove the bonding and then
make the bonding again and the problem gets fixed (i have to do this
everytime i reboot my blades).
Have you tried to check the Save network configuration check box, or
clicking the button from the host's NICs sub-tab?
This should persist the configuration that you set on the host across
reboots..
SERVER' s Software:
CentOS 6.4 (64 bits) - 2.6.32-358.6.2.el6.x86_64
Ovirt EL6 official rpms.
Anyone experienced this kind of problems?
Best regards,
Ricardo Esteves.
___
Users mailing list
Users@ovirt.org mailto:Users@ovirt.org mailto:Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
___
Users mailing list
Users@ovirt.org mailto:Users@ovirt.org mailto:Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
___
Users mailing list
Users@ovirt.org mailto:Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
HBAInventory = {'iSCSI': [{'InitiatorName':
'iqn.1994-05.com.redhat:blade5.vi.pt'}], 'FC': []}
ISCSIInitiatorName =
Re: [Users] [Engine-devel] [Feedback required][host-deploy] Fedora-19 misses tar at minimal setup
I would advocate for option 2. - Original Message - From: Michal Skrivanek michal.skriva...@redhat.com To: Alon Bar-Lev alo...@redhat.com Cc: Juan Hernandez jhern...@redhat.com, engine-devel engine-de...@ovirt.org, arch a...@ovirt.org, users users@ovirt.org Sent: Tuesday, July 30, 2013 3:25:24 PM Subject: Re: [Engine-devel] [Users] [Feedback required][host-deploy] Fedora-19misses tar at minimal setup On Jul 30, 2013, at 15:12 , Alon Bar-Lev alo...@redhat.com wrote: Hello All, Starting the discussion again... I would like to receive feedback regarding how we should cope with a state presented to use by Fedora. Fedora-19 minimal setup does not install tar utility which is required to deploy files during the host-deploy process (Hosts-Add Host). I guess because of 2.8M in size (including translations) -- a standard commonly used utility was removed. How about filing bug on that? This is such a basic utility I can't imagine anyone removing it. There are three alternatives : 1. Instruct users who are using minimal installations to manually install tar utility just like they configure repository, dns, etc.. Benefit: simplicity. Benefit: use standard tools. Benefit: lower payload to transmit. Drawback: require tar at destination machine. 2. Do not use tar but self extracting python script, a patch is ready[1]. Benefit: ability to deploy environment in which tar is missing. Drawback: non standard tool at destination machine. Drawback: complexity within our code. 3. Do not use tar but cpio, a patch is ready[2]. Benefit: simplicity. Benefit: use standard tools. Benefit: lower payload to transmit. Benefit: ability to use Fedora-19 minimal. Drawback: cpio is even less common than tar, even if it exists in Fedora-19 it can be removed without anyone notice. Drawback: most other distributions will not have cpio in their minimal installation. [[[ There was 4rd alternative, using python tar module to deploy tar. However, there is a bug in that module when processing last block if empty. This is edge condition but happened to at least one of the users and I could reproduce it. ]]] What option do you prefer? Regards, Alon Bar-Lev [1] http://gerrit.ovirt.org/#/c/17295/ [2] http://gerrit.ovirt.org/#/c/17396/ ___ Engine-devel mailing list engine-de...@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Arch mailing list a...@ovirt.org http://lists.ovirt.org/mailman/listinfo/arch ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] local repo for Fedora 18 based nodes
Hi René, thanks for the information and the URL! Will have a look at this :) Cheers, Sven. Sven Knohsalla | System Administration | Netbiscuits Office +49 631 68036 433 | Fax +49 631 68036 111 |E-Mail s.knohsa...@netbiscuits.com | Skype: netbiscuits.admin Netbiscuits GmbH | Europaallee 10 | 67657 | GERMANY -Ursprüngliche Nachricht- Von: René Koch (ovido) [mailto:r.k...@ovido.at] Gesendet: Dienstag, 30. Juli 2013 15:20 An: Sven Knohsalla Cc: users@ovirt.org Betreff: Re: [Users] local repo for Fedora 18 based nodes On Tue, 2013-07-30 at 08:01 -0400, Sven Knohsalla wrote: Hi, we currently run F18 based nodes as oVirt 3.2.1 HVs. For installation it was necessary to have internet access for the nodes during the triggered setup from engine server. Which repo does the engine/HV need to make an offline installation possible: http://resources.ovirt.org/releases/stable/rpm/Fedora/18/ ? Hi Sven, yes, that's the right one... I wanted to setup a small repo server for the HVs on the engine itself (although need this for OSMA), do I need any custom configuration on the engine server therefore or is it sufficient to populate the repo file on the HVs? All you have to do is to change the URL of ovirt.repo to point to your repo-server... Btw, you can also have a look at Spacewalk, but if you only want a repo-server it may be an overkill: https://fedorahosted.org/spacewalk/ Regards, René Thanks in advance! Best, Sven. Sven Knohsalla | System Administration Office +49 631 68036 433 | Fax +49 631 68036 111 |E-Mail s.knohsa...@netbiscuits.com | Skype: netbiscuits.admin Netbiscuits GmbH | Europaallee 10 | 67657 | GERMANY https://my.netbiscuits.com/image/image_gallery?uuid=3a1a9d19-c305-4032 -8cef-00b03c3d4c79groupId=10211t=1361534926402 https://my.netbiscuits.com/image/image_gallery?uuid=3031deca-7e56-4417 -9822-3d6d72f71ef0groupId=10211t=1347280983812 https://my.netbiscuits.com/image/image_gallery?uuid=1d1a5e29-ceda-4ab1 -9353-67a1e838364dgroupId=10211t=1347281040591 https://my.netbiscuits.com/image/image_gallery?uuid=c99bf866-be25-4236 -a0ee-dca68ec828a5groupId=10211t=1347280983848 https://my.netbiscuits.com/image/image_gallery?uuid=d62ba951-14dc-450d -b5f1-be33884225e3groupId=10211t=1347280983872 https://my.netbiscuits.com/image/image_gallery?uuid=7b28f500-f415-40bb -851f-0cd55beeaf45groupId=10211t=1347280983791 https://my.netbiscuits.com/image/image_gallery?uuid=cc8764d0-a5ac-4623 -bb63-da3ca7c97f94groupId=10211t=1347280983836 https://my.netbiscuits.com/image/image_gallery?uuid=a15e871c-a11b-419c -acca-da5a0ebd5856groupId=10211t=1347281040599 Register Court: Local Court Kaiserslautern | Commercial Register ID: HR B 3604 Management Board: Guido Moggert, Michael Neidhöfer, Christian Reitz, Martin Süß This message and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. It may also be privileged or otherwise protected by work product immunity or other legal rules. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. Warning: Although Netbiscuits has taken reasonable precautions to ensure no viruses are present in this email, the company cannot accept responsibility for any loss or damage arising from the use of this email or attachments. Beschreibung: Beschreibung: http://www.netbiscuits.com/image/image_gallery?uuid=0ba7711a-a277-4ea0 -acb0-17fe13c3089dgroupId=10211t=1348560850164Please consider the environment before printing ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] Nic names : always start by eth0
You need to delete the udev created files under /etc/udev.d I believe persistent-net-70-* or something (can't check). And then create your template Vincent Connected by Motorola Sven M. Geschke ov...@nebulaone.com wrote: Hi AFAIK This is more a CentOS- than an oVirt-issue. CentOS behaves identically on vSphere. If I remember correctly, this is due to the fact that the MAC-address of the virtual NIC has to change, when you create a VM from a template. CentOS however keeps the MAC address of the template and just adds the new MAC, which then of course becomes eth1. --SMG - Original Message - From: gregoire leroy gregoire.le...@retenodus.net To: users@ovirt.org Sent: Tuesday, July 30, 2013 7:59:35 AM Subject: [Users] Nic names : always start by eth0 Hello, I have an ovirt cluster which runs CentOS VM. I have a template to create VM. On this template, there are two interfaces, eth0 and eth1. When I create a VM using this template, the new interfaces are named eth2 and eth3. It can be pretty annoying and I would like to know if it would be possible to always start by eth0 ? If I remember the discussion on IRC, it would be necessary to clean old udev rules (in centos it seems to be /etc/udev/rules.d/70-persistent-net.rules) Thanks, Regards, Grégoire ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] [Engine-devel] [Feedback required][host-deploy] Fedora-19 misses tar at minimal setup
Il 30/07/2013 15:12, Alon Bar-Lev ha scritto: Hello All, Starting the discussion again... I would like to receive feedback regarding how we should cope with a state presented to use by Fedora. Fedora-19 minimal setup does not install tar utility which is required to deploy files during the host-deploy process (Hosts-Add Host). I guess because of 2.8M in size (including translations) -- a standard commonly used utility was removed. There are three alternatives : 1. Instruct users who are using minimal installations to manually install tar utility just like they configure repository, dns, etc.. Benefit: simplicity. Benefit: use standard tools. Benefit: lower payload to transmit. Drawback: require tar at destination machine. 2. Do not use tar but self extracting python script, a patch is ready[1]. Benefit: ability to deploy environment in which tar is missing. Drawback: non standard tool at destination machine. Drawback: complexity within our code. 3. Do not use tar but cpio, a patch is ready[2]. Benefit: simplicity. Benefit: use standard tools. Benefit: lower payload to transmit. Benefit: ability to use Fedora-19 minimal. Drawback: cpio is even less common than tar, even if it exists in Fedora-19 it can be removed without anyone notice. Drawback: most other distributions will not have cpio in their minimal installation. [[[ There was 4rd alternative, using python tar module to deploy tar. However, there is a bug in that module when processing last block if empty. This is edge condition but happened to at least one of the users and I could reproduce it. ]]] What option do you prefer? Well, honestly, the solution I like more than the others is having the python tar bug fixed and be free to use the python tar lib. I would like to exclude cpio: it's on rpm based distro but not commonly available on others. I would like to exclude the RTFM solution, having it working out of the box. So my second choice is using a self extracting script. If you think pyar is a non standard tool, do you have considered the use of shar? Or do you think it's also a non standard tool? Regards, Alon Bar-Lev [1] http://gerrit.ovirt.org/#/c/17295/ [2] http://gerrit.ovirt.org/#/c/17396/ ___ Engine-devel mailing list engine-de...@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] upgrade to latest master not working
- Original Message - | From: Dead Horse deadhorseconsult...@gmail.com | To: Doron Fediuck dfedi...@redhat.com | Cc: Alon Bar-Lev alo...@redhat.com, users users@ovirt.org, Dave Chen wei.d.c...@intel.com, Eli Mesika | emes...@redhat.com | Sent: Tuesday, July 30, 2013 6:55:18 PM | Subject: Re: [Users] upgrade to latest master not working | | The only error I can find in the upgrade log is: | 2013-07-29 14:06:28 DEBUG otopi.plugins.otopi.packagers.yumpackager | yumpackager.verbose:84 Yum Done: ovirt-engine.noarch 0:3.3.0-20.fc18 - u | 2013-07-29 14:06:28 INFO otopi.plugins.otopi.packagers.yumpackager | yumpackager.info:88 Yum update: 10/18: ovirt-engine | 2013-07-29 14:06:35 DEBUG otopi.plugins.otopi.packagers.yumpackager | yumpackager.verbose:84 Yum Done: ovirt-engine.noarch 0:3.3.0-20.fc18 - u | 2013-07-29 14:06:35 DEBUG otopi.plugins.otopi.packagers.yumpackager | yumpackager.verbose:84 Yum Done: ovirt-engine-3.3.0-20.fc18.noarch | 2013-07-29 14:06:37 INFO otopi.plugins.otopi.packagers.yumpackager | yumpackager.info:88 Yum update: 11/18: ovirt-engine-dbscripts | 2013-07-29 14:06:38 DEBUG otopi.plugins.otopi.packagers.yumpackager | yumpackager.verbose:84 Yum Done: ovirt-engine-dbscripts-3.3.0-20.fc18.noarch | 2013-07-29 14:06:38 DEBUG otopi.plugins.otopi.packagers.yumpackager | yumpackager.verbose:84 Yum Done: ovirt-engine-backend | Traceback (most recent call last): | File /usr/lib/python2.7/site-packages/yum/rpmtrans.py, line 464, in | callback | self._unInstStop( bytes, total, h ) | File /usr/lib/python2.7/site-packages/yum/rpmtrans.py, line 564, in | _unInstStop | self.total_actions) | File /usr/lib/python2.7/site-packages/otopi/miniyum.py, line 204, in | event | package=package.name, | AttributeError: 'str' object has no attribute 'name' | FATAL ERROR: python callback bound method RPMTransaction.callback of | yum.rpmtrans.RPMTransaction instance at 0x4587560 failed, aborting! | | To test the database upgrade I will revert to a previous snapshot of the | debug VM, capture the dbase from the previous engine version, re-run | upgrade, dump the upgraded database, restore the previous, and then test a | manual run of the database upgrade script. | | Does this sound prudent? | - DHC | Yes. Although lots of work, it may show if there's a DB upgrade bug we missed, or indeed the general upgrade procedure has / had an issue. | | On Tue, Jul 30, 2013 at 5:54 AM, Doron Fediuck dfedi...@redhat.com wrote: | | Thanks. | So this leads me further to the upgrade procedure | which may have fail, thus not completing the DB upgrade. | Can you please check the upgrade logs to see if something | matches this flow? | | - Original Message - | | From: Dead Horse deadhorseconsult...@gmail.com | | To: Doron Fediuck dfedi...@redhat.com | | Cc: Alon Bar-Lev alo...@redhat.com, users users@ovirt.org, | Dave Chen wei.d.c...@intel.com, Eli Mesika | | emes...@redhat.com | | Sent: Tuesday, July 30, 2013 6:37:55 AM | | Subject: Re: [Users] upgrade to latest master not working | | | | The engine version I am attempting to upgrade from was built from: | | --- | | commit: dbc3d31110ce372a1fa7e06f64c4a5c64544c679 | | tree: ee9ee41c3e855c26f491c77fda9622c05af3fc54 | | parent: 82644cae97f3c546ee631ae79c925c91e7bed836 | | | | userportal,webadmin: Change remove message | | Change-Id: Ia934e33d1a975e0235e1a1ffae0c8a4a7af66f10 | | Signed-off-by: Alexander Wels aw...@redhat.com | | --- | | Thus it is version 3.3 and not 3.2. The upgrade (built from this master | | this AM) was attempted ovirt a fresh install of the packages built from | the | | above commit. I also confirmed the install was fully functional. | | | | - DHC | | | | | | | | On Mon, Jul 29, 2013 at 4:08 PM, Doron Fediuck dfedi...@redhat.com | wrote: | | | | | | | | - Original Message - | | | From: Alon Bar-Lev alo...@redhat.com | | | To: Doron Fediuck dfedi...@redhat.com | | | Cc: Dead Horse deadhorseconsult...@gmail.com, users | | users@ovirt.org, Dave Chen wei.d.c...@intel.com, Eli | | | Mesika emes...@redhat.com | | | Sent: Monday, July 29, 2013 11:51:35 PM | | | Subject: Re: [Users] upgrade to latest master not working | | | | | | | | | | | | - Original Message - | | | From: Doron Fediuck dfedi...@redhat.com | | | To: Alon Bar-Lev alo...@redhat.com | | | Cc: Dead Horse deadhorseconsult...@gmail.com, users | | | users@ovirt.org, Dave Chen wei.d.c...@intel.com, Eli | | | Mesika emes...@redhat.com | | | Sent: Monday, July 29, 2013 11:43:46 PM | | | Subject: Re: [Users] upgrade to latest master not working | | | | | | | | | | | | - Original Message - | | | | From: Alon Bar-Lev alo...@redhat.com | | | | To: Doron Fediuck dfedi...@redhat.com | | | | Cc: Dead Horse deadhorseconsult...@gmail.com, users | | | | users@ovirt.org, Dave Chen wei.d.c...@intel.com, Eli | | | | Mesika
Re: [Users] Fibre channel - LVM problems
Hi Ayal,
On Mon, 2013-07-29 at 10:13 -0400, Ayal Baron wrote:
I have found a similar issue here:
https://www.redhat.com/archives/lvm-devel/2011-February/msg00127.html
After discussing this with Peter Rajnoha, it looks like the specific issue in
the above thread has been resolved and your issue is probably a reincarnation
of the problem. Can you manually run the pvchange with - to get more
info?
Thanks.
I'm attaching logs from manual executions of both pvcreate and pvchange.
Regards,
Lukasz
#libdm-config.c:863 Setting activation/monitoring to 1
#lvmcmdline.c:1091 Processing: pvchange --config ' devices { preferred_names = [^/dev/mapper/] ignore_suspended_devices=1 write_cache_state=0 disable_after_error_count=3 filter = [ a%3600a0b800074a36e06e951f14e7d%, r%.*% ] } global { locking_type=1 prioritise_write_locks=1 wait_for_locks=1 } backup { retain_min = 50 retain_days = 0 } ' --metadataignore n /dev/mapper/3600a0b800074a36e06e951f14e7d -
#lvmcmdline.c:1094 O_DIRECT will be used
#libdm-config.c:799 Setting global/locking_type to 1
#libdm-config.c:799 Setting global/wait_for_locks to 1
#locking/locking.c:242 File-based locking selected.
#libdm-config.c:768 Setting global/locking_dir to /run/lock/lvm
#libdm-config.c:863 Setting global/prioritise_write_locks to 1
#libdm-common.c:872 Preparing SELinux context for /run/lock/lvm to system_u:object_r:lvm_lock_t:s0.
#libdm-common.c:875 Resetting SELinux context to default value.
#pvchange.c:209 Using physical volume(s) on command line
#device/dev-cache.c:332 /dev/mapper/3600a0b800074a36e06e951f14e7d: Added to device cache
#ioctl/libdm-iface.c:1724 dm version OF [16384] (*1)
#ioctl/libdm-iface.c:1724 dm status (253:2) OF [16384] (*1)
#device/dev-io.c:524 Opened /dev/mapper/3600a0b800074a36e06e951f14e7d RO O_DIRECT
#device/dev-io.c:271 /dev/mapper/3600a0b800074a36e06e951f14e7d: size is 209715200 sectors
#device/dev-io.c:577 Closed /dev/mapper/3600a0b800074a36e06e951f14e7d
#device/dev-io.c:271 /dev/mapper/3600a0b800074a36e06e951f14e7d: size is 209715200 sectors
#device/dev-io.c:524 Opened /dev/mapper/3600a0b800074a36e06e951f14e7d RO O_DIRECT
#device/dev-io.c:137 /dev/mapper/3600a0b800074a36e06e951f14e7d: block size is 4096 bytes
#device/dev-io.c:577 Closed /dev/mapper/3600a0b800074a36e06e951f14e7d
#filters/filter-composite.c:31 Using /dev/mapper/3600a0b800074a36e06e951f14e7d
#device/dev-io.c:524 Opened /dev/mapper/3600a0b800074a36e06e951f14e7d RO O_DIRECT
#device/dev-io.c:137 /dev/mapper/3600a0b800074a36e06e951f14e7d: block size is 4096 bytes
#label/label.c:156 /dev/mapper/3600a0b800074a36e06e951f14e7d: lvm2 label detected at sector 1
#cache/lvmcache.c:1336 lvmcache: /dev/mapper/3600a0b800074a36e06e951f14e7d: now in VG #orphans_lvm2 (#orphans_lvm2) with 0 mdas
#metadata/metadata.c:4468 Setting ignored flag for mda /dev/mapper/3600a0b800074a36e06e951f14e7d at offset 4096.
#format_text/text_label.c:299 Ignoring mda on device /dev/mapper/3600a0b800074a36e06e951f14e7d at offset 4096
#metadata/metadata.c:4468 Setting ignored flag for mda /dev/mapper/3600a0b800074a36e06e951f14e7d at offset 107239964672.
#format_text/text_label.c:299 Ignoring mda on device /dev/mapper/3600a0b800074a36e06e951f14e7d at offset 107239964672
#device/dev-io.c:577 Closed /dev/mapper/3600a0b800074a36e06e951f14e7d
#libdm-config.c:768 Setting response to OK
#libdm-config.c:768 Setting response to OK
#libdm-config.c:768 Setting id to wiCjbg-mYay-0NQf-r4qu-xK1Y-Lc8K-KxhmIc
#libdm-config.c:768 Setting format to lvm2
#libdm-config.c:799 Setting device to 64770
#libdm-config.c:799 Setting dev_size to 107374182400
#libdm-config.c:799 Setting label_sector to 1
#ioctl/libdm-iface.c:1724 dm status (253:2) OF [16384] (*1)
#device/dev-io.c:524 Opened /dev/mapper/3600a0b800074a36e06e951f14e7d RO O_DIRECT
#device/dev-io.c:271 /dev/mapper/3600a0b800074a36e06e951f14e7d: size is 209715200 sectors
#device/dev-io.c:577 Closed /dev/mapper/3600a0b800074a36e06e951f14e7d
#device/dev-io.c:271 /dev/mapper/3600a0b800074a36e06e951f14e7d: size is 209715200 sectors
#device/dev-io.c:524 Opened /dev/mapper/3600a0b800074a36e06e951f14e7d RO O_DIRECT
#device/dev-io.c:137 /dev/mapper/3600a0b800074a36e06e951f14e7d: block size is 4096 bytes
#device/dev-io.c:577 Closed /dev/mapper/3600a0b800074a36e06e951f14e7d
#filters/filter-composite.c:31 Using /dev/mapper/3600a0b800074a36e06e951f14e7d
#libdm-config.c:799 Setting size to 135262208
#libdm-config.c:799 Setting start to 4096
#libdm-config.c:799 Setting ignore to 1
Re: [Users] Bonding - VMs Network performance problem
Hi Ricardo, Thanks a lot for the extra and very relevant info. Could you please create a bug in bugzilla so we can better track it? Best, Toni - Original Message - From: Ricardo Esteves gmail.com To: Users@ovirt.org Sent: Tuesday, July 30, 2013 5:58:44 PM Subject: Re: [Users] Bonding - VMs Network performance problem Hi, I also noticed this on /var/log/messages while the problem was happening (i was downloading a file in the VM from the web): Jul 30 16:55:55 blade5 kernel: bond0.1: received packets cannot be forwarded while LRO is enabled Jul 30 16:55:56 blade5 kernel: bond0.1: received packets cannot be forwarded while LRO is enabled Jul 30 16:55:56 blade5 kernel: bond0.1: received packets cannot be forwarded while LRO is enabled Jul 30 16:55:56 blade5 kernel: bond0.1: received packets cannot be forwarded while LRO is enabled Jul 30 16:55:56 blade5 kernel: bond0.1: received packets cannot be forwarded while LRO is enabled Jul 30 16:55:56 blade5 kernel: bond0.1: received packets cannot be forwarded while LRO is enabled Jul 30 16:55:57 blade5 kernel: bond0.1: received packets cannot be forwarded while LRO is enabled Jul 30 16:55:57 blade5 kernel: bond0.1: received packets cannot be forwarded while LRO is enabled Jul 30 16:55:57 blade5 kernel: bond0.1: received packets cannot be forwarded while LRO is enabled Jul 30 16:55:57 blade5 kernel: bond0.1: received packets cannot be forwarded while LRO is enabled Best regards, Ricardo Esteves. -Original Message- From : Ricardo Esteves maverick...@gmail.com To : Users@ovirt.org Cc : Itamar Heim ih...@redhat.com , Mike Kolesnik mkole...@redhat.com Subject : Re: [Users] Bonding - VMs Network performance problem Date : Tue, 30 Jul 2013 15:10:24 +0100 Good afternoon, In attachment the result of vdsClient -s 0 getVdsCaps during problem and after problem resolved. Best regards, Ricardo Esteves. -Original Message- From : Mike Kolesnik mkole...@redhat.com To : Ricardo Esteves maverick...@gmail.com Cc : Users@ovirt.org , Itamar Heim ih...@redhat.com Subject : Re: [Users] Bonding - VMs Network performance problem Date : Tue, 16 Jul 2013 10:01:31 -0400 (EDT) - Original Message - On 07/16/2013 04:09 PM, Ricardo Esteves wrote: Hi, Not really. I can resolve temporally, unconfiguring the bond and then configure it again. But when i reboot the server the problem comes back. can you compare the network configuration before and after you change it the setup network? Perhaps you can send pastebin of a 'vdsClient 0 getVdsCaps' (or 'vdsClient -s 0 getVdsCaps' if the first doesn't work) from the host when the bond is slow, and one after you break and create it again? if you don't have vdsClient command you can 'yum install vdsm-cli' and it should be available.-Original Message- *From*: Itamar Heim ih...@redhat.com mailto:itamar%20heim%20%3cih...@redhat.com %3e *To*: Ricardo Esteves maverick...@gmail.com mailto:ricardo%20esteves%20%3cmaverick...@gmail.com %3e *Subject*: Re: [Users] Bonding - VMs Network performance problem *Date*: Tue, 16 Jul 2013 15:38:10 +0300 On 07/01/2013 03:12 PM, Ricardo Esteves wrote: Hi, Yes, i'm still experiencing this problem, in fact just happened a few minutes ago. :) All MTUs are 1500. was this resolved? -Original Message- *From*: Livnat Peer lp...@redhat.com mailto:lp...@redhat.com mailto:livnat%20peer%20%3clp...@redhat.com %3e *To*: Ricardo Esteves maverick...@gmail.commailto:maverick...@gmail.com mailto:ricardo%20esteves%20%3cmaverick...@gmail.com %3e *Subject*: Re: [Users] Bonding - VMs Network performance problem *Date*: Sun, 23 Jun 2013 11:33:58 +0300 Hi Ricardo, Are you still experiencing the problem described below? Are you configuring MTU (to something other than default or 1500) for one of the networks on the bond? Thanks, Livnat On 06/18/2013 05:36 PM, Ricardo Esteves wrote: Good afternoon, Yes, the Save network configuration is checked, configurations are persistent across boots. The problem is not the persistence of the configurations, the problem is that after a reboot the network performance on the VMs is very bad, and to fix it i need to remove the bonding and add it again. In attachment, the screenshots of my network configuration. Best regards, Ricardo Esteves. -Original Message- *From*: Mike Kolesnik mkole...@redhat.com mailto:mkole...@redhat.com mailto:mkole...@redhat.com mailto:mike%20kolesnik%20%3cmkole...@redhat.com %3e *To*: Ricardo Esteves maverick...@gmail.commailto:maverick...@gmail.com mailto:maverick...@gmail.com mailto:ricardo%20esteves%20%3cmaverick...@gmail.com %3e *Cc*: Users@ovirt.org mailto:Users@ovirt.org mailto:Users@ovirt.org mailto:Users@ovirt.org*Subject*: Re:
Re: [Users] Nic names : always start by eth0
On Tue, 30 Jul 2013 16:40:16 +0200 Vincent Van der Kussrn vinc...@vanderkussen.org wrote: I hadn't looked at the history below which already explains it. you can also add a .reconfigure file in your root that allows you to provide a new root pwd on boot. - Vincent You need to delete the udev created files under /etc/udev.d I believe persistent-net-70-* or something (can't check). And then create your template Vincent Connected by Motorola Sven M. Geschke ov...@nebulaone.com wrote: Hi AFAIK This is more a CentOS- than an oVirt-issue. CentOS behaves identically on vSphere. If I remember correctly, this is due to the fact that the MAC-address of the virtual NIC has to change, when you create a VM from a template. CentOS however keeps the MAC address of the template and just adds the new MAC, which then of course becomes eth1. --SMG - Original Message - From: gregoire leroy gregoire.le...@retenodus.net To: users@ovirt.org Sent: Tuesday, July 30, 2013 7:59:35 AM Subject: [Users] Nic names : always start by eth0 Hello, I have an ovirt cluster which runs CentOS VM. I have a template to create VM. On this template, there are two interfaces, eth0 and eth1. When I create a VM using this template, the new interfaces are named eth2 and eth3. It can be pretty annoying and I would like to know if it would be possible to always start by eth0 ? If I remember the discussion on IRC, it would be necessary to clean old udev rules (in centos it seems to be /etc/udev/rules.d/70-persistent-net.rules) Thanks, Regards, Grégoire ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] [ATN] oVirt 3.3 release, moving to RC [3.3 branching, blockers review]
On Tue, Jul 30, 2013 at 06:05:46PM +0300, Moran Goldboim wrote: We would like to go a head on oVirt 3.3 release process and issue an RC for tomorrow meeting: Maintainers/ Package owners == -branch your git repo (master) with 3.3 branch (making master ready for 3.4) -for tomorrow meeting, overview [1], see if you have any changes to it -if you don't have any blockers under your component, please branch 3.3 with RC1 branch | -master | -engine_3.3 | -RC1 | -engine_3.2 ... Users with your experience from test day and with nightlies, if you feel there are additional candidates to block this version for please add it to the tracker bug [1]. Suggested Schedule Wed Jul 31st - review of blockers for the version and component readiness Mon Aug 5th - RC1 release Wed Aug 7th - Release readiness review (in case of blockers an RC2 will be issued) Thanks. [1]*Bug 918494* https://bugzilla.redhat.com/show_bug.cgi?id=918494 -Tracker: oVirt 3.3 release I've just tagged vdsm-4.12.0 and branched ovirt-3.3 branch for the vdsm repository starting at git has 620343d6317c849fc985a5083cebb68c995f7c15. Expect a deluge of non-ovirt-3.3 merges to the master branch soon. Future ovirt-3.3 fixes would have to be backported and cherry-picked. Dan. ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] Nic names : always start by eth0
On 07/30/2013 04:13 PM, René Koch (ovido) wrote: Hi, The easiest way is to remove 70-persistent-net.rules in your master-vm, remove HWADDR-strings from ifcfg-eth* friles, shut it down and create the template. Btw, also remove your ssh-keys in your template to create unique ones for each vm... will cloud-init solve this one? Regards, René On Tue, 2013-07-30 at 14:59 +0200, gregoire.le...@retenodus.net wrote: Hello, I have an ovirt cluster which runs CentOS VM. I have a template to create VM. On this template, there are two interfaces, eth0 and eth1. When I create a VM using this template, the new interfaces are named eth2 and eth3. It can be pretty annoying and I would like to know if it would be possible to always start by eth0 ? If I remember the discussion on IRC, it would be necessary to clean old udev rules (in centos it seems to be /etc/udev/rules.d/70-persistent-net.rules) Thanks, Regards, Grégoire ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] [ATN] oVirt 3.3 release, moving to RC [3.3 branching, blockers review]
On 07/30/2013 06:05 PM, Moran Goldboim wrote: We would like to go a head on oVirt 3.3 release process and issue an RC how can we do this before folks review all the bugs with target release of 3.3 and either suggest them as blockers or move them from 3.3? there are currently 59 NEW, 7 ASSIGNED and 22 POST with target release of 3.3? http://alturl.com/aq23x for tomorrow meeting: Maintainers/ Package owners == -branch your git repo (master) with 3.3 branch (making master ready for 3.4) -for tomorrow meeting, overview [1], see if you have any changes to it -if you don't have any blockers under your component, please branch 3.3 with RC1 branch | -master | -engine_3.3 | -RC1 | -engine_3.2 ... Users with your experience from test day and with nightlies, if you feel there are additional candidates to block this version for please add it to the tracker bug [1]. Suggested Schedule Wed Jul 31st - review of blockers for the version and component readiness Mon Aug 5th - RC1 release Wed Aug 7th - Release readiness review (in case of blockers an RC2 will be issued) Thanks. [1]*Bug 918494* https://bugzilla.redhat.com/show_bug.cgi?id=918494 -Tracker: oVirt 3.3 release ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] [ATN] oVirt 3.3 release, moving to RC [3.3 branching, blockers review]
On 07/30/2013 09:56 PM, Itamar Heim wrote: On 07/30/2013 06:05 PM, Moran Goldboim wrote: We would like to go a head on oVirt 3.3 release process and issue an RC how can we do this before folks review all the bugs with target release of 3.3 and either suggest them as blockers or move them from 3.3? there are currently 59 NEW, 7 ASSIGNED and 22 POST with target release of 3.3? http://alturl.com/aq23x that the aim of this mail, maintainers should review their realm for blockers (unscrubbed bugs as well), and this release should get into stabilization mode. by tomorrow we should have a better view on what are the blockers for the version, we are already going to delay this release, and i would like to get a clear view by tomorrow, as mentioned later in the mail - RC should go out without any known blockers. for tomorrow meeting: Maintainers/ Package owners == -branch your git repo (master) with 3.3 branch (making master ready for 3.4) -for tomorrow meeting, overview [1], see if you have any changes to it -if you don't have any blockers under your component, please branch 3.3 with RC1 branch | -master | -engine_3.3 | -RC1 | -engine_3.2 ... Users with your experience from test day and with nightlies, if you feel there are additional candidates to block this version for please add it to the tracker bug [1]. Suggested Schedule Wed Jul 31st - review of blockers for the version and component readiness Mon Aug 5th - RC1 release Wed Aug 7th - Release readiness review (in case of blockers an RC2 will be issued) Thanks. [1]*Bug 918494* https://bugzilla.redhat.com/show_bug.cgi?id=918494 -Tracker: oVirt 3.3 release ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] upgrade to latest master not working
- Original Message - From: Dead Horse deadhorseconsult...@gmail.com To: Doron Fediuck dfedi...@redhat.com Cc: Alon Bar-Lev alo...@redhat.com, users users@ovirt.org, Dave Chen wei.d.c...@intel.com, Eli Mesika emes...@redhat.com Sent: Tuesday, July 30, 2013 11:20:01 PM Subject: Re: [Users] upgrade to latest master not working Ok, so something from yesterday morning to today changed. I again rebuilt engine from the latest commit this AM. Accordingly I also built this mornings latest commits of otopi and ovirt-host-deploy. I then attempted upgrade and this time I did not note any major issues. The upgrade appears to have succeeded, and engine starts and runs. The only things that caused failures during upgrade were: - If the previous version ovirt-engine-sdk is not removed manually and replaced with ovirt-engine-sdk-python engine-upgrade fails due to package dependency issues. (which then upsets ovirt-iso-uploader, ovirt-image-uploader, ovirt-log-collector dependencies on ovirt-engine-sdk) - If there is a leftover releasepreview directory engine-upgrade will not run There were some error messages in the engine log griping about Could not parse option AutoRecoveryAllowedTypes value. I have attached the engine log file from the first start of the engine after upgrade. The other minor thing to note is that the default ovirt.brand theme is not working. The CSS styles are not being applied. Changes to welcome_page.template and messages.properties were picked up however. Yes, this is known issue, the patch was reverted because of some issues, now ready[1] [1] http://gerrit.ovirt.org/#/c/17484/ - DHC On Tue, Jul 30, 2013 at 11:04 AM, Doron Fediuck dfedi...@redhat.com wrote: - Original Message - | From: Dead Horse deadhorseconsult...@gmail.com | To: Doron Fediuck dfedi...@redhat.com | Cc: Alon Bar-Lev alo...@redhat.com, users users@ovirt.org, Dave Chen wei.d.c...@intel.com, Eli Mesika | emes...@redhat.com | Sent: Tuesday, July 30, 2013 6:55:18 PM | Subject: Re: [Users] upgrade to latest master not working | | The only error I can find in the upgrade log is: | 2013-07-29 14:06:28 DEBUG otopi.plugins.otopi.packagers.yumpackager | yumpackager.verbose:84 Yum Done: ovirt-engine.noarch 0:3.3.0-20.fc18 - u | 2013-07-29 14:06:28 INFO otopi.plugins.otopi.packagers.yumpackager | yumpackager.info:88 Yum update: 10/18: ovirt-engine | 2013-07-29 14:06:35 DEBUG otopi.plugins.otopi.packagers.yumpackager | yumpackager.verbose:84 Yum Done: ovirt-engine.noarch 0:3.3.0-20.fc18 - u | 2013-07-29 14:06:35 DEBUG otopi.plugins.otopi.packagers.yumpackager | yumpackager.verbose:84 Yum Done: ovirt-engine-3.3.0-20.fc18.noarch | 2013-07-29 14:06:37 INFO otopi.plugins.otopi.packagers.yumpackager | yumpackager.info:88 Yum update: 11/18: ovirt-engine-dbscripts | 2013-07-29 14:06:38 DEBUG otopi.plugins.otopi.packagers.yumpackager | yumpackager.verbose:84 Yum Done: ovirt-engine-dbscripts-3.3.0-20.fc18.noarch | 2013-07-29 14:06:38 DEBUG otopi.plugins.otopi.packagers.yumpackager | yumpackager.verbose:84 Yum Done: ovirt-engine-backend | Traceback (most recent call last): | File /usr/lib/python2.7/site-packages/yum/rpmtrans.py, line 464, in | callback | self._unInstStop( bytes, total, h ) | File /usr/lib/python2.7/site-packages/yum/rpmtrans.py, line 564, in | _unInstStop | self.total_actions) | File /usr/lib/python2.7/site-packages/otopi/miniyum.py, line 204, in | event | package=package.name, | AttributeError: 'str' object has no attribute 'name' | FATAL ERROR: python callback bound method RPMTransaction.callback of | yum.rpmtrans.RPMTransaction instance at 0x4587560 failed, aborting! | | To test the database upgrade I will revert to a previous snapshot of the | debug VM, capture the dbase from the previous engine version, re-run | upgrade, dump the upgraded database, restore the previous, and then test a | manual run of the database upgrade script. | | Does this sound prudent? | - DHC | Yes. Although lots of work, it may show if there's a DB upgrade bug we missed, or indeed the general upgrade procedure has / had an issue. | | On Tue, Jul 30, 2013 at 5:54 AM, Doron Fediuck dfedi...@redhat.com wrote: | | Thanks. | So this leads me further to the upgrade procedure | which may have fail, thus not completing the DB upgrade. | Can you please check the upgrade logs to see if something | matches this flow? | | - Original Message - | | From: Dead Horse deadhorseconsult...@gmail.com | | To: Doron Fediuck dfedi...@redhat.com | | Cc: Alon Bar-Lev alo...@redhat.com, users users@ovirt.org, | Dave Chen wei.d.c...@intel.com, Eli Mesika | | emes...@redhat.com | | Sent: Tuesday, July 30, 2013 6:37:55 AM | | Subject: Re: [Users] upgrade to latest master not working | | | | The engine version I am attempting to upgrade
Re: [Users] upgrade to latest master not working
Big thanks DHC for your time and efforts. Since neither of us managed to reproduce the issue I suggest we drop it for now. If someone else will hit into it, we should try and get more info on a possible failure which will not complete the db upgrade. Thanks again, Doron - Original Message - | From: Dead Horse deadhorseconsult...@gmail.com | To: Doron Fediuck dfedi...@redhat.com | Cc: Alon Bar-Lev alo...@redhat.com, users users@ovirt.org, Dave Chen wei.d.c...@intel.com, Eli Mesika | emes...@redhat.com | Sent: Tuesday, July 30, 2013 11:20:01 PM | Subject: Re: [Users] upgrade to latest master not working | | Ok, so something from yesterday morning to today changed. I again rebuilt | engine from the latest commit this AM. Accordingly I also built this | mornings latest commits of otopi and ovirt-host-deploy. I then attempted | upgrade and this time I did not note any major issues. The upgrade appears | to have succeeded, and engine starts and runs. | The only things that caused failures during upgrade were: | - If the previous version ovirt-engine-sdk is not removed manually and | replaced with ovirt-engine-sdk-python engine-upgrade fails due to package | dependency issues. (which then upsets ovirt-iso-uploader, | ovirt-image-uploader, ovirt-log-collector dependencies on ovirt-engine-sdk) | - If there is a leftover releasepreview directory engine-upgrade will not | run | | There were some error messages in the engine log griping about Could not | parse option AutoRecoveryAllowedTypes value. I have attached the engine | log file from the first start of the engine after upgrade. | | The other minor thing to note is that the default ovirt.brand theme is not | working. The CSS styles are not being applied. Changes to | welcome_page.template and messages.properties were picked up however. | | - DHC | | | | On Tue, Jul 30, 2013 at 11:04 AM, Doron Fediuck dfedi...@redhat.com wrote: | | | | - Original Message - | | From: Dead Horse deadhorseconsult...@gmail.com | | To: Doron Fediuck dfedi...@redhat.com | | Cc: Alon Bar-Lev alo...@redhat.com, users users@ovirt.org, | Dave Chen wei.d.c...@intel.com, Eli Mesika | | emes...@redhat.com | | Sent: Tuesday, July 30, 2013 6:55:18 PM | | Subject: Re: [Users] upgrade to latest master not working | | | | The only error I can find in the upgrade log is: | | 2013-07-29 14:06:28 DEBUG otopi.plugins.otopi.packagers.yumpackager | | yumpackager.verbose:84 Yum Done: ovirt-engine.noarch 0:3.3.0-20.fc18 - u | | 2013-07-29 14:06:28 INFO otopi.plugins.otopi.packagers.yumpackager | | yumpackager.info:88 Yum update: 10/18: ovirt-engine | | 2013-07-29 14:06:35 DEBUG otopi.plugins.otopi.packagers.yumpackager | | yumpackager.verbose:84 Yum Done: ovirt-engine.noarch 0:3.3.0-20.fc18 - u | | 2013-07-29 14:06:35 DEBUG otopi.plugins.otopi.packagers.yumpackager | | yumpackager.verbose:84 Yum Done: ovirt-engine-3.3.0-20.fc18.noarch | | 2013-07-29 14:06:37 INFO otopi.plugins.otopi.packagers.yumpackager | | yumpackager.info:88 Yum update: 11/18: ovirt-engine-dbscripts | | 2013-07-29 14:06:38 DEBUG otopi.plugins.otopi.packagers.yumpackager | | yumpackager.verbose:84 Yum Done: | ovirt-engine-dbscripts-3.3.0-20.fc18.noarch | | 2013-07-29 14:06:38 DEBUG otopi.plugins.otopi.packagers.yumpackager | | yumpackager.verbose:84 Yum Done: ovirt-engine-backend | | Traceback (most recent call last): | | File /usr/lib/python2.7/site-packages/yum/rpmtrans.py, line 464, in | | callback | | self._unInstStop( bytes, total, h ) | | File /usr/lib/python2.7/site-packages/yum/rpmtrans.py, line 564, in | | _unInstStop | | self.total_actions) | | File /usr/lib/python2.7/site-packages/otopi/miniyum.py, line 204, in | | event | | package=package.name, | | AttributeError: 'str' object has no attribute 'name' | | FATAL ERROR: python callback bound method RPMTransaction.callback of | | yum.rpmtrans.RPMTransaction instance at 0x4587560 failed, aborting! | | | | To test the database upgrade I will revert to a previous snapshot of the | | debug VM, capture the dbase from the previous engine version, re-run | | upgrade, dump the upgraded database, restore the previous, and then test | a | | manual run of the database upgrade script. | | | | Does this sound prudent? | | - DHC | | | | Yes. Although lots of work, it may show if there's a DB upgrade bug we | missed, or indeed the general upgrade procedure has / had an issue. | | | | | On Tue, Jul 30, 2013 at 5:54 AM, Doron Fediuck dfedi...@redhat.com | wrote: | | | | Thanks. | | So this leads me further to the upgrade procedure | | which may have fail, thus not completing the DB upgrade. | | Can you please check the upgrade logs to see if something | | matches this flow? | | | | - Original Message - | | | From: Dead Horse deadhorseconsult...@gmail.com | | | To: Doron Fediuck dfedi...@redhat.com | | | Cc: Alon Bar-Lev alo...@redhat.com, users users@ovirt.org, |
Re: [Users] upgrade to latest master not working
Agreed, I did revert my victim VM back the pre-upgrade snapshot and retry the upgrade with the same results with yesterdays packages.I had watch on the logs but I did not see any DB upgrade failures. Given that I figured for the heck of it I would just rebuild with this mornings latest commits to see if the issue still persisted, I actually fully expected it to fail the same. However to my surprise it did not fail, thus I assume something changed between yesterday morning this morning that allowed things to work. for grins the packages I used yesterday were generated from: engine commit: ec2b57124edd5ae1fa41e986adadfefb9c5f1aa7 otopi commit: 8e3e3c27cbcd4330143d571a3ce8caa36c6d20ef ovirt-host-deply commit: 35a5b5f5e6d6c240ef1d20904bc06498b0ed81e1 and the packages I generated this morning that worked were from: engine commit: 28251d9acd1ecbe39b9b79e7e2e69342f57c9bd7 otopi commit: 10892fbf3fe805cea416dfa3ba628f98ffa88b3e ovirt-host-deply commit: e9c98c67dcdfca21091141bcb732727f50eb97d1 - DHC On Tue, Jul 30, 2013 at 3:27 PM, Doron Fediuck dfedi...@redhat.com wrote: Big thanks DHC for your time and efforts. Since neither of us managed to reproduce the issue I suggest we drop it for now. If someone else will hit into it, we should try and get more info on a possible failure which will not complete the db upgrade. Thanks again, Doron - Original Message - | From: Dead Horse deadhorseconsult...@gmail.com | To: Doron Fediuck dfedi...@redhat.com | Cc: Alon Bar-Lev alo...@redhat.com, users users@ovirt.org, Dave Chen wei.d.c...@intel.com, Eli Mesika | emes...@redhat.com | Sent: Tuesday, July 30, 2013 11:20:01 PM | Subject: Re: [Users] upgrade to latest master not working | | Ok, so something from yesterday morning to today changed. I again rebuilt | engine from the latest commit this AM. Accordingly I also built this | mornings latest commits of otopi and ovirt-host-deploy. I then attempted | upgrade and this time I did not note any major issues. The upgrade appears | to have succeeded, and engine starts and runs. | The only things that caused failures during upgrade were: | - If the previous version ovirt-engine-sdk is not removed manually and | replaced with ovirt-engine-sdk-python engine-upgrade fails due to package | dependency issues. (which then upsets ovirt-iso-uploader, | ovirt-image-uploader, ovirt-log-collector dependencies on ovirt-engine-sdk) | - If there is a leftover releasepreview directory engine-upgrade will not | run | | There were some error messages in the engine log griping about Could not | parse option AutoRecoveryAllowedTypes value. I have attached the engine | log file from the first start of the engine after upgrade. | | The other minor thing to note is that the default ovirt.brand theme is not | working. The CSS styles are not being applied. Changes to | welcome_page.template and messages.properties were picked up however. | | - DHC | | | | On Tue, Jul 30, 2013 at 11:04 AM, Doron Fediuck dfedi...@redhat.com wrote: | | | | - Original Message - | | From: Dead Horse deadhorseconsult...@gmail.com | | To: Doron Fediuck dfedi...@redhat.com | | Cc: Alon Bar-Lev alo...@redhat.com, users users@ovirt.org, | Dave Chen wei.d.c...@intel.com, Eli Mesika | | emes...@redhat.com | | Sent: Tuesday, July 30, 2013 6:55:18 PM | | Subject: Re: [Users] upgrade to latest master not working | | | | The only error I can find in the upgrade log is: | | 2013-07-29 14:06:28 DEBUG otopi.plugins.otopi.packagers.yumpackager | | yumpackager.verbose:84 Yum Done: ovirt-engine.noarch 0:3.3.0-20.fc18 - u | | 2013-07-29 14:06:28 INFO otopi.plugins.otopi.packagers.yumpackager | | yumpackager.info:88 Yum update: 10/18: ovirt-engine | | 2013-07-29 14:06:35 DEBUG otopi.plugins.otopi.packagers.yumpackager | | yumpackager.verbose:84 Yum Done: ovirt-engine.noarch 0:3.3.0-20.fc18 - u | | 2013-07-29 14:06:35 DEBUG otopi.plugins.otopi.packagers.yumpackager | | yumpackager.verbose:84 Yum Done: ovirt-engine-3.3.0-20.fc18.noarch | | 2013-07-29 14:06:37 INFO otopi.plugins.otopi.packagers.yumpackager | | yumpackager.info:88 Yum update: 11/18: ovirt-engine-dbscripts | | 2013-07-29 14:06:38 DEBUG otopi.plugins.otopi.packagers.yumpackager | | yumpackager.verbose:84 Yum Done: | ovirt-engine-dbscripts-3.3.0-20.fc18.noarch | | 2013-07-29 14:06:38 DEBUG otopi.plugins.otopi.packagers.yumpackager | | yumpackager.verbose:84 Yum Done: ovirt-engine-backend | | Traceback (most recent call last): | | File /usr/lib/python2.7/site-packages/yum/rpmtrans.py, line 464, in | | callback | | self._unInstStop( bytes, total, h ) | | File /usr/lib/python2.7/site-packages/yum/rpmtrans.py, line 564, in | | _unInstStop | | self.total_actions) | | File /usr/lib/python2.7/site-packages/otopi/miniyum.py, line 204, in | | event | | package=package.name, | | AttributeError: 'str' object has no attribute
Re: [Users] [Engine-devel] [Feedback required][host-deploy] Fedora-19 misses tar at minimal setup
On 07/30/2013 09:25 AM, Michal Skrivanek wrote: On Jul 30, 2013, at 15:12 , Alon Bar-Lev alo...@redhat.com wrote: Hello All, Starting the discussion again... I would like to receive feedback regarding how we should cope with a state presented to use by Fedora. Fedora-19 minimal setup does not install tar utility which is required to deploy files during the host-deploy process (Hosts-Add Host). I guess because of 2.8M in size (including translations) -- a standard commonly used utility was removed. How about filing bug on that? This is such a basic utility I can't imagine anyone removing it. +1 I do agree with Michael. I have opened a thread in fedora devel mailing list anyway. There are three alternatives : 1. Instruct users who are using minimal installations to manually install tar utility just like they configure repository, dns, etc.. Benefit: simplicity. Benefit: use standard tools. Benefit: lower payload to transmit. Drawback: require tar at destination machine. 2. Do not use tar but self extracting python script, a patch is ready[1]. Benefit: ability to deploy environment in which tar is missing. Drawback: non standard tool at destination machine. Drawback: complexity within our code. 3. Do not use tar but cpio, a patch is ready[2]. Benefit: simplicity. Benefit: use standard tools. Benefit: lower payload to transmit. Benefit: ability to use Fedora-19 minimal. Drawback: cpio is even less common than tar, even if it exists in Fedora-19 it can be removed without anyone notice. Drawback: most other distributions will not have cpio in their minimal installation. [[[ There was 4rd alternative, using python tar module to deploy tar. However, there is a bug in that module when processing last block if empty. This is edge condition but happened to at least one of the users and I could reproduce it. ]]] What option do you prefer? Regards, Alon Bar-Lev [1] http://gerrit.ovirt.org/#/c/17295/ [2] http://gerrit.ovirt.org/#/c/17396/ ___ Engine-devel mailing list engine-de...@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list engine-de...@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel -- Cheers Douglas ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] [Engine-devel] [Feedback required][host-deploy] Fedora-19 misses tar at minimal setup
On Tue, Jul 30, 2013 at 10:09:47AM -0400, Antoni Segura Puimedon wrote: I would advocate for option 2. - Original Message - From: Michal Skrivanek michal.skriva...@redhat.com To: Alon Bar-Lev alo...@redhat.com Cc: Juan Hernandez jhern...@redhat.com, engine-devel engine-de...@ovirt.org, arch a...@ovirt.org, users users@ovirt.org Sent: Tuesday, July 30, 2013 3:25:24 PM Subject: Re: [Engine-devel] [Users] [Feedback required][host-deploy] Fedora-19 misses tar at minimal setup On Jul 30, 2013, at 15:12 , Alon Bar-Lev alo...@redhat.com wrote: Hello All, Starting the discussion again... I would like to receive feedback regarding how we should cope with a state presented to use by Fedora. Fedora-19 minimal setup does not install tar utility which is required to deploy files during the host-deploy process (Hosts-Add Host). I guess because of 2.8M in size (including translations) -- a standard commonly used utility was removed. How about filing bug on that? This is such a basic utility I can't imagine anyone removing it. There are three alternatives : 1. Instruct users who are using minimal installations to manually install tar utility just like they configure repository, dns, etc.. Benefit: simplicity. Benefit: use standard tools. Benefit: lower payload to transmit. Drawback: require tar at destination machine. 2. Do not use tar but self extracting python script, a patch is ready[1]. Benefit: ability to deploy environment in which tar is missing. Drawback: non standard tool at destination machine. Drawback: complexity within our code. How about option 2.1: convince Fedora to reintroduce tar? It is ironic that Gnome is shipped by default, but not such a staple utility. Where in Fedora did this decision take place? Can it be undone? Is it commonplace these days among other distros to boycot tar? Dan. ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] [ATN] oVirt 3.3 release, moving to RC [3.3 branching, blockers review]
On Tue, Jul 30, 2013 at 06:05:46PM +0300, Moran Goldboim wrote: We would like to go a head on oVirt 3.3 release process and issue an RC for tomorrow meeting: Maintainers/ Package owners == -branch your git repo (master) with 3.3 branch (making master ready for 3.4) -for tomorrow meeting, overview [1], see if you have any changes to it -if you don't have any blockers under your component, please branch 3.3 with RC1 branch | -master | -engine_3.3 | -RC1 | -engine_3.2 ... Users with your experience from test day and with nightlies, if you feel there are additional candidates to block this version for please add it to the tracker bug [1]. Suggested Schedule Wed Jul 31st - review of blockers for the version and component readiness Mon Aug 5th - RC1 release Wed Aug 7th - Release readiness review (in case of blockers an RC2 will be issued) Thanks. [1]*Bug 918494* https://bugzilla.redhat.com/show_bug.cgi?id=918494 -Tracker: oVirt 3.3 release I've just tagged vdsm-4.12.0 and branched ovirt-3.3 branch for the vdsm repository starting at git has 620343d6317c849fc985a5083cebb68c995f7c15. Expect a deluge of non-ovirt-3.3 merges to the master branch soon. Future ovirt-3.3 fixes would have to be backported and cherry-picked. Dan. ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
