Hi,
Is it possible to force ovirt 3.6.x to use qcow compat 1.1 insted of 0.10?
Regards
enax
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
Hi guys,
I'm trying to servers to a new oVirt 4.0 cluster. I've upgraded the
engine (not hosted, standalone) to version 4.0.6.3 and run engine-setup
and everything seemed to go fine.
When reinstalling oVirt on a host after removing it from the 3.6 compat
cluster into a 4.0 compat cluster causes
it wasn't the cluster compatibility that I missed, but
that the data center compatibility level needed to be updated to 3.6 as
well. I just didn't read the error message closely enough.
RS> So the upgrade failed, but the 4.0 rpms were installed, so the engine won't
RS> start. How can I fix t
Hi,
It has been introduced in the following patch :
https://gerrit.ovirt.org/#/c/56522/
Thanks,
Fred
On Tue, May 10, 2016 at 11:24 AM, Dobó László <laszlo.d...@ezit.hu> wrote:
> Hi,
>
> Is it possible to force ovirt 3.6.x to use qcow compat 1.1 insted of 0.10?
>
again
Activate Export and ISO domains as required.
(From https://access.redhat.com/solutions/2332581 )
And I also tried to search mail-archive.com for past Email but didn't find
anything matching this particular issue.
https://www.mail-archive.com/search?l=users%40ovirt.org=3.6+compat=0=0
hat.com/solutions/2332581 )
>
> And I also tried to search mail-archive.com for past Email but didn't
> find anything matching this particular issue.
>
> https://www.mail-archive.com/search?l=users%40ovirt.org=
> 3.6+compat=0=0
> https://www.mail-archive.com/search?l=users%40
Hello,
I'm trying to upgrade to 4.0 from 3.6. I dutify checked that my clusters
were set to 3.6 compatibility and started the engine upgrade. unfortunately
I forgot to check the unused Default cluser. :-/
So the upgrade failed, but the 4.0 rpms were installed, so the engine won't
start. How can
lling oVirt on a host after removing it from the 3.6 compat
> cluster into a 4.0 compat cluster causes issues when reinstalling and
> setting up the management network for some reason. I haven't been able
> to track this issue down fully yet.
>
> Whats weird is that even wh
closely enough.
>
> RS> So the upgrade failed, but the 4.0 rpms were installed, so the engine
> won't
> RS> start. How can I fix the compat level (or delete Default cluster)?
>
> For the record, I ended up using 'yum history' to roll back the updated
> packages, and was then ab
gt; wrote:
> > Hi guys,
> >
> > I'm trying to servers to a new oVirt 4.0 cluster. I've upgraded the
> > engine (not hosted, standalone) to version 4.0.6.3 and run engine-setup
> > and everything seemed to go fine.
> >
> > When reinstalling oVirt on a hos
st
Email but didn't find anything matching this particular issue.
https://www.mail-archive.com/search?l=users%40ovirt.org=3.6+compat=0=0
https://www.mail-archive.com/search?l=users%40ovirt.org=ovirt+Data+center+compat=0=0
So has anyone found another way to fix this problem e.g. does the ovirt DB need
gt; self-signed), and I imported the combined certificate into the
> /etc/pki/ovirt-engine/.truststore key file. Not sure if related, but
> just in case.
>
> I had to downgrade to 3.6.7. I'm attaching requested logs, if you need
> anything else don't hesitate to ask.
FYI I mig
g that we're using our own SSL certificates (not
> > self-signed), and I imported the combined certificate into the
> > /etc/pki/ovirt-engine/.truststore key file. Not sure if related, but
> > just in case.
> >
> > I had to downgrade to 3.6.7. I'm attaching requested logs, i
[+gluster-users]
Any known compat issues with gluster 3.7.8-1.el7 client packages and
glusterfs 3.7.6-1.el7 server?
On 02/17/2016 04:33 PM, Matteo wrote:
Hi,
today I update one node os, in the updates gluster client
packages where upgraded from 3.7.6-1.el7, centos-ovirt36 repository
Seems that the "info" command is broken.
the status command for example seems to work ok.
Matteo
- Il 17-feb-16, alle 14:15, Sahina Bose sab...@redhat.com ha scritto:
> [+gluster-users]
>
> Any known compat issues with gluster 3.7.8-1.el7 client packages and
> gluste
ke sure state is clean and stable (no running/pending storage
>> actions,
>> no VMs in the middle of migration etc), all clusters are compat level 3.6,
>> etc.
>> 2. Move to global maintenance
>> 3. backup the engine using engine-backup and keep the backup elsewhere
>>
upgrades every 3-6 months or so.
That’s why we do not really require it and still support 3.6 cluster compat
in 4.2, so that does give you longer time to update. And even the cluster
upgrades are rolling, we do not require any real downtime other than for
rebooting individual VMs and some
>
>> [+gluster-users]
>>
>> Any known compat issues with gluster 3.7.8-1.el7 client packages and
>> glusterfs 3.7.6-1.el7 server?
>>
There might be some new information that 3.7.8 CLI expects, but I'd
need to check to verify what it is. We don't really test the
don’t really know
> what’s required for HE to change its cluster
>
>
We need a fix for the engine to allow migrating HE 3.6 to 4.0 and upgarfde
of that cluster compat level - If we want to upgrade the HE cluster version
the HE-VM itself must move away to a new cluster. Migrating to
, but
> > just in case.
> >
> > I had to downgrade to 3.6.7. I'm attaching requested logs, if you need
> > anything else don't hesitate to ask.
>
>
> FYI I migrated my 3.6 env (engine + 1 host) to 4.0 and the host is up
> and running fine on datacenter/cluster 4.0 compat l
; >> AFAIK 4.0 engine can import 3.6 storage domains without problem.
> >> >> >>
> >> >> >> > - Do I first need another master storage domain or can I
> directly
> >> >> >> > import
> >> >> >> > my
> >
storage domain what is the risk it fails ( I
>> >> >> > have
>> >> >> > backups, but it would cost a day to restore all )
>> >> >>
>> >> >> No idea, but IIRC we got many successful reports and at mo
t.com ha scritto:
[+gluster-users]
Any known compat issues with gluster 3.7.8-1.el7 client packages and
glusterfs 3.7.6-1.el7 server?
There might be some new information that 3.7.8 CLI expects, but I'd
need to check to verify what it is. We don't really test the Gluster
CLI for backwards compatibili
? Or should I install same hosted-engine version?
> >> >> >>
> >> >> >> AFAIK 4.0 engine can import 3.6 storage domains without problem.
> >> >> >>
> >> >> >> > - Do I first need another master storage domain or can I
> di
We found if we move the rebuilt host to a new cluster setup for 4.1
compatibility it could startup VMs just fine.
So we are guessing its just a 3.6 compat mode issue.
I'll try upgrading the rest of the nodes to 4.1 and change compat mode.
Hopefully all will just work then.
We'll see this weekend
;> Again no idea. Perhaps do some test?
> >> >>
> >> >> >
> >> >> > Another option would be upgrade the OS ( with redhat-upgrade-tool )
> >> >> > or
> >> >> > is
> >> >> > this a path for disas
so we decided to not support it. If you decide
>> >> to
>> >> try,
>> >> make sure you test carefully beforehand. From ovirt's POV:
>> >> 1. You'll need to handle postgresql upgrade.
>> >> 2. Right after OS upgrade, you'll still have (I think
d-engine
>> > up to
>> > el7 and run oVirt 4.
>>
>> We are working on a tool/wizard to help with this process. It used to
>> work,
>> but at some point it was decided that one of the actions it does is risky
>> and was blocked, thus the tool is broken curr
ing: 'hosted-engine --upgrade-appliance'.
> As noted above, this is currently broken.
>
> There are several open bugs about it, e.g.:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1319457
> https://bugzilla.redhat.com/show_bug.cgi?id=1343425
> https://bugzilla.redhat.com/show_bug.cg
how_bug.cgi?id=1343425
https://bugzilla.redhat.com/show_bug.cgi?id=1343593 (closed, this is
what broke the tool)
Basically, you can manually do what the tool is supposed to do:
1. Make sure state is clean and stable (no running/pending storage actions,
no VMs in the middle of migration etc), all clus
Auftrag von
>> Clint Boggio [cl...@theboggios.com]
>> Gesendet: Montag, 18. April 2016 14:16
>> An: users@ovirt.org
>> Betreff: [ovirt-users] Disks Illegal State
>>
>> OVirt 3.6, 4 node cluster with dedicated engine. Main storage domain is
>> iscsi, ISO and Ex
> > An: users@ovirt.org
> > Betreff: [ovirt-users] Disks Illegal State
> >
> > OVirt 3.6, 4 node cluster with dedicated engine. Main storage
> > domain is iscsi, ISO and Export domains are NFS.
> >
> > Several of my VM snapshot disks show to be in an "illeg
rt.org [users-boun...@ovirt.org] im
> Auftrag von Clint Boggio [cl...@theboggios.com]
> >> Gesendet: Montag, 18. April 2016 14:16
> >> An: users@ovirt.org
> >> Betreff: [ovirt-users] Disks Illegal State
> >>
> >> OVirt 3.6, 4 node cluster with dedicated e
> Von: users-boun...@ovirt.org [users-boun...@ovirt.org] im Auftrag von
> Clint Boggio [cl...@theboggios.com]
> Gesendet: Montag, 18. April 2016 14:16
> An: users@ovirt.org
> Betreff: [ovirt-users] Disks Illegal State
>
> OVirt 3.6, 4 node cluster with dedicated engine
risky
>> and was blocked, thus the tool is broken currently.
>>
>> You can invoke the tool by running: 'hosted-engine --upgrade-appliance'.
>> As noted above, this is currently broken.
>>
>> There are several open bugs about it, e.g.:
>>
>> https://bugzilla.re
ade fails, rollback will most likely not work,
> >> so you'll have to manually handle this - take a full vm backup and make
> >> sure you can restore it.
> >>
> >> >
> >> > I hope someone can tell me how I can smoothly upgrade my hosted-engine
&g
ork for us well, so we decided to not support it. If you decide
>> >> to
>> >> try,
>> >> make sure you test carefully beforehand. From ovirt's POV:
>> >> 1. You'll need to handle postgresql upgrade.
>> >> 2. Right after OS upgrade, you'll st
t test this.
> >> 3. Specifically, if upgrade fails, rollback will most likely not work,
> >> so you'll have to manually handle this - take a full vm backup and make
> >> sure you can restore it.
> >>
> >> >
> >> > I hope someone can
5a4b789318/2782e797-e49a-4364-99d7-d7544a42e939
> lvchange -ay
> 6c77adb1-74fc-4fa9-a0ac-3b5a4b789318/4bc34865-64b8-4a6c-b2d0-0aaab3f2aa12
>
> # Find the top volume by running qemu-img info on all the lvs
>
> # qemu-img info
> /dev/6c77adb1-74fc-4fa9-a0ac-3b5a4b789318/2782e797-e49a-
Greetings.
We are in the process of migrating from oVirt 3.6 to 4.0. To properly
test 4.0 we have setup a parallel 4.0 environment.
For the non critical vm:s we thought we try the "export vms --> move
storage domain to the other DC --> import vms" method.
While many import
40 matches
Mail list logo
