bwCloud-OS - User contributions [en]

Booking Units

2026-04-10T11:13:59Z

Admin: /* Reference values for BEH calculation in bwCloud-OS */

= General concept =
'''Booking units''' (sometimes abbreviated as '''BEH''' [Buchungseinheiten]) are a standardized accounting and allocation mechanism used in shared-service environments, particularly in information technology (IT), cloud computing, and other resource-based services. They provide a common quantitative measure for planning, consuming, and charging for services whose underlying costs are heterogeneous or variable.
Booking units are not a physical resource themselves; rather, they represent an abstracted unit of consumption that aggregates multiple cost drivers into a single, comparable metric.

== Purpose and role ==

The primary role of booking units is to simplify the management and allocation of shared resources. In complex service environments, actual costs are typically influenced by multiple factors, such as infrastructure investment, energy consumption, personnel effort, maintenance, and software licensing. Booking units translate these diverse inputs into a uniform measure that can be used for:
* allocating capacity among multiple users or institutions,
* tracking and comparing service consumption over time,
* enabling internal charging, cost recovery, or cost-neutral settlement models,
* supporting planning, budgeting, and governance processes.
By decoupling service usage from individual technical parameters, booking units allow users to focus on consumption at a service level rather than on detailed cost structures.

== Use in shared and public-sector services ==

Booking units are commonly applied in environments where multiple organizations jointly use a centrally operated service, such as public-sector IT platforms, academic computing infrastructures, or cooperative cloud services. In these contexts, booking units help balance transparency and simplicity:

* '''Transparency''', by providing a traceable link between service usage and incurred costs.
* '''Simplicity''', by avoiding institution-specific pricing models or detailed cost breakdowns for each technical component.

In cost-neutral models, booking units are often used not to generate profit, but to ensure that total costs incurred during a given accounting period are fully distributed among participants according to their relative usage.

== Determination of booking units ==

The determination of booking units typically follows a multi-step methodological process. While implementations vary, common principles include:

# '''Identification of cost drivers'''
#: Relevant cost components are identified, such as compute capacity, storage volume, network usage, operational effort, and overhead costs.
# '''Weighting and aggregation'''
#: Individual cost drivers are weighted according to their contribution to overall costs and aggregated into a single composite unit.
# '''Normalization'''
#: The resulting unit is normalized to ensure comparability across services, time periods, or user groups. This may involve defining a reference workload or baseline consumption pattern.
# '''Periodic calibration'''
#: Booking unit definitions are regularly reviewed and adjusted to reflect changes in technology, cost structures, or usage behavior.

The calculation is often retrospective: actual costs incurred during an accounting period are distributed across the total number of booking units consumed, ensuring alignment between usage and expenditure.

== Booking units and pricing ==

Booking units should be distinguished from fixed prices. In many models, especially in non-commercial or public-sector settings, a booking unit does not have a predetermined monetary value. Instead, the monetary value of a booking unit is calculated after the accounting period, based on total costs and total consumption.
This approach contrasts with commercial pricing models, where prices per unit are typically set in advance and include profit margins or risk buffers.

== Advantages and limitations ==

=== Advantages ===
* Enables fair and usage-based cost allocation
* Reduces complexity in multi-tenant service environments
* Supports cost transparency without exposing sensitive internal calculations
* Flexible and adaptable to evolving service portfolios

=== Limitations ===
* Requires careful design and governance to maintain trust
* May be less intuitive for end users than simple fixed pricing
* Periodic recalibration can introduce variability in unit value

= Reference values for BEH calculation in bwCloud-OS =

Within '''bwCloud-OS''', the conversion of technical resource consumption into booking units (BEHs) is based on standardized reference values for core infrastructure resources. These reference values define how individual resource usages contribute to the overall BEH consumption.
A commonly applied reference model uses the following baseline assumptions:

* '''vCPU''': One virtual CPU allocated for one day constitutes one reference unit of compute consumption:
** 1 vCPU equals 1 BEH/day

* '''RAM''': One gigabyte (GB) of allocated main memory for one day constitutes two reference unit of memory consumption:
** 1 GB equals 2 BEH/day

* '''Volume storage''': Ten gigabyte (GB) of persistent block storage allocated for one day constitutes one reference unit of storage consumption.
** 10 GB equals 1 BEH/day

E.g.: This implicates that the usage of a tiny sized virtual machine consumes 8 BEH per day. (The flavor <code>p1.tiny</code>is a configuration of 2 vCPUs, 2 GB RAM and 20 GB Storage)

Actual BEH consumption is calculated by weighting and aggregating these resource-specific reference units according to their relative cost relevance within the overall service operation. The exact weighting factors may be adjusted periodically to reflect changes in hardware costs, energy prices, or operational overhead, while the underlying reference values remain stable to ensure consistency and comparability over time.

These reference values serve as a technical normalization layer and do not represent fixed prices; the monetary value of a BEH is determined retrospectively based on total incurred costs and total BEH consumption within the accounting period.

Blocked and Allowed Ports

2026-04-02T10:51:17Z

Admin: /* Region Mannheim */

== General ==
The '''data centers of the universities''' of the bwCloud-OS operating sites '''block''' certain ports within their respective networks for security reasons. The bwCloud-OS regions are also affected, because the bwCloud-OS hardware is connected to the '''central network infrastructure'''.

Some of the '''public IP ranges''' of the bwCloud-OS regions are part of the '''BelWü address space'''. These addresses are logically '''outside''' the network ranges of the hosting universities (the locations of bwCloud). The addresses are treated as external by the firewalls of the respective institutions.

== Effects of the Packet Firewall for Users ==
The most important effect for users is that the '''network runs more reliably and securely'''. Many hacker attacks are already blocked at the packet firewall and do not reach the campus or the end systems. The importance of this protection is evident from the fact that attacks now occur almost daily.

However, there are a number of '''limitations''' to consider: if services other than the generally allowed ones listed here should be accessible from outside, this must be '''reported to the university IT'''. The corresponding service will then be enabled on the packet firewall.

It may also happen that seemingly outbound connections from the instance to certain services do not work. This occurs whenever the external server providing the service tries to establish a return connection to the instance, which is often difficult for the user to verify.

== Region Freiburg ==
TODO: add

{| class="wikitable"
! Transport !! Port !! Protocol !! Description !! Blocking
|-
|-
|}

== Region Mannheim ==

The bwcloud networks are accessible from the outside on '''all ports'''.

The following ports are blocked outbound (for all networks):

{| class="wikitable"
! Transport !! Port !! Description
|-
| UDP, TCP || 128 || Reserved / GSS X License
|-
| TCP || 129-139 || NetBIOS / RPC
|-
| UDP, TCP || 445 || SMB / Microsoft-DS
|-
| UDP || 11211 || Memcached
|-
| UDP || 32100 || IoT
|}

== Region Karlsruhe ==
In the bwCloud-OS Karlsruhe network, the following ports are blocked:

{| class="wikitable"
! Transport !! Port !! Protocol !! Description !! Blocking
|-
| UDP, TCP || 111 || RPC Portmapper || Portmapper Security || inbound/outbound
|}
== Region Ulm ==
In the bwCloud-OS Region Ulm the following ports are blocked by the Uni border firewall:

{| class="wikitable"
! Transport !! Port Range !! Description / Reason
|-
| TCP, UDP || 0 - 19 || lower protocols, like chargen, etc. used for DDoS
|-
| TCP, UDP || 23 || telnet
|-
| TCP, UDP || 42 || WINS
|-
| TCP, UDP || 67 - 69 || DHCP, tftp
|-
| TCP, UDP || 111 || rpc
|-
| TCP, UDP || 119 || nntp
|-
| TCP, UDP || 135 || loc-srv
|-
| TCP, UDP || 137 - 139 || SMB
|-
| TCP, UDP || 143 || IMAP, with explicit allow list
|-
| TCP, UDP || 161 - 162 || SNMP
|-
| TCP, UDP || 427 || SLP, Service Location Protocol
|-
| TCP, UDP || 445 || ms-ds
|-
| TCP, UDP || 512 - 515 || exec, login, who, syslog, shell, printer
|-
| TCP, UDP || 520 - 521 || rip, ripng
|-
| TCP, UDP || 548 || AFP, Apple File Protocol
|-
| TCP, UDP || 623 || IPMI
|-
| TCP, UDP || 631 || cups
|-
| TCP, UDP || 993 || IMAP, with explicit allow list
|-
| TCP, UDP || 1900 || SSDP
|-
| TCP, UDP || 2049 || nfsd
|-
| TCP, UDP || 3306 || MySQL
|-
| TCP, UDP || 3389 || RDP
|-
| TCP, UDP || 4045 || nfs lockd
|-
| TCP, UDP || 4369 || Erlang Port Mapper Daemon (EPMD)
|-
| TCP, UDP || 5432 || Postgres
|-
| TCP, UDP || 6443 || Kubernetes
|-
| TCP, UDP || 9000 - 10999 || 3CX RTP, with explicit allow list
|-
| TCP, UDP || 9100 || raw printer queues
|-
| TCP, UDP || 49152 || MS-RPC, allow incoming only established
|-
| TCP, UDP || 49664 - 49670 || MS-RPC, allow incoming only established
|-
|-
| TCP || 25 || SMTP, with explicit allow list
|-
| TCP || 110 || POP
|-
| TCP || 389 || LDAP, with explicit allow list
|-
| TCP || 873 || rsync - maybe make a Server ACL like FTP
|-
| TCP || 995 || POPS
|-
| TCP || 1801 || Microsoft Message Queuing Service, CVE-2023-21554
|-
| TCP || 5800 || VNC
|-
| TCP || 5900 || VNC
|-
| TCP || 5901 || VNC, sic may be more...
|-
| TCP || 6000 || X-Server
|-
| TCP || 6379 || REDIS
|-
| TCP || 9401 || Veeam Backup, CVE-2023-27532
|-
| TCP || 27017 || MongoDB
|-
|-
| UDP || 53 || DNS, with explicit allow list
|-
| UDP || 123 || NTP, with explicit allow list
|-
| UDP || 177 || XDMCP, X Display Manager ...
|-
| UDP || 389 || LDAP, UDP-based Amplification Attacks
|-
| UDP || 1434 || MS-SQL
|-
| UDP || 3283 || Apple Remote Desktop
|-
| UDP || 3478 || STUN, with explicit allow list
|-
| UDP || 3702 || WS-Discovery
|-
| UDP || 5093 || SPSS License Server
|-
| UDP || 5353 || mDNS, UDP-based Amplification Attacks
|-
|}

Blocked and Allowed Ports

2026-04-02T10:50:26Z

Admin:

== General ==
The '''data centers of the universities''' of the bwCloud-OS operating sites '''block''' certain ports within their respective networks for security reasons. The bwCloud-OS regions are also affected, because the bwCloud-OS hardware is connected to the '''central network infrastructure'''.

Some of the '''public IP ranges''' of the bwCloud-OS regions are part of the '''BelWü address space'''. These addresses are logically '''outside''' the network ranges of the hosting universities (the locations of bwCloud). The addresses are treated as external by the firewalls of the respective institutions.

== Effects of the Packet Firewall for Users ==
The most important effect for users is that the '''network runs more reliably and securely'''. Many hacker attacks are already blocked at the packet firewall and do not reach the campus or the end systems. The importance of this protection is evident from the fact that attacks now occur almost daily.

However, there are a number of '''limitations''' to consider: if services other than the generally allowed ones listed here should be accessible from outside, this must be '''reported to the university IT'''. The corresponding service will then be enabled on the packet firewall.

It may also happen that seemingly outbound connections from the instance to certain services do not work. This occurs whenever the external server providing the service tries to establish a return connection to the instance, which is often difficult for the user to verify.

