7:16 a.m.
Hello all.
When you use oVirt with a Block Storage the only option available to
store de VMs is LVM.
Does LVM in oVirt use Thinprovisoned (supported in LVM2) instead of
having to use the SAN Thinprovisioned features ?
Fernando
8:15 a.m.
On 9 August 2016 at 15:16, Fernando Frediani
<fernando.frediani(a)upx.com.br> wrote:
Hello all.
When you use oVirt with a Block Storage the only option available to store
de VMs is LVM.
Does LVM in oVirt use Thinprovisoned (supported in LVM2) instead of having
to use the SAN Thinprovisioned features ?
You can set the disk format to COW. I will effectively be thin-provisioned.
I do this from the API, not sure if you can get the UI to do it.
--
Barak Korren
bkorren(a)redhat.com
RHEV-CI Team
10:54 a.m.
On Tue, Aug 9, 2016 at 3:16 PM, Fernando Frediani
<fernando.frediani(a)upx.com.br> wrote:
Hello all.
When you use oVirt with a Block Storage the only option available to store
de VMs is LVM.
Does LVM in oVirt use Thinprovisoned (supported in LVM2) instead of having
to use the SAN Thinprovisioned features ?
No, we use regular lvs. thin pool are not supported in a cluster.
Using thin provisioned LUN for ovirt storage domain is the best option
(supported
since 4.0). We discard removed lvs, so you get back the storage on the storage
server and can use it for other thin provisioned LUNs.
Nir
12:27 p.m.
Really ? That's pretty bad and another downside unfortunately.
The fact that the only option for block storage is LVM (so there is not
suitable Clustered Filesystem to run QCOW2 files) and now that LVM2
Thinprovisioned is not supported can be a real issue where
Thinprovisioned LUNs are not available in the Storage Controller.
Have these topics ever came up in the feature/product management
meetings are any of them something being considered ?
The same way CPU and Memory overprovision are key features in order to
justify the overall solution cost Storage Thinprovision equally
necessary otherwise the Storage stuff end up costing more than half of
whole platform solution.
Thanks for the answer anyway. Hopefully at least LVM2 Thinprovisioning
comes up anytime soon.
Fernando
Em 11/08/2016 12:54, Nir Soffer escreveu:
On Tue, Aug 9, 2016 at 3:16 PM, Fernando Frediani
<fernando.frediani(a)upx.com.br> wrote:
> Hello all.
>
> When you use oVirt with a Block Storage the only option available to store
> de VMs is LVM.
>
> Does LVM in oVirt use Thinprovisoned (supported in LVM2) instead of having
> to use the SAN Thinprovisioned features ?
No, we use regular lvs. thin pool are not supported in a cluster.
Using thin provisioned LUN for ovirt storage domain is the best option
(supported
since 4.0). We discard removed lvs, so you get back the storage on the storage
server and can use it for other thin provisioned LUNs.
Nir
12:43 p.m.
Once upon a time, Fernando Frediani <fernando.frediani(a)upx.com.br> said:
Thanks for the answer anyway. Hopefully at least LVM2
Thinprovisioning comes up anytime soon.
This has nothing to do with oVirt; it is something the core Linux LVM
code does not support. Last time I looked, nobody was working on it
upstream.
You can still thin-provision VMs in oVirt, there's just not a way to
release space if a VM image shrinks significantly.
--
Chris Adams <cma(a)cmadams.net>
12:47 p.m.
I use LVM2 and Thinprovisioned LVs to put Filesystems and it works with
no issues. It's just a question of handling it correctly to tell it how
to create each storage chunk that way. The same way those LVs can be
used to run VMs as they are in traditional LVM.
Not sure what you mean by cote Linux not supporting it.
Fernando
Em 11/08/2016 14:43, Chris Adams escreveu:
Once upon a time, Fernando Frediani
<fernando.frediani(a)upx.com.br> said:
> Thanks for the answer anyway. Hopefully at least LVM2
> Thinprovisioning comes up anytime soon.
This has nothing to do with oVirt; it is something the core Linux LVM
code does not support. Last time I looked, nobody was working on it
upstream.
You can still thin-provision VMs in oVirt, there's just not a way to
release space if a VM image shrinks significantly.
1:12 p.m.
Once upon a time, Fernando Frediani <fernando.frediani(a)upx.com.br> said:
I use LVM2 and Thinprovisioned LVs to put Filesystems and it works
with no issues. It's just a question of handling it correctly to
tell it how to create each storage chunk that way. The same way
those LVs can be used to run VMs as they are in traditional LVM.
Not sure what you mean by cote Linux not supporting it.
To do that with multiple access, you have to be running in clustered LVM
mode, and thin provisioning is not supported with CLVM.
--
Chris Adams <cma(a)cmadams.net>
1:26 p.m.
Ok Chris, got what you mean.
Thanks for clarifying.
Fernando
Em 11/08/2016 15:12, Chris Adams escreveu:
Once upon a time, Fernando Frediani
<fernando.frediani(a)upx.com.br> said:
> I use LVM2 and Thinprovisioned LVs to put Filesystems and it works
> with no issues. It's just a question of handling it correctly to
> tell it how to create each storage chunk that way. The same way
> those LVs can be used to run VMs as they are in traditional LVM.
>
> Not sure what you mean by cote Linux not supporting it.
To do that with multiple access, you have to be running in clustered LVM
mode, and thin provisioning is not supported with CLVM.
10:34 a.m.
On Thu, Aug 11, 2016 at 8:27 PM, Fernando Frediani <
fernando.frediani(a)upx.com.br> wrote:
Really ? That's pretty bad and another downside unfortunately.
The fact that the only option for block storage is LVM (so there is not
suitable Clustered Filesystem to run QCOW2 files) and now that LVM2
Thinprovisioned is not supported can be a real issue where Thinprovisioned
LUNs are not available in the Storage Controller.
I think you are missing the design of the oVirt storage sub-system. There
is no need to running a clustered filesystem - oVirt ensures only one host
access a logical volume (disk) at any given time.
I don't see exactly how LVM2 thin provisioning would have helped if the
storage controller does not support thin provisioning - if you give 1TB to
oVirt, why does it matter if it uses LVM TP or not? (and we can use qcow2
over LVM). Perhaps I'm missing something here.
Note that you can provision some LUN and when needed, just add more LUNs to
the storage domain. You can also extend it, of course.
Have these topics ever came up in the feature/product management
meetings
are any of them something being considered ?
The same way CPU and Memory overprovision are key features in order to
justify the overall solution cost Storage Thinprovision equally necessary
otherwise the Storage stuff end up costing more than half of whole platform
solution.
Thanks for the answer anyway. Hopefully at least LVM2 Thinprovisioning
comes up anytime soon.
Don't think so. Why? As a replacement of qcow2? Not sure it's worth the
effort (you'll also need to get snapshots and all under LVM2 - what is the
clear benefit here?).
Y.
Fernando
Em 11/08/2016 12:54, Nir Soffer escreveu:
> On Tue, Aug 9, 2016 at 3:16 PM, Fernando Frediani
> <fernando.frediani(a)upx.com.br> wrote:
>
>> Hello all.
>>
>> When you use oVirt with a Block Storage the only option available to
>> store
>> de VMs is LVM.
>>
>> Does LVM in oVirt use Thinprovisoned (supported in LVM2) instead of
>> having
>> to use the SAN Thinprovisioned features ?
>>
> No, we use regular lvs. thin pool are not supported in a cluster.
>
> Using thin provisioned LUN for ovirt storage domain is the best option
> (supported
> since 4.0). We discard removed lvs, so you get back the storage on the
> storage
> server and can use it for other thin provisioned LUNs.
>
> Nir
>
_______________________________________________
Users mailing list
Users(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
2829
days inactive
2834
days old
8 comments
5 participants
participants (5)
-
Barak Korren -
Chris Adams -
Fernando Frediani -
Nir Soffer -
Yaniv Kaul