- Users - oVirt List Archives

Re: [ovirt-users] hosted engine health check issues
by Martin Sivak 23 Apr '14

23 Apr '14

Hi René, > >> libvirtError: Failed to acquire lock: No space left on device > >> 2014-04-22 12:38:17+0200 654 [3093]: r2 cmd_acquire 2,9,5733 invalid > >> lockspace found -1 failed 0 name 2851af27-8744-445d-9fb1-a0d083c8dc82 Can you please check the contents of /rhev/data-center/<your nfs mount>/<nfs domain uuid>/ha_agent/? This is how it should look like: [root@dev-03 ~]# ls -al /rhev/data-center/mnt/euryale\:_home_ovirt_he/e16de6a2-53f5-4ab3-95a3-255d08398824/ha_agent/ total 2036 drwxr-x---. 2 vdsm kvm 4096 Mar 19 18:46 . drwxr-xr-x. 6 vdsm kvm 4096 Mar 19 18:46 .. -rw-rw----. 1 vdsm kvm 1048576 Apr 23 11:05 hosted-engine.lockspace -rw-rw----. 1 vdsm kvm 1028096 Mar 19 18:46 hosted-engine.metadata The errors seem to indicate that you somehow lost the lockspace file. -- Martin Sivák msivak(a)redhat.com Red Hat Czech RHEV-M SLA / Brno, CZ ----- Original Message ----- > On 04/23/2014 12:28 AM, Doron Fediuck wrote: > > Hi Rene, > > any idea what closed your ovirtmgmt bridge? > > as long as it is down vdsm may have issues starting up properly > > and this is why you see the complaints on the rpc server. > > > > Can you try manually fixing the network part first and then > > restart vdsm? > > Once vdsm is happy hosted engine VM will start. > > Thanks for your feedback, Doron. > > My ovirtmgmt bridge seems to be on or isn't it: > # brctl show ovirtmgmt > bridge name bridge id STP enabled interfaces > ovirtmgmt 8000.0025907587c2 no eth0.200 > > # ip a s ovirtmgmt > 7: ovirtmgmt: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue > state UNKNOWN > link/ether 00:25:90:75:87:c2 brd ff:ff:ff:ff:ff:ff > inet 10.0.200.102/24 brd 10.0.200.255 scope global ovirtmgmt > inet6 fe80::225:90ff:fe75:87c2/64 scope link > valid_lft forever preferred_lft forever > > # ip a s eth0.200 > 6: eth0.200@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc > noqueue state UP > link/ether 00:25:90:75:87:c2 brd ff:ff:ff:ff:ff:ff > inet6 fe80::225:90ff:fe75:87c2/64 scope link > valid_lft forever preferred_lft forever > > I tried the following yesterday: > Copy virtual disk from GlusterFS storage to local disk of host and > create a new vm with virt-manager which loads ovirtmgmt disk. I could > reach my engine over the ovirtmgmt bridge (so bridge must be working). > > I also started libvirtd with Option -v and I saw the following in > libvirtd.log when trying to start ovirt engine: > 2014-04-22 14:18:25.432+0000: 8901: debug : virCommandRunAsync:2250 : > Command result 0, with PID 11491 > 2014-04-22 14:18:25.478+0000: 8901: debug : virCommandRun:2045 : Result > exit status 255, stdout: '' stderr: 'iptables v1.4.7: goto 'FO-vnet0' is > not a chain > > So it could be that something is broken in my hosted-engine network. Do > you have any clue how I can troubleshoot this? > > > Thanks, > René > > > > > > ----- Original Message ----- > >> From: "René Koch" <rkoch(a)linuxland.at> > >> To: "Martin Sivak" <msivak(a)redhat.com> > >> Cc: users(a)ovirt.org > >> Sent: Tuesday, April 22, 2014 1:46:38 PM > >> Subject: Re: [ovirt-users] hosted engine health check issues > >> > >> Hi, > >> > >> I rebooted one of my ovirt hosts today and the result is now that I > >> can't start hosted-engine anymore. > >> > >> ovirt-ha-agent isn't running because the lockspace file is missing > >> (sanlock complains about it). > >> So I tried to start hosted-engine with --vm-start and I get the > >> following errors: > >> > >> ==> /var/log/sanlock.log <== > >> 2014-04-22 12:38:17+0200 654 [3093]: r2 cmd_acquire 2,9,5733 invalid > >> lockspace found -1 failed 0 name 2851af27-8744-445d-9fb1-a0d083c8dc82 > >> > >> ==> /var/log/messages <== > >> Apr 22 12:38:17 ovirt-host02 sanlock[3079]: 2014-04-22 12:38:17+0200 654 > >> [3093]: r2 cmd_acquire 2,9,5733 invalid lockspace found -1 failed 0 name > >> 2851af27-8744-445d-9fb1-a0d083c8dc82 > >> Apr 22 12:38:17 ovirt-host02 kernel: ovirtmgmt: port 2(vnet0) entering > >> disabled state > >> Apr 22 12:38:17 ovirt-host02 kernel: device vnet0 left promiscuous mode > >> Apr 22 12:38:17 ovirt-host02 kernel: ovirtmgmt: port 2(vnet0) entering > >> disabled state > >> > >> ==> /var/log/vdsm/vdsm.log <== > >> Thread-21::DEBUG::2014-04-22 > >> 12:38:17,563::libvirtconnection::124::root::(wrapper) Unknown > >> libvirterror: ecode: 38 edom: 42 level: 2 message: Failed to acquire > >> lock: No space left on device > >> Thread-21::DEBUG::2014-04-22 > >> 12:38:17,563::vm::2263::vm.Vm::(_startUnderlyingVm) > >> vmId=`f26dd37e-13b5-430c-b2f2-ecd098b82a91`::_ongoingCreations released > >> Thread-21::ERROR::2014-04-22 > >> 12:38:17,564::vm::2289::vm.Vm::(_startUnderlyingVm) > >> vmId=`f26dd37e-13b5-430c-b2f2-ecd098b82a91`::The vm start process failed > >> Traceback (most recent call last): > >> File "/usr/share/vdsm/vm.py", line 2249, in _startUnderlyingVm > >> self._run() > >> File "/usr/share/vdsm/vm.py", line 3170, in _run > >> self._connection.createXML(domxml, flags), > >> File "/usr/lib64/python2.6/site-packages/vdsm/libvirtconnection.py", > >> line 92, in wrapper > >> ret = f(*args, **kwargs) > >> File "/usr/lib64/python2.6/site-packages/libvirt.py", line 2665, in > >> createXML > >> if ret is None:raise libvirtError('virDomainCreateXML() failed', > >> conn=self) > >> libvirtError: Failed to acquire lock: No space left on device > >> > >> ==> /var/log/messages <== > >> Apr 22 12:38:17 ovirt-host02 vdsm vm.Vm ERROR > >> vmId=`f26dd37e-13b5-430c-b2f2-ecd098b82a91`::The vm start process > >> failed#012Traceback (most recent call last):#012 File > >> "/usr/share/vdsm/vm.py", line 2249, in _startUnderlyingVm#012 > >> self._run()#012 File "/usr/share/vdsm/vm.py", line 3170, in _run#012 > >> self._connection.createXML(domxml, flags),#012 File > >> "/usr/lib64/python2.6/site-packages/vdsm/libvirtconnection.py", line 92, > >> in wrapper#012 ret = f(*args, **kwargs)#012 File > >> "/usr/lib64/python2.6/site-packages/libvirt.py", line 2665, in > >> createXML#012 if ret is None:raise libvirtError('virDomainCreateXML() > >> failed', conn=self)#012libvirtError: Failed to acquire lock: No space > >> left on device > >> > >> ==> /var/log/vdsm/vdsm.log <== > >> Thread-21::DEBUG::2014-04-22 > >> 12:38:17,569::vm::2731::vm.Vm::(setDownStatus) > >> vmId=`f26dd37e-13b5-430c-b2f2-ecd098b82a91`::Changed state to Down: > >> Failed to acquire lock: No space left on device > >> > >> > >> No space left on device is nonsense as there is enough space (I had this > >> issue last time as well where I had to patch machine.py, but this file > >> is now Python 2.6.6 compatible. > >> > >> Any idea what prevents hosted-engine from starting? > >> ovirt-ha-broker, vdsmd and sanlock are running btw. > >> > >> Btw, I can see in log that json rpc server module is missing - which > >> package is required for CentOS 6.5? > >> Apr 22 12:37:14 ovirt-host02 vdsm vds WARNING Unable to load the json > >> rpc server module. Please make sure it is installed. > >> > >> > >> Thanks, > >> René > >> > >> > >> > >> On 04/17/2014 10:02 AM, Martin Sivak wrote: > >>> Hi, > >>> > >>>>>> How can I disable notifications? > >>> > >>> The notification is configured in /etc/ovirt-hosted-engine-ha/broker.conf > >>> section notification. > >>> The email is sent when the key state_transition exists and the string > >>> OldState-NewState contains the (case insensitive) regexp from the value. > >>> > >>>>>> Is it intended to send out these messages and detect that ovirt engine > >>>>>> is down (which is false anyway), but not to restart the vm? > >>> > >>> Forget about emails for now and check the > >>> /var/log/ovirt-hosted-engine-ha/agent.log and broker.log (and attach them > >>> as well btw). > >>> > >>>>>> oVirt hosts think that hosted engine is down because it seems that > >>>>>> hosts > >>>>>> can't write to hosted-engine.lockspace due to glusterfs issues (or at > >>>>>> least I think so). > >>> > >>> The hosts think so or can't really write there? The lockspace is managed > >>> by > >>> sanlock and our HA daemons do not touch it at all. We only ask sanlock to > >>> get make sure we have unique server id. > >>> > >>>>>> Is is possible or planned to make the whole ha feature optional? > >>> > >>> Well the system won't perform any automatic actions if you put the hosted > >>> engine to global maintenance and only start/stop/migrate the VM manually. > >>> I would discourage you from stopping agent/broker, because the engine > >>> itself has some logic based on the reporting. > >>> > >>> Regards > >>> > >>> -- > >>> Martin Sivák > >>> msivak(a)redhat.com > >>> Red Hat Czech > >>> RHEV-M SLA / Brno, CZ > >>> > >>> ----- Original Message ----- > >>>> On 04/15/2014 04:53 PM, Jiri Moskovcak wrote: > >>>>> On 04/14/2014 10:50 AM, René Koch wrote: > >>>>>> Hi, > >>>>>> > >>>>>> I have some issues with hosted engine status. > >>>>>> > >>>>>> oVirt hosts think that hosted engine is down because it seems that > >>>>>> hosts > >>>>>> can't write to hosted-engine.lockspace due to glusterfs issues (or at > >>>>>> least I think so). > >>>>>> > >>>>>> Here's the output of vm-status: > >>>>>> > >>>>>> # hosted-engine --vm-status > >>>>>> > >>>>>> > >>>>>> --== Host 1 status ==-- > >>>>>> > >>>>>> Status up-to-date : False > >>>>>> Hostname : 10.0.200.102 > >>>>>> Host ID : 1 > >>>>>> Engine status : unknown stale-data > >>>>>> Score : 2400 > >>>>>> Local maintenance : False > >>>>>> Host timestamp : 1397035677 > >>>>>> Extra metadata (valid at timestamp): > >>>>>> metadata_parse_version=1 > >>>>>> metadata_feature_version=1 > >>>>>> timestamp=1397035677 (Wed Apr 9 11:27:57 2014) > >>>>>> host-id=1 > >>>>>> score=2400 > >>>>>> maintenance=False > >>>>>> state=EngineUp > >>>>>> > >>>>>> > >>>>>> --== Host 2 status ==-- > >>>>>> > >>>>>> Status up-to-date : True > >>>>>> Hostname : 10.0.200.101 > >>>>>> Host ID : 2 > >>>>>> Engine status : {'reason': 'vm not running on > >>>>>> this > >>>>>> host', 'health': 'bad', 'vm': 'down', 'detail': 'unknown'} > >>>>>> Score : 0 > >>>>>> Local maintenance : False > >>>>>> Host timestamp : 1397464031 > >>>>>> Extra metadata (valid at timestamp): > >>>>>> metadata_parse_version=1 > >>>>>> metadata_feature_version=1 > >>>>>> timestamp=1397464031 (Mon Apr 14 10:27:11 2014) > >>>>>> host-id=2 > >>>>>> score=0 > >>>>>> maintenance=False > >>>>>> state=EngineUnexpectedlyDown > >>>>>> timeout=Mon Apr 14 10:35:05 2014 > >>>>>> > >>>>>> oVirt engine is sending me 2 emails every 10 minutes with the > >>>>>> following > >>>>>> subjects: > >>>>>> - ovirt-hosted-engine state transition EngineDown-EngineStart > >>>>>> - ovirt-hosted-engine state transition EngineStart-EngineUp > >>>>>> > >>>>>> In oVirt webadmin I can see the following message: > >>>>>> VM HostedEngine is down. Exit message: internal error Failed to > >>>>>> acquire > >>>>>> lock: error -243. > >>>>>> > >>>>>> These messages are really annoying as oVirt isn't doing anything with > >>>>>> hosted engine - I have an uptime of 9 days in my engine vm. > >>>>>> > >>>>>> So my questions are now: > >>>>>> Is it intended to send out these messages and detect that ovirt engine > >>>>>> is down (which is false anyway), but not to restart the vm? > >>>>>> > >>>>>> How can I disable notifications? I'm planning to write a Nagios plugin > >>>>>> which parses the output of hosted-engine --vm-status and only Nagios > >>>>>> should notify me, not hosted-engine script. > >>>>>> > >>>>>> Is is possible or planned to make the whole ha feature optional? I > >>>>>> really really really hate cluster software as it causes more troubles > >>>>>> then standalone machines and in my case the hosted-engine ha feature > >>>>>> really causes troubles (and I didn't had a hardware or network outage > >>>>>> yet only issues with hosted-engine ha agent). I don't need any ha > >>>>>> feature for hosted engine. I just want to run engine virtualized on > >>>>>> oVirt and if engine vm fails (e.g. because of issues with a host) I'll > >>>>>> restart it on another node. > >>>>> > >>>>> Hi, you can: > >>>>> 1. edit /etc/ovirt-hosted-engine-ha/{agent,broker}-log.conf and tweak > >>>>> the logger as you like > >>>>> 2. or kill ovirt-ha-broker & ovirt-ha-agent services > >>>> > >>>> Thanks for the information. > >>>> So engine is able to run when ovirt-ha-broker and ovirt-ha-agent isn't > >>>> running? > >>>> > >>>> > >>>> Regards, > >>>> René > >>>> > >>>>> > >>>>> --Jirka > >>>>>> > >>>>>> Thanks, > >>>>>> René > >>>>>> > >>>>>> > >>>>> > >>>> _______________________________________________ > >>>> Users mailing list > >>>> Users(a)ovirt.org > >>>> http://lists.ovirt.org/mailman/listinfo/users > >>>> > >> _______________________________________________ > >> Users mailing list > >> Users(a)ovirt.org > >> http://lists.ovirt.org/mailman/listinfo/users > >> >

