sue with the mac address length in IB
> cards. IIRC there was a hardware vendor who was working on a patch to
> extend the length and add the appropriate validation.
>
>
> Dead Horse wrote:
>
> When attempting to activate/add a host with Infiniband cards present:
>
> vdsm.l
the cursor jumps off to
>> one of the edges of my *monitor*, and not into the console window- as
>>
>> you would expect. Maybe virt-viewer mistakenly "thinks" that the edges
>> of it´s window really are the edges of the whole monitor? Am I holding
>> i
I took the liberty of creating a wiki page on how to use EL6 based hosts
with the ovirt-engine.
It can be found here: http://wiki.ovirt.org/wiki/Using_EL6_hosts_with_Ovirt
Feel free to change/edit/contribute or provide feedback.
- DHC
___
Users mailing l
ing loaded
(https://bugzilla.redhat.com/show_bug.cgi?id=832935). Fixed that by
building and installing a newer sanlock where this was fixed.
- DHC
On Sat, Aug 11, 2012 at 4:31 PM, Itamar Heim wrote:
> On 08/10/2012 04:21 PM, Dead Horse wrote:
>
>> When I try adding an EL 6.3 base
Any hints on getting the console button/right click context console
operation to work on ovirt 3.1?
I have installed the remote-viewer package from here:
http://spice-space.org/download/gtk/windows/virt-viewer-0.5.3_x64.exe
I am Using IE 8 under windows 7 as the browser.
My guess here is that the
This is a pure RHEL 6.3 node.
Given that I gather in order to make this work I need to build the newer
vdsm 4.10.x and update/build the other according dependent packages?
- DHC
On Fri, Aug 10, 2012 at 8:23 AM, Andrew Cathrow wrote:
>
> - Original Message -
>
> > Fr
I am not using the dreyou repo. Rather a pure EL 6.3 and it's associated
packages.
- DHC
On Fri, Aug 10, 2012 at 8:07 AM, Robert Middleswarth <
rob...@middleswarth.net> wrote:
> On 08/10/2012 02:02 AM, Dead Horse wrote:
>
> With ovirt 3.1 EL 6.3 nodes will only work with
64-rhel6,model_kvm32,model_coreduo,model_kvm64,model_core2duo,model_n270,model_Conroe,model_Penryn,model_Nehalem,model_Opteron_G1',
'ISCSIInitiatorName': 'iqn.1994-05.com.redhat:decf7eb6ff3f', 'memSize':
'36140', 'reservedMem': '256&#
With ovirt 3.1 EL 6.3 nodes will only work with a data center set to 3.0
compatibility mode. Is there any reason(s) why EL 6.3+ nodes would not be
allowed in a 3.1 compatibility level cluster? This assumes non use of
gluster since adding vdsm-gluster to an EL 6 node requires some work
package updat
Any thoughts here on this, should I file a bug?
Per: http://wiki.ovirt.org/wiki/Second_Release
Working upgrade is one of the release criteria.
I will help in any way possible to get a 3.0 to 3.1 upgrade path working.
- DHC
On Thu, Jul 19, 2012 at 3:40 PM, Dead Horse
wrote:
> If it helps here
_temp_Upgrade_add_job_table();
**
DROP FUNCTION
* QUERY **
insert into
schema_version(version,script,checksum,installed_by,started_at,ended_at,state,current,comment)
values
(trim('03010260'),'upgrade/03_01_0260_add_job_table
ng to run
"/usr/share/ovirt-engine/dbscripts/upgrade.sh".
- DHC
On Thu, Jul 19, 2012 at 7:04 AM, Robert Middleswarth <
rob...@middleswarth.net> wrote:
> On 07/19/2012 04:10 AM, Eli Mesika wrote:
>
>>
>> - Original Message -
>>
>>> From: "Dea
Steps taken:
Load up bare metal or a VM with FC16
Install 3.0 from http://www.ovirt.org/releases/stable/fedora/16/
Setup up something minimal (EG: engine-setup then setup a basic
datacenter/cluster/etc)
Add a FC16 or EL based node for fun as well and some VM's if feeling
ambitious.
Back up databa
Did some further refining and testing on this.
I found that all that needed to be done to create a NAT or private network
for your ovirt guests is (in this example we create a NAT network):
1) Login into your ovirt nodes (all will need to have this created
consistently across them.
2) connect to
I have tried to create a NAT network within ovirt for guests to use via
libvirt/virsh as the vdsm@rhevh on an ovirt node.
Something like this:
virsh # net-info nat
Namenat
UUIDb09d09a8-ebbd-476d-9045-e66012c9e83d
Active: yes
Persistent: yes
Autostart: yes
B
Built and verified that both the latest fedora rawhide qemu and the latest
QEMU from git do not resolve this.
Here: fedora/development/rawhide/source/SRPMS/q/qemu-1.0-15.fc18.src.rpm)
and
Here: http://git.qemu.org/qemu.git
I suspect that unless the patches made to RHEL qemu, mentioned by the qemu
Seeing an issue wherein ovirt moves a managed host to non-operational state.
This occurs with the currently released version of ovirt and the latest
development builds.
The ovirt host is loaded with Fedora core 16 and equipped with most current
development version of the vdsm.
*Editorial node*
The
101 - 117 of 117 matches
Mail list logo
