Re: [ovirt-users] Standalone Gluster Storage
We did use the backup-volfile-servers option but still had trouble. We were simply adding all servers in the cluster as backups, is there a best practice that should be followed? On Tue, Dec 12, 2017 at 8:59 AM, Artem Tambovskiy < artem.tambovs...@gmail.com> wrote: > I did exactly the same mistake with my standalone GlusterFS cluster and > now need to take down all Storage Domains in order to fix this mistake. > Probably, worth to add a few words about this in Installation guide! > > On Tue, Dec 12, 2017 at 4:52 PM, Simone Tiraboschi <stira...@redhat.com> > wrote: > >> >> >> On Mon, Dec 11, 2017 at 8:44 PM, Beau Sapach <bsap...@ualberta.ca> wrote: >> >>> We've been doing some experimenting with gluster, and have built a >>> stand-alone gluster cluster (not managed by oVirt). We've been able to >>> create a storage domain backed by that gluster cluster and run VMs with >>> their disks on that storage. >>> >>> The problem we have is that when we take a gluster node down for >>> updates, maintenance etc. the entire storage domain goes offline in oVirt. >>> Other gluster clients, that is servers connecting directly to the gluster >>> cluster don't seem to notice if one node goes offline. >>> >>> Is anyone else using gluster storage in oVirt that is not managed within >>> oVirt? >>> >> >> Did you set also the backup-volfile-servers mount option? >> >> >>> >>> >>> -- >>> Beau Sapach >>> *System Administrator | Information Technology Services | University of >>> Alberta Libraries* >>> *Phone: 780.492.4181 <(780)%20492-4181> | Email: beau.sap...@ualberta.ca >>> <beau.sap...@ualberta.ca>* >>> >>> >>> ___ >>> 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 > > -- Beau Sapach *System Administrator | Information Technology Services | University of Alberta Libraries* *Phone: 780.492.4181 | Email: beau.sap...@ualberta.ca <beau.sap...@ualberta.ca>* ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
[ovirt-users] Standalone Gluster Storage
We've been doing some experimenting with gluster, and have built a stand-alone gluster cluster (not managed by oVirt). We've been able to create a storage domain backed by that gluster cluster and run VMs with their disks on that storage. The problem we have is that when we take a gluster node down for updates, maintenance etc. the entire storage domain goes offline in oVirt. Other gluster clients, that is servers connecting directly to the gluster cluster don't seem to notice if one node goes offline. Is anyone else using gluster storage in oVirt that is not managed within oVirt? -- Beau Sapach *System Administrator | Information Technology Services | University of Alberta Libraries* *Phone: 780.492.4181 | Email: beau.sap...@ualberta.ca <beau.sap...@ualberta.ca>* ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [ovirt-users] 10Gb Networking with OVN
Yes, we've done some testing. With an oVirt VM running on a host using 10Gb ethernet copying data to a physical machine also using 10Gb ethernet we don't see network utilization exceed 800Mbits or so. A bit of research online yields some experimentation done by others who used SR-IOV to achieve 10Gb from a VM. I'm not sure where the bottleneck is, possibly in the VirtIO driver. Beau On Mon, Dec 11, 2017 at 1:23 AM, Dominik Holler <dhol...@redhat.com> wrote: > Is there an indication that the VMs will not take advantage of 10Gb? > > On Thu, 7 Dec 2017 15:27:25 -0700 > Beau Sapach <bsap...@ualberta.ca> wrote: > > > Hello everyone, > > > > I see here: > > https://www.ovirt.org/blog/2017/09/introducing-ovirt-4.2.0/ that > > version 4.2 will have OVN support. Does anyone know if this will > > allow VMs to take advantage of 10Gb networking without needing SR-IOV? > > > > > > -- Beau Sapach *System Administrator | Information Technology Services | University of Alberta Libraries* *Phone: 780.492.4181 | Email: beau.sap...@ualberta.ca <beau.sap...@ualberta.ca>* ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
[ovirt-users] 10Gb Networking with OVN
Hello everyone, I see here: https://www.ovirt.org/blog/2017/09/introducing-ovirt-4.2.0/ that version 4.2 will have OVN support. Does anyone know if this will allow VMs to take advantage of 10Gb networking without needing SR-IOV? -- Beau Sapach *System Administrator | Information Technology Services | University of Alberta Libraries* *Phone: 780.492.4181 | Email: beau.sap...@ualberta.ca <beau.sap...@ualberta.ca>* ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [ovirt-users] Select As SPM Fails
Hmmm, makes sense, thanks for the info! I'm not enthusiastic about
installing packages outside of the ovirt repos so will probably look into
an upgrade regardless. I noticed that ovirt 4 only lists support for
RHEL/CentOS 7.2, will a situation such as this crop up again eventually as
incremental updates for the OS continue to push it past the supported
version? I've been running oVirt for less than a year now so I'm curious
what to expect.
On Thu, Jan 19, 2017 at 10:42 AM, Michael Watters <michael.watt...@dart.biz>
wrote:
> You can upgrade vdsm without upgrading to ovirt 4. I went through the
> same issue on our cluster a few weeks ago and the process was pretty
> simple.
>
> You'll need to do this on each of your hosts.
>
> yum --enablerepo=extras install -y epel-release git
> git clone https://github.com/oVirt/vdsm.git
> cd vdsm
> git checkout v4.17.35
> yum install -y `cat ./automation/build-artifacts.packages`
> ./automation/build-artifacts.sh
>
> cd /root/rpmbuild/RPMS/noarch
> yum --enablerepo=extras install centos-release-qemu-ev
> yum localinstall vdsm-4.17.35-1.el7.centos.noarch.rpm
> vdsm-hook-vmfex-dev-4.17.35-1.el7.centos.noarch.rpm
> vdsm-infra-4.17.35-1.el7.centos.noarch.rpm
> vdsm-jsonrpc-4.17.35-1.el7.centos.noarch.rpm
> vdsm-python-4.17.35-1.el7.centos.noarch.rpm
> vdsm-xmlrpc-4.17.35-1.el7.centos.noarch.rpm
> vdsm-yajsonrpc-4.17.35-1.el7.centos.noarch.rpm
> vdsm-python-4.17.35-1.el7.centos.noarch.rpm
> vdsm-xmlrpc-4.17.35-1.el7.centos.noarch.rpm vdsm-cli-4.17.35-1.el7.centos.
> noarch.rpm
> systemctl restart vdsmd
>
> The qemu-ev repo is needed to avoid dependency errors.
>
>
> On Thu, 2017-01-19 at 09:16 -0700, Beau Sapach wrote:
> > Uh oh, looks like an upgrade to version 4 is the only option then
> > unless I'm missing something.
> >
> > On Thu, Jan 19, 2017 at 1:36 AM, Pavel Gashev <p...@acronis.com>
> > wrote:
> > > Beau,
> > >
> > > Looks like you have upgraded to CentOS 7.3. Now you have to update
> > > the vdsm package to 4.17.35.
> > >
> > >
> > > From: <users-boun...@ovirt.org> on behalf of Beau Sapach <bsapach@u
> > > alberta.ca>
> > > Date: Wednesday 18 January 2017 at 23:56
> > > To: "users@ovirt.org" <users@ovirt.org>
> > > Subject: [ovirt-users] Select As SPM Fails
> > >
> > > Hello everyone,
> > >
> > > I'm about to start digging through the mailing list archives in
> > > search of a solution but thought I would post to the list as well.
> > > I'm running oVirt 3.6 on a 2 node CentOS7 cluster backed by fiber
> > > channel storage and with a separate engine VM running outside of
> > > the cluster (NOT hosted-engine).
> > >
> > > When I try to move the SPM role from one node to the other I get
> > > the following in the web interface:
> > >
> > >
> > >
> > > When I look into /var/log/ovirt-engine/engine.log I see the
> > > following:
> > >
> > > 2017-01-18 13:35:09,332 ERROR
> > > [org.ovirt.engine.core.vdsbroker.vdsbroker.HSMGetAllTasksStatusesVD
> > > SCommand] (default task-26) [6990cfca] Failed in
> > > 'HSMGetAllTasksStatusesVDS' method
> > > 2017-01-18 13:35:09,340 ERROR
> > > [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirect
> > > or] (default task-26) [6990cfca] Correlation ID: null, Call Stack:
> > > null, Custom Event ID: -1, Message: VDSM v6 command failed: Logical
> > > Volume extend failed
> > >
> > > When I look at the task list on the host currently holding the SPM
> > > role (in this case 'v6'), using: vdsClient -s 0 getAllTasks, I see
> > > a long list like this:
> > >
> > > dc75d3e7-cea7-449b-9a04-76fd8ef0f82b :
> > > verb = downloadImageFromStream
> > > code = 554
> > > state = recovered
> > > tag = spm
> > > result =
> > > message = Logical Volume extend failed
> > > id = dc75d3e7-cea7-449b-9a04-76fd8ef0f82b
> > >
> > > When I look at /var/log/vdsm/vdsm.log on the host in question (v6)
> > > I see messages like this:
> > >
> > > '531dd533-22b1-47a0-aae8-76c1dd7d9a56': {'code': 554, 'tag':
> > > u'spm', 'state': 'recovered', 'verb': 'downloadImageFromStreaam',
> > > 'result': '', 'message': 'Logical Volume extend failed', 'id':
> > > '531dd533-22b1-47a0-aae8-76c1dd7d9a56'}
> > >
> > > As well as the error from the attempted extend of the logical
> > > volume:
>
Re: [ovirt-users] Select As SPM Fails
Uh oh, looks like an upgrade to version 4 is the only option then
unless I'm missing something.
On Thu, Jan 19, 2017 at 1:36 AM, Pavel Gashev <p...@acronis.com> wrote:
> Beau,
>
>
>
> Looks like you have upgraded to CentOS 7.3. Now you have to update the
> vdsm package to 4.17.35.
>
>
>
>
>
> *From: *<users-boun...@ovirt.org> on behalf of Beau Sapach <
> bsap...@ualberta.ca>
> *Date: *Wednesday 18 January 2017 at 23:56
> *To: *"users@ovirt.org" <users@ovirt.org>
> *Subject: *[ovirt-users] Select As SPM Fails
>
>
>
> Hello everyone,
>
>
>
> I'm about to start digging through the mailing list archives in search of
> a solution but thought I would post to the list as well. I'm running oVirt
> 3.6 on a 2 node CentOS7 cluster backed by fiber channel storage and with a
> separate engine VM running outside of the cluster (NOT hosted-engine).
>
>
>
> When I try to move the SPM role from one node to the other I get the
> following in the web interface:
>
>
>
> [image: nline image 1]
>
>
>
> When I look into /var/log/ovirt-engine/engine.log I see the following:
>
>
>
> 2017-01-18 13:35:09,332 ERROR [org.ovirt.engine.core.vdsbroker.vdsbroker.
> HSMGetAllTasksStatusesVDSCommand] (default task-26) [6990cfca] Failed in
> 'HSMGetAllTasksStatusesVDS' method
>
> 2017-01-18 13:35:09,340 ERROR [org.ovirt.engine.core.dal.
> dbbroker.auditloghandling.AuditLogDirector] (default task-26) [6990cfca]
> Correlation ID: null, Call Stack: null, Custom Event ID: -1, Message: VDSM
> v6 command failed: Logical Volume extend failed
>
>
>
> When I look at the task list on the host currently holding the SPM role
> (in this case 'v6'), using: vdsClient -s 0 getAllTasks, I see a long list
> like this:
>
>
>
> dc75d3e7-cea7-449b-9a04-76fd8ef0f82b :
>
> verb = downloadImageFromStream
>
> code = 554
>
> state = recovered
>
> tag = spm
>
> result =
>
> message = Logical Volume extend failed
>
> id = dc75d3e7-cea7-449b-9a04-76fd8ef0f82b
>
>
>
> When I look at /var/log/vdsm/vdsm.log on the host in question (v6) I see
> messages like this:
>
>
>
> '531dd533-22b1-47a0-aae8-76c1dd7d9a56': {'code': 554, 'tag': u'spm',
> 'state': 'recovered', 'verb': 'downloadImageFromStreaam', 'result': '',
> 'message': 'Logical Volume extend failed', 'id': '531dd533-22b1-47a0-aae8-
> 76c1dd7d9a56'}
>
>
>
> As well as the error from the attempted extend of the logical volume:
>
>
>
> e980df5f-d068-4c84-8aa7-9ce792690562::ERROR::2017-01-18
> 13:24:50,710::task::866::Storage.TaskManager.Task::(_setError)
> Task=`e980df5f-d068-4c84-8aa7-9ce792690562`::Unexpected error
>
> Traceback (most recent call last):
>
> File "/usr/share/vdsm/storage/task.py", line 873, in _run
>
> return fn(*args, **kargs)
>
> File "/usr/share/vdsm/storage/task.py", line 332, in run
>
> return self.cmd(*self.argslist, **self.argsdict)
>
> File "/usr/share/vdsm/storage/securable.py", line 77, in wrapper
>
> return method(self, *args, **kwargs)
>
> File "/usr/share/vdsm/storage/sp.py", line 1776, in
> downloadImageFromStream
>
> .copyToImage(methodArgs, sdUUID, imgUUID, volUUID)
>
> File "/usr/share/vdsm/storage/image.py", line 1373, in copyToImage
>
> / volume.BLOCK_SIZE)
>
> File "/usr/share/vdsm/storage/blockVolume.py", line 310, in extend
>
> lvm.extendLV(self.sdUUID, self.volUUID, sizemb)
>
> File "/usr/share/vdsm/storage/lvm.py", line 1179, in extendLV
>
> _resizeLV("lvextend", vgName, lvName, size)
>
> File "/usr/share/vdsm/storage/lvm.py", line 1175, in _resizeLV
>
> raise se.LogicalVolumeExtendError(vgName, lvName, "%sM" % (size, ))
>
> LogicalVolumeExtendError:
>
> Logical Volume extend failed: 'vgname=ae05947f-875c-4507-ad51-62b0d35ef567
> lvname=caaef597-eddd-4c24-8df2-a61f35f744f8 newsize=1M'
>
> e980df5f-d068-4c84-8aa7-9ce792690562::DEBUG::2017-01-18
> 13:24:50,711::task::885::Storage.TaskManager.Task::(_run)
> Task=`e980df5f-d068-4c84-8aa7-9ce792690562`::Task._run:
> e980df5f-d068-4c84-8aa7-9ce792690562 () {} failed - stopping task
>
>
>
> The logical volume in question is an OVF_STORE disk that lives on one of
> the fiber channel backed LUNs. If I run:
>
>
>
> vdsClient -s 0 ClearTask TASK-UUID-HERE
>
>
>
> for each task that appears in the:
>
>
>
> vdsClient -s 0 getAllTasks
>
>
>
> output then they disappear and I'm able to move the SPM role to the other
> host.
>
>
>
> This problem then crops up again on the new host once the SPM role is
> moved. What's going on here? Does anyone have any insight as to how to
> prevent this task from re-appearing? Or why it's failing in the first
> place?
>
>
>
> Beau
>
>
>
>
>
>
>
--
Beau Sapach
*System Administrator | Information Technology Services | University of
Alberta Libraries*
*Phone: 780.492.4181 | Email: beau.sap...@ualberta.ca
<beau.sap...@ualberta.ca>*
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
[ovirt-users] Select As SPM Fails
Hello everyone,
I'm about to start digging through the mailing list archives in search of a
solution but thought I would post to the list as well. I'm running oVirt
3.6 on a 2 node CentOS7 cluster backed by fiber channel storage and with a
separate engine VM running outside of the cluster (NOT hosted-engine).
When I try to move the SPM role from one node to the other I get the
following in the web interface:
[image: Inline image 1]
When I look into /var/log/ovirt-engine/engine.log I see the following:
2017-01-18 13:35:09,332 ERROR
[org.ovirt.engine.core.vdsbroker.vdsbroker.HSMGetAllTasksStatusesVDSCommand]
(default task-26) [6990cfca] Failed in 'HSMGetAllTasksStatusesVDS' method
2017-01-18 13:35:09,340 ERROR
[org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
(default task-26) [6990cfca] Correlation ID: null, Call Stack: null, Custom
Event ID: -1, Message: VDSM v6 command failed: Logical Volume extend failed
When I look at the task list on the host currently holding the SPM role (in
this case 'v6'), using: vdsClient -s 0 getAllTasks, I see a long list like
this:
dc75d3e7-cea7-449b-9a04-76fd8ef0f82b :
verb = downloadImageFromStream
code = 554
state = recovered
tag = spm
result =
message = Logical Volume extend failed
id = dc75d3e7-cea7-449b-9a04-76fd8ef0f82b
When I look at /var/log/vdsm/vdsm.log on the host in question (v6) I see
messages like this:
'531dd533-22b1-47a0-aae8-76c1dd7d9a56': {'code': 554, 'tag': u'spm',
'state': 'recovered', 'verb': 'downloadImageFromStreaam', 'result': '',
'message': 'Logical Volume extend failed', 'id':
'531dd533-22b1-47a0-aae8-76c1dd7d9a56'}
As well as the error from the attempted extend of the logical volume:
e980df5f-d068-4c84-8aa7-9ce792690562::ERROR::2017-01-18
13:24:50,710::task::866::Storage.TaskManager.Task::(_setError)
Task=`e980df5f-d068-4c84-8aa7-9ce792690562`::Unexpected error
Traceback (most recent call last):
File "/usr/share/vdsm/storage/task.py", line 873, in _run
return fn(*args, **kargs)
File "/usr/share/vdsm/storage/task.py", line 332, in run
return self.cmd(*self.argslist, **self.argsdict)
File "/usr/share/vdsm/storage/securable.py", line 77, in wrapper
return method(self, *args, **kwargs)
File "/usr/share/vdsm/storage/sp.py", line 1776, in
downloadImageFromStream
.copyToImage(methodArgs, sdUUID, imgUUID, volUUID)
File "/usr/share/vdsm/storage/image.py", line 1373, in copyToImage
/ volume.BLOCK_SIZE)
File "/usr/share/vdsm/storage/blockVolume.py", line 310, in extend
lvm.extendLV(self.sdUUID, self.volUUID, sizemb)
File "/usr/share/vdsm/storage/lvm.py", line 1179, in extendLV
_resizeLV("lvextend", vgName, lvName, size)
File "/usr/share/vdsm/storage/lvm.py", line 1175, in _resizeLV
raise se.LogicalVolumeExtendError(vgName, lvName, "%sM" % (size, ))
LogicalVolumeExtendError:
Logical Volume extend failed: 'vgname=ae05947f-875c-4507-ad51-62b0d35ef567
lvname=caaef597-eddd-4c24-8df2-a61f35f744f8 newsize=1M'
e980df5f-d068-4c84-8aa7-9ce792690562::DEBUG::2017-01-18
13:24:50,711::task::885::Storage.TaskManager.Task::(_run)
Task=`e980df5f-d068-4c84-8aa7-9ce792690562`::Task._run:
e980df5f-d068-4c84-8aa7-9ce792690562 () {} failed - stopping task
The logical volume in question is an OVF_STORE disk that lives on one of
the fiber channel backed LUNs. If I run:
vdsClient -s 0 ClearTask TASK-UUID-HERE
for each task that appears in the:
vdsClient -s 0 getAllTasks
output then they disappear and I'm able to move the SPM role to the other
host.
This problem then crops up again on the new host once the SPM role is
moved. What's going on here? Does anyone have any insight as to how to
prevent this task from re-appearing? Or why it's failing in the first
place?
Beau
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