2 1

hosted engine health check issues
by René Koch 22 Apr '14

22 Apr '14

Hi, I have some issues with hosted engine status. oVirt hosts think that hosted engine is down because it seems that hosts can't write to hosted-engine.lockspace due to glusterfs issues (or at least I think so). Here's the output of vm-status: # hosted-engine --vm-status --== Host 1 status ==-- Status up-to-date : False Hostname : 10.0.200.102 Host ID : 1 Engine status : unknown stale-data Score : 2400 Local maintenance : False Host timestamp : 1397035677 Extra metadata (valid at timestamp): metadata_parse_version=1 metadata_feature_version=1 timestamp=1397035677 (Wed Apr 9 11:27:57 2014) host-id=1 score=2400 maintenance=False state=EngineUp --== Host 2 status ==-- Status up-to-date : True Hostname : 10.0.200.101 Host ID : 2 Engine status : {'reason': 'vm not running on this host', 'health': 'bad', 'vm': 'down', 'detail': 'unknown'} Score : 0 Local maintenance : False Host timestamp : 1397464031 Extra metadata (valid at timestamp): metadata_parse_version=1 metadata_feature_version=1 timestamp=1397464031 (Mon Apr 14 10:27:11 2014) host-id=2 score=0 maintenance=False state=EngineUnexpectedlyDown timeout=Mon Apr 14 10:35:05 2014 oVirt engine is sending me 2 emails every 10 minutes with the following subjects: - ovirt-hosted-engine state transition EngineDown-EngineStart - ovirt-hosted-engine state transition EngineStart-EngineUp In oVirt webadmin I can see the following message: VM HostedEngine is down. Exit message: internal error Failed to acquire lock: error -243. These messages are really annoying as oVirt isn't doing anything with hosted engine - I have an uptime of 9 days in my engine vm. So my questions are now: Is it intended to send out these messages and detect that ovirt engine is down (which is false anyway), but not to restart the vm? How can I disable notifications? I'm planning to write a Nagios plugin which parses the output of hosted-engine --vm-status and only Nagios should notify me, not hosted-engine script. Is is possible or planned to make the whole ha feature optional? I really really really hate cluster software as it causes more troubles then standalone machines and in my case the hosted-engine ha feature really causes troubles (and I didn't had a hardware or network outage yet only issues with hosted-engine ha agent). I don't need any ha feature for hosted engine. I just want to run engine virtualized on oVirt and if engine vm fails (e.g. because of issues with a host) I'll restart it on another node. Thanks, René -- Best Regards René Koch Senior Solution Architect ============================================ LIS-Linuxland GmbH Brünner Straße 163, A-1210 Vienna Phone: +43 1 236 91 60 Mobile: +43 660 / 512 21 31 E-Mail: rkoch(a)linuxland.at ============================================

