OpenNebula Front End High Availability<\/a>, this is a YouTube video showing exactly how to create a cluster for OpenNebula.<\/p>\n\n\n\nIn our case, we will use 10.229.128.250 as the VIP of the cluster.<\/p>\n\n\n\n
You should be able to connect to the VIP and run Sunstone.<\/p>\n\n\n\n
Via cli you should see the following:<\/p>\n\n\n\n
[root@onepoc ~]# onezone show 0
ZONE 0 INFORMATION
ID : 0
NAME : OpenNebula
STATE : ENABLED
ZONE SERVERS
ID NAME ENDPOINT
0 10.229.128.231 http:\/\/10.229.128.231:2633\/RPC2
1 10.229.128.232 http:\/\/10.229.128.232:2633\/RPC2
2 10.229.128.233 http:\/\/10.229.128.233:2633\/RPC2
HA & FEDERATION SYNC STATUS
ID NAME STATE TERM INDEX COMMIT VOTE FED_INDEX
0 10.229.128.231 leader 244 16355 16355 0 -1
1 10.229.128.232 follower 244 16355 16355 0 -1
2 10.229.128.233 follower 244 16355 16355 -1 -1
ZONE TEMPLATE
ENDPOINT=\"http:\/\/localhost:2633\/RPC2\"
ENDPOINT_GRPC=\"localhost:2634\"<\/pre>\n\n\n\nYou can see that the cluster zone 0, hast three members.<\/p>\n\n\n\n
Member with ID 0 is the (10.229.128.231) is the leader. It you look at the network issuing “ip add”, you will see:<\/p>\n\n\n\n
ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link\/ether 00:50:01:00:01:00 brd ff:ff:ff:ff:ff:ff
altname enp0s3
inet 10.229.128.231\/24 brd 10.229.128.255 scope global noprefixroute ens3
valid_lft forever preferred_lft forever
inet 10.229.128.230\/24 scope global secondary ens3
valid_lft forever preferred_lft forever
inet6 fe80::250:1ff:fe00:100\/64 scope link noprefixroute
valid_lft forever preferred_lft forever<\/pre>\n\n\n\nNotice that in addition of having .231, it has IP .230 which is the VIP.<\/p>\n\n\n\n
I recommend that you play with this by shutting a node, the cluster will move the VIP and you should be able to reach the cluster and manage it.<\/p>\n\n\n\n
Interestingly enough, Sunstone does not give you the detail information you get by using the command line.<\/p>\n\n\n\n
Now that you have a cluster you need to add NFS. Once again this step is well known so I will not go into much detail.<\/p>\n\n\n\n
You need to install the NFS server packages on all member of the cluster and configure your fstab file so the shares are mount automatically.<\/p>\n\n\n\n
Here I run into issues, using Ubuntu NFS shares get mount during boot.<\/p>\n\n\n\n
With Alma linux this was not the case, spent a whole afternoon troubleshooting could not make it work, thus I added the “mount -a” on “rc.local” to make sure the shares are available.<\/p>\n\n\n\n
If you got everything right you should see:<\/p>\n\n\n\n
[root@onepoc ~]# onedatastore list
ID NAME SIZE AVA CLUSTERS IMAGES TYPE DS TM STAT
109 NFS-SYSTEM 60.8G 61% 0 0 sys - shared on
108 NFS-IMAGE 60.8G 61% 0 2 img fs shared on
107 NFS-FILE 60.8G 61% 0 0 fil fs shared on
2 files 14.6G 98% 0 0 fil fs local on
1 default 14.6G 98% 0 2 img fs local on
0 system - - 0 0 sys - local on<\/pre>\n\n\n\n Now to something that is not well documented in my opinion.<\/p>\n\n\n\n
As I already mentioned, the ISO runs ansible playbooks to automate the configuration.<\/p>\n\n\n\n
This carries a problem, if you add two more controllers, or use the “onefemenu” to add an interface for example, ansible will clover you BGP configuration.<\/p>\n\n\n\n
That is the reason we configure BGP directly after we have three nodes, we make sure the setup works then we copy it to a backup file and finally restore it as mentioned previusly on the rc.local files.<\/p>\n\n\n\n
On each controller (which will act a route reflectors) edit the \/etc\/frr\/bgpd.conf to contain:<\/p>\n\n\n\n
[root@onepoc ~]# cat \/etc\/frr\/bgpd.conf
! Route Reflector configuration
!
hostname 10.229.128.231
!
log file \/var\/log\/frr\/bgpd.log informational
!
router bgp 64512
bgp router-id 10.229.128.231
bgp cluster-id 10.229.128.231
no bgp default ipv4-unicast
neighbor fabric peer-group
neighbor fabric remote-as 64512
neighbor fabric capability extended-nexthop
neighbor fabric update-source 10.229.128.231
# bgp listen range 172.16.1.5\/32 peer-group fabric
# bgp listen range 172.16.1.4\/32 peer-group fabric
bgp listen range 172.16.1.0\/24 peer-group fabric
bgp listen range 10.229.128.0\/24 peer-group fabric
address-family l2vpn evpn
neighbor fabric activate
neighbor fabric route-reflector-client
advertise-all-vni
advertise-svi-ip
exit-address-family
end<\/pre>\n\n\n\nFor each controller, change the router-id, cluster-id, comment out the \/32 commands and add the range stated.<\/p>\n\n\n\n
You can look on the FRR web site about the syntax, briefly you are allowing the BGP process to listen on requests on certain networks and if so allow make BGP peering.<\/p>\n\n\n\n
In addition it is very import that you advertise all vnis and all svis (allows you to see the VXLAN and MAC addresses that the hypervisors are advertising).<\/p>\n\n\n\n
On each of the hypervisors, edit the same file and have it to it looks like this:<\/p>\n\n\n\n
hostname 10.229.128.235
!
router bgp 64512
bgp router-id 10.229.128.235
no bgp default ipv4-unicast
neighbor fabric peer-group
neighbor fabric remote-as 64512
neighbor fabric capability extended-nexthop
neighbor 10.229.128.231 peer-group fabric
neighbor 10.229.128.232 peer-group fabric
neighbor 10.229.128.233 peer-group fabric
!
address-family l2vpn evpn
neighbor fabric activate
advertise-all-vni
advertise-svi-ip
exit-address-family
exit<\/pre>\n\n\n\nOnce gain change the IP addresses to much your setup.<\/p>\n\n\n\n
Notice we are peering with the three controllers (not the VIP address).<\/p>\n\n\n\n
After all of this using vtysh (the frr cli) you should see:<\/p>\n\n\n\n
<\/p>\n\n\n\n
[root@onenode01 ~]# vtysh
Hello, this is FRRouting (version 10.5.3).
Copyright 1996-2005 Kunihiro Ishiguro, et al.
onenode01# sh bgp summary
L2VPN EVPN Summary:
BGP router identifier 10.229.128.235, local AS number 64512 VRF default vrf-id 0
BGP table version 0
RIB entries 0, using 0 bytes of memory
Peers 3, using 71 KiB of memory
Peer groups 1, using 64 bytes of memory
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up\/Down State\/PfxRcd PfxSnt Desc
10.229.128.231 4 64512 373 373 0 0 0 06:10:35 0 0 FRRouting\/10.5.3
10.229.128.232 4 64512 374 374 0 0 0 05:07:00 0 0 FRRouting\/10.5.3
10.229.128.233 4 64512 374 374 0 0 0 05:06:36 0 0 FRRouting\/10.5.3<\/pre>\n\n\n\nAnd on the controller:<\/p>\n\n\n\n
[root@onepoc ~]# vtysh
Hello, this is FRRouting (version 10.5.3).
Copyright 1996-2005 Kunihiro Ishiguro, et al.
onepoc# sh bgp summary
L2VPN EVPN Summary:
BGP router identifier 10.229.128.231, local AS number 64512 VRF default vrf-id 0
BGP table version 0
RIB entries 0, using 0 bytes of memory
Peers 2, using 47 KiB of memory
Peer groups 1, using 64 bytes of memory
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up\/Down State\/PfxRcd PfxSnt Desc
*10.229.128.234 4 64512 375 375 0 0 0 06:12:12 0 0 FRRouting\/10.5.3
*10.229.128.235 4 64512 375 375 0 0 0 06:12:11 0 0 FRRouting\/10.5.3
Total number of neighbors 2
* - dynamic neighbor
2 dynamic neighbor(s), limit 100<\/pre>\n\n\n\nOf course since you are not running any VMs at this point you will not see any L2VPN EVPN routes advertised via VXLAN.<\/p>\n\n\n\n
Access to External Networks<\/h2>\n\n\n\n
You now have a new shiny three node two hypervisor OPenNenula cluster.<\/p>\n\n\n\n
Go crazy, download some images, create VMs, create VXLAN networks, etc.<\/p>\n\n\n\n
So you have a VM, it can talk to other VMs in their own network however, you want it to be able to reach the Internet.<\/p>\n\n\n\n
The default gateway for all VMs trying to access the Internet will be: 172.16.100.254, the VRRP ip!.<\/p>\n\n\n\n
Add the following to rc.local on both hypervisors:<\/p>\n\n\n\n
iptables -t nat -A POSTROUTING -s 172.16.100.0\/24 ! -d 172.16.100.0\/24 -o ens3 -j MASQUERADE<\/pre>\n\n\n\nThis will ensure that when you create a VM on either, when it tries to get to the Internet will hit the VRRP IP and do masquerading.<\/p>\n\n\n\n
When you create a new VM, you need to remember to give it a gateway that needs to be known. This is easily done by creating a virtual router which its default gateway is the .254 and all other virtual networks connect to this virtual routers (the default GW for each virtual network) thus your VMs can reach the Internet.<\/p>\n\n\n\n
Since this is also a router (virtual nonetheless), you can have rules to prevent inter VM communications. Remember the virtual router can be any linux appliance, the one OpenNebula uses is a minimal Alpine VM. I did create my own (Alpine also) and it works very well.<\/p>\n\n\n\n
VMs, VXLAN and Testing<\/em><\/h3>\n\n\n\nI will not go into how to create VMs, or a VXLAN network however, I want to show what EVPN BGP will show you.<\/p>\n\n\n\n
Of course you need to create a few VMS and at least three networks.<\/p>\n\n\n\n
First the virtual networks created:<\/p>\n\n\n\n
[root@onepoc ~]# onevnet list
ID USER GROUP NAME CLUSTERS BRIDGE STATE LEASES OUTD ERRO
3 oneadmin oneadmin VM-1 0 VM-1 rdy 2 0 0
1 oneadmin oneadmin vxlan-600 0 vxlan600 rdy 2 0 0
0 oneadmin oneadmin vxlan-500 0 vx500 rdy 2 0 0<\/pre>\n\n\n\nI created three networks:<\/p>\n\n\n\n
\n- A standard network for normal VMs<\/li>\n\n\n\n
- Two VXLAN networks: vxlan600 and vxlan500<\/li>\n<\/ul>\n\n\n\n
Then four virtual machines were created:<\/p>\n\n\n\n
[root@onepoc ~]# onevm list
ID USER GROUP NAME STAT CPU MEM HOST TIME
6 oneadmin oneadmin VM-TEST1 poff 0.25 256M 172.16.1.5 17d 23h06
5 oneadmin oneadmin Router-1 runn 0.25 256M 172.16.1.4 17d 23h31
3 oneadmin oneadmin vxlan-600-1 poff 0.25 256M 172.16.1.4 18d 17h11
2 oneadmin oneadmin vxlan-500-1 poff 0.25 256M 172.16.1.5 18d 17h32<\/pre>\n\n\n\nThe VMs created are:<\/p>\n\n\n\n
\n- VM-TEST1 (to access Router-1)<\/li>\n\n\n\n
- Router-1 (the virtual router that allows access to the Internet)<\/li>\n\n\n\n
- vxlan-600-1 (VMS on VXLAN NET600)<\/li>\n\n\n\n
- vxlan-500-1 (VMS on VXLAN NET500)<\/li>\n<\/ul>\n\n\n\n
If you SSH onto Router-1:<\/p>\n\n\n\n
\/home\/miguel # cat \/etc\/os-release
NAME=\"Alpine Linux\"
ID=alpine
VERSION_ID=3.21.7
PRETTY_NAME=\"Alpine Linux v3.21\"
HOME_URL=\"https:\/\/alpinelinux.org\/\"
BUG_REPORT_URL=\"https:\/\/gitlab.alpinelinux.org\/alpine\/aports\/-\/issues\"
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1000
link\/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1\/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1\/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc pfifo_fast state UP qlen 1000
link\/ether 02:00:ac:10:32:33 brd ff:ff:ff:ff:ff:ff
inet 172.16.50.254\/24 scope global eth0
valid_lft forever preferred_lft forever
inet6 fe80::acff:fe10:3233\/64 scope link
valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc pfifo_fast state UP qlen 1000
link\/ether 02:00:ac:10:33:33 brd ff:ff:ff:ff:ff:ff
inet 172.16.51.254\/24 scope global eth1
valid_lft forever preferred_lft forever
inet6 fe80::acff:fe10:3333\/64 scope link
valid_lft forever preferred_lft forever
4: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
link\/ether 02:00:ac:10:64:02 brd ff:ff:ff:ff:ff:ff
inet 172.16.100.2\/24 scope global eth2
valid_lft forever preferred_lft forever
inet6 fe80::acff:fe10:6402\/64 scope link
valid_lft forever preferred_lft forever<\/pre>\n\n\n\nA few things to notice:<\/p>\n\n\n\n
\n- The router is running alpine linux 3.21 with forwarding enable and IPTABLES installed<\/li>\n\n\n\n
- eth2 allows access to the Internet. It has IP address 172.16.100.2 and the default GW is 172.16.100.254<\/li>\n\n\n\n
- eth0 and eth1 are the ports that connect to the VXLAN VMs.<\/li>\n\n\n\n
- Both have as ip addresses ending in .254, the default gateway for each VM. This is done when you create the VM or via a VM template among other things.<\/li>\n\n\n\n
- This is as it was pointed out a VM. OpenNebula has now an appliance you can download. It is an Alpine Linux machine. So I decided to make my own.<\/li>\n<\/ul>\n\n\n\n
If you start the other VLXLAN VMs, you should see BGP starting to advertise their mac addresses. This is importan because a VM on VXLAN-500 hypervisor 1 would not be able to talk to another VM on VXLAN-500 on hypervisor 2 unless VTEP and EVPN is working.<\/p>\n\n\n\n
As an added bonus since we are using Router-1 VMs on different VXLANS will be able to communicate unless you add specific IPTABLES rules to deny access.<\/p>\n\n\n\n
After starting th other VMS we can test connectivity.<\/p>\n\n\n\n
On the Router:<\/p>\n\n\n\n
PING 172.16.100.1 (172.16.100.1): 56 data bytes
64 bytes from 172.16.100.1: seq=8 ttl=64 time=2103.056 ms
64 bytes from 172.16.100.1: seq=9 ttl=64 time=1101.773 ms
\/home\/miguel # ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: seq=0 ttl=114 time=40.752 ms
64 bytes from 8.8.8.8: seq=1 ttl=114 time=40.707 ms<\/pre>\n\n\n\nThe router can ping VM-1 at IP 172.16.100.1, the router can also ping the Internet.<\/p>\n\n\n\n
Now let’s connect to one of the VMS. We will use VXLAN-500-1 becase it is on hypervisor 2, while the router runs on hypervisor 1. This will ensure the BGP EVPN is actually working.<\/p>\n\n\n\n
From the router we SSH onto 172.16.50.50, I created a local user.<\/p>\n\n\n\n
vxlan-500-1:~$ ip add
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1000
link\/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1\/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1\/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc pfifo_fast state UP qlen 1000
link\/ether 02:00:ac:10:32:32 brd ff:ff:ff:ff:ff:ff
inet 172.16.50.50\/24 scope global eth0
valid_lft forever preferred_lft forever
inet6 fe80::acff:fe10:3232\/64 scope link
valid_lft forever preferred_lft forever
vxlan-500-1:~$ ip route
default via 172.16.50.254 dev eth0 metric 1 onlink
169.254.16.9 dev eth0 scope link
172.16.50.0\/24 dev eth0 scope link src 172.16.50.50<\/pre>\n\n\n\nWe should be able to ping the Internet, and we know BGP is also working.<\/p>\n\n\n\n
vxlan-500-1:~$ ping www.google.com
PING www.google.com (142.251.154.119): 56 data bytes
64 bytes from 142.251.154.119: seq=0 ttl=42 time=52.869 ms
64 bytes from 142.251.154.119: seq=1 ttl=42 time=54.530 ms<\/pre>\n\n\n\nSo let’s take a look at BGP EVPN. On the controller:<\/p>\n\n\n\n
onepoc# sh bgp l2vpn evpn
BGP table version is 12, local router ID is 10.229.128.231
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal
Origin codes: i - IGP, e - EGP, ? - incomplete
EVPN type-1 prefix: [1]:[EthTag]:[ESI]:[IPlen]:[VTEP-IP]:[Frag-id]
EVPN type-2 prefix: [2]:[EthTag]:[MAClen]:[MAC]:[IPlen]:[IP]
EVPN type-3 prefix: [3]:[EthTag]:[IPlen]:[OrigIP]
EVPN type-4 prefix: [4]:[ESI]:[IPlen]:[OrigIP]
EVPN type-5 prefix: [5]:[EthTag]:[IPlen]:[IP]
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 10.229.128.234:2
*>i [2]:[0]:[48]:[02:00:ac:10:32:33]
10.229.128.234 100 0 i
RT:64512:500 ET:8
*>i [2]:[0]:[48]:[46:ce:d0:b2:0b:fd]:[128]:[fe80::4e9:97ff:feef:66a4]
10.229.128.234 100 0 i
RT:64512:500 ET:8
*>i [2]:[0]:[48]:[7a:b1:b9:46:44:93]:[128]:[fe80::4e9:97ff:feef:66a4]
10.229.128.234 100 0 i
RT:64512:500 ET:8
*>i [3]:[0]:[32]:[10.229.128.234]
10.229.128.234 100 0 i
RT:64512:500 ET:8
Route Distinguisher: 10.229.128.234:3
*>i [2]:[0]:[48]:[02:00:ac:10:33:32]
10.229.128.234 100 0 i
RT:64512:600 ET:8
*>i [2]:[0]:[48]:[8e:41:5b:98:77:10]:[128]:[fe80::7802:84ff:fe45:d10]
10.229.128.234 100 0 i
RT:64512:600 ET:8
*>i [3]:[0]:[32]:[10.229.128.234]
10.229.128.234 100 0 i
RT:64512:600 ET:8
Route Distinguisher: 10.229.128.235:2
*>i [2]:[0]:[48]:[02:00:ac:10:32:32]
10.229.128.235 100 0 i
RT:64512:500 ET:8
*>i [2]:[0]:[48]:[42:15:35:2c:98:e3]
10.229.128.235 100 0 i
RT:64512:500 ET:8
*>i [2]:[0]:[48]:[42:af:f6:d1:11:98]:[128]:[fe80::e8e4:6aff:fee7:e526]
10.229.128.235 100 0 i
RT:64512:500 ET:8
*>i [3]:[0]:[32]:[10.229.128.235]
10.229.128.235 100 0 i
RT:64512:500 ET:8<\/pre>\n\n\n\nIt works!. This is a lot to understand so I will not go into details.<\/p>\n\n\n\n
Suffice to say that both hypervisors (10.229.128.234, and .235) are advertising VNIs and MAC addresses. The controller acts as a route reflector so each hypervisor knows where to find a machine MAC address and connect to it, VTEPs are working, VXLAN has created tunnels and L2VPN EVPN is advertising routes. Very cool.<\/p>\n\n\n\n
We could ask ourselves what interface are the VTEPs using, you see .234 and .235 as the routes in BGP. These are not technically the actual VTEPs, when you create the VXLAN you tell OpenNebula what interface to use. We told it to use ens4. You can check this by issuing the following on each hypervisors:<\/p>\n\n\n\n
[root@onenode00 ~]# ip link show type vxlan
11: ens4.500: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue master vx500 state UNKNOWN mode DEFAULT group default qlen 1000
link\/ether 46:ce:d0:b2:0b:fd brd ff:ff:ff:ff:ff:ff
15: ens4.600: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue master vxlan600 state UNKNOWN mode DEFAULT group default qlen 1000
link\/ether d2:a9:46:da:0c:64 brd ff:ff:ff:ff:ff:ff
[root@onenode01 ~]# ip link show type vxlan
14: ens4.500: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue master vx500 state UNKNOWN mode DEFAULT group default qlen 1000
link\/ether 5a:02:f4:da:3b:68 brd ff:ff:ff:ff:ff:ff<\/pre>\n\n\n\nAs you can see, on both hypervisors the VTEPs are using ens4.vni, 500 and 600 respectively. I will let the reader ponder why we see the .234, .235 addresses rather than the ens4 IP addresses that actually create the tunnels.<\/p>\n\n\n\n
Conclusions<\/h2>\n\n\n\n
This is it. You now have a working production OpenNebula cluster.<\/p>\n\n\n\n
Some caveats:<\/p>\n\n\n\n
\n- I tried using OVS for VXLANs. Run into issues, BGP would not advertise VNIs. I am trouble shooting this. The reason is that OVS is an abstract layer which is supposed to be OS agnostic. However, that is one of the problems at one point it needs to interact with the OS interfaces and kernel (the kernel space not the user space) to correctly send BGP packets from within OVS. This works of course but I myself have not figure it out yet. When I do I will post a solution.<\/li>\n\n\n\n
- Using the kernel way for doing VXLANs is not an issue per say, OVS in my opinions is more elegant and scales better.<\/li>\n\n\n\n
- Using the ISO is fantastic but since it uses ansible, if you want to change network parameters do not use “onefemenu” on the controller or “onehostmenu” on the hosts. Use “nmtui” or as we did configure the network directly.<\/li>\n\n\n\n
- If you need to add another hypervisor, use the trick we stated, add the new host then immediately run the backup BGP configuration to avoid interruptions on all nodes. Then modify the BGP configuration of the new hypervisor.<\/li>\n\n\n\n
- Perhaps this could be automated but I did not wanted to go into the rabbit hole and poke around the ansible scripts.<\/li>\n\n\n\n
- Finally I did not create VRFs. This will be necessary for multi-tenancy on a production system. Your VNIs are already segmenting the network however you need to let the hosts known that they need to segment the kernel space. You will have to tweak your BGP configuration, create VRFs using FRR, map VLANs, and so on so far. Not difficult to do but you will need to test on a LAB setup until you feel confortable with it. <\/li>\n\n\n\n
- Refer to the FRR documentation and also a good resource for this is PROXMOX since they do VRFs off the bat when you create VXLANs using their SDN implementation.<\/li>\n<\/ul>\n\n\n\n
Well there you have it.<\/p>\n\n\n\n
Ciao.<\/p>\n","protected":false},"excerpt":{"rendered":"
In this blog I will show how to install an OpenNebula cluster from scratch, well almost, using an ISO that allows you to create a minimal configuration. The initial setup can be extended to have an almost functional production setup.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-934","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/blog.miguelsarmiento.com\/index.php?rest_route=\/wp\/v2\/posts\/934","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.miguelsarmiento.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.miguelsarmiento.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.miguelsarmiento.com\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.miguelsarmiento.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=934"}],"version-history":[{"count":91,"href":"https:\/\/blog.miguelsarmiento.com\/index.php?rest_route=\/wp\/v2\/posts\/934\/revisions"}],"predecessor-version":[{"id":1041,"href":"https:\/\/blog.miguelsarmiento.com\/index.php?rest_route=\/wp\/v2\/posts\/934\/revisions\/1041"}],"wp:attachment":[{"href":"https:\/\/blog.miguelsarmiento.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=934"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.miguelsarmiento.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=934"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.miguelsarmiento.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=934"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
![\"\"](\"https:\/\/blog.miguelsarmiento.com\/wp-content\/uploads\/2026\/08\/open-nebula-cluster.png\")
<\/a>