== Region Freiburg ==
TODO: add

{| class="wikitable"
! Transport !! Port !! Protocol !! Description !! Blocking
|-
|-
|}

== Region Mannheim ==

The bwcloud networks are accessible from the outside on all ports.

The following ports are blocked outbound (for all networks):

{| class="wikitable"
! Transport !! Port !! Description
|-
| UDP, TCP || 128 || Reserved / GSS X License
|-
| TCP || 129-139 || NetBIOS / RPC
|-
| UDP, TCP || 445 || SMB / Microsoft-DS
|-
| UDP || 11211 || Memcached
|-
| UDP || 32100 || IoT
|}

== Region Karlsruhe ==
In the bwCloud-OS Karlsruhe network, the following ports are blocked:

{| class="wikitable"
! Transport !! Port !! Protocol !! Description !! Blocking
|-
| UDP, TCP || 111 || RPC Portmapper || Portmapper Security || inbound/outbound
|}
== Region Ulm ==
In the bwCloud-OS Region Ulm the following ports are blocked by the Uni border firewall:

{| class="wikitable"
! Transport !! Port Range !! Description / Reason
|-
| TCP, UDP || 0 - 19 || lower protocols, like chargen, etc. used for DDoS
|-
| TCP, UDP || 23 || telnet
|-
| TCP, UDP || 42 || WINS
|-
| TCP, UDP || 67 - 69 || DHCP, tftp
|-
| TCP, UDP || 111 || rpc
|-
| TCP, UDP || 119 || nntp
|-
| TCP, UDP || 135 || loc-srv
|-
| TCP, UDP || 137 - 139 || SMB
|-
| TCP, UDP || 143 || IMAP, with explicit allow list
|-
| TCP, UDP || 161 - 162 || SNMP
|-
| TCP, UDP || 427 || SLP, Service Location Protocol
|-
| TCP, UDP || 445 || ms-ds
|-
| TCP, UDP || 512 - 515 || exec, login, who, syslog, shell, printer
|-
| TCP, UDP || 520 - 521 || rip, ripng
|-
| TCP, UDP || 548 || AFP, Apple File Protocol
|-
| TCP, UDP || 623 || IPMI
|-
| TCP, UDP || 631 || cups
|-
| TCP, UDP || 993 || IMAP, with explicit allow list
|-
| TCP, UDP || 1900 || SSDP
|-
| TCP, UDP || 2049 || nfsd
|-
| TCP, UDP || 3306 || MySQL
|-
| TCP, UDP || 3389 || RDP
|-
| TCP, UDP || 4045 || nfs lockd
|-
| TCP, UDP || 4369 || Erlang Port Mapper Daemon (EPMD)
|-
| TCP, UDP || 5432 || Postgres
|-
| TCP, UDP || 6443 || Kubernetes
|-
| TCP, UDP || 9000 - 10999 || 3CX RTP, with explicit allow list
|-
| TCP, UDP || 9100 || raw printer queues
|-
| TCP, UDP || 49152 || MS-RPC, allow incoming only established
|-
| TCP, UDP || 49664 - 49670 || MS-RPC, allow incoming only established
|-
|-
| TCP || 25 || SMTP, with explicit allow list
|-
| TCP || 110 || POP
|-
| TCP || 389 || LDAP, with explicit allow list
|-
| TCP || 873 || rsync - maybe make a Server ACL like FTP
|-
| TCP || 995 || POPS
|-
| TCP || 1801 || Microsoft Message Queuing Service, CVE-2023-21554
|-
| TCP || 5800 || VNC
|-
| TCP || 5900 || VNC
|-
| TCP || 5901 || VNC, sic may be more...
|-
| TCP || 6000 || X-Server
|-
| TCP || 6379 || REDIS
|-
| TCP || 9401 || Veeam Backup, CVE-2023-27532
|-
| TCP || 27017 || MongoDB
|-
|-
| UDP || 53 || DNS, with explicit allow list
|-
| UDP || 123 || NTP, with explicit allow list
|-
| UDP || 177 || XDMCP, X Display Manager ...
|-
| UDP || 389 || LDAP, UDP-based Amplification Attacks
|-
| UDP || 1434 || MS-SQL
|-
| UDP || 3283 || Apple Remote Desktop
|-
| UDP || 3478 || STUN, with explicit allow list
|-
| UDP || 3702 || WS-Discovery
|-
| UDP || 5093 || SPSS License Server
|-
| UDP || 5353 || mDNS, UDP-based Amplification Attacks
|-
|}

Blocked and Allowed Ports

2026-04-02T10:48:05Z

Admin: /* Region Mannheim */

== General ==
The '''data centers of the universities''' of the bwCloud-OS operating sites '''block''' certain ports within their respective networks for security reasons. The bwCloud-OS regions are also affected, because the bwCloud-OS hardware is connected to the '''central network infrastructure'''.

Some of the '''public IP ranges''' of the bwCloud-OS regions are part of the '''BelWü address space'''. These addresses are logically '''outside''' the network ranges of the hosting universities (the locations of bwCloud). The addresses are treated as external by the firewalls of the respective institutions.

== Effects of the Packet Firewall for Users ==
The most important effect for users is that the '''network runs more reliably and securely'''. Many hacker attacks are already blocked at the packet firewall and do not reach the campus or the end systems. The importance of this protection is evident from the fact that attacks now occur almost daily.

However, there are a number of '''limitations''' to consider: if services other than the generally allowed ones listed here should be accessible from outside, this must be '''reported to the university IT'''. The corresponding service will then be enabled on the packet firewall.

It may also happen that seemingly outbound connections from the instance to certain services do not work. This occurs whenever the external server providing the service tries to establish a return connection to the instance, which is often difficult for the user to verify.

== Region Freiburg ==
TODO: add