5 8

Fwd: [RHSA-2014:0421-01] Moderate: qemu-kvm-rhev security update
by Sven Kieske 22 Apr '14

22 Apr '14

Hi list, if you do not already monitor some security lists: You are strongly encouraged to update your qemu-kvm packages, especially on CentOS :) See below for details -------- Original-Nachricht -------- Betreff: [RHSA-2014:0421-01] Moderate: qemu-kvm-rhev security update Datum: Tue, 22 Apr 2014 17:52:38 +0000 Von: <bugzilla(a)redhat.com> An: <rhsa-announce(a)redhat.com>, <rhev-watch-list(a)redhat.com> ===================================================================== Red Hat Security Advisory Synopsis: Moderate: qemu-kvm-rhev security update Advisory ID: RHSA-2014:0421-01 Product: Red Hat Enterprise Virtualization Advisory URL: https://rhn.redhat.com/errata/RHSA-2014-0421.html Issue date: 2014-04-22 CVE Names: CVE-2014-0142 CVE-2014-0143 CVE-2014-0144 CVE-2014-0145 CVE-2014-0146 CVE-2014-0147 CVE-2014-0148 CVE-2014-0150 ===================================================================== 1. Summary: Updated qemu-kvm-rhev packages that fix several security issues are now available for Red Hat Enterprise Virtualization. The Red Hat Security Response Team has rated this update as having Moderate security impact. Common Vulnerability Scoring System (CVSS) base scores, which give detailed severity ratings, are available for each vulnerability from the CVE links in the References section. 2. Relevant releases/architectures: RHEV Agents (vdsm) - x86_64 3. Description: KVM (Kernel-based Virtual Machine) is a full virtualization solution for Linux on AMD64 and Intel 64 systems. The qemu-kvm-rhev package provides the user-space component for running virtual machines using KVM in environments managed by Red Hat Enterprise Virtualization Manager. Multiple integer overflow, input validation, logic error, and buffer overflow flaws were discovered in various QEMU block drivers. An attacker able to modify a disk image file loaded by a guest could use these flaws to crash the guest, or corrupt QEMU process memory on the host, potentially resulting in arbitrary code execution on the host with the privileges of the QEMU process. (CVE-2014-0143, CVE-2014-0144, CVE-2014-0145, CVE-2014-0147) A buffer overflow flaw was found in the way the virtio_net_handle_mac() function of QEMU processed guest requests to update the table of MAC addresses. A privileged guest user could use this flaw to corrupt QEMU process memory on the host, potentially resulting in arbitrary code execution on the host with the privileges of the QEMU process. (CVE-2014-0150) A divide-by-zero flaw was found in the seek_to_sector() function of the parallels block driver in QEMU. An attacker able to modify a disk image file loaded by a guest could use this flaw to crash the guest. (CVE-2014-0142) A NULL pointer dereference flaw was found in the QCOW2 block driver in QEMU. An attacker able to modify a disk image file loaded by a guest could use this flaw to crash the guest. (CVE-2014-0146) It was found that the block driver for Hyper-V VHDX images did not correctly calculate BAT (Block Allocation Table) entries due to a missing bounds check. An attacker able to modify a disk image file loaded by a guest could use this flaw to crash the guest. (CVE-2014-0148) The CVE-2014-0143 issues were discovered by Kevin Wolf and Stefan Hajnoczi of Red Hat, the CVE-2014-0144 issues were discovered by Fam Zheng, Jeff Cody, Kevin Wolf, and Stefan Hajnoczi of Red Hat, the CVE-2014-0145 issues were discovered by Stefan Hajnoczi of Red Hat, the CVE-2014-0150 issue was discovered by Michael S. Tsirkin of Red Hat, the CVE-2014-0142, CVE-2014-0146, and CVE-2014-0147 issues were discovered by Kevin Wolf of Red Hat, and the CVE-2014-0148 issue was discovered by Jeff Cody of Red Hat. All users of qemu-kvm-rhev are advised to upgrade to these updated packages, which contain backported patches to correct these issues. After installing this update, shut down all running virtual machines. Once all virtual machines have shut down, start them again for this update to take effect. 4. Solution: Before applying this update, make sure all previously released errata relevant to your system have been applied. This update is available via the Red Hat Network. Details on how to use the Red Hat Network to apply this update are available at https://access.redhat.com/site/articles/11258 5. Bugs fixed (https://bugzilla.redhat.com/) 1078201 - CVE-2014-0142 qemu: crash by possible division by zero 1078212 - CVE-2014-0148 Qemu: vhdx: bounds checking for block_size and logical_sector_size 1078232 - CVE-2014-0146 Qemu: qcow2: NULL dereference in qcow2_open() error path 1078846 - CVE-2014-0150 qemu: virtio-net: buffer overflow in virtio_net_handle_mac() function 1078848 - CVE-2014-0147 Qemu: block: possible crash due signed types or logic error 1078885 - CVE-2014-0145 Qemu: prevent possible buffer overflows 1079140 - CVE-2014-0143 Qemu: block: multiple integer overflow flaws 1079240 - CVE-2014-0144 Qemu: block: missing input validation 6. Package List: RHEV Agents (vdsm): Source: ftp://ftp.redhat.com/pub/redhat/linux/enterprise/6Server/en/RHEV/SRPMS/qemu… x86_64: qemu-img-rhev-0.12.1.2-2.415.el6_5.8.x86_64.rpm qemu-kvm-rhev-0.12.1.2-2.415.el6_5.8.x86_64.rpm qemu-kvm-rhev-debuginfo-0.12.1.2-2.415.el6_5.8.x86_64.rpm qemu-kvm-rhev-tools-0.12.1.2-2.415.el6_5.8.x86_64.rpm These packages are GPG signed by Red Hat for security. Our key and details on how to verify the signature are available from https://access.redhat.com/security/team/key/#package 7. References: https://www.redhat.com/security/data/cve/CVE-2014-0142.html https://www.redhat.com/security/data/cve/CVE-2014-0143.html https://www.redhat.com/security/data/cve/CVE-2014-0144.html https://www.redhat.com/security/data/cve/CVE-2014-0145.html https://www.redhat.com/security/data/cve/CVE-2014-0146.html https://www.redhat.com/security/data/cve/CVE-2014-0147.html https://www.redhat.com/security/data/cve/CVE-2014-0148.html https://www.redhat.com/security/data/cve/CVE-2014-0150.html https://access.redhat.com/security/updates/classification/#moderate 8. Contact: The Red Hat security contact is <secalert(a)redhat.com>. More contact details at https://access.redhat.com/security/team/contact/ Copyright 2014 Red Hat, Inc. -- rhev-watch-list mailing list rhev-watch-list(a)redhat.com https://www.redhat.com/mailman/listinfo/rhev-watch-list

