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/ >>> >>

I'm running oVirt + Gluster in HCI config and had similar questions as you when building it out. There is no SPOF if you're doing 3x HCI nodes. I regularly put 1 of my 3 Nodes into Maintenance or shutdown Gluster and have had no SPOFs. Are you only doing a single Node? If so, the point of failure is ... that 1 node :) I'm running pfSense in hardware still (a Netgate ARM device). There's plenty of opinions on Reddit, StackOverflow, etc. about running any router in VM. There's several steps you'd need to take when I looked into it, and if you setup pfSense's interfaces as virtio / vhost I'd imagine you'd bump into limitations b/c those para devices weren't intended to do things like hardware offload, advanced routing, etc.; so you may have to setup PCI passthru / SR-IOV to get all of pfSense's routing capabilities. So I'm keeping pfSense in hardware ... though I've thought of creating a backup pfSense instance in VM encase of hardware disaster to keep my Internet up in "limp mode" ... but creating a cellular Hotspot is my current backup plan :) Why? The HE is a manager to the cluster and sits on the management network (ovirtmgmt), so giving it public IPs would be adding a security risk to the setup. I keep my HE accessible only via local VLAN and that's how most folks lock it down. Are you thinking the HE or HCI includes a load balancer? Eitherway, oVirt doesn't, but putting a load balancer in front of VM's and giving it your public IP would make more sense for exposing things to the Internet ... but I'm assuming too much and don't know what your cluster will be running.