{| class="wikitable"
! Transport !! Port !! Protocol !! Description !! Blocking
|-
|-

== Region Mannheim ==

The bwcloud networks are accessible from the outside on all ports.

The following ports are blocked outbound (for all networks):

{| class="wikitable"
! Transport !! Port !! Description
|-
| UDP, TCP || 128 || Reserved / GSS X License
|-
| TCP || 129-139 || NetBIOS / RPC
|-
| UDP, TCP || 445 || SMB / Microsoft-DS
|-
| UDP || 11211 || Memcached
|-
| UDP || 32100 || IoT
|}

== Region Karlsruhe ==
In the bwCloud-OS Karlsruhe network, the following ports are blocked:

{| class="wikitable"
! Transport !! Port !! Protocol !! Description !! Blocking
|-
| UDP, TCP || 111 || RPC Portmapper || Portmapper Security || inbound/outbound
|}
== Region Ulm ==
In the bwCloud-OS Region Ulm the following ports are blocked by the Uni border firewall:

{| class="wikitable"
! Transport !! Port Range !! Description / Reason
|-
| TCP, UDP || 0 - 19 || lower protocols, like chargen, etc. used for DDoS
|-
| TCP, UDP || 23 || telnet
|-
| TCP, UDP || 42 || WINS
|-
| TCP, UDP || 67 - 69 || DHCP, tftp
|-
| TCP, UDP || 111 || rpc
|-
| TCP, UDP || 119 || nntp
|-
| TCP, UDP || 135 || loc-srv
|-
| TCP, UDP || 137 - 139 || SMB
|-
| TCP, UDP || 143 || IMAP, with explicit allow list
|-
| TCP, UDP || 161 - 162 || SNMP
|-
| TCP, UDP || 427 || SLP, Service Location Protocol
|-
| TCP, UDP || 445 || ms-ds
|-
| TCP, UDP || 512 - 515 || exec, login, who, syslog, shell, printer
|-
| TCP, UDP || 520 - 521 || rip, ripng
|-
| TCP, UDP || 548 || AFP, Apple File Protocol
|-
| TCP, UDP || 623 || IPMI
|-
| TCP, UDP || 631 || cups
|-
| TCP, UDP || 993 || IMAP, with explicit allow list
|-
| TCP, UDP || 1900 || SSDP
|-
| TCP, UDP || 2049 || nfsd
|-
| TCP, UDP || 3306 || MySQL
|-
| TCP, UDP || 3389 || RDP
|-
| TCP, UDP || 4045 || nfs lockd
|-
| TCP, UDP || 4369 || Erlang Port Mapper Daemon (EPMD)
|-
| TCP, UDP || 5432 || Postgres
|-
| TCP, UDP || 6443 || Kubernetes
|-
| TCP, UDP || 9000 - 10999 || 3CX RTP, with explicit allow list
|-
| TCP, UDP || 9100 || raw printer queues
|-
| TCP, UDP || 49152 || MS-RPC, allow incoming only established
|-
| TCP, UDP || 49664 - 49670 || MS-RPC, allow incoming only established
|-
|-
| TCP || 25 || SMTP, with explicit allow list
|-
| TCP || 110 || POP
|-
| TCP || 389 || LDAP, with explicit allow list
|-
| TCP || 873 || rsync - maybe make a Server ACL like FTP
|-
| TCP || 995 || POPS
|-
| TCP || 1801 || Microsoft Message Queuing Service, CVE-2023-21554
|-
| TCP || 5800 || VNC
|-
| TCP || 5900 || VNC
|-
| TCP || 5901 || VNC, sic may be more...
|-
| TCP || 6000 || X-Server
|-
| TCP || 6379 || REDIS
|-
| TCP || 9401 || Veeam Backup, CVE-2023-27532
|-
| TCP || 27017 || MongoDB
|-
|-
| UDP || 53 || DNS, with explicit allow list
|-
| UDP || 123 || NTP, with explicit allow list
|-
| UDP || 177 || XDMCP, X Display Manager ...
|-
| UDP || 389 || LDAP, UDP-based Amplification Attacks
|-
| UDP || 1434 || MS-SQL
|-
| UDP || 3283 || Apple Remote Desktop
|-
| UDP || 3478 || STUN, with explicit allow list
|-
| UDP || 3702 || WS-Discovery
|-
| UDP || 5093 || SPSS License Server
|-
| UDP || 5353 || mDNS, UDP-based Amplification Attacks
|-
|}

Table: Images Gen3

2026-03-31T08:49:54Z

Admin:

{| class="wikitable sortable" style="border-collapse: collapse; width: 100%; margin: 1em 0; font-family: sans-serif;"
! style="background-color: #232e58; color: white; padding: 12px; text-align: left; font-weight: bold; border: 1px solid #1a2340;" | Image Name
! style="background-color: #232e58; color: white; padding: 12px; text-align: left; font-weight: bold; border: 1px solid #1a2340;" | Default SSH Username
! style="background-color: #232e58; color: white; padding: 12px; text-align: left; font-weight: bold; border: 1px solid #1a2340;" | Last Updated
! style="background-color: #232e58; color: white; padding: 12px; text-align: left; font-weight: bold; border: 1px solid #1a2340;" | Min. Disk (GB)
|-
| style="background-color: #f8f9fa; padding: 10px; border: 1px solid #ddd; font-weight: 500;" | AlmaLinux 10
| style="background-color: #f8f9fa; padding: 10px; border: 1px solid #ddd;" | <code style="background-color: #e8f1fa; padding: 2px 6px; border-radius: 3px; color: #07307d; font-weight: 500;">almalinux</code>
| style="background-color: #f8f9fa; padding: 10px; border: 1px solid #ddd;" | 20.03.2026
| style="background-color: #f8f9fa; padding: 10px; border: 1px solid #ddd; text-align: center;" | 10
|-
| style="padding: 10px; border: 1px solid #ddd; font-weight: 500;" | CentOS Stream 10
| style="padding: 10px; border: 1px solid #ddd;" | <code style="background-color: #e8f1fa; padding: 2px 6px; border-radius: 3px; color: #07307d; font-weight: 500;">cloud-user</code>
| style="padding: 10px; border: 1px solid #ddd;" | 20.03.2026
| style="padding: 10px; border: 1px solid #ddd; text-align: center;" | 10
|-
| style="background-color: #f8f9fa; padding: 10px; border: 1px solid #ddd; font-weight: 500;" | Debian 13
| style="background-color: #f8f9fa; padding: 10px; border: 1px solid #ddd;" | <code style="background-color: #e8f1fa; padding: 2px 6px; border-radius: 3px; color: #07307d; font-weight: 500;">debian</code>
| style="background-color: #f8f9fa; padding: 10px; border: 1px solid #ddd;" | 19.03.2026
| style="background-color: #f8f9fa; padding: 10px; border: 1px solid #ddd; text-align: center;" | 3
|-
| style="padding: 10px; border: 1px solid #ddd; font-weight: 500;" | Fedora 43
| style="padding: 10px; border: 1px solid #ddd;" | <code style="background-color: #e8f1fa; padding: 2px 6px; border-radius: 3px; color: #07307d; font-weight: 500;">fedora</code>
| style="padding: 10px; border: 1px solid #ddd;" | 20.03.2026
| style="padding: 10px; border: 1px solid #ddd; text-align: center;" | 5
|-
| style="background-color: #f8f9fa; padding: 10px; border: 1px solid #ddd; font-weight: 500;" | openSUSE Leap 16.0
| style="background-color: #f8f9fa; padding: 10px; border: 1px solid #ddd;" | <code style="background-color: #e8f1fa; padding: 2px 6px; border-radius: 3px; color: #07307d; font-weight: 500;">sles</code>
| style="background-color: #f8f9fa; padding: 10px; border: 1px solid #ddd;" | 20.03.2026
| style="background-color: #f8f9fa; padding: 10px; border: 1px solid #ddd; text-align: center;" | 3
|-
| style="padding: 10px; border: 1px solid #ddd; font-weight: 500;" | Rocky 10
| style="padding: 10px; border: 1px solid #ddd;" | <code style="background-color: #e8f1fa; padding: 2px 6px; border-radius: 3px; color: #07307d; font-weight: 500;">rocky</code>
| style="padding: 10px; border: 1px solid #ddd;" | 20.03.2026
| style="padding: 10px; border: 1px solid #ddd; text-align: center;" | 10
|-
| style="background-color: #f8f9fa; padding: 10px; border: 1px solid #ddd; font-weight: 500;" | Ubuntu 24.04
| style="background-color: #f8f9fa; padding: 10px; border: 1px solid #ddd;" | <code style="background-color: #e8f1fa; padding: 2px 6px; border-radius: 3px; color: #07307d; font-weight: 500;">ubuntu</code>
| style="background-color: #f8f9fa; padding: 10px; border: 1px solid #ddd;" | 20.03.2026
| style="background-color: #f8f9fa; padding: 10px; border: 1px solid #ddd; text-align: center;" | 5
|}

Key User: Migration Guide

2026-03-23T12:50:32Z

Admin: /* Networks */

{| class="mw-message-box mw-message-box-warning"
| style="vertical-align:middle;" | '''⚠️ Please Note:''' This guide is still work in progress.
|}

{{InANutshell|
<li>Both bwCloud-OS environments are completely independent.</li>
<li>Security groups won't carry over automatically.</li>
<li>Networks and IP addresses will change.</li>
<li>You can either start a new instance (VM) and copy your old data over, or migrate the old VM yourself.</li>
<li>For migrating volumes, attach a fresh volume to a new VM in the new cloud and copy your data directly over the network using rsync.</li>
}}

__TOC__

= General Information =

This guide explains how to migrate your resources from the old bwCloud-OS Gen2 environment to bwCloud-OS Gen3. Because the two environments are completely separated, there is no automatic migration path. You will need to manually export your resources from the old cloud, download them locally, and upload them to the new cloud. Please note that network settings and Security Groups cannot be copied and must be reconfigured manually in the new environment.

=== Dashboard Login ===

* [https://portal.bw-cloud.org/ Old bwCloud-OS Gen2]
* [https://portal.ul.bwcos.de/auth/login/?next=/%20https://portal.ul.bwcos.de/ New bwCloud-OS Gen3]

=== Networks ===

The new infrastructure includes not only new networks but also new network-related features such as load balancers. You can find an overview [[Networks_Gen3|here]].

Network-specific differences between regions and details about the individual networks can be found in the following guide.

➡️ [[Guide:_Network_Configuration_by_Region|Guide: Network Configuration by Region]]

= Transferring =

== Transferring Volumes ==

While it is technically possible to migrate a Cinder volume by converting it to an image and uploading it to the new cloud, we do not recommend this approach. The process is extremely slow, and depending on the backend configuration, the upload may silently fail entirely.

'''Our recommendation: create a fresh volume and copy your data over the network.'''
* In the new environment, create a new empty volume of the appropriate size and attach it to a new VM.
* Format and mount the volume on the new VM. Detailed instructions can be found [[Guide:_Volumes_and_Images#Create_and_Attach_a_Volume|here]].
* Make sure your old VM (with the old volume mounted) is reachable from the new VM via SSH (either by exchanging SSH keys or setting a password in the VM).
* Sync your data directly over the network using '''rsync'''.

<pre>
rsync -avz --progress /path/to/old/data/ root@<NEW_VM_IP>:/path/to/new/destination/
</pre>

== Transferring VMs ==

==== Prerequisites ====
* Access to both bwCloud-OS environments and
* Application Credentials, as described [[Programmatic_Access_and_Automation#Application_Credentials|here]]
* OpenStack Client installed, as described [[Programmatic_Access_and_Automation#OpenStack_Client|here]]

When transferring a VM, you create a snapshot of its current state, download it, and use it as a base image in the new environment.

'''Step 1: Create a Snapshot'''

First, source your old bwCloud-OS Gen2 credentials and find the ID of the instance (VM) you want to migrate:

<pre>
source old-creds.sh
openstack server list
openstack server image create --name <snapshot_name> <instance_id>
</pre>

'''Step 2: Download the Snapshot'''

The Image ID should have been prompted in the previous step. However, it is also possible to find the ID of your created snapshot and download it to your local computer later:

<pre>
openstack image list
openstack image save --file myimage.img <snapshot_id>
</pre>

'''Step 3: Upload to the New Environment (bwCloud-OS Gen3)'''

Source your new cloud credentials and upload the image file. '''Important''': Always set the visibility to Private so other users cannot use your image as a base for their services.

<pre>
source new-creds.sh
openstack image create --file myimage.img --private myimage
</pre>

Alternative: You can also upload the downloaded .img file using the new Horizon GUI by navigating to '''Compute -> Images'''.

'''Step 4: Start the Instance'''

You can now start a new instance using this uploaded image. Remember to reconfigure your '''Security Groups''' and note that you will receive a '''new IP address'''.

To start a new instance:
* Log in to the bwCloud-OS Gen3 Dashboard.
* Navigate to Project --> Compute --> Images. The uploaded snapshot should be listed there.
* Click on "Start", choose an instance name, and select the network and SSH key (or create a new one).

Key User: Migration Guide

2026-03-23T12:50:22Z

Admin: /* Networks */

{| class="mw-message-box mw-message-box-warning"
| style="vertical-align:middle;" | '''⚠️ Please Note:''' This guide is still work in progress.
|}

{{InANutshell|
<li>Both bwCloud-OS environments are completely independent.</li>
<li>Security groups won't carry over automatically.</li>
<li>Networks and IP addresses will change.</li>
<li>You can either start a new instance (VM) and copy your old data over, or migrate the old VM yourself.</li>
<li>For migrating volumes, attach a fresh volume to a new VM in the new cloud and copy your data directly over the network using rsync.</li>
}}

__TOC__

= General Information =

This guide explains how to migrate your resources from the old bwCloud-OS Gen2 environment to bwCloud-OS Gen3. Because the two environments are completely separated, there is no automatic migration path. You will need to manually export your resources from the old cloud, download them locally, and upload them to the new cloud. Please note that network settings and Security Groups cannot be copied and must be reconfigured manually in the new environment.

=== Dashboard Login ===

* [https://portal.bw-cloud.org/ Old bwCloud-OS Gen2]
* [https://portal.ul.bwcos.de/auth/login/?next=/%20https://portal.ul.bwcos.de/ New bwCloud-OS Gen3]

=== Networks ===

The new infrastructure includes not only new networks but also new network-related features such as load balancers. You can find an overview [[Networks_Gen3|here]].
Network-specific differences between regions and details about the individual networks can be found in the following guide.

➡️ [[Guide:_Network_Configuration_by_Region|Guide: Network Configuration by Region]]

= Transferring =

== Transferring Volumes ==

While it is technically possible to migrate a Cinder volume by converting it to an image and uploading it to the new cloud, we do not recommend this approach. The process is extremely slow, and depending on the backend configuration, the upload may silently fail entirely.

'''Our recommendation: create a fresh volume and copy your data over the network.'''
* In the new environment, create a new empty volume of the appropriate size and attach it to a new VM.
* Format and mount the volume on the new VM. Detailed instructions can be found [[Guide:_Volumes_and_Images#Create_and_Attach_a_Volume|here]].
* Make sure your old VM (with the old volume mounted) is reachable from the new VM via SSH (either by exchanging SSH keys or setting a password in the VM).
* Sync your data directly over the network using '''rsync'''.

<pre>
rsync -avz --progress /path/to/old/data/ root@<NEW_VM_IP>:/path/to/new/destination/
</pre>

== Transferring VMs ==

==== Prerequisites ====
* Access to both bwCloud-OS environments and
* Application Credentials, as described [[Programmatic_Access_and_Automation#Application_Credentials|here]]
* OpenStack Client installed, as described [[Programmatic_Access_and_Automation#OpenStack_Client|here]]

When transferring a VM, you create a snapshot of its current state, download it, and use it as a base image in the new environment.

'''Step 1: Create a Snapshot'''

First, source your old bwCloud-OS Gen2 credentials and find the ID of the instance (VM) you want to migrate:

<pre>
source old-creds.sh
openstack server list
openstack server image create --name <snapshot_name> <instance_id>
</pre>

'''Step 2: Download the Snapshot'''

The Image ID should have been prompted in the previous step. However, it is also possible to find the ID of your created snapshot and download it to your local computer later:

<pre>
openstack image list
openstack image save --file myimage.img <snapshot_id>
</pre>

'''Step 3: Upload to the New Environment (bwCloud-OS Gen3)'''

Source your new cloud credentials and upload the image file. '''Important''': Always set the visibility to Private so other users cannot use your image as a base for their services.

<pre>
source new-creds.sh
openstack image create --file myimage.img --private myimage
</pre>

Alternative: You can also upload the downloaded .img file using the new Horizon GUI by navigating to '''Compute -> Images'''.

'''Step 4: Start the Instance'''

You can now start a new instance using this uploaded image. Remember to reconfigure your '''Security Groups''' and note that you will receive a '''new IP address'''.

To start a new instance:
* Log in to the bwCloud-OS Gen3 Dashboard.
* Navigate to Project --> Compute --> Images. The uploaded snapshot should be listed there.
* Click on "Start", choose an instance name, and select the network and SSH key (or create a new one).

Table: Images Gen3

2026-03-20T09:54:37Z

Admin: Created page with "{| class="wikitable sortable" style="border-collapse: collapse; width: 100%; margin: 1em 0; font-family: sans-serif;" ! style="background-color: #232e58; color: white; padding: 12px; text-align: left; font-weight: bold; border: 1px solid #1a2340;" | Image Name ! style="background-color: #232e58; color: white; padding: 12px; text-align: left; font-weight: bold; border: 1px solid #1a2340;" | Default SSH Username ! style="background-color: #232e58; color: white; padding: 12..."

{| class="wikitable sortable" style="border-collapse: collapse; width: 100%; margin: 1em 0; font-family: sans-serif;"
! style="background-color: #232e58; color: white; padding: 12px; text-align: left; font-weight: bold; border: 1px solid #1a2340;" | Image Name
! style="background-color: #232e58; color: white; padding: 12px; text-align: left; font-weight: bold; border: 1px solid #1a2340;" | Default SSH Username
! style="background-color: #232e58; color: white; padding: 12px; text-align: left; font-weight: bold; border: 1px solid #1a2340;" | Last Updated
! style="background-color: #232e58; color: white; padding: 12px; text-align: left; font-weight: bold; border: 1px solid #1a2340;" | Min. Disk (GB)
! style="background-color: #232e58; color: white; padding: 12px; text-align: left; font-weight: bold; border: 1px solid #1a2340;" | Min. RAM (MB)
|-
| style="background-color: #f8f9fa; padding: 10px; border: 1px solid #ddd; font-weight: 500;" | AlmaLinux 10
| style="background-color: #f8f9fa; padding: 10px; border: 1px solid #ddd;" | <code style="background-color: #e8f1fa; padding: 2px 6px; border-radius: 3px; color: #07307d; font-weight: 500;">almalinux</code>
| style="background-color: #f8f9fa; padding: 10px; border: 1px solid #ddd;" | 20.03.2026
| style="background-color: #f8f9fa; padding: 10px; border: 1px solid #ddd; text-align: center;" | 10
| style="background-color: #f8f9fa; padding: 10px; border: 1px solid #ddd; text-align: center;" | 256
|-
| style="padding: 10px; border: 1px solid #ddd; font-weight: 500;" | CentOS Stream 10
| style="padding: 10px; border: 1px solid #ddd;" | <code style="background-color: #e8f1fa; padding: 2px 6px; border-radius: 3px; color: #07307d; font-weight: 500;">cloud-user</code>
| style="padding: 10px; border: 1px solid #ddd;" | 20.03.2026
| style="padding: 10px; border: 1px solid #ddd; text-align: center;" | 10
| style="padding: 10px; border: 1px solid #ddd; text-align: center;" | 256
|-
| style="background-color: #f8f9fa; padding: 10px; border: 1px solid #ddd; font-weight: 500;" | Debian 13
| style="background-color: #f8f9fa; padding: 10px; border: 1px solid #ddd;" | <code style="background-color: #e8f1fa; padding: 2px 6px; border-radius: 3px; color: #07307d; font-weight: 500;">debian</code>
| style="background-color: #f8f9fa; padding: 10px; border: 1px solid #ddd;" | 19.03.2026
| style="background-color: #f8f9fa; padding: 10px; border: 1px solid #ddd; text-align: center;" | 3
| style="background-color: #f8f9fa; padding: 10px; border: 1px solid #ddd; text-align: center;" | 256
|-
| style="padding: 10px; border: 1px solid #ddd; font-weight: 500;" | Fedora 43
| style="padding: 10px; border: 1px solid #ddd;" | <code style="background-color: #e8f1fa; padding: 2px 6px; border-radius: 3px; color: #07307d; font-weight: 500;">fedora</code>
| style="padding: 10px; border: 1px solid #ddd;" | 20.03.2026
| style="padding: 10px; border: 1px solid #ddd; text-align: center;" | 5
| style="padding: 10px; border: 1px solid #ddd; text-align: center;" | 256
|-
| style="background-color: #f8f9fa; padding: 10px; border: 1px solid #ddd; font-weight: 500;" | openSUSE Leap 16.0
| style="background-color: #f8f9fa; padding: 10px; border: 1px solid #ddd;" | <code style="background-color: #e8f1fa; padding: 2px 6px; border-radius: 3px; color: #07307d; font-weight: 500;">opensuse</code>
| style="background-color: #f8f9fa; padding: 10px; border: 1px solid #ddd;" | 20.03.2026
| style="background-color: #f8f9fa; padding: 10px; border: 1px solid #ddd; text-align: center;" | 3
| style="background-color: #f8f9fa; padding: 10px; border: 1px solid #ddd; text-align: center;" | 256
|-
| style="padding: 10px; border: 1px solid #ddd; font-weight: 500;" | Rocky 10
| style="padding: 10px; border: 1px solid #ddd;" | <code style="background-color: #e8f1fa; padding: 2px 6px; border-radius: 3px; color: #07307d; font-weight: 500;">rocky</code>
| style="padding: 10px; border: 1px solid #ddd;" | 20.03.2026
| style="padding: 10px; border: 1px solid #ddd; text-align: center;" | 10
| style="padding: 10px; border: 1px solid #ddd; text-align: center;" | 256
|-
| style="background-color: #f8f9fa; padding: 10px; border: 1px solid #ddd; font-weight: 500;" | Ubuntu 24.04
| style="background-color: #f8f9fa; padding: 10px; border: 1px solid #ddd;" | <code style="background-color: #e8f1fa; padding: 2px 6px; border-radius: 3px; color: #07307d; font-weight: 500;">ubuntu</code>
| style="background-color: #f8f9fa; padding: 10px; border: 1px solid #ddd;" | 20.03.2026
| style="background-color: #f8f9fa; padding: 10px; border: 1px solid #ddd; text-align: center;" | 5
| style="background-color: #f8f9fa; padding: 10px; border: 1px solid #ddd; text-align: center;" | 256
|}

Networks Gen3

2026-03-19T15:24:48Z

Admin:

{{InANutshell|
<li>Each bwCloud-OS instance launched using the standard method is automatically assigned a public IP address.</li>
<li> Floating IPs, which persist independent of instances, are also available.
</li>
<li> Load Balancers are available and allow traffic to be distributed across multiple backend instances via a single public address.
</li>
<li>Instances are assigned a persistent FQDN based on their name, project and region.</li>
<li>Domain hosting is not provided, but you can point your own domain to the FQDN of the instance using a CNAME record.</li>
}}

__TOC__

= Networks & IP addresses =

== Will my instance receive a public IP? ==

By default, every VM receives a '''public IPv6 address'''. Depending on the assigned or chosen network, it also receives either a '''public IPv4 address''' or a '''private IPv4 address'''. In the latter case, '''IPv4 egress connectivity''' is provided via '''SNAT'''.

'''Note:''' In not available by default, '''IPv4 ingress connectivity''' can also be provided via a [https://bw-support.scc.kit.edu/ support ticket].

'''Note:''' Each '''[[Registration#Regions|region]]''' in bwCloud-OS has its own set of networks and IP address ranges'''.'''

[[Guide: Network Configuration by Region|➡️ Guide: Network Configuration by Region]]

== How long does an IP remain assigned to my instance? ==


The IP address(es''')''' assigned to your instance remains associated with it for the entire lifetime of the instance — even if you stop (shut down) the instance.

The IP is only released when the instance is deleted (terminated). After termination, the IP is returned to the regional pool and may be reassigned to another instance in the region.

'''Note:''' Floating IPs will persist even after an Instance deletion. They can be released manually.

== Are Floating IPs also available for instances? ==


Yes.
'''Floating IPs''' provide a mechanism to perform 1:1 NAT between a public IPv4 address and a private IPv4 address of an instance enabling ingress IPv4 connectivity.

For more information and detailed setup instructions, see the guide below.

➡️ [[Guide: Routers and Floating IPs|Routers and Floating IPs Guide]]
== Are Load Balancers available in bwCloud-OS? ==


Yes.
bwCloud-OS provides '''Load Balancers''' based on '''OpenStack Octavia'''. They allow you to distribute traffic across multiple backend instances and expose services via a single public endpoint.

A typical setup involves creating a private network, deploying backend VMs, and configuring a load balancer with a listener, pool, and members. A [[Networks Gen3#Floating-IPs|Floating IP]] can then be assigned to make the service publicly accessible.

For more information and detailed setup instructions, see the guide below.

➡️ [[Guide: Load Balancers]]

= Domains and FQDNs =

== Does bwCloud-OS assign FQDNs? ==


Yes. Every running instance in bwCloud-OS is automatically assigned a '''fully qualified domain name (FQDN)'''. This allows the instance to be reached via a '''persistent network identifier'''. This FQDN is valid for the '''lifetime''' of the instance.

==== Format of an instance FQDN ====

* The '''instance name'''
* The '''project name'''
* The '''zone prefix''' (<code>vm</code> for instances)
* The '''region abbreviation''' (e.g., <code>ma</code> for Mannheim)
* The '''domain suffix''': <code>.bwcloud-os-instance.de.</code>

'''Example:'''

If your instance name is <code>instance-name</code> the project is called <code>project-name</code> and it runs in Mannheim (<code>ma</code>), the FQDN will be:<pre>instance-name.project-name.vm.ma.bwcloud-os-instance.de</pre>The FQDN can also be found in the '''[https://portal.ul.bwcos.de/ Dashboard]''', under '''Instances''' -> '''Instance Name''' -> '''Interfaces''' -> '''Name'''.

== Can I get a request more DNS records in bwCloud-OS? ==

Yes.

We manage the top level domain <code>bwcloud-os-instance.de.</code> It is possible to request a DNS record for a floating IP for example.

== Can I obtain a custom domain through bwCloud-OS? ==


No, bwCloud-OS does '''not''' provide custom '''domain registration'''. However, you can use your own domain — either through your home institution or an external domain provider — to point to your instance.

Some options o achieve this are described below.

== How can I point a domain to an instance? ==


You can point a domain to your instance in two main ways:

==== 🔹 CNAME to the instance FQDN ====
Since the FQDN is persistent for the lifetime of the instance (even if the instance is stopped and started again), you can safely set a CNAME record like:

<code>myvm.example.org → instance-name.project-name.vm.region.bwcloud-os-instance.de</code>

==== 🔹 Dynamic DNS ====
Alternatively, you can configure a Dynamic DNS setup where your VM updates its IP in a third party DNS service — especially if you don’t have your own domain, or your use case involves frequently changing IPs or multiple IPs.

== Does bwCloud-OS provide TLS/SSL certificates? ==


No, bwCloud-OS does '''not''' provide '''certificates.''' However, you can obtain certificates directly from public providers like '''Let’s Encrypt''' using tools such as '''Certbot''' that you install and run on your instance.

Key User: Migration Guide

2026-03-19T14:37:34Z

Admin: /* Networks */

{| class="mw-message-box mw-message-box-warning"
| style="vertical-align:middle;" | '''⚠️ Please Note:''' This guide is still work in progress.
|}

{{InANutshell|
<li>Both bwCloud-OS environments are completely independent.</li>
<li>Security groups won't carry over automatically.</li>
<li>Networks and IP addresses will change.</li>
<li>You can either start a new instance (VM) and copy your old data over, or migrate the old VM yourself.</li>
<li>For migrating volumes, attach a fresh volume to a new VM in the new cloud and copy your data directly over the network using rsync.</li>
}}

__TOC__

= General Information =

This guide explains how to migrate your resources from the old bwCloud-OS Gen2 environment to bwCloud-OS Gen3. Because the two environments are completely separated, there is no automatic migration path. You will need to manually export your resources from the old cloud, download them locally, and upload them to the new cloud. Please note that network settings and Security Groups cannot be copied and must be reconfigured manually in the new environment.

=== Dashboard Login ===

* [https://portal.bw-cloud.org/ Old bwCloud-OS Gen2]
* [https://portal.ul.bwcos.de/auth/login/?next=/%20https://portal.ul.bwcos.de/ New bwCloud-OS Gen3]

=== Networks ===

The new bwCloud-OS Gen3 environment includes significant changes to the network architecture. These region-specific changes are described in the following Guide.

➡️ [[Guide:_Network_Configuration_by_Region|Guide: Network Configuration by Region]]

= Transferring =

== Transferring Volumes ==

While it is technically possible to migrate a Cinder volume by converting it to an image and uploading it to the new cloud, we do not recommend this approach. The process is extremely slow, and depending on the backend configuration, the upload may silently fail entirely.

'''Our recommendation: create a fresh volume and copy your data over the network.'''
* In the new environment, create a new empty volume of the appropriate size and attach it to a new VM.
* Format and mount the volume on the new VM. Detailed instructions can be found [[Guide:_Volumes_and_Images#Create_and_Attach_a_Volume|here]].
* Make sure your old VM (with the old volume mounted) is reachable from the new VM via SSH (either by exchanging SSH keys or setting a password in the VM).
* Sync your data directly over the network using '''rsync'''.

<pre>
rsync -avz --progress /path/to/old/data/ root@<NEW_VM_IP>:/path/to/new/destination/
</pre>

== Transferring VMs ==

==== Prerequisites ====
* Access to both bwCloud-OS environments and
* Application Credentials, as described [[Programmatic_Access_and_Automation#Application_Credentials|here]]
* OpenStack Client installed, as described [[Programmatic_Access_and_Automation#OpenStack_Client|here]]

When transferring a VM, you create a snapshot of its current state, download it, and use it as a base image in the new environment.

'''Step 1: Create a Snapshot'''

First, source your old bwCloud-OS Gen2 credentials and find the ID of the instance (VM) you want to migrate:

<pre>
source old-creds.sh
openstack server list
openstack server image create --name <snapshot_name> <instance_id>
</pre>

'''Step 2: Download the Snapshot'''

The Image ID should have been prompted in the previous step. However, it is also possible to find the ID of your created snapshot and download it to your local computer later:

<pre>
openstack image list
openstack image save --file myimage.img <snapshot_id>
</pre>

'''Step 3: Upload to the New Environment (bwCloud-OS Gen3)'''

Source your new cloud credentials and upload the image file. '''Important''': Always set the visibility to Private so other users cannot use your image as a base for their services.

<pre>
source new-creds.sh
openstack image create --file myimage.img --private myimage
</pre>

Alternative: You can also upload the downloaded .img file using the new Horizon GUI by navigating to '''Compute -> Images'''.

'''Step 4: Start the Instance'''

You can now start a new instance using this uploaded image. Remember to reconfigure your '''Security Groups''' and note that you will receive a '''new IP address'''.

To start a new instance:
* Log in to the bwCloud-OS Gen3 Dashboard.
* Navigate to Project --> Compute --> Images. The uploaded snapshot should be listed there.
* Click on "Start", choose an instance name, and select the network and SSH key (or create a new one).

Key User: Migration Guide

2026-03-19T14:37:21Z

Admin: /* General Information */

{| class="mw-message-box mw-message-box-warning"
| style="vertical-align:middle;" | '''⚠️ Please Note:''' This guide is still work in progress.
|}

{{InANutshell|
<li>Both bwCloud-OS environments are completely independent.</li>
<li>Security groups won't carry over automatically.</li>
<li>Networks and IP addresses will change.</li>
<li>You can either start a new instance (VM) and copy your old data over, or migrate the old VM yourself.</li>
<li>For migrating volumes, attach a fresh volume to a new VM in the new cloud and copy your data directly over the network using rsync.</li>
}}

__TOC__

= General Information =

This guide explains how to migrate your resources from the old bwCloud-OS Gen2 environment to bwCloud-OS Gen3. Because the two environments are completely separated, there is no automatic migration path. You will need to manually export your resources from the old cloud, download them locally, and upload them to the new cloud. Please note that network settings and Security Groups cannot be copied and must be reconfigured manually in the new environment.

=== Dashboard Login ===

* [https://portal.bw-cloud.org/ Old bwCloud-OS Gen2]
* [https://portal.ul.bwcos.de/auth/login/?next=/%20https://portal.ul.bwcos.de/ New bwCloud-OS Gen3]

=== Networks ===

The new bwCloud-OS Gen3 environment includes significant changes to the network architecture. These region-specific changes are described in the following Guide.
➡️ [[Guide:_Network_Configuration_by_Region|Guide: Network Configuration by Region]]

= Transferring =

== Transferring Volumes ==

While it is technically possible to migrate a Cinder volume by converting it to an image and uploading it to the new cloud, we do not recommend this approach. The process is extremely slow, and depending on the backend configuration, the upload may silently fail entirely.

'''Our recommendation: create a fresh volume and copy your data over the network.'''
* In the new environment, create a new empty volume of the appropriate size and attach it to a new VM.
* Format and mount the volume on the new VM. Detailed instructions can be found [[Guide:_Volumes_and_Images#Create_and_Attach_a_Volume|here]].
* Make sure your old VM (with the old volume mounted) is reachable from the new VM via SSH (either by exchanging SSH keys or setting a password in the VM).
* Sync your data directly over the network using '''rsync'''.

<pre>
rsync -avz --progress /path/to/old/data/ root@<NEW_VM_IP>:/path/to/new/destination/
</pre>

== Transferring VMs ==

==== Prerequisites ====
* Access to both bwCloud-OS environments and
* Application Credentials, as described [[Programmatic_Access_and_Automation#Application_Credentials|here]]
* OpenStack Client installed, as described [[Programmatic_Access_and_Automation#OpenStack_Client|here]]

When transferring a VM, you create a snapshot of its current state, download it, and use it as a base image in the new environment.

'''Step 1: Create a Snapshot'''

First, source your old bwCloud-OS Gen2 credentials and find the ID of the instance (VM) you want to migrate:

<pre>
source old-creds.sh
openstack server list
openstack server image create --name <snapshot_name> <instance_id>
</pre>

'''Step 2: Download the Snapshot'''

The Image ID should have been prompted in the previous step. However, it is also possible to find the ID of your created snapshot and download it to your local computer later:

<pre>
openstack image list
openstack image save --file myimage.img <snapshot_id>
</pre>

'''Step 3: Upload to the New Environment (bwCloud-OS Gen3)'''

Source your new cloud credentials and upload the image file. '''Important''': Always set the visibility to Private so other users cannot use your image as a base for their services.

<pre>
source new-creds.sh
openstack image create --file myimage.img --private myimage
</pre>

Alternative: You can also upload the downloaded .img file using the new Horizon GUI by navigating to '''Compute -> Images'''.

'''Step 4: Start the Instance'''

You can now start a new instance using this uploaded image. Remember to reconfigure your '''Security Groups''' and note that you will receive a '''new IP address'''.

To start a new instance:
* Log in to the bwCloud-OS Gen3 Dashboard.
* Navigate to Project --> Compute --> Images. The uploaded snapshot should be listed there.
* Click on "Start", choose an instance name, and select the network and SSH key (or create a new one).

Key User: Migration Guide

2026-03-19T14:35:01Z

Admin: /* Network Changes */

{| class="mw-message-box mw-message-box-warning"
| style="vertical-align:middle;" | '''⚠️ Please Note:''' This guide is still work in progress.
|}

{{InANutshell|
<li>Both bwCloud-OS environments are completely independent.</li>
<li>Security groups won't carry over automatically.</li>
<li>Networks and IP addresses will change.</li>
<li>You can either start a new instance (VM) and copy your old data over, or migrate the old VM yourself.</li>
<li>For migrating volumes, attach a fresh volume to a new VM in the new cloud and copy your data directly over the network using rsync.</li>
}}

__TOC__

= General Information =

This guide explains how to migrate your resources from the old bwCloud-OS Gen2 environment to bwCloud-OS Gen3. Because the two environments are completely separated, there is no automatic migration path. You will need to manually export your resources from the old cloud, download them locally, and upload them to the new cloud. Please note that network settings and Security Groups cannot be copied and must be reconfigured manually in the new environment.

=== Dashboard Login ===

* [https://portal.bw-cloud.org/ Old bwCloud-OS Gen2]
* [https://portal.ul.bwcos.de/auth/login/?next=/%20https://portal.ul.bwcos.de/ New bwCloud-OS Gen3]

=== Networks ===

The new bwCloud-OS Gen3 environment includes significant changes to the network architecture. These region-specific changes are described in this [[Guide:_Network_Configuration_by_Region|guide]].

= Transferring =

== Transferring Volumes ==

While it is technically possible to migrate a Cinder volume by converting it to an image and uploading it to the new cloud, we do not recommend this approach. The process is extremely slow, and depending on the backend configuration, the upload may silently fail entirely.

'''Our recommendation: create a fresh volume and copy your data over the network.'''
* In the new environment, create a new empty volume of the appropriate size and attach it to a new VM.
* Format and mount the volume on the new VM. Detailed instructions can be found [[Guide:_Volumes_and_Images#Create_and_Attach_a_Volume|here]].
* Make sure your old VM (with the old volume mounted) is reachable from the new VM via SSH (either by exchanging SSH keys or setting a password in the VM).
* Sync your data directly over the network using '''rsync'''.

<pre>
rsync -avz --progress /path/to/old/data/ root@<NEW_VM_IP>:/path/to/new/destination/
</pre>

== Transferring VMs ==

==== Prerequisites ====
* Access to both bwCloud-OS environments and
* Application Credentials, as described [[Programmatic_Access_and_Automation#Application_Credentials|here]]
* OpenStack Client installed, as described [[Programmatic_Access_and_Automation#OpenStack_Client|here]]

When transferring a VM, you create a snapshot of its current state, download it, and use it as a base image in the new environment.

'''Step 1: Create a Snapshot'''

First, source your old bwCloud-OS Gen2 credentials and find the ID of the instance (VM) you want to migrate:

<pre>
source old-creds.sh
openstack server list
openstack server image create --name <snapshot_name> <instance_id>
</pre>

'''Step 2: Download the Snapshot'''

The Image ID should have been prompted in the previous step. However, it is also possible to find the ID of your created snapshot and download it to your local computer later:

<pre>
openstack image list
openstack image save --file myimage.img <snapshot_id>
</pre>

'''Step 3: Upload to the New Environment (bwCloud-OS Gen3)'''

Source your new cloud credentials and upload the image file. '''Important''': Always set the visibility to Private so other users cannot use your image as a base for their services.

<pre>
source new-creds.sh
openstack image create --file myimage.img --private myimage
</pre>

Alternative: You can also upload the downloaded .img file using the new Horizon GUI by navigating to '''Compute -> Images'''.

'''Step 4: Start the Instance'''

You can now start a new instance using this uploaded image. Remember to reconfigure your '''Security Groups''' and note that you will receive a '''new IP address'''.

To start a new instance:
* Log in to the bwCloud-OS Gen3 Dashboard.
* Navigate to Project --> Compute --> Images. The uploaded snapshot should be listed there.
* Click on "Start", choose an instance name, and select the network and SSH key (or create a new one).

Key User: Migration Guide

2026-03-19T14:31:53Z

Admin: /* General Information */

{| class="mw-message-box mw-message-box-warning"
| style="vertical-align:middle;" | '''⚠️ Please Note:''' This guide is still work in progress.
|}

{{InANutshell|
<li>Both bwCloud-OS environments are completely independent.</li>
<li>Security groups won't carry over automatically.</li>
<li>Networks and IP addresses will change.</li>
<li>You can either start a new instance (VM) and copy your old data over, or migrate the old VM yourself.</li>
<li>For migrating volumes, attach a fresh volume to a new VM in the new cloud and copy your data directly over the network using rsync.</li>
}}

__TOC__

= General Information =

This guide explains how to migrate your resources from the old bwCloud-OS Gen2 environment to bwCloud-OS Gen3. Because the two environments are completely separated, there is no automatic migration path. You will need to manually export your resources from the old cloud, download them locally, and upload them to the new cloud. Please note that network settings and Security Groups cannot be copied and must be reconfigured manually in the new environment.

=== Dashboard Login ===

* [https://portal.bw-cloud.org/ Old bwCloud-OS Gen2]
* [https://portal.ul.bwcos.de/auth/login/?next=/%20https://portal.ul.bwcos.de/ New bwCloud-OS Gen3]

=== Network Changes ===

= Transferring =

== Transferring Volumes ==

While it is technically possible to migrate a Cinder volume by converting it to an image and uploading it to the new cloud, we do not recommend this approach. The process is extremely slow, and depending on the backend configuration, the upload may silently fail entirely.

'''Our recommendation: create a fresh volume and copy your data over the network.'''
* In the new environment, create a new empty volume of the appropriate size and attach it to a new VM.
* Format and mount the volume on the new VM. Detailed instructions can be found [[Guide:_Volumes_and_Images#Create_and_Attach_a_Volume|here]].
* Make sure your old VM (with the old volume mounted) is reachable from the new VM via SSH (either by exchanging SSH keys or setting a password in the VM).
* Sync your data directly over the network using '''rsync'''.

<pre>
rsync -avz --progress /path/to/old/data/ root@<NEW_VM_IP>:/path/to/new/destination/
</pre>

== Transferring VMs ==

==== Prerequisites ====
* Access to both bwCloud-OS environments and
* Application Credentials, as described [[Programmatic_Access_and_Automation#Application_Credentials|here]]
* OpenStack Client installed, as described [[Programmatic_Access_and_Automation#OpenStack_Client|here]]

When transferring a VM, you create a snapshot of its current state, download it, and use it as a base image in the new environment.

'''Step 1: Create a Snapshot'''

First, source your old bwCloud-OS Gen2 credentials and find the ID of the instance (VM) you want to migrate:

<pre>
source old-creds.sh
openstack server list
openstack server image create --name <snapshot_name> <instance_id>
</pre>

'''Step 2: Download the Snapshot'''

The Image ID should have been prompted in the previous step. However, it is also possible to find the ID of your created snapshot and download it to your local computer later:

<pre>
openstack image list
openstack image save --file myimage.img <snapshot_id>
</pre>

'''Step 3: Upload to the New Environment (bwCloud-OS Gen3)'''

Source your new cloud credentials and upload the image file. '''Important''': Always set the visibility to Private so other users cannot use your image as a base for their services.

<pre>
source new-creds.sh
openstack image create --file myimage.img --private myimage
</pre>

Alternative: You can also upload the downloaded .img file using the new Horizon GUI by navigating to '''Compute -> Images'''.

'''Step 4: Start the Instance'''

You can now start a new instance using this uploaded image. Remember to reconfigure your '''Security Groups''' and note that you will receive a '''new IP address'''.

To start a new instance:
* Log in to the bwCloud-OS Gen3 Dashboard.
* Navigate to Project --> Compute --> Images. The uploaded snapshot should be listed there.
* Click on "Start", choose an instance name, and select the network and SSH key (or create a new one).

Key User: Migration Guide

2026-03-19T14:30:59Z

Admin: /* General Information */

{| class="mw-message-box mw-message-box-warning"
| style="vertical-align:middle;" | '''⚠️ Please Note:''' This guide is still work in progress.
|}

{{InANutshell|
<li>Both bwCloud-OS environments are completely independent.</li>
<li>Security groups won't carry over automatically.</li>
<li>Networks and IP addresses will change.</li>
<li>You can either start a new instance (VM) and copy your old data over, or migrate the old VM yourself.</li>
<li>For migrating volumes, attach a fresh volume to a new VM in the new cloud and copy your data directly over the network using rsync.</li>
}}

__TOC__

= General Information =

This guide explains how to migrate your resources from the old bwCloud-OS Gen2 environment to bwCloud-OS Gen3. Because the two environments are completely separated, there is no automatic migration path. You will need to manually export your resources from the old cloud, download them locally, and upload them to the new cloud. Please note that network settings and Security Groups cannot be copied and must be reconfigured manually in the new environment.

'''Dashboard Login:'''
* [https://portal.bw-cloud.org/ Old bwCloud-OS Gen2]
* [https://portal.ul.bwcos.de/auth/login/?next=/%20https://portal.ul.bwcos.de/ New bwCloud-OS Gen3]

= Transferring =

== Transferring Volumes ==

While it is technically possible to migrate a Cinder volume by converting it to an image and uploading it to the new cloud, we do not recommend this approach. The process is extremely slow, and depending on the backend configuration, the upload may silently fail entirely.

'''Our recommendation: create a fresh volume and copy your data over the network.'''
* In the new environment, create a new empty volume of the appropriate size and attach it to a new VM.
* Format and mount the volume on the new VM. Detailed instructions can be found [[Guide:_Volumes_and_Images#Create_and_Attach_a_Volume|here]].
* Make sure your old VM (with the old volume mounted) is reachable from the new VM via SSH (either by exchanging SSH keys or setting a password in the VM).
* Sync your data directly over the network using '''rsync'''.

<pre>
rsync -avz --progress /path/to/old/data/ root@<NEW_VM_IP>:/path/to/new/destination/
</pre>

== Transferring VMs ==

==== Prerequisites ====
* Access to both bwCloud-OS environments and
* Application Credentials, as described [[Programmatic_Access_and_Automation#Application_Credentials|here]]
* OpenStack Client installed, as described [[Programmatic_Access_and_Automation#OpenStack_Client|here]]

When transferring a VM, you create a snapshot of its current state, download it, and use it as a base image in the new environment.

'''Step 1: Create a Snapshot'''

First, source your old bwCloud-OS Gen2 credentials and find the ID of the instance (VM) you want to migrate:

<pre>
source old-creds.sh
openstack server list
openstack server image create --name <snapshot_name> <instance_id>
</pre>

'''Step 2: Download the Snapshot'''

The Image ID should have been prompted in the previous step. However, it is also possible to find the ID of your created snapshot and download it to your local computer later:

<pre>
openstack image list
openstack image save --file myimage.img <snapshot_id>
</pre>

'''Step 3: Upload to the New Environment (bwCloud-OS Gen3)'''

Source your new cloud credentials and upload the image file. '''Important''': Always set the visibility to Private so other users cannot use your image as a base for their services.

<pre>
source new-creds.sh
openstack image create --file myimage.img --private myimage
</pre>

Alternative: You can also upload the downloaded .img file using the new Horizon GUI by navigating to '''Compute -> Images'''.

'''Step 4: Start the Instance'''

You can now start a new instance using this uploaded image. Remember to reconfigure your '''Security Groups''' and note that you will receive a '''new IP address'''.

To start a new instance:
* Log in to the bwCloud-OS Gen3 Dashboard.
* Navigate to Project --> Compute --> Images. The uploaded snapshot should be listed there.
* Click on "Start", choose an instance name, and select the network and SSH key (or create a new one).

Key User: Migration Guide

2026-03-19T14:30:44Z

Admin: /* General Information */

{| class="mw-message-box mw-message-box-warning"
| style="vertical-align:middle;" | '''⚠️ Please Note:''' This guide is still work in progress.
|}

{{InANutshell|
<li>Both bwCloud-OS environments are completely independent.</li>
<li>Security groups won't carry over automatically.</li>
<li>Networks and IP addresses will change.</li>
<li>You can either start a new instance (VM) and copy your old data over, or migrate the old VM yourself.</li>
<li>For migrating volumes, attach a fresh volume to a new VM in the new cloud and copy your data directly over the network using rsync.</li>
}}

__TOC__

= General Information =

This guide explains how to migrate your resources from the old bwCloud-OS Gen2 environment to bwCloud-OS Gen3. Because the two environments are completely separated, there is no automatic migration path. You will need to manually export your resources from the old cloud, download them locally, and upload them to the new cloud. Please note that network settings and Security Groups cannot be copied and must be reconfigured manually in the new environment.

'''Dashboard Login:'''
* [https://portal.bw-cloud.org/ Old bwCloud-OS Gen2]: https://portal.bw-cloud.org/
* [https://portal.ul.bwcos.de/auth/login/?next=/%20https://portal.ul.bwcos.de/ New bwCloud-OS Gen3]: [https://portal.ul.bwcos.de/auth/login/?next=/ https://portal.ul.bwcos.de/]

= Transferring =

== Transferring Volumes ==

While it is technically possible to migrate a Cinder volume by converting it to an image and uploading it to the new cloud, we do not recommend this approach. The process is extremely slow, and depending on the backend configuration, the upload may silently fail entirely.

'''Our recommendation: create a fresh volume and copy your data over the network.'''
* In the new environment, create a new empty volume of the appropriate size and attach it to a new VM.
* Format and mount the volume on the new VM. Detailed instructions can be found [[Guide:_Volumes_and_Images#Create_and_Attach_a_Volume|here]].
* Make sure your old VM (with the old volume mounted) is reachable from the new VM via SSH (either by exchanging SSH keys or setting a password in the VM).
* Sync your data directly over the network using '''rsync'''.

<pre>
rsync -avz --progress /path/to/old/data/ root@<NEW_VM_IP>:/path/to/new/destination/
</pre>

== Transferring VMs ==

==== Prerequisites ====
* Access to both bwCloud-OS environments and
* Application Credentials, as described [[Programmatic_Access_and_Automation#Application_Credentials|here]]
* OpenStack Client installed, as described [[Programmatic_Access_and_Automation#OpenStack_Client|here]]

When transferring a VM, you create a snapshot of its current state, download it, and use it as a base image in the new environment.

'''Step 1: Create a Snapshot'''

First, source your old bwCloud-OS Gen2 credentials and find the ID of the instance (VM) you want to migrate:

<pre>
source old-creds.sh
openstack server list
openstack server image create --name <snapshot_name> <instance_id>
</pre>

'''Step 2: Download the Snapshot'''

The Image ID should have been prompted in the previous step. However, it is also possible to find the ID of your created snapshot and download it to your local computer later:

<pre>
openstack image list
openstack image save --file myimage.img <snapshot_id>
</pre>

'''Step 3: Upload to the New Environment (bwCloud-OS Gen3)'''

Source your new cloud credentials and upload the image file. '''Important''': Always set the visibility to Private so other users cannot use your image as a base for their services.

<pre>
source new-creds.sh
openstack image create --file myimage.img --private myimage
</pre>

Alternative: You can also upload the downloaded .img file using the new Horizon GUI by navigating to '''Compute -> Images'''.

'''Step 4: Start the Instance'''

You can now start a new instance using this uploaded image. Remember to reconfigure your '''Security Groups''' and note that you will receive a '''new IP address'''.

To start a new instance:
* Log in to the bwCloud-OS Gen3 Dashboard.
* Navigate to Project --> Compute --> Images. The uploaded snapshot should be listed there.
* Click on "Start", choose an instance name, and select the network and SSH key (or create a new one).

Key User: Migration Guide

2026-03-16T14:00:10Z

Admin:

{| class="mw-message-box mw-message-box-warning"
| style="vertical-align:middle;" | '''⚠️ Please Note:''' This guide is still work in progress.
|}

{{InANutshell|
<li>Both bwCloud-OS environments are completely independent.</li>
<li>Security groups won't carry over automatically.</li>
<li>Networks and IP addresses will change.</li>
<li>You can either start a new instance (VM) and copy your old data over, or migrate the old VM yourself.</li>
<li>For migrating volumes, attach a fresh volume to a new VM in the new cloud and copy your data directly over the network using rsync.</li>
}}

__TOC__

= General Information =

This guide explains how to migrate your resources from the old bwCloud-OS Gen2 environment to bwCloud-OS Gen3. Because the two environments are completely separated, there is no automatic migration path. You will need to manually export your resources from the old cloud, download them locally, and upload them to the new cloud. Please note that network settings and Security Groups cannot be copied and must be reconfigured manually in the new environment.

'''Login:'''
* Old bwCloud-OS Gen2: https://portal.bw-cloud.org/
* New bwCloud-OS Gen3: ....

= Transferring =

== Transferring Volumes ==

While it is technically possible to migrate a Cinder volume by converting it to an image and uploading it to the new cloud, we do not recommend this approach. The process is extremely slow, and depending on the backend configuration, the upload may silently fail entirely.

'''Our recommendation: create a fresh volume and copy your data over the network.'''
* In the new environment, create a new empty volume of the appropriate size and attach it to a new VM.
* Format and mount the volume on the new VM. Detailed instructions can be found [[Guide:_Volumes_and_Images#Create_and_Attach_a_Volume|here]].
* Make sure your old VM (with the old volume mounted) is reachable from the new VM via SSH (either by exchanging SSH keys or setting a password in the VM).
* Sync your data directly over the network using '''rsync'''.

<pre>
rsync -avz --progress /path/to/old/data/ root@<NEW_VM_IP>:/path/to/new/destination/
</pre>

== Transferring VMs ==

==== Prerequisites ====
* Access to both bwCloud-OS environments and
* Application Credentials, as described [[Programmatic_Access_and_Automation#Application_Credentials|here]]
* OpenStack Client installed, as described [[Programmatic_Access_and_Automation#OpenStack_Client|here]]

When transferring a VM, you create a snapshot of its current state, download it, and use it as a base image in the new environment.

'''Step 1: Create a Snapshot'''

First, source your old bwCloud-OS Gen2 credentials and find the ID of the instance (VM) you want to migrate:

<pre>
source old-creds.sh
openstack server list
openstack server image create --name <snapshot_name> <instance_id>
</pre>

'''Step 2: Download the Snapshot'''

The Image ID should have been prompted in the previous step. However, it is also possible to find the ID of your created snapshot and download it to your local computer later:

<pre>
openstack image list
openstack image save --file myimage.img <snapshot_id>
</pre>

'''Step 3: Upload to the New Environment (bwCloud-OS Gen3)'''

Source your new cloud credentials and upload the image file. '''Important''': Always set the visibility to Private so other users cannot use your image as a base for their services.

<pre>
source new-creds.sh
openstack image create --file myimage.img --private myimage
</pre>

Alternative: You can also upload the downloaded .img file using the new Horizon GUI by navigating to '''Compute -> Images'''.

'''Step 4: Start the Instance'''

You can now start a new instance using this uploaded image. Remember to reconfigure your '''Security Groups''' and note that you will receive a '''new IP address'''.

To start a new instance:
* Log in to the bwCloud-OS Gen3 Dashboard.
* Navigate to Project --> Compute --> Images. The uploaded snapshot should be listed there.
* Click on "Start", choose an instance name, and select the network and SSH key (or create a new one).

Key User: Migration Guide

2026-03-16T13:59:40Z

Admin: Created page with "{| class="mw-message-box mw-message-box-warning" | style="vertical-align:middle;" | '''⚠️ Please Note:''' This guide is still work in progress. |} {{InANutshell| <li>Both bwCloud-OS environments are completely independent.</li> <li>Security groups won't carry over automatically.</li> <li>Networks and IP addresses will change.</li> <li>You can either start a new instance (VM) and copy your old data over, or migrate the old VM yourself.</li> <li>For migrating volumes..."

{| class="mw-message-box mw-message-box-warning"
| style="vertical-align:middle;" | '''⚠️ Please Note:''' This guide is still work in progress.
|}

{{InANutshell|
<li>Both bwCloud-OS environments are completely independent.</li>
<li>Security groups won't carry over automatically.</li>
<li>Networks and IP addresses will change.</li>
<li>You can either start a new instance (VM) and copy your old data over, or migrate the old VM yourself.</li>
<li>For migrating volumes, attach a fresh volume to a new VM in the new cloud and copy your data directly over the network using rsync.</li>
}}

__TOC__

= General Information =

This guide explains how to migrate your resources from the old bwCloud-OS Gen2 environment to bwCloud-OS Gen3. Because the two environments are completely separated, there is no automatic migration path. You will need to manually export your resources from the old cloud, download them locally, and upload them to the new cloud. Please note that network settings and Security Groups cannot be copied and must be reconfigured manually in the new environment.

'''Login:'''
* Old bwCloud-OS Gen2: https://portal.bw-cloud.org/
* New bwCloud-OS Gen3: ....

= Transferring =

== Transferring Volumes ==

While it is technically possible to migrate a Cinder volume by converting it to an image and uploading it to the new cloud, we do not recommend this approach. The process is extremely slow, and depending on the backend configuration, the upload may silently fail entirely.

'''Our recommendation: create a fresh volume and copy your data over the network.'''
* In the new environment, create a new empty volume of the appropriate size and attach it to a new VM.
* Format and mount the volume on the new VM. Detailed instructions can be found [[Guide:_Volumes_and_Images#Create_and_Attach_a_Volume|here]].
* Make sure your old VM (with the old volume mounted) is reachable from the new VM via SSH (either by exchanging SSH keys or setting a password in the VM).
* Sync your data directly over the network using '''rsync'''.

<pre>
rsync -avz --progress /path/to/old/data/ root@<NEW_VM_IP>:/path/to/new/destination/
</pre>

== Transferring VMs ==

==== Prerequisites ====
* Access to both bwCloud-OS environments and
* Application Credentials, as described [[Programmatic_Access_and_Automation#Application_Credentials|here]]
* OpenStack Client installed, as described [[Programmatic_Access_and_Automation#OpenStack_Client|here]]

When transferring a VM, you create a snapshot of its current state, download it, and use it as a base image in the new environment.

'''Step 1: Create a Snapshot'''

First, source your old bwCloud-OS Gen2 credentials and find the ID of the instance (VM) you want to migrate:

<pre>
source old-creds.sh
openstack server list
openstack server image create --name <snapshot_name> <instance_id>
</pre>

'''Step 2: Download the Snapshot'''

The Image ID should have been prompted in the previous step. However, it is also possible to find the ID of your created snapshot and download it to your local computer later:

<pre>
openstack image list
openstack image save --file myimage.img <snapshot_id>
</pre>

'''Step 3: Upload to the New Environment (bwCloud-OS Gen3)'''

Source your new cloud credentials and upload the image file. '''Important''': Always set the visibility to Private so other users cannot use your image as a base for their services.

<pre>
source new-creds.sh
openstack image create --file myimage.img --private myimage
</pre>

Alternative: You can also upload the downloaded .img file using the new Horizon GUI by navigating to '''Compute -> Images'''.

'''Step 4: Start the Instance'''

You can now start a new instance using this uploaded image. Remember to reconfigure your '''Security Groups''' and note that you will receive a '''new IP address'''.

To start a new instance:
* Log in to the bwCloud-OS Gen3 Dashboard.
* Navigate to Project --> Compute --> Images. The uploaded snapshot should be listed there.
* Click on "Start", choose an instance name, and select the network and SSH key (or create a new one).

Networks Gen3

2026-03-16T13:54:27Z

Admin: /* Will my instance receive a public IP? */

{{InANutshell|
<li>Each bwCloud-OS instance launched using the standard method is automatically assigned a public IP address.</li>
<li>Instances are also assigned a persistent FQDN based on their name, project and region.</li>
<li>Domain hosting is not provided, but you can point your own domain to the instance’s FQDN using a CNAME record.</li>
}}

__TOC__

= Networks & IP-addresses =

== Will my instance receive a public IP? ==

IPv6-addresses: yes

IPv4-addresses: no

By default every VM will receive a private IPv4-addresses. Egress IPv4 connectivity is provided via SNAT.

'''📌 Note:''' IPv4 ingress connectivity is also possible in every region via request.

'''📌 Note:''' Each '''region''' in bwCloud-OS has its '''own set of IP address ranges.'''

[[Guide:_Public_IPv4_Allocation_in_Regions|➡️ A detailed Guide to public IPv4 allocation in Regions]]

== How long does an IP remain assigned to my instance? ==


The IP address(es''')''' assigned to your instance remains associated with it for the entire lifetime of the instance — even if you stop (shut down) the instance.

The IP is only released when the instance is deleted (terminated). After termination, the IP is returned to the regional pool and may be reassigned to another instance in the region.

'''📌 Note:''' Floating IPs will remain even after an Instance deletion. They have to be released manually.

== Are Floating IPs also available for instances? ==


Yes.

Floating IPs provide a mechanism to 1:1 NAT a public IPv4 addresse to a private IPv4 address of an instance enabling ingress IPv4 connectivity.

For more information and detailed setup instructions, see the guide below.

➡️ [[Guide: Routers and Floating IPs|Routers and Floating IPs Guide]].

= Domains and FQDNs =

== Does bwCloud-OS also assign FQDNs? ==


Yes. Every running instance in bwCloud-OS is automatically assigned a '''generic hostname (FQDN)'''. This allows the instance to be reached via a '''persistent network identifier''', even if its public IP address changes. This FQDN is valid for the '''lifetime''' of the instance.

==== Format of the instance's FQDN ====

* The '''UUID''' '''of the instance'''
* The '''project name'''
* The '''region abbreviation''' (e.g., <code>ma</code> for Mannheim)
* The '''domain suffix''': <code>.bw-cloud-instance.org</code>

'''Example:'''

If your instance name is <code>kos</code>, the project is called <code>yarn</code> and it runs in Mannheim (<code>ma</code>), the FQDN will be:<pre>kos.yarn.vm.ma.bwcloud-os-instance.de.</pre>The FQDN can also be found in the '''[https://portal.bw-cloud.org/ Dashboard]''', on the '''Instances''' -> '''Network''' -> '''Interface''' page.

== Can I get a request more DNS records in bwCloud-OS? ==

Yes.

We manage the top level domain <code>bwcloud-os-instance.de.</code> It is possible to request a DNS record for a floating IP for example.

== Can I get a custom domain via bwCloud-OS? ==


No, bwCloud-OS does '''not''' provide custom '''domain hosting'''. However, you can use your '''own domain''' — either through your home institution or an external domain provider — to '''point to your instance'''.

Some options are described below.

== How can I point a domain to an instance? ==


You can point a domain to your instance in two main ways:

==== 🔹 CNAME to the instance FQDN ====
The instance’s FQDN is based on its UUID and region. Since the UUID is persistent for the instance's lifetime (even if the instance is stopped and started again), you can safely set a CNAME record like:

<code>myvm.example.org → instance-name.project-name.vm.region.bwcloud-os-instance.de</code>

==== 🔹 Dynamic DNS ====
Alternatively, you can configure a Dynamic DNS setup where your VM updates its IP in a third-party DNS service — especially if you don’t have your own domain, or your use case involves frequently changing or multiple IPs.

== Can I get a certificate from bwCloud-OS? ==


No, bwCloud-OS does '''not''' provide '''certificates.''' However, you can obtain certificates directly from public providers like '''Let’s Encrypt''' using tools such as '''Certbot''', which you install and run on your instance.

Networks Gen3

2026-03-16T13:54:16Z

Admin: /* Will my instance receive a public IP? */

{{InANutshell|
<li>Each bwCloud-OS instance launched using the standard method is automatically assigned a public IP address.</li>
<li>Instances are also assigned a persistent FQDN based on their name, project and region.</li>
<li>Domain hosting is not provided, but you can point your own domain to the instance’s FQDN using a CNAME record.</li>
}}

__TOC__

= Networks & IP-addresses =

== Will my instance receive a public IP? ==

IPv6-addresses: yes

IPv4-addresses: no

By default every VM will receive a private IPv4-addresses. Egress IPv4 connectivity is provided via SNAT.

'''📌 Note:''' IPv4 ingress connectivity is also possible in every region via request.

'''📌 Note:''' Each '''region''' in bwCloud-OS has its '''own set of IP address ranges.'''

[[Guide:_Public_IPv4_Allocation_in_Regions|➡️ A detailed Guide to public IPv4 allocation in Regions]]

== How long does an IP remain assigned to my instance? ==


The IP address(es''')''' assigned to your instance remains associated with it for the entire lifetime of the instance — even if you stop (shut down) the instance.

The IP is only released when the instance is deleted (terminated). After termination, the IP is returned to the regional pool and may be reassigned to another instance in the region.

'''📌 Note:''' Floating IPs will remain even after an Instance deletion. They have to be released manually.

== Are Floating IPs also available for instances? ==


Yes.

Floating IPs provide a mechanism to 1:1 NAT a public IPv4 addresse to a private IPv4 address of an instance enabling ingress IPv4 connectivity.

For more information and detailed setup instructions, see the guide below.

➡️ [[Guide: Routers and Floating IPs|Routers and Floating IPs Guide]].

= Domains and FQDNs =

== Does bwCloud-OS also assign FQDNs? ==


Yes. Every running instance in bwCloud-OS is automatically assigned a '''generic hostname (FQDN)'''. This allows the instance to be reached via a '''persistent network identifier''', even if its public IP address changes. This FQDN is valid for the '''lifetime''' of the instance.

==== Format of the instance's FQDN ====

* The '''UUID''' '''of the instance'''
* The '''project name'''
* The '''region abbreviation''' (e.g., <code>ma</code> for Mannheim)
* The '''domain suffix''': <code>.bw-cloud-instance.org</code>

'''Example:'''

If your instance name is <code>kos</code>, the project is called <code>yarn</code> and it runs in Mannheim (<code>ma</code>), the FQDN will be:<pre>kos.yarn.vm.ma.bwcloud-os-instance.de.</pre>The FQDN can also be found in the '''[https://portal.bw-cloud.org/ Dashboard]''', on the '''Instances''' -> '''Network''' -> '''Interface''' page.

== Can I get a request more DNS records in bwCloud-OS? ==

Yes.

We manage the top level domain <code>bwcloud-os-instance.de.</code> It is possible to request a DNS record for a floating IP for example.

== Can I get a custom domain via bwCloud-OS? ==


No, bwCloud-OS does '''not''' provide custom '''domain hosting'''. However, you can use your '''own domain''' — either through your home institution or an external domain provider — to '''point to your instance'''.

Some options are described below.

== How can I point a domain to an instance? ==


You can point a domain to your instance in two main ways:

==== 🔹 CNAME to the instance FQDN ====
The instance’s FQDN is based on its UUID and region. Since the UUID is persistent for the instance's lifetime (even if the instance is stopped and started again), you can safely set a CNAME record like:

<code>myvm.example.org → instance-name.project-name.vm.region.bwcloud-os-instance.de</code>

==== 🔹 Dynamic DNS ====
Alternatively, you can configure a Dynamic DNS setup where your VM updates its IP in a third-party DNS service — especially if you don’t have your own domain, or your use case involves frequently changing or multiple IPs.

== Can I get a certificate from bwCloud-OS? ==


No, bwCloud-OS does '''not''' provide '''certificates.''' However, you can obtain certificates directly from public providers like '''Let’s Encrypt''' using tools such as '''Certbot''', which you install and run on your instance.

Networks Gen3

2026-03-16T13:52:58Z

Admin: /* Will my instance receive a public IP? */

{{InANutshell|
<li>Each bwCloud-OS instance launched using the standard method is automatically assigned a public IP address.</li>
<li>Instances are also assigned a persistent FQDN based on their name, project and region.</li>
<li>Domain hosting is not provided, but you can point your own domain to the instance’s FQDN using a CNAME record.</li>
}}

__TOC__

= Networks & IP-addresses =

== Will my instance receive a public IP? ==

IPv6-addresses: yes

IPv4-addresses: no

By default every VM will receive a private IPv4-addresses. Egress IPv4 connectivity is provided via SNAT.

'''📌 Note:''' IPv4 ingress connectivity is also possible in every region via request.

'''📌 Note:''' Each '''region''' in bwCloud-OS has its '''own set of IP address ranges.''' A detailed [[Guide:_Public_IPv4_Allocation_in_Regions|Guide]] is available.

== How long does an IP remain assigned to my instance? ==


The IP address(es''')''' assigned to your instance remains associated with it for the entire lifetime of the instance — even if you stop (shut down) the instance.

The IP is only released when the instance is deleted (terminated). After termination, the IP is returned to the regional pool and may be reassigned to another instance in the region.

'''📌 Note:''' Floating IPs will remain even after an Instance deletion. They have to be released manually.

== Are Floating IPs also available for instances? ==


Yes.

Floating IPs provide a mechanism to 1:1 NAT a public IPv4 addresse to a private IPv4 address of an instance enabling ingress IPv4 connectivity.

For more information and detailed setup instructions, see the guide below.

➡️ [[Guide: Routers and Floating IPs|Routers and Floating IPs Guide]].

= Domains and FQDNs =

== Does bwCloud-OS also assign FQDNs? ==


Yes. Every running instance in bwCloud-OS is automatically assigned a '''generic hostname (FQDN)'''. This allows the instance to be reached via a '''persistent network identifier''', even if its public IP address changes. This FQDN is valid for the '''lifetime''' of the instance.

==== Format of the instance's FQDN ====

* The '''UUID''' '''of the instance'''
* The '''project name'''
* The '''region abbreviation''' (e.g., <code>ma</code> for Mannheim)
* The '''domain suffix''': <code>.bw-cloud-instance.org</code>

'''Example:'''

If your instance name is <code>kos</code>, the project is called <code>yarn</code> and it runs in Mannheim (<code>ma</code>), the FQDN will be:<pre>kos.yarn.vm.ma.bwcloud-os-instance.de.</pre>The FQDN can also be found in the '''[https://portal.bw-cloud.org/ Dashboard]''', on the '''Instances''' -> '''Network''' -> '''Interface''' page.

== Can I get a request more DNS records in bwCloud-OS? ==

Yes.

We manage the top level domain <code>bwcloud-os-instance.de.</code> It is possible to request a DNS record for a floating IP for example.

== Can I get a custom domain via bwCloud-OS? ==


No, bwCloud-OS does '''not''' provide custom '''domain hosting'''. However, you can use your '''own domain''' — either through your home institution or an external domain provider — to '''point to your instance'''.

Some options are described below.

== How can I point a domain to an instance? ==


You can point a domain to your instance in two main ways:

==== 🔹 CNAME to the instance FQDN ====
The instance’s FQDN is based on its UUID and region. Since the UUID is persistent for the instance's lifetime (even if the instance is stopped and started again), you can safely set a CNAME record like:

<code>myvm.example.org → instance-name.project-name.vm.region.bwcloud-os-instance.de</code>

==== 🔹 Dynamic DNS ====
Alternatively, you can configure a Dynamic DNS setup where your VM updates its IP in a third-party DNS service — especially if you don’t have your own domain, or your use case involves frequently changing or multiple IPs.

== Can I get a certificate from bwCloud-OS? ==


No, bwCloud-OS does '''not''' provide '''certificates.''' However, you can obtain certificates directly from public providers like '''Let’s Encrypt''' using tools such as '''Certbot''', which you install and run on your instance.

Guide: Network Configuration by Region

2026-03-16T13:52:09Z

Admin: Created page with "== Guide =="

== Guide ==

Networks Gen3

2026-03-16T13:51:18Z

Admin: Created page with " {{InANutshell| <li>Each bwCloud-OS instance launched using the standard method is automatically assigned a public IP address.</li> <li>Instances are also assigned a persistent FQDN based on their name, project and region.</li> <li>Domain hosting is not provided, but you can point your own domain to the instance’s FQDN using a CNAME record.</li> }} __TOC__ = Networks & IP-addresses..."

{{InANutshell|
<li>Each bwCloud-OS instance launched using the standard method is automatically assigned a public IP address.</li>
<li>Instances are also assigned a persistent FQDN based on their name, project and region.</li>
<li>Domain hosting is not provided, but you can point your own domain to the instance’s FQDN using a CNAME record.</li>
}}

__TOC__

= Networks & IP-addresses =

== Will my instance receive a public IP? ==

IPv6-addresses: yes

IPv4-addresses: no

By default every VM will receive a private IPv4-addresses. Egress IPv4 connectivity is provided via SNAT.

'''📌 Note:''' IPv4 ingress connectivity is also possible in every region via request.

'''📌 Note:''' Each '''region''' in bwCloud-OS has its '''own set of IP address ranges.'''

== How long does an IP remain assigned to my instance? ==


The IP address(es''')''' assigned to your instance remains associated with it for the entire lifetime of the instance — even if you stop (shut down) the instance.

The IP is only released when the instance is deleted (terminated). After termination, the IP is returned to the regional pool and may be reassigned to another instance in the region.

'''📌 Note:''' Floating IPs will remain even after an Instance deletion. They have to be released manually.

== Are Floating IPs also available for instances? ==


Yes.

Floating IPs provide a mechanism to 1:1 NAT a public IPv4 addresse to a private IPv4 address of an instance enabling ingress IPv4 connectivity.

For more information and detailed setup instructions, see the guide below.

➡️ [[Guide: Routers and Floating IPs|Routers and Floating IPs Guide]].

= Domains and FQDNs =

== Does bwCloud-OS also assign FQDNs? ==


Yes. Every running instance in bwCloud-OS is automatically assigned a '''generic hostname (FQDN)'''. This allows the instance to be reached via a '''persistent network identifier''', even if its public IP address changes. This FQDN is valid for the '''lifetime''' of the instance.

==== Format of the instance's FQDN ====

* The '''UUID''' '''of the instance'''
* The '''project name'''
* The '''region abbreviation''' (e.g., <code>ma</code> for Mannheim)
* The '''domain suffix''': <code>.bw-cloud-instance.org</code>

'''Example:'''

If your instance name is <code>kos</code>, the project is called <code>yarn</code> and it runs in Mannheim (<code>ma</code>), the FQDN will be:<pre>kos.yarn.vm.ma.bwcloud-os-instance.de.</pre>The FQDN can also be found in the '''[https://portal.bw-cloud.org/ Dashboard]''', on the '''Instances''' -> '''Network''' -> '''Interface''' page.

== Can I get a request more DNS records in bwCloud-OS? ==

Yes.

We manage the top level domain <code>bwcloud-os-instance.de.</code> It is possible to request a DNS record for a floating IP for example.

== Can I get a custom domain via bwCloud-OS? ==


No, bwCloud-OS does '''not''' provide custom '''domain hosting'''. However, you can use your '''own domain''' — either through your home institution or an external domain provider — to '''point to your instance'''.

Some options are described below.

== How can I point a domain to an instance? ==


You can point a domain to your instance in two main ways:

==== 🔹 CNAME to the instance FQDN ====
The instance’s FQDN is based on its UUID and region. Since the UUID is persistent for the instance's lifetime (even if the instance is stopped and started again), you can safely set a CNAME record like:

<code>myvm.example.org → instance-name.project-name.vm.region.bwcloud-os-instance.de</code>

==== 🔹 Dynamic DNS ====
Alternatively, you can configure a Dynamic DNS setup where your VM updates its IP in a third-party DNS service — especially if you don’t have your own domain, or your use case involves frequently changing or multiple IPs.

== Can I get a certificate from bwCloud-OS? ==


No, bwCloud-OS does '''not''' provide '''certificates.''' However, you can obtain certificates directly from public providers like '''Let’s Encrypt''' using tools such as '''Certbot''', which you install and run on your instance.