1 0

Re: [ovirt-users] Ovirt + GLUSTER
by Jeremiah Jahn 22 Apr '14

22 Apr '14

Nothing too complicated. SL 6x and 5 8 vm hosts running on a hitachi blade symphony. 25 Server guests 15+ desktop windows guests 3x 12TB storage servers (All 1TB based raid 10 SSDs) 10Gbs PTP between 2 of the servers, with one geolocation server offsite. Most of the server images/luns are exported through 4Gbps FC cards from the servers using LIO except the desktop machines with are attached directly to the gluster storage pool since normal users can create them. Various servers use use the gluster system directly for storing a large number of documents and providing public access to the tune of about 300 to 400 thousand requests per day. We aggregate, provide public access, efiling, e-payments and case management software to most of the illinois circuit court system. Gluster has worked like a champ. On Tue, Apr 22, 2014 at 8:05 AM, Ovirt User <ldrt8789(a)gmail.com> wrote: > what type of configuration and use case ? > > Il giorno 22/apr/2014, alle ore 14:53, Jeremiah Jahn <jeremiah(a)goodinassociates.com> ha scritto: > >> I am. >> >> On Mon, Apr 21, 2014 at 1:50 PM, Joop <jvdwege(a)xs4all.nl> wrote: >>> Ovirt User wrote: >>>> >>>> Hello, >>>> >>>> anyone are using ovirt with glusterFS as storage domain in production >>>> environment ? >>>> >>>> >>> >>> Not directly production but almost. Having problems? >>> >>> Regards, >>> >>> Joop >>> >>> >>> _______________________________________________ >>> Users mailing list >>> Users(a)ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/users >

