Regarding Gluster question. The volumes would be provisioned with LVM on the same block device. I believe 100Gb is recommended for the engine volume. The other volumes such as data would be created on another logical volume and you can use up the rest of the available space there. Ex. 100gb engine, 500Gb data and 400Gb vmstore. Data domains are basically the same now, in the past there used to be different domain types such as ISO domains which are deprecated. You don't really need any more than engine volume and data volume. You could have a volume for storing ISOs if you wanted to. You could have a separate volume for OS disks and another volume for data disks which would give you more flexibility for backups (so that you could backup data disks but not OS for example). On Fri, May 29, 2020 at 10:29 AM Jiří Sléžka <jiri.slezka(a)slu.cz&gt; wrote:

Last time I used oVirt to deploy my gluster, cockpit was using thick LVs instead of thin LVM. I think that thin LVM is way more suitable for the task. Then you can set the size to anything needed. Best Regards, Strahil Nikolov На 29 май 2020 г. 18:27:59 GMT+03:00, Jayme <jaymef(a)gmail.com&gt; написа: >Also, I can't think of the limit off the top of my head. I believe it's >either 75 or 100Gb. If the engine volume is set any lower the >installation >will fail. There is a minimum size requirement. > >On Fri, May 29, 2020 at 12:09 PM Jayme <jaymef(a)gmail.com&gt; wrote: > >> Regarding Gluster question. The volumes would be provisioned with LVM >on >> the same block device. I believe 100Gb is recommended for the engine >> volume. The other volumes such as data would be created on another >logical >> volume and you can use up the rest of the available space there. Ex. >100gb >> engine, 500Gb data and 400Gb vmstore. >> >> Data domains are basically the same now, in the past there used to be >> different domain types such as ISO domains which are deprecated. You >don't >> really need any more than engine volume and data volume. You could >have a >> volume for storing ISOs if you wanted to. You could have a separate >volume >> for OS disks and another volume for data disks which would give you >more >> flexibility for backups (so that you could backup data disks but not >OS for >> example). >> >> On Fri, May 29, 2020 at 10:29 AM Jiří Sléžka <jiri.slezka(a)slu.cz&gt; >wrote: >> >>> Hello, >>> >>> I am just curious if basic gluster HCI layout which is suggested in >>> cockpit has some deeper meaning. >>> >>> There are suggested 3 volumes >>> >>> * engine - it is clear, it is the volume where engine vm is running. >>> When this vm is 51GB big how small could this volume be? I have 1TB >SSD >>> storage and I would like utilize it as much as possible. Could I >create >>> this volume as small as this vm is? Is it safe for example for >future >>> upgrades? >>> >>> * vmstore - it make sense it is a space for all other vms running in >>> oVirt. Right? >>> >>> * data - which purpose has this volume? other data like for example >>> ISOs? Direct disks? >>> >>> Another infra question... or maybe request for comment >>> >>> I have small amount of public ipv4 addresses in my housing (but I >have >>> own switches there so I can create vlans and separate internal >traffic). >>> I can access only these public ipv4 addresses directly. I would like >to >>> conserve these addressess as much as possible so what is the best >>> approach in your opinion? >>> >>> * Install all hosts and HE with management network on private >addressess >>> >>> * have small router (hw appliance with for example LEDE) which >will >>> utilize one ipv4 address and will do NAT and vpn for accessing my >>> internals vlans. >>> + looks like simple approach to me >>> - single point of failure in this router (not really - just in >case >>> oVirt is badly broken and I need to access internal vlans to recover >it) >>> >>> * have this router as virtual appliance inside oVirt (something >like >>> pfSense for example) >>> + no need hw router >>> + not sure but I could probably configure vrrp redundancy >>> - still single point of failure like in first case >>> >>> * any other approach? Could ovn help here somehow? >>> >>> * Install all hosts and HE with public addresses :-) >>> + access to all hosts directly >>> - 3 node HCI cluster uses 4 public ip addressess >>> >>> Thanks for your opinions >>> >>> Cheers, >>> >>> Jiri >>> >>> _______________________________________________ >>> Users mailing list -- users(a)ovirt.org >>> To unsubscribe send an email to users-leave(a)ovirt.org >>> Privacy Statement: https://www.ovirt.org/privacy-policy.html >>> oVirt Code of Conduct: >>> https://www.ovirt.org/community/about/community-guidelines/ >>> List Archives: >>> >https://lists.ovirt.org/archives/list/users@ovirt.org/message/LIFQQHTFVTS6KICR5MTRPGO5CH7QDLK7/ >>> >>

On 5/29/20 5:27 PM, Jayme wrote: thanks for reply. Meantime I was looking into RHV 4.4 beta docs and the limit is mentioned there Minimum Total - 55 GB https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.4-... but oVirt HE vm is created with 51GB disk as Strahil mentioned in other post in this thread cockpit/ansible deploys engine lv for gluster brick as thick volume. Data and vmstore is deployed as thin volume. I will probably use default 100GB thick volume... (and only one other volume for vms on ssd disk) Cheers, Jiri