1 1

Ovirt + GLUSTER
by Ovirt User 22 Apr '14

22 Apr '14

Hello, anyone are using ovirt with glusterFS as storage domain in production environment ? Thanks Lukas

4 3

converting windows guests with v2v, where to put the iso?
by Jeremiah Jahn 22 Apr '14

22 Apr '14

I'm getting the following error. RedHat seems to thin the answer is to use their virtio-win rpm. As far as I can tell, this is not available anywhere, So I've just got to go and get the iso that it installs from kvm.org. Ok, done. now that I have said iso, where the heck do I put it, since it doesn't seem to align with the structure that v2v is looking for. virt-v2v: Installation failed because the following files referenced in the configuration file are required, but missing: /usr/share/virtio-win/drivers/i386/WinXP

5 8

Call for Papers Deadline in One Week: Fossetcon 2014
by Brian Proffitt 22 Apr '14

22 Apr '14

Conference: Fossetcon 2014 Information: Fossetcon relies on the Free and Open Source Software Community for support in making Fossetcon a memorable event that aims to be: The Gateway to the Open Source Community. They are currently seeking talks on virtualization. Date: Sept 11-13, 2014 Location: Orlando, Florida Website: http://fossetcon.org/2014/ Call for Papers Deadline: June 15, 2014 Call for Papers URL: http://fossetcon.org/2014/call-papers-and-registration -- 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

Call for Papers Deadline in Three Weeks: Fossetcon 2014
by Brian Proffitt 22 Apr '14

22 Apr '14

Conference: Fossetcon 2014 Information: Fossetcon relies on the Free and Open Source Software Community for support in making Fossetcon a memorable event that aims to be: The Gateway to the Open Source Community. They are currently seeking talks on virtualization. Date: Sept 11-13, 2014 Location: Orlando, Florida Website: http://fossetcon.org/2014/ Call for Papers Deadline: June 15, 2014 Call for Papers URL: http://fossetcon.org/2014/call-papers-and-registration -- 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

Query for adding non kvm hosts to ovirt engine
by Peter Harris 22 Apr '14

22 Apr '14

I have a small test environment, where I am trying to work out the detail of configuring ovirt + gluster as our main customer support environment. All boxes running Scientific Linux 6.5 and ovirt 3.4 and glusterfs 3.5: mgr1 : ovirt-engine installed and vdsm-gluster vmhost1 : main vm server, added to mgr1 as host vmhost2 : second vm server, add to mgr1 as host strg1 : first gluster storage server strg2 : second gluster storage server mgr1 is an old box, hardware does not support virtualization vmhost1 and vmhost2 have full vt capability strg1 and strg2 hardware does not support virtualization In the past, if I have created a gluster only ovirt-engine install, I have been able to add strg1 and strg2 as hosts. Is there any way I can use mgr1 to manage both vm hosts and storage hosts, and add strg1 and strg2 to mgr1 as hosts. At the moment, I get the following error: 2014-04-22 10:27:37 DEBUG otopi.ovirt_host_deploy.hardware hardware._isVirtualizationEnabled:186 virtualization support GenuineIntel (cpu: False, bios: True) 2014-04-22 10:27:37 DEBUG otopi.ovirt_host_deploy.hardware hardware.detect:202 Hardware supports virtualization 2014-04-22 10:27:37 DEBUG otopi.context context._executeMethod:152 method exception Traceback (most recent call last): File "/tmp/ovirt-2p0fjrQMTb/pythonlib/otopi/context.py", line 142, in _executeMethod method['method']() File "/tmp/ovirt-2p0fjrQMTb/otopi-plugins/ovirt-host-deploy/vdsm/hardware.py", line 68, in _validate_virtualization _('Hardware does not support virtualization') RuntimeError: Hardware does not support virtualization Many thanks

2 1

ovirt-engine install getting failed
by Subhashish Laha 22 Apr '14

22 Apr '14

I am trying to setup Ovirt Engine but getting below error yum -y install ovirt-engine Transaction check error: file /usr/lib/python2.7/site-packages/sos/plugins/postgresql.py conflicts between attempted installs of ovirt-log-collector-3.4.1-1.fc19.noarch and sos- 3.0-23.fc19.noarch file /usr/lib/python2.7/site-packages/sos/plugins/postgresql.pyc conflicts between attempted installs of ovirt-log-collector-3.4.1-1.fc19.noarch and sos- 3.0-23.fc19.noarch file /usr/lib/python2.7/site-packages/sos/plugins/postgresql.pyo conflicts between attempted installs of ovirt-log-collector-3.4.1-1.fc19.noarch and sos- 3.0-23.fc19.noarch Error Summary ------------- [root@localhost ~]#

2 2