bwCloud-OS - User contributions [en]

Guide: Instance Action Menu

2026-05-29T11:54:45Z

Admin: /* 💽 Storage Management */

= Instance Action Menu (Dashboard Guide) =

Once an instance is running, you can manage it using the dropdown menu located on the far right of the instance list ('''Compute → Instances'''). This menu provides various options for network, storage, power state, and instance lifecycle management.

Below is an explanation of all available actions, grouped by their function.

== 💾 Core Action: Snapshots ==
* '''Create Snapshot:''' This is typically the default button next to the dropdown menu. It creates a complete, point-in-time image of the instance's current disk state. This snapshot can be used as a backup or as a template to launch new instances with the exact same configuration.

== 🌐 Network Configuration ==
These options manage how your instance communicates internally and externally.
* '''Associate / Disassociate Floating IP:''' Assigns a public IP address to your instance, making it accessible from the internet (e.g., for SSH or web servers). Use ''Disassociate'' to remove the public IP and free it up for other resources. See [[Guide:_Routers_and_Floating_IPs|here]] for more details.
* '''Attach / Detach Interface:''' Adds or removes a virtual Network Interface Card (NIC). This is useful if your instance needs to connect to multiple separate private networks simultaneously.
* '''Edit Security Groups:''' Allows you to attach or detach Security Groups (virtual firewalls). These groups define which incoming (ingress) and outgoing (egress) traffic is permitted for the instance.
* '''Edit Port Security Groups:''' Manages security rules directly on the network port level, offering more granular control than instance-level security groups.

== 💽 Storage Management ==
* '''Attach / Detach Volume:''' Connects or disconnects persistent block storage (Cinder Volumes) to your instance. Volumes are ideal for storing data that must persist even if the instance is deleted or rebuilt. For more details see [[Guide:_Volumes_and_Images#Create_and_Attach_a_Volume|here]].

== ⚙️ Administration & Diagnostics ==
* '''Edit Instance:''' Allows you to change basic metadata, such as the instance's display name.
* '''Update Meta''' Add or edit key-value tags associated with the instance. This can be used for organizational purposes or to trigger specific cloud-init scripts during boot.
* '''Console:''' Opens an interactive, web-based terminal directly in your browser (VNC/SPICE). This is crucial for troubleshooting if you lose SSH access due to network misconfiguration or firewall issues.
* '''View Log:''' Displays the console output and boot logs of the instance. This is the first place to look if an instance fails to boot properly.
* '''Rescue Instance:''' Reboots the instance using a temporary, minimal rescue operating system. Your original root disk is attached as a secondary drive, allowing you to fix broken file systems or recover a lost password.
* '''Lock / Unlock Instance:''' Prevents accidental changes, state modifications, or deletion of the instance by other users within the same project.

== ⏸️ Power States & Resource Management ==
These options allow you to temporarily halt an instance.
* '''Pause / Unpause Instance:''' Freezes the instance. The state is kept in RAM, allowing for an immediate resume. However, it still consumes compute resources on the host.
* '''Suspend / Resume Instance:''' Saves the current RAM state to disk and halts the instance. This frees up hypervisor resources, but resuming takes slightly longer than unpausing.
* '''Shelve / Unshelve Instance:''' Shuts down the instance and moves it off the compute node into image storage. This completely frees up your allocated CPU and RAM quota. ''Unshelving'' restores the instance to a new compute node.

== ⚠️ System Actions ==
These actions severely impact the instance lifecycle and are often marked in red in the dashboard to prevent accidental clicks.
* '''Resize Instance:''' Changes the instance's flavor (e.g., upgrading from ''m1.small'' to ''m1.medium''). This requires the instance to be restarted and the resize action to be explicitly confirmed afterwards.
* '''Soft Reboot Instance:''' Sends a graceful shutdown signal to the guest operating system, allowing it to close processes safely before rebooting (similar to typing <code>sudo reboot</code>).
* '''Hard Reboot Instance:''' Forces an immediate restart at the hypervisor level (similar to pressing the physical reset button on a server). Use this only if the instance is unresponsive.
* '''Shut Off Instance:''' Forcibly powers down the instance (virtual power plug pull). ⚠️''Please note that a stopped instance still incurs costs. To avoid incurring further costs, it must be deleted. (Applies only to Gen3; see [[Booking_Units|Booking Units]].)''
* '''Rebuild Instance:''' Re-installs the operating system from a selected image. '''Warning:''' All data on the local ephemeral root disk will be permanently destroyed. The instance retains its IP address and ID.
* '''Delete Instance:''' Permanently destroys the instance and all ephemeral data. Attached volumes and Floating IPs will be detached but not deleted.

----

Guide: Instance Action Menu

2026-05-29T11:53:43Z

Admin: /* ⚠️ System Actions */

= Instance Action Menu (Dashboard Guide) =

Once an instance is running, you can manage it using the dropdown menu located on the far right of the instance list ('''Compute → Instances'''). This menu provides various options for network, storage, power state, and instance lifecycle management.

Below is an explanation of all available actions, grouped by their function.

== 💾 Core Action: Snapshots ==
* '''Create Snapshot:''' This is typically the default button next to the dropdown menu. It creates a complete, point-in-time image of the instance's current disk state. This snapshot can be used as a backup or as a template to launch new instances with the exact same configuration.

== 🌐 Network Configuration ==
These options manage how your instance communicates internally and externally.
* '''Associate / Disassociate Floating IP:''' Assigns a public IP address to your instance, making it accessible from the internet (e.g., for SSH or web servers). Use ''Disassociate'' to remove the public IP and free it up for other resources. See [[Guide:_Routers_and_Floating_IPs|here]] for more details.
* '''Attach / Detach Interface:''' Adds or removes a virtual Network Interface Card (NIC). This is useful if your instance needs to connect to multiple separate private networks simultaneously.
* '''Edit Security Groups:''' Allows you to attach or detach Security Groups (virtual firewalls). These groups define which incoming (ingress) and outgoing (egress) traffic is permitted for the instance.
* '''Edit Port Security Groups:''' Manages security rules directly on the network port level, offering more granular control than instance-level security groups.

== 💽 Storage Management ==
* '''Attach / Detach Volume:''' Connects or disconnects persistent block storage (Cinder Volumes) to your instance. Volumes are ideal for storing data that must persist even if the instance is deleted or rebuilt.

== ⚙️ Administration & Diagnostics ==
* '''Edit Instance:''' Allows you to change basic metadata, such as the instance's display name.
* '''Update Meta''' Add or edit key-value tags associated with the instance. This can be used for organizational purposes or to trigger specific cloud-init scripts during boot.
* '''Console:''' Opens an interactive, web-based terminal directly in your browser (VNC/SPICE). This is crucial for troubleshooting if you lose SSH access due to network misconfiguration or firewall issues.
* '''View Log:''' Displays the console output and boot logs of the instance. This is the first place to look if an instance fails to boot properly.
* '''Rescue Instance:''' Reboots the instance using a temporary, minimal rescue operating system. Your original root disk is attached as a secondary drive, allowing you to fix broken file systems or recover a lost password.
* '''Lock / Unlock Instance:''' Prevents accidental changes, state modifications, or deletion of the instance by other users within the same project.

== ⏸️ Power States & Resource Management ==
These options allow you to temporarily halt an instance.
* '''Pause / Unpause Instance:''' Freezes the instance. The state is kept in RAM, allowing for an immediate resume. However, it still consumes compute resources on the host.
* '''Suspend / Resume Instance:''' Saves the current RAM state to disk and halts the instance. This frees up hypervisor resources, but resuming takes slightly longer than unpausing.
* '''Shelve / Unshelve Instance:''' Shuts down the instance and moves it off the compute node into image storage. This completely frees up your allocated CPU and RAM quota. ''Unshelving'' restores the instance to a new compute node.

== ⚠️ System Actions ==
These actions severely impact the instance lifecycle and are often marked in red in the dashboard to prevent accidental clicks.
* '''Resize Instance:''' Changes the instance's flavor (e.g., upgrading from ''m1.small'' to ''m1.medium''). This requires the instance to be restarted and the resize action to be explicitly confirmed afterwards.
* '''Soft Reboot Instance:''' Sends a graceful shutdown signal to the guest operating system, allowing it to close processes safely before rebooting (similar to typing <code>sudo reboot</code>).
* '''Hard Reboot Instance:''' Forces an immediate restart at the hypervisor level (similar to pressing the physical reset button on a server). Use this only if the instance is unresponsive.
* '''Shut Off Instance:''' Forcibly powers down the instance (virtual power plug pull). ⚠️''Please note that a stopped instance still incurs costs. To avoid incurring further costs, it must be deleted. (Applies only to Gen3; see [[Booking_Units|Booking Units]].)''
* '''Rebuild Instance:''' Re-installs the operating system from a selected image. '''Warning:''' All data on the local ephemeral root disk will be permanently destroyed. The instance retains its IP address and ID.
* '''Delete Instance:''' Permanently destroys the instance and all ephemeral data. Attached volumes and Floating IPs will be detached but not deleted.

----

Instances (VMs)

2026-05-29T11:53:05Z

Admin: /* What actions can I perform on a running instance? */

{{InANutshell|
<li>Instances can be '''created''' via the [https://portal.bw-cloud.org/ '''Dashboard'''] wizard, select: name →source → flavor → network → SSH key → launch.</li>
<li>The '''source''' defines the base disk for the instance, usually a pre-configured '''image''' containing the operating system (Rocky, Ubuntu, etc.) and initial software optimized for cloud environments.<li>
<li>The available resources of a virtual machine (vCPU, memory, etc.) are pre-defined by [[Instances_(VMs)#What_are_instance_flavors,_and_which_flavors_are_available?|flavors]]. Choose a '''flavor''' that fits your workload and available [[Projects and Quota#Project Quota|quota]] when launching your instance.</li>
<li>To '''access''' your bwCloud-OS virtual machines, you must register an '''SSH key pair''' and assign it when creating instances. ''If you lose your private SSH key, you will '''lose access''' to your instance!''</li>}}

__TOC__

= Creating Instances =

== How do I create a virtual machine using Dashboard (GUI)? ==


In the [https://portal.bw-cloud.org/ '''Dashboard'''], click '''Instances''' in the left-hand menu. On the new page, click '''Launch Instance.''' A dialog will open, guiding you through the configuration step by step:

* '''Details''': Enter a descriptive name for your instance.

* '''Source''': Select a source for the instance (image, snapshot, volume, etc.) — typically a [[Images|preconfigured image]] (e.g., ''Debian x''). Use the ↑ arrow to move the source into the ''Allocated'' list.
* '''Flavor''': Choose a [[Flavors|flavor]] based on your required vCPU, RAM, etc. If your [[Projects and Quota#Project Quota|quota]] is insufficient, a yellow warning icon will appear.
* '''Networks''': Choose a network. Default settings are usually appropriate.
* '''Security Groups''': No changes are mandatory at this point. You can [[Security#Security Groups - Open a port for access|adjust rules]] later if necessary.
* '''Key Pair''': Select a [[Instances (VMs)#SSH-Key|registered public SSH key]] to be injected into the instance. This step is mandatory. Without a valid SSH key, remote access to the instance will not be possible.

After completing the required selections, click '''Launch Instance''' in the dialog. Once the instance has finished building and reaches the '''Running''' state, its IP address(es) will be shown in the '''Instances''' overview. You can then [[Instances (VMs)#SSH-Access|access]] the instance via its [[Networks#Will my instance receive a public IP?|''public'' IP address]].

If you need further assistance, check out the illustrated guide below.

[[Guide: Instance Creation|➡️ Illustrated Instance Creation Guide]]

== How do I create a virtual machine via the command line (CLI)? ==

Instances can also be deployed using the OpenStack CLI. Further details are available [[Programmatic Access and Automation#CLI-COMMANDS|here]].

== Can I also create instances automatically? ==


Instances can also be deployed automatically using tools like Ansible. Further details are available [[Programmatic Access and Automation#Auto-Deployment|here]].

= Connecting to Instances =

== Why do I need an SSH key, and how can I get one? ==


SSH keys provide secure, passwordless access to your virtual machines. You can either use your existing keys or generate a new SSH key pair through the bwCloud-OS Dashboard.

For detailed instructions, see the following guide.

➡️ [[Guide: SSH#Key-Pair-Creation|SSH Guide]]

== How do I access my instance via SSH? ==


Once your instance is running, you can connect to it via SSH from '''Linux''', '''macOS''', or '''Windows''' using the following command:

<code>ssh -i /path/to/private-key <user>@<address></code>

* <code><user></code> is the default username, e.g. <code>ubuntu</code> for Ubuntu images. For other images, see the [[Images|Image Overview]].
* <code><address></code> is the DNS name ([[Networks#FQDN|FQDN]]) or the public IP address of your running instance. Both can be found in the [https://portal.bw-cloud.org/ Dashboard], on the '''Instances''' page.

For (advanced) SSH connection methods, see the following guide.

➡️ [[Guide: SSH|SSH Guide]]

== Can I replace a lost SSH key for my instance? ==


If you lose your private SSH key, it '''cannot be replaced''' — not even by the Support team. Access to the instance is only possible if you previously enabled password login via the virtual console.

== I no longer have access to my instance, what can I do? ==


A possible (but tedious) workaround is described in the guide below.

➡️ [[Guide: Rescue and Recovery|Rescue and Recovery Guide]]

= Resources of Instances =

== What are instance flavors, and which flavors are available? ==


bwCloud-OS offers various predefined resource packages, called '''flavors''', which define the vCPU, RAM, and disk size of an instance.

For currently available flavors, see our [[flavors|Flavor Table]].

If your current quota does not allow the use of certain flavors, you can [[Projects and Quota#Project Quota|request a quota increase]].

== How can I assign more resources to a running instance? ==


If your project has sufficient [[Projects and Quota#Project Quota|quota]] (vCPU, RAM, etc.), you can resize an existing VM to a '''larger flavor'''. This process '''restarts the VM''' and updates its allocated resources.

''While it is also possible to resize an instance to a '''smaller flavor''' (i.e. reduce its resources), this is '''not recommended''', as it can lead to unpredictable behavior or system instability.''

'''Important Notes:'''

* Data on attached volumes remains unchanged.
* The IP addresses remain unchanged.
* ''Back up important data before resizing''.

'''Prerequisites:'''

* Enough quota is available in the selected region.
* A larger, compatible flavor is available (see [[Flavors]]).
* A short maintenance window must be scheduled (brief downtime expected).
'''Step-by-Step Procedure:'''
# Log in to the [https://portal.bw-cloud.org/ Dashboard] and select the appropriate '''region''' in the top-left menu.
# Navigate to '''Project → Compute → Instances'''.
# Open the dropdown menu next to the instance you want to resize and select '''Resize Instance'''.
# Select a larger '''flavor''' (e.g., from <code>m1.small</code> to <code>m1.medium</code>) and confirm with '''Resize'''.
# Wait until the instance status changes to <code>VERIFY_RESIZE</code> and the VM becomes reachable again.
'''Verify & Confirm:'''
# Check that the resources match the new flavor '''('''inside the instance):
#* RAM/CPU: <code>free -h</code>, <code>nproc</code>
#* Disk layout: <code>lsblk</code>, <code>df -h</code>
# If everything works as expected, select '''Confirm Resize''' in the instance dropdown.
# If issues occur, select '''Revert Resize''' to roll back to the previous flavor.
'''Further Notes:'''
* Attached data volumes are not resized automatically. To expand a volume:
# Go to the [https://portal.bw-cloud.org/ Dashboard] and use '''Volumes → Volume → Extend Volume'''.
# After resizing the volume, resize the filesystem '''inside the instance''' using a command such as:
#* <code>sudo resize2fs</code> (for ext4)
#* <code>sudo xfs_growfs</code> (for XFS)

= Managing Running Instances =

== What actions can I perform on a running instance? ==

Once your instance is running, you can manage its lifecycle, network, and storage directly from the dashboard.
For a complete breakdown of all available options in the instance dropdown menu (like Snapshots, Resizing, or Shelving), please refer to our dedicated guide:

➡️ [[Guide: Instance Action Menu|Instance Action Menu Guide]]

Instances (VMs)

2026-05-29T11:52:17Z

Admin: /* What actions can I perform on a running instance? */

{{InANutshell|
<li>Instances can be '''created''' via the [https://portal.bw-cloud.org/ '''Dashboard'''] wizard, select: name →source → flavor → network → SSH key → launch.</li>
<li>The '''source''' defines the base disk for the instance, usually a pre-configured '''image''' containing the operating system (Rocky, Ubuntu, etc.) and initial software optimized for cloud environments.<li>
<li>The available resources of a virtual machine (vCPU, memory, etc.) are pre-defined by [[Instances_(VMs)#What_are_instance_flavors,_and_which_flavors_are_available?|flavors]]. Choose a '''flavor''' that fits your workload and available [[Projects and Quota#Project Quota|quota]] when launching your instance.</li>
<li>To '''access''' your bwCloud-OS virtual machines, you must register an '''SSH key pair''' and assign it when creating instances. ''If you lose your private SSH key, you will '''lose access''' to your instance!''</li>}}

__TOC__

= Creating Instances =

== How do I create a virtual machine using Dashboard (GUI)? ==


In the [https://portal.bw-cloud.org/ '''Dashboard'''], click '''Instances''' in the left-hand menu. On the new page, click '''Launch Instance.''' A dialog will open, guiding you through the configuration step by step:

* '''Details''': Enter a descriptive name for your instance.

* '''Source''': Select a source for the instance (image, snapshot, volume, etc.) — typically a [[Images|preconfigured image]] (e.g., ''Debian x''). Use the ↑ arrow to move the source into the ''Allocated'' list.
* '''Flavor''': Choose a [[Flavors|flavor]] based on your required vCPU, RAM, etc. If your [[Projects and Quota#Project Quota|quota]] is insufficient, a yellow warning icon will appear.
* '''Networks''': Choose a network. Default settings are usually appropriate.
* '''Security Groups''': No changes are mandatory at this point. You can [[Security#Security Groups - Open a port for access|adjust rules]] later if necessary.
* '''Key Pair''': Select a [[Instances (VMs)#SSH-Key|registered public SSH key]] to be injected into the instance. This step is mandatory. Without a valid SSH key, remote access to the instance will not be possible.

After completing the required selections, click '''Launch Instance''' in the dialog. Once the instance has finished building and reaches the '''Running''' state, its IP address(es) will be shown in the '''Instances''' overview. You can then [[Instances (VMs)#SSH-Access|access]] the instance via its [[Networks#Will my instance receive a public IP?|''public'' IP address]].

If you need further assistance, check out the illustrated guide below.

[[Guide: Instance Creation|➡️ Illustrated Instance Creation Guide]]

== How do I create a virtual machine via the command line (CLI)? ==

Instances can also be deployed using the OpenStack CLI. Further details are available [[Programmatic Access and Automation#CLI-COMMANDS|here]].

== Can I also create instances automatically? ==


Instances can also be deployed automatically using tools like Ansible. Further details are available [[Programmatic Access and Automation#Auto-Deployment|here]].

= Connecting to Instances =

== Why do I need an SSH key, and how can I get one? ==


SSH keys provide secure, passwordless access to your virtual machines. You can either use your existing keys or generate a new SSH key pair through the bwCloud-OS Dashboard.

For detailed instructions, see the following guide.

➡️ [[Guide: SSH#Key-Pair-Creation|SSH Guide]]

== How do I access my instance via SSH? ==


Once your instance is running, you can connect to it via SSH from '''Linux''', '''macOS''', or '''Windows''' using the following command:

<code>ssh -i /path/to/private-key <user>@<address></code>

* <code><user></code> is the default username, e.g. <code>ubuntu</code> for Ubuntu images. For other images, see the [[Images|Image Overview]].
* <code><address></code> is the DNS name ([[Networks#FQDN|FQDN]]) or the public IP address of your running instance. Both can be found in the [https://portal.bw-cloud.org/ Dashboard], on the '''Instances''' page.

For (advanced) SSH connection methods, see the following guide.

➡️ [[Guide: SSH|SSH Guide]]

== Can I replace a lost SSH key for my instance? ==


If you lose your private SSH key, it '''cannot be replaced''' — not even by the Support team. Access to the instance is only possible if you previously enabled password login via the virtual console.

== I no longer have access to my instance, what can I do? ==


A possible (but tedious) workaround is described in the guide below.

➡️ [[Guide: Rescue and Recovery|Rescue and Recovery Guide]]

= Resources of Instances =

== What are instance flavors, and which flavors are available? ==


bwCloud-OS offers various predefined resource packages, called '''flavors''', which define the vCPU, RAM, and disk size of an instance.

For currently available flavors, see our [[flavors|Flavor Table]].

If your current quota does not allow the use of certain flavors, you can [[Projects and Quota#Project Quota|request a quota increase]].

== How can I assign more resources to a running instance? ==


If your project has sufficient [[Projects and Quota#Project Quota|quota]] (vCPU, RAM, etc.), you can resize an existing VM to a '''larger flavor'''. This process '''restarts the VM''' and updates its allocated resources.

''While it is also possible to resize an instance to a '''smaller flavor''' (i.e. reduce its resources), this is '''not recommended''', as it can lead to unpredictable behavior or system instability.''

'''Important Notes:'''

* Data on attached volumes remains unchanged.
* The IP addresses remain unchanged.
* ''Back up important data before resizing''.

'''Prerequisites:'''

* Enough quota is available in the selected region.
* A larger, compatible flavor is available (see [[Flavors]]).
* A short maintenance window must be scheduled (brief downtime expected).
'''Step-by-Step Procedure:'''
# Log in to the [https://portal.bw-cloud.org/ Dashboard] and select the appropriate '''region''' in the top-left menu.
# Navigate to '''Project → Compute → Instances'''.
# Open the dropdown menu next to the instance you want to resize and select '''Resize Instance'''.
# Select a larger '''flavor''' (e.g., from <code>m1.small</code> to <code>m1.medium</code>) and confirm with '''Resize'''.
# Wait until the instance status changes to <code>VERIFY_RESIZE</code> and the VM becomes reachable again.
'''Verify & Confirm:'''
# Check that the resources match the new flavor '''('''inside the instance):
#* RAM/CPU: <code>free -h</code>, <code>nproc</code>
#* Disk layout: <code>lsblk</code>, <code>df -h</code>
# If everything works as expected, select '''Confirm Resize''' in the instance dropdown.
# If issues occur, select '''Revert Resize''' to roll back to the previous flavor.
'''Further Notes:'''
* Attached data volumes are not resized automatically. To expand a volume:
# Go to the [https://portal.bw-cloud.org/ Dashboard] and use '''Volumes → Volume → Extend Volume'''.
# After resizing the volume, resize the filesystem '''inside the instance''' using a command such as:
#* <code>sudo resize2fs</code> (for ext4)
#* <code>sudo xfs_growfs</code> (for XFS)

= Managing Running Instances =

== What actions can I perform on a running instance? ==

Once your instance is running, you can manage its lifecycle, network, and storage directly from the dashboard.
For a complete breakdown of all available options in the instance dropdown menu (like Snapshots, Resizing, or Shelving), please refer to our dedicated guide:
➡️ [[Guide: Instance Action Menu|Instance Action Menu Guide]]

Instances (VMs)

2026-05-29T11:51:57Z

Admin:

{{InANutshell|
<li>Instances can be '''created''' via the [https://portal.bw-cloud.org/ '''Dashboard'''] wizard, select: name →source → flavor → network → SSH key → launch.</li>
<li>The '''source''' defines the base disk for the instance, usually a pre-configured '''image''' containing the operating system (Rocky, Ubuntu, etc.) and initial software optimized for cloud environments.<li>
<li>The available resources of a virtual machine (vCPU, memory, etc.) are pre-defined by [[Instances_(VMs)#What_are_instance_flavors,_and_which_flavors_are_available?|flavors]]. Choose a '''flavor''' that fits your workload and available [[Projects and Quota#Project Quota|quota]] when launching your instance.</li>
<li>To '''access''' your bwCloud-OS virtual machines, you must register an '''SSH key pair''' and assign it when creating instances. ''If you lose your private SSH key, you will '''lose access''' to your instance!''</li>}}

__TOC__

= Creating Instances =

== How do I create a virtual machine using Dashboard (GUI)? ==


In the [https://portal.bw-cloud.org/ '''Dashboard'''], click '''Instances''' in the left-hand menu. On the new page, click '''Launch Instance.''' A dialog will open, guiding you through the configuration step by step:

* '''Details''': Enter a descriptive name for your instance.

* '''Source''': Select a source for the instance (image, snapshot, volume, etc.) — typically a [[Images|preconfigured image]] (e.g., ''Debian x''). Use the ↑ arrow to move the source into the ''Allocated'' list.
* '''Flavor''': Choose a [[Flavors|flavor]] based on your required vCPU, RAM, etc. If your [[Projects and Quota#Project Quota|quota]] is insufficient, a yellow warning icon will appear.
* '''Networks''': Choose a network. Default settings are usually appropriate.
* '''Security Groups''': No changes are mandatory at this point. You can [[Security#Security Groups - Open a port for access|adjust rules]] later if necessary.
* '''Key Pair''': Select a [[Instances (VMs)#SSH-Key|registered public SSH key]] to be injected into the instance. This step is mandatory. Without a valid SSH key, remote access to the instance will not be possible.

After completing the required selections, click '''Launch Instance''' in the dialog. Once the instance has finished building and reaches the '''Running''' state, its IP address(es) will be shown in the '''Instances''' overview. You can then [[Instances (VMs)#SSH-Access|access]] the instance via its [[Networks#Will my instance receive a public IP?|''public'' IP address]].

If you need further assistance, check out the illustrated guide below.

[[Guide: Instance Creation|➡️ Illustrated Instance Creation Guide]]

== How do I create a virtual machine via the command line (CLI)? ==

Instances can also be deployed using the OpenStack CLI. Further details are available [[Programmatic Access and Automation#CLI-COMMANDS|here]].

== Can I also create instances automatically? ==


Instances can also be deployed automatically using tools like Ansible. Further details are available [[Programmatic Access and Automation#Auto-Deployment|here]].

= Connecting to Instances =

== Why do I need an SSH key, and how can I get one? ==


SSH keys provide secure, passwordless access to your virtual machines. You can either use your existing keys or generate a new SSH key pair through the bwCloud-OS Dashboard.

For detailed instructions, see the following guide.

➡️ [[Guide: SSH#Key-Pair-Creation|SSH Guide]]

== How do I access my instance via SSH? ==


Once your instance is running, you can connect to it via SSH from '''Linux''', '''macOS''', or '''Windows''' using the following command:

<code>ssh -i /path/to/private-key <user>@<address></code>

* <code><user></code> is the default username, e.g. <code>ubuntu</code> for Ubuntu images. For other images, see the [[Images|Image Overview]].
* <code><address></code> is the DNS name ([[Networks#FQDN|FQDN]]) or the public IP address of your running instance. Both can be found in the [https://portal.bw-cloud.org/ Dashboard], on the '''Instances''' page.

For (advanced) SSH connection methods, see the following guide.

➡️ [[Guide: SSH|SSH Guide]]

== Can I replace a lost SSH key for my instance? ==


If you lose your private SSH key, it '''cannot be replaced''' — not even by the Support team. Access to the instance is only possible if you previously enabled password login via the virtual console.

== I no longer have access to my instance, what can I do? ==


A possible (but tedious) workaround is described in the guide below.

➡️ [[Guide: Rescue and Recovery|Rescue and Recovery Guide]]

= Resources of Instances =

== What are instance flavors, and which flavors are available? ==


bwCloud-OS offers various predefined resource packages, called '''flavors''', which define the vCPU, RAM, and disk size of an instance.

For currently available flavors, see our [[flavors|Flavor Table]].

If your current quota does not allow the use of certain flavors, you can [[Projects and Quota#Project Quota|request a quota increase]].

== How can I assign more resources to a running instance? ==


If your project has sufficient [[Projects and Quota#Project Quota|quota]] (vCPU, RAM, etc.), you can resize an existing VM to a '''larger flavor'''. This process '''restarts the VM''' and updates its allocated resources.

''While it is also possible to resize an instance to a '''smaller flavor''' (i.e. reduce its resources), this is '''not recommended''', as it can lead to unpredictable behavior or system instability.''

'''Important Notes:'''

* Data on attached volumes remains unchanged.
* The IP addresses remain unchanged.
* ''Back up important data before resizing''.

'''Prerequisites:'''

* Enough quota is available in the selected region.
* A larger, compatible flavor is available (see [[Flavors]]).
* A short maintenance window must be scheduled (brief downtime expected).
'''Step-by-Step Procedure:'''
# Log in to the [https://portal.bw-cloud.org/ Dashboard] and select the appropriate '''region''' in the top-left menu.
# Navigate to '''Project → Compute → Instances'''.
# Open the dropdown menu next to the instance you want to resize and select '''Resize Instance'''.
# Select a larger '''flavor''' (e.g., from <code>m1.small</code> to <code>m1.medium</code>) and confirm with '''Resize'''.
# Wait until the instance status changes to <code>VERIFY_RESIZE</code> and the VM becomes reachable again.
'''Verify & Confirm:'''
# Check that the resources match the new flavor '''('''inside the instance):
#* RAM/CPU: <code>free -h</code>, <code>nproc</code>
#* Disk layout: <code>lsblk</code>, <code>df -h</code>
# If everything works as expected, select '''Confirm Resize''' in the instance dropdown.
# If issues occur, select '''Revert Resize''' to roll back to the previous flavor.
'''Further Notes:'''
* Attached data volumes are not resized automatically. To expand a volume:
# Go to the [https://portal.bw-cloud.org/ Dashboard] and use '''Volumes → Volume → Extend Volume'''.
# After resizing the volume, resize the filesystem '''inside the instance''' using a command such as:
#* <code>sudo resize2fs</code> (for ext4)
#* <code>sudo xfs_growfs</code> (for XFS)

= Managing Running Instances =

== What actions can I perform on a running instance? ==

Once your instance is running, you can manage its lifecycle, network, and storage directly from the dashboard. For a complete breakdown of all available options in the instance dropdown menu (like Snapshots, Resizing, or Shelving), please refer to our dedicated guide:
➡️ [[Guide: Instance Action Menu|Instance Action Menu Guide]]

Guide: Instance Action Menu

2026-05-29T11:46:45Z

Admin: /* 🌐 Network Configuration */

= Instance Action Menu (Dashboard Guide) =

Once an instance is running, you can manage it using the dropdown menu located on the far right of the instance list ('''Compute → Instances'''). This menu provides various options for network, storage, power state, and instance lifecycle management.

Below is an explanation of all available actions, grouped by their function.

== 💾 Core Action: Snapshots ==
* '''Create Snapshot:''' This is typically the default button next to the dropdown menu. It creates a complete, point-in-time image of the instance's current disk state. This snapshot can be used as a backup or as a template to launch new instances with the exact same configuration.

== 🌐 Network Configuration ==
These options manage how your instance communicates internally and externally.
* '''Associate / Disassociate Floating IP:''' Assigns a public IP address to your instance, making it accessible from the internet (e.g., for SSH or web servers). Use ''Disassociate'' to remove the public IP and free it up for other resources. See [[Guide:_Routers_and_Floating_IPs|here]] for more details.
* '''Attach / Detach Interface:''' Adds or removes a virtual Network Interface Card (NIC). This is useful if your instance needs to connect to multiple separate private networks simultaneously.
* '''Edit Security Groups:''' Allows you to attach or detach Security Groups (virtual firewalls). These groups define which incoming (ingress) and outgoing (egress) traffic is permitted for the instance.
* '''Edit Port Security Groups:''' Manages security rules directly on the network port level, offering more granular control than instance-level security groups.

== 💽 Storage Management ==
* '''Attach / Detach Volume:''' Connects or disconnects persistent block storage (Cinder Volumes) to your instance. Volumes are ideal for storing data that must persist even if the instance is deleted or rebuilt.

== ⚙️ Administration & Diagnostics ==
* '''Edit Instance:''' Allows you to change basic metadata, such as the instance's display name.
* '''Update Meta''' Add or edit key-value tags associated with the instance. This can be used for organizational purposes or to trigger specific cloud-init scripts during boot.
* '''Console:''' Opens an interactive, web-based terminal directly in your browser (VNC/SPICE). This is crucial for troubleshooting if you lose SSH access due to network misconfiguration or firewall issues.
* '''View Log:''' Displays the console output and boot logs of the instance. This is the first place to look if an instance fails to boot properly.
* '''Rescue Instance:''' Reboots the instance using a temporary, minimal rescue operating system. Your original root disk is attached as a secondary drive, allowing you to fix broken file systems or recover a lost password.
* '''Lock / Unlock Instance:''' Prevents accidental changes, state modifications, or deletion of the instance by other users within the same project.

== ⏸️ Power States & Resource Management ==
These options allow you to temporarily halt an instance.
* '''Pause / Unpause Instance:''' Freezes the instance. The state is kept in RAM, allowing for an immediate resume. However, it still consumes compute resources on the host.
* '''Suspend / Resume Instance:''' Saves the current RAM state to disk and halts the instance. This frees up hypervisor resources, but resuming takes slightly longer than unpausing.
* '''Shelve / Unshelve Instance:''' Shuts down the instance and moves it off the compute node into image storage. This completely frees up your allocated CPU and RAM quota. ''Unshelving'' restores the instance to a new compute node.

== ⚠️ System Actions ==
These actions severely impact the instance lifecycle and are often marked in red in the dashboard to prevent accidental clicks.
* '''Resize Instance:''' Changes the instance's flavor (e.g., upgrading from ''m1.small'' to ''m1.medium''). This requires the instance to be restarted and the resize action to be explicitly confirmed afterwards.
* '''Soft Reboot Instance:''' Sends a graceful shutdown signal to the guest operating system, allowing it to close processes safely before rebooting (similar to typing <code>sudo reboot</code>).
* '''Hard Reboot Instance:''' Forces an immediate restart at the hypervisor level (similar to pressing the physical reset button on a server). Use this only if the instance is unresponsive.
* '''Shut Off Instance:''' Forcibly powers down the instance (virtual power plug pull). ''Please note that a stopped instance still incurs costs. To avoid incurring further costs, it must be deleted. (Applies only to Gen3; see [[Booking_Units|Booking Units]].)''
* '''Rebuild Instance:''' Re-installs the operating system from a selected image. '''Warning:''' All data on the local ephemeral root disk will be permanently destroyed. The instance retains its IP address and ID.
* '''Delete Instance:''' Permanently destroys the instance and all ephemeral data. Attached volumes and Floating IPs will be detached but not deleted.

----

Guide: Instance Action Menu

2026-05-29T11:46:03Z

Admin: /* Step-by-Step Example: Associating a Floating IP */

= Instance Action Menu (Dashboard Guide) =

Once an instance is running, you can manage it using the dropdown menu located on the far right of the instance list ('''Compute → Instances'''). This menu provides various options for network, storage, power state, and instance lifecycle management.

Below is an explanation of all available actions, grouped by their function.

== 💾 Core Action: Snapshots ==
* '''Create Snapshot:''' This is typically the default button next to the dropdown menu. It creates a complete, point-in-time image of the instance's current disk state. This snapshot can be used as a backup or as a template to launch new instances with the exact same configuration.

== 🌐 Network Configuration ==
These options manage how your instance communicates internally and externally.
* '''Associate / Disassociate Floating IP:''' Assigns a public IP address to your instance, making it accessible from the internet (e.g., for SSH or web servers). Use ''Disassociate'' to remove the public IP and free it up for other resources.
* '''Attach / Detach Interface:''' Adds or removes a virtual Network Interface Card (NIC). This is useful if your instance needs to connect to multiple separate private networks simultaneously.
* '''Edit Security Groups:''' Allows you to attach or detach Security Groups (virtual firewalls). These groups define which incoming (ingress) and outgoing (egress) traffic is permitted for the instance.
* '''Edit Port Security Groups:''' Manages security rules directly on the network port level, offering more granular control than instance-level security groups.

== 💽 Storage Management ==
* '''Attach / Detach Volume:''' Connects or disconnects persistent block storage (Cinder Volumes) to your instance. Volumes are ideal for storing data that must persist even if the instance is deleted or rebuilt.

== ⚙️ Administration & Diagnostics ==
* '''Edit Instance:''' Allows you to change basic metadata, such as the instance's display name.
* '''Update Meta''' Add or edit key-value tags associated with the instance. This can be used for organizational purposes or to trigger specific cloud-init scripts during boot.
* '''Console:''' Opens an interactive, web-based terminal directly in your browser (VNC/SPICE). This is crucial for troubleshooting if you lose SSH access due to network misconfiguration or firewall issues.
* '''View Log:''' Displays the console output and boot logs of the instance. This is the first place to look if an instance fails to boot properly.
* '''Rescue Instance:''' Reboots the instance using a temporary, minimal rescue operating system. Your original root disk is attached as a secondary drive, allowing you to fix broken file systems or recover a lost password.
* '''Lock / Unlock Instance:''' Prevents accidental changes, state modifications, or deletion of the instance by other users within the same project.

== ⏸️ Power States & Resource Management ==
These options allow you to temporarily halt an instance.
* '''Pause / Unpause Instance:''' Freezes the instance. The state is kept in RAM, allowing for an immediate resume. However, it still consumes compute resources on the host.
* '''Suspend / Resume Instance:''' Saves the current RAM state to disk and halts the instance. This frees up hypervisor resources, but resuming takes slightly longer than unpausing.
* '''Shelve / Unshelve Instance:''' Shuts down the instance and moves it off the compute node into image storage. This completely frees up your allocated CPU and RAM quota. ''Unshelving'' restores the instance to a new compute node.

== ⚠️ System Actions ==
These actions severely impact the instance lifecycle and are often marked in red in the dashboard to prevent accidental clicks.
* '''Resize Instance:''' Changes the instance's flavor (e.g., upgrading from ''m1.small'' to ''m1.medium''). This requires the instance to be restarted and the resize action to be explicitly confirmed afterwards.
* '''Soft Reboot Instance:''' Sends a graceful shutdown signal to the guest operating system, allowing it to close processes safely before rebooting (similar to typing <code>sudo reboot</code>).
* '''Hard Reboot Instance:''' Forces an immediate restart at the hypervisor level (similar to pressing the physical reset button on a server). Use this only if the instance is unresponsive.
* '''Shut Off Instance:''' Forcibly powers down the instance (virtual power plug pull). ''Please note that a stopped instance still incurs costs. To avoid incurring further costs, it must be deleted. (Applies only to Gen3; see [[Booking_Units|Booking Units]].)''
* '''Rebuild Instance:''' Re-installs the operating system from a selected image. '''Warning:''' All data on the local ephemeral root disk will be permanently destroyed. The instance retains its IP address and ID.
* '''Delete Instance:''' Permanently destroys the instance and all ephemeral data. Attached volumes and Floating IPs will be detached but not deleted.

----

Guide: Instance Action Menu

2026-05-29T11:45:20Z

Admin: /* ⚠️ System Actions */

= Instance Action Menu (Dashboard Guide) =

Once an instance is running, you can manage it using the dropdown menu located on the far right of the instance list ('''Compute → Instances'''). This menu provides various options for network, storage, power state, and instance lifecycle management.

Below is an explanation of all available actions, grouped by their function.

== 💾 Core Action: Snapshots ==
* '''Create Snapshot:''' This is typically the default button next to the dropdown menu. It creates a complete, point-in-time image of the instance's current disk state. This snapshot can be used as a backup or as a template to launch new instances with the exact same configuration.

== 🌐 Network Configuration ==
These options manage how your instance communicates internally and externally.
* '''Associate / Disassociate Floating IP:''' Assigns a public IP address to your instance, making it accessible from the internet (e.g., for SSH or web servers). Use ''Disassociate'' to remove the public IP and free it up for other resources.
* '''Attach / Detach Interface:''' Adds or removes a virtual Network Interface Card (NIC). This is useful if your instance needs to connect to multiple separate private networks simultaneously.
* '''Edit Security Groups:''' Allows you to attach or detach Security Groups (virtual firewalls). These groups define which incoming (ingress) and outgoing (egress) traffic is permitted for the instance.
* '''Edit Port Security Groups:''' Manages security rules directly on the network port level, offering more granular control than instance-level security groups.

== 💽 Storage Management ==
* '''Attach / Detach Volume:''' Connects or disconnects persistent block storage (Cinder Volumes) to your instance. Volumes are ideal for storing data that must persist even if the instance is deleted or rebuilt.

== ⚙️ Administration & Diagnostics ==
* '''Edit Instance:''' Allows you to change basic metadata, such as the instance's display name.
* '''Update Meta''' Add or edit key-value tags associated with the instance. This can be used for organizational purposes or to trigger specific cloud-init scripts during boot.
* '''Console:''' Opens an interactive, web-based terminal directly in your browser (VNC/SPICE). This is crucial for troubleshooting if you lose SSH access due to network misconfiguration or firewall issues.
* '''View Log:''' Displays the console output and boot logs of the instance. This is the first place to look if an instance fails to boot properly.
* '''Rescue Instance:''' Reboots the instance using a temporary, minimal rescue operating system. Your original root disk is attached as a secondary drive, allowing you to fix broken file systems or recover a lost password.
* '''Lock / Unlock Instance:''' Prevents accidental changes, state modifications, or deletion of the instance by other users within the same project.

== ⏸️ Power States & Resource Management ==
These options allow you to temporarily halt an instance.
* '''Pause / Unpause Instance:''' Freezes the instance. The state is kept in RAM, allowing for an immediate resume. However, it still consumes compute resources on the host.
* '''Suspend / Resume Instance:''' Saves the current RAM state to disk and halts the instance. This frees up hypervisor resources, but resuming takes slightly longer than unpausing.
* '''Shelve / Unshelve Instance:''' Shuts down the instance and moves it off the compute node into image storage. This completely frees up your allocated CPU and RAM quota. ''Unshelving'' restores the instance to a new compute node.

== ⚠️ System Actions ==
These actions severely impact the instance lifecycle and are often marked in red in the dashboard to prevent accidental clicks.
* '''Resize Instance:''' Changes the instance's flavor (e.g., upgrading from ''m1.small'' to ''m1.medium''). This requires the instance to be restarted and the resize action to be explicitly confirmed afterwards.
* '''Soft Reboot Instance:''' Sends a graceful shutdown signal to the guest operating system, allowing it to close processes safely before rebooting (similar to typing <code>sudo reboot</code>).
* '''Hard Reboot Instance:''' Forces an immediate restart at the hypervisor level (similar to pressing the physical reset button on a server). Use this only if the instance is unresponsive.
* '''Shut Off Instance:''' Forcibly powers down the instance (virtual power plug pull). ''Please note that a stopped instance still incurs costs. To avoid incurring further costs, it must be deleted. (Applies only to Gen3; see [[Booking_Units|Booking Units]].)''
* '''Rebuild Instance:''' Re-installs the operating system from a selected image. '''Warning:''' All data on the local ephemeral root disk will be permanently destroyed. The instance retains its IP address and ID.
* '''Delete Instance:''' Permanently destroys the instance and all ephemeral data. Attached volumes and Floating IPs will be detached but not deleted.

----

=== Step-by-Step Example: Associating a Floating IP ===

If you need your instance to be reachable from the outside world (e.g., for an SSH connection), you must assign it a Floating IP.

# Navigate to '''Compute → Instances'''.
# Locate your running instance in the list.
# Open the dropdown menu on the right side and select '''Associate Floating IP'''.
# A new window will appear:
#* '''IP Address:''' Select an available IP from the list. If the list is empty, click the '''+ (Plus)''' button to allocate a new IP from the public pool.
#* '''Port to be associated:''' Select the network interface of your instance that should receive the IP (usually, there is only one).
# Click '''Associate'''. The Floating IP will now be displayed next to your internal IP in the instance list.

Guide: Instance Action Menu

2026-05-29T11:43:08Z

Admin: /* ⚠️ Critical System Actions */

= Instance Action Menu (Dashboard Guide) =

Once an instance is running, you can manage it using the dropdown menu located on the far right of the instance list ('''Compute → Instances'''). This menu provides various options for network, storage, power state, and instance lifecycle management.

Below is an explanation of all available actions, grouped by their function.

== 💾 Core Action: Snapshots ==
* '''Create Snapshot:''' This is typically the default button next to the dropdown menu. It creates a complete, point-in-time image of the instance's current disk state. This snapshot can be used as a backup or as a template to launch new instances with the exact same configuration.

== 🌐 Network Configuration ==
These options manage how your instance communicates internally and externally.
* '''Associate / Disassociate Floating IP:''' Assigns a public IP address to your instance, making it accessible from the internet (e.g., for SSH or web servers). Use ''Disassociate'' to remove the public IP and free it up for other resources.
* '''Attach / Detach Interface:''' Adds or removes a virtual Network Interface Card (NIC). This is useful if your instance needs to connect to multiple separate private networks simultaneously.
* '''Edit Security Groups:''' Allows you to attach or detach Security Groups (virtual firewalls). These groups define which incoming (ingress) and outgoing (egress) traffic is permitted for the instance.
* '''Edit Port Security Groups:''' Manages security rules directly on the network port level, offering more granular control than instance-level security groups.

== 💽 Storage Management ==
* '''Attach / Detach Volume:''' Connects or disconnects persistent block storage (Cinder Volumes) to your instance. Volumes are ideal for storing data that must persist even if the instance is deleted or rebuilt.

== ⚙️ Administration & Diagnostics ==
* '''Edit Instance:''' Allows you to change basic metadata, such as the instance's display name.
* '''Update Meta''' Add or edit key-value tags associated with the instance. This can be used for organizational purposes or to trigger specific cloud-init scripts during boot.
* '''Console:''' Opens an interactive, web-based terminal directly in your browser (VNC/SPICE). This is crucial for troubleshooting if you lose SSH access due to network misconfiguration or firewall issues.
* '''View Log:''' Displays the console output and boot logs of the instance. This is the first place to look if an instance fails to boot properly.
* '''Rescue Instance:''' Reboots the instance using a temporary, minimal rescue operating system. Your original root disk is attached as a secondary drive, allowing you to fix broken file systems or recover a lost password.
* '''Lock / Unlock Instance:''' Prevents accidental changes, state modifications, or deletion of the instance by other users within the same project.

== ⏸️ Power States & Resource Management ==
These options allow you to temporarily halt an instance.
* '''Pause / Unpause Instance:''' Freezes the instance. The state is kept in RAM, allowing for an immediate resume. However, it still consumes compute resources on the host.
* '''Suspend / Resume Instance:''' Saves the current RAM state to disk and halts the instance. This frees up hypervisor resources, but resuming takes slightly longer than unpausing.
* '''Shelve / Unshelve Instance:''' Shuts down the instance and moves it off the compute node into image storage. This completely frees up your allocated CPU and RAM quota. ''Unshelving'' restores the instance to a new compute node.

== ⚠️ System Actions ==
These actions severely impact the instance lifecycle and are often marked in red in the dashboard to prevent accidental clicks.
* '''Resize Instance:''' Changes the instance's flavor (e.g., upgrading from ''m1.small'' to ''m1.medium''). This requires the instance to be restarted and the resize action to be explicitly confirmed afterwards.
* '''Soft Reboot Instance:''' Sends a graceful shutdown signal to the guest operating system, allowing it to close processes safely before rebooting (similar to typing <code>sudo reboot</code>).
* '''Hard Reboot Instance:''' Forces an immediate restart at the hypervisor level (similar to pressing the physical reset button on a server). Use this only if the instance is unresponsive.
* '''Shut Off Instance:''' Forcibly powers down the instance (virtual power plug pull).
* '''Rebuild Instance:''' Re-installs the operating system from a selected image. '''Warning:''' All data on the local ephemeral root disk will be permanently destroyed. The instance retains its IP address and ID.
* '''Delete Instance:''' Permanently destroys the instance and all ephemeral data. Attached volumes and Floating IPs will be detached but not deleted.

----

=== Step-by-Step Example: Associating a Floating IP ===

If you need your instance to be reachable from the outside world (e.g., for an SSH connection), you must assign it a Floating IP.

# Navigate to '''Compute → Instances'''.
# Locate your running instance in the list.
# Open the dropdown menu on the right side and select '''Associate Floating IP'''.
# A new window will appear:
#* '''IP Address:''' Select an available IP from the list. If the list is empty, click the '''+ (Plus)''' button to allocate a new IP from the public pool.
#* '''Port to be associated:''' Select the network interface of your instance that should receive the IP (usually, there is only one).
# Click '''Associate'''. The Floating IP will now be displayed next to your internal IP in the instance list.

Guide: Instance Action Menu

2026-05-29T11:40:09Z

Admin: Created page with "= Instance Action Menu (Dashboard Guide) = Once an instance is running, you can manage it using the dropdown menu located on the far right of the instance list ('''Compute → Instances'''). This menu provides various options for network, storage, power state, and instance lifecycle management. Below is an explanation of all available actions, grouped by their function. == 💾 Core Action: Snapshots == * '''Create Snapshot:''' This is typically the default button nex..."

= Instance Action Menu (Dashboard Guide) =

Once an instance is running, you can manage it using the dropdown menu located on the far right of the instance list ('''Compute → Instances'''). This menu provides various options for network, storage, power state, and instance lifecycle management.

Below is an explanation of all available actions, grouped by their function.

== 💾 Core Action: Snapshots ==
* '''Create Snapshot:''' This is typically the default button next to the dropdown menu. It creates a complete, point-in-time image of the instance's current disk state. This snapshot can be used as a backup or as a template to launch new instances with the exact same configuration.

== 🌐 Network Configuration ==
These options manage how your instance communicates internally and externally.
* '''Associate / Disassociate Floating IP:''' Assigns a public IP address to your instance, making it accessible from the internet (e.g., for SSH or web servers). Use ''Disassociate'' to remove the public IP and free it up for other resources.
* '''Attach / Detach Interface:''' Adds or removes a virtual Network Interface Card (NIC). This is useful if your instance needs to connect to multiple separate private networks simultaneously.
* '''Edit Security Groups:''' Allows you to attach or detach Security Groups (virtual firewalls). These groups define which incoming (ingress) and outgoing (egress) traffic is permitted for the instance.
* '''Edit Port Security Groups:''' Manages security rules directly on the network port level, offering more granular control than instance-level security groups.

== 💽 Storage Management ==
* '''Attach / Detach Volume:''' Connects or disconnects persistent block storage (Cinder Volumes) to your instance. Volumes are ideal for storing data that must persist even if the instance is deleted or rebuilt.

== ⚙️ Administration & Diagnostics ==
* '''Edit Instance:''' Allows you to change basic metadata, such as the instance's display name.
* '''Update Meta''' Add or edit key-value tags associated with the instance. This can be used for organizational purposes or to trigger specific cloud-init scripts during boot.
* '''Console:''' Opens an interactive, web-based terminal directly in your browser (VNC/SPICE). This is crucial for troubleshooting if you lose SSH access due to network misconfiguration or firewall issues.
* '''View Log:''' Displays the console output and boot logs of the instance. This is the first place to look if an instance fails to boot properly.
* '''Rescue Instance:''' Reboots the instance using a temporary, minimal rescue operating system. Your original root disk is attached as a secondary drive, allowing you to fix broken file systems or recover a lost password.
* '''Lock / Unlock Instance:''' Prevents accidental changes, state modifications, or deletion of the instance by other users within the same project.

== ⏸️ Power States & Resource Management ==
These options allow you to temporarily halt an instance.
* '''Pause / Unpause Instance:''' Freezes the instance. The state is kept in RAM, allowing for an immediate resume. However, it still consumes compute resources on the host.
* '''Suspend / Resume Instance:''' Saves the current RAM state to disk and halts the instance. This frees up hypervisor resources, but resuming takes slightly longer than unpausing.
* '''Shelve / Unshelve Instance:''' Shuts down the instance and moves it off the compute node into image storage. This completely frees up your allocated CPU and RAM quota. ''Unshelving'' restores the instance to a new compute node.

== ⚠️ Critical System Actions ==
These actions severely impact the instance lifecycle and are often marked in red in the dashboard to prevent accidental clicks.
* '''Resize Instance:''' Changes the instance's flavor (e.g., upgrading from ''m1.small'' to ''m1.medium''). This requires the instance to be restarted and the resize action to be explicitly confirmed afterwards.
* '''Soft Reboot Instance:''' Sends a graceful shutdown signal to the guest operating system, allowing it to close processes safely before rebooting (similar to typing <code>sudo reboot</code>).
* '''Hard Reboot Instance:''' Forces an immediate restart at the hypervisor level (similar to pressing the physical reset button on a server). Use this only if the instance is unresponsive.
* '''Shut Off Instance:''' Forcibly powers down the instance (virtual power plug pull).
* '''Rebuild Instance:''' Re-installs the operating system from a selected image. '''Warning:''' All data on the local ephemeral root disk will be permanently destroyed. The instance retains its IP address and ID.
* '''Delete Instance:''' Permanently destroys the instance and all ephemeral data. Attached volumes and Floating IPs will be detached but not deleted.

----

=== Step-by-Step Example: Associating a Floating IP ===

If you need your instance to be reachable from the outside world (e.g., for an SSH connection), you must assign it a Floating IP.

# Navigate to '''Compute → Instances'''.
# Locate your running instance in the list.
# Open the dropdown menu on the right side and select '''Associate Floating IP'''.
# A new window will appear:
#* '''IP Address:''' Select an available IP from the list. If the list is empty, click the '''+ (Plus)''' button to allocate a new IP from the public pool.
#* '''Port to be associated:''' Select the network interface of your instance that should receive the IP (usually, there is only one).
# Click '''Associate'''. The Floating IP will now be displayed next to your internal IP in the instance list.

Guide: Project and Quota

2026-05-29T08:18:17Z

Admin: /* List of quota flavors */

➡️ '''Back to the FAQ for [[Projects and Quota]].'''

Quota defines the resource limits allocated to a project, such as vCPUs, RAM, networks, and storage

== Project and eligibility ==
Before a quota can be set for a project, in advance an [[Guide: Entitlement & Eligibility|entitlement/ eligibility]] needs to be granted to the project owner.

* Each project is associated with an eligibility hold by the owner of the project.
* The maximal quota a user can request is restricted by the quota flavor of his/her eligibility.
== List of quota flavors ==
The supported quota packages are described in the table below.
{| class="wikitable"
|+List of supported quota flavors
!quota flavor
!Note
|-
|empty
|Fallback. Every user owns this. User can’t generate costs. See [[Guide: Entitlement & Eligibility#Empty-eligibility|empty-eligibility.]]
|-
|tiny_1
|
|-
|xtiny_1
|
|-
|medium_1
|
|-
|xmedium_1
|
|-
|large_1
|
|-
|xlarge_1
|
|-
|custom
|User can choose the quota to be requested. See [[Guide: Entitlement & Eligibility#Custom-eligibility|custom-eligibility]].
|}
Each quota flavor is associated with resources granted to [[Projects and Quota|projects]].
{| class="wikitable"
|+Resources associated with each quota flavor
!quota flavor
!'''instances'''
!'''cores'''
!'''ram_gb'''
!'''volumes'''
! style="border-right: 3px solid #a2a9b1;" | BEH/day
!'''volumes_gb'''
!'''backups'''
!'''backups_gb'''
!'''networks'''
!'''subnets'''
!'''routers'''
!'''floating_ips'''
!'''security_groups'''
!'''snapshots'''
|-
|'''empty'''
|0
|0
|0
|0
| style="border-right: 3px solid #a2a9b1;" |
|0
|0
|0
|0
|0
|0
|0
|20
|0
|-
|'''tiny_1'''
|1
|1
|1
|10
| style="border-right: 3px solid #a2a9b1;" | 4
|100
|30
|300
|10
|10
|1
|0
|20
|10
|-
|'''xtiny_1'''
|2
|2
|2
|10
| style="border-right: 3px solid #a2a9b1;" | 7
|100
|30
|300
|10
|10
|1
|0
|20
|10
|-
|'''medium_1'''
|4
|4
|4
|20
| style="border-right: 3px solid #a2a9b1;" | 14
|200
|60
|600
|10
|10
|1
|1
|20
|20
|-
|'''xmedium_1'''
|8
|8
|8
|20
| style="border-right: 3px solid #a2a9b1;" | 26
|200
|60
|600
|10
|10
|1
|1
|20
|20
|-
|'''large_1'''
|16
|16
|16
|40
| style="border-right: 3px solid #a2a9b1;" | 52
|400
|120
|1200
|20
|20
|2
|2
|20
|40
|-
|'''xlarge_1'''
|32
|32
|32
|40
| style="border-right: 3px solid #a2a9b1;" | 100
|400
|120
|1200
|20
|20
|2
| valign="top" |2
|20
|40
|-
|'''custom'''
|*
|*
|*
|*
| style="border-right: 3px solid #a2a9b1;" |
|*
|*
|*
|*
|*
|*
| valign="top" |*
|*
|*
|}

Below is the basic translation for calculating Booking Units (BEH). For full details and the complete calculation basis, please refer to the [https://wiki.bwcloud-os.de/index.php/Booking_Units Booking Units page].

{| class="wikitable"
|+
! Resource
! BEH/Day
|-
| 1 vCPU
| 1
|-
| 1 GB RAM
| 2
|-
| 10 GB Disk
| 1
|}

== Examples ==

=== Project and eligibility examples ===

==== Example project and eligibility 1 ====
In the illustration is a life cycle for a project presented.

# First, ''User I'' registers for the bwCloud-OS. At this moment, he/she is holding one ''Eligibility A''. Automatic is a start project with a quota created. Only ''User I'' is member of this project.
# Later on, the user holds an additional and larger ''Eligibility B'', granted by his/her home organization. After a [[Projects and Quota#How can I request an additional quota?|request for quota change]] more quota is granted, and the link for the associated eligibility is updated.
# ''User II'' holds no eligibility; hence, he/she can login to the bwCloud-OS, but can't use compute resources. ''User I'' wants to share the resources of ''start'' ''project I'' with ''User II''. After the [[Projects and Quota#Can project members be changed?|request for a new project member]], ''User II'' is also able to use compute resources. The former assigned eligibility will be free for use again.

[[File:Example project eligibility.drawio.png|thumb|Relationship between project and eligibility.]]

Guide: Project and Quota

2026-05-29T08:12:38Z

Admin: /* List of quota flavors */

➡️ '''Back to the FAQ for [[Projects and Quota]].'''

Quota defines the resource limits allocated to a project, such as vCPUs, RAM, networks, and storage

== Project and eligibility ==
Before a quota can be set for a project, in advance an [[Guide: Entitlement & Eligibility|entitlement/ eligibility]] needs to be granted to the project owner.

* Each project is associated with an eligibility hold by the owner of the project.
* The maximal quota a user can request is restricted by the quota flavor of his/her eligibility.
== List of quota flavors ==
The supported quota packages are described in the table below.
{| class="wikitable"
|+List of supported quota flavors
!quota flavor
!Note
|-
|empty
|Fallback. Every user owns this. User can’t generate costs. See [[Guide: Entitlement & Eligibility#Empty-eligibility|empty-eligibility.]]
|-
|tiny_1
|
|-
|xtiny_1
|
|-
|medium_1
|
|-
|xmedium_1
|
|-
|large_1
|
|-
|xlarge_1
|
|-
|custom
|User can choose the quota to be requested. See [[Guide: Entitlement & Eligibility#Custom-eligibility|custom-eligibility]].
|}
Each quota flavor is associated with resources granted to [[Projects and Quota|projects]].
{| class="wikitable"
|+Resources associated with each quota flavor
!quota flavor
!'''instances'''
!'''cores'''
!'''ram_gb'''
!'''volumes'''
! style="border-right: 3px solid #a2a9b1;" | BEH/Tag
!'''volumes_gb'''
!'''backups'''
!'''backups_gb'''
!'''networks'''
!'''subnets'''
!'''routers'''
!'''floating_ips'''
!'''security_groups'''
!'''snapshots'''
|-
|'''empty'''
|0
|0
|0
|0
| style="border-right: 3px solid #a2a9b1;" |
|0
|0
|0
|0
|0
|0
|0
|20
|0
|-
|'''tiny_1'''
|1
|1
|1
|10
| style="border-right: 3px solid #a2a9b1;" | 4
|100
|30
|300
|10
|10
|1
|0
|20
|10
|-
|'''xtiny_1'''
|2
|2
|2
|10
| style="border-right: 3px solid #a2a9b1;" | 7
|100
|30
|300
|10
|10
|1
|0
|20
|10
|-
|'''medium_1'''
|4
|4
|4
|20
| style="border-right: 3px solid #a2a9b1;" | 14
|200
|60
|600
|10
|10
|1
|1
|20
|20
|-
|'''xmedium_1'''
|8
|8
|8
|20
| style="border-right: 3px solid #a2a9b1;" | 26
|200
|60
|600
|10
|10
|1
|1
|20
|20
|-
|'''large_1'''
|16
|16
|16
|40
| style="border-right: 3px solid #a2a9b1;" | 52
|400
|120
|1200
|20
|20
|2
|2
|20
|40
|-
|'''xlarge_1'''
|32
|32
|32
|40
| style="border-right: 3px solid #a2a9b1;" | 100
|400
|120
|1200
|20
|20
|2
| valign="top" |2
|20
|40
|-
|'''custom'''
|*
|*
|*
|*
| style="border-right: 3px solid #a2a9b1;" |
|*
|*
|*
|*
|*
|*
| valign="top" |*
|*
|*
|}

Below is the basic translation for calculating Booking Units (BEH). For full details and the complete calculation basis, please refer to the [https://wiki.bwcloud-os.de/index.php/Booking_Units Booking Units page].

{| class="wikitable"
|+
! Resource
! BEH/Day
|-
| 1 vCPU
| 1
|-
| 1 GB RAM
| 2
|-
| 10 GB Disk
| 1
|}

== Examples ==

=== Project and eligibility examples ===

==== Example project and eligibility 1 ====
In the illustration is a life cycle for a project presented.

# First, ''User I'' registers for the bwCloud-OS. At this moment, he/she is holding one ''Eligibility A''. Automatic is a start project with a quota created. Only ''User I'' is member of this project.
# Later on, the user holds an additional and larger ''Eligibility B'', granted by his/her home organization. After a [[Projects and Quota#How can I request an additional quota?|request for quota change]] more quota is granted, and the link for the associated eligibility is updated.
# ''User II'' holds no eligibility; hence, he/she can login to the bwCloud-OS, but can't use compute resources. ''User I'' wants to share the resources of ''start'' ''project I'' with ''User II''. After the [[Projects and Quota#Can project members be changed?|request for a new project member]], ''User II'' is also able to use compute resources. The former assigned eligibility will be free for use again.

[[File:Example project eligibility.drawio.png|thumb|Relationship between project and eligibility.]]

Guide: Project and Quota

2026-05-29T08:11:52Z

Admin: /* List of quota flavors */

➡️ '''Back to the FAQ for [[Projects and Quota]].'''

Quota defines the resource limits allocated to a project, such as vCPUs, RAM, networks, and storage

== Project and eligibility ==
Before a quota can be set for a project, in advance an [[Guide: Entitlement & Eligibility|entitlement/ eligibility]] needs to be granted to the project owner.

* Each project is associated with an eligibility hold by the owner of the project.
* The maximal quota a user can request is restricted by the quota flavor of his/her eligibility.
== List of quota flavors ==
The supported quota packages are described in the table below.
{| class="wikitable"
|+List of supported quota flavors
!quota flavor
!Note
|-
|empty
|Fallback. Every user owns this. User can’t generate costs. See [[Guide: Entitlement & Eligibility#Empty-eligibility|empty-eligibility.]]
|-
|tiny_1
|
|-
|xtiny_1
|
|-
|medium_1
|
|-
|xmedium_1
|
|-
|large_1
|
|-
|xlarge_1
|
|-
|custom
|User can choose the quota to be requested. See [[Guide: Entitlement & Eligibility#Custom-eligibility|custom-eligibility]].
|}
Each quota flavor is associated with resources granted to [[Projects and Quota|projects]].
{| class="wikitable"
|+Resources associated with each quota flavor
!quota flavor
!'''instances'''
!'''cores'''
!'''ram_gb'''
!'''volumes'''
! style="border-right: 3px solid #a2a9b1;" | BEH/Tag
!'''volumes_gb'''
!'''backups'''
!'''backups_gb'''
!'''networks'''
!'''subnets'''
!'''routers'''
!'''floating_ips'''
!'''security_groups'''
!'''snapshots'''
|-
|'''empty'''
|0
|0
|0
|0
| style="border-right: 3px solid #a2a9b1;" |
|0
|0
|0
|0
|0
|0
|0
|20
|0
|-
|'''tiny_1'''
|1
|1
|1
|10
| style="border-right: 3px solid #a2a9b1;" | 4
|100
|30
|300
|10
|10
|1
|0
|20
|10
|-
|'''xtiny_1'''
|2
|2
|2
|10
| style="border-right: 3px solid #a2a9b1;" | 7
|100
|30
|300
|10
|10
|1
|0
|20
|10
|-
|'''medium_1'''
|4
|4
|4
|20
| style="border-right: 3px solid #a2a9b1;" | 14
|200
|60
|600
|10
|10
|1
|1
|20
|20
|-
|'''xmedium_1'''
|8
|8
|8
|20
| style="border-right: 3px solid #a2a9b1;" | 26
|200
|60
|600
|10
|10
|1
|1
|20
|20
|-
|'''large_1'''
|16
|16
|16
|40
| style="border-right: 3px solid #a2a9b1;" | 52
|400
|120
|1200
|20
|20
|2
|2
|20
|40
|-
|'''xlarge_1'''
|32
|32
|32
|40
| style="border-right: 3px solid #a2a9b1;" | 100
|400
|120
|1200
|20
|20
|2
| valign="top" |2
|20
|40
|-
|'''custom'''
|*
|*
|*
|*
| style="border-right: 3px solid #a2a9b1;" |
|*
|*
|*
|*
|*
|*
| valign="top" |*
|*
|*
|}

Below is the basic translation for calculating Booking Units (BEH). For full details and the complete calculation basis, please refer to the [https://wiki.bwcloud-os.de/index.php/Booking_Units Booking Units page].

{| class="wikitable"
|+ Basic Calculation of BEH
! Resource
! BEH/Day
|-
| 1 vCPU
| 1
|-
| 1 GB RAM
| 2
|-
| 10 GB Disk
| 1
|}

== Examples ==

=== Project and eligibility examples ===

==== Example project and eligibility 1 ====
In the illustration is a life cycle for a project presented.

# First, ''User I'' registers for the bwCloud-OS. At this moment, he/she is holding one ''Eligibility A''. Automatic is a start project with a quota created. Only ''User I'' is member of this project.
# Later on, the user holds an additional and larger ''Eligibility B'', granted by his/her home organization. After a [[Projects and Quota#How can I request an additional quota?|request for quota change]] more quota is granted, and the link for the associated eligibility is updated.
# ''User II'' holds no eligibility; hence, he/she can login to the bwCloud-OS, but can't use compute resources. ''User I'' wants to share the resources of ''start'' ''project I'' with ''User II''. After the [[Projects and Quota#Can project members be changed?|request for a new project member]], ''User II'' is also able to use compute resources. The former assigned eligibility will be free for use again.

[[File:Example project eligibility.drawio.png|thumb|Relationship between project and eligibility.]]

Guide: Project and Quota

2026-05-29T08:07:19Z

Admin: /* List of quota flavors */

➡️ '''Back to the FAQ for [[Projects and Quota]].'''

Quota defines the resource limits allocated to a project, such as vCPUs, RAM, networks, and storage

== Project and eligibility ==
Before a quota can be set for a project, in advance an [[Guide: Entitlement & Eligibility|entitlement/ eligibility]] needs to be granted to the project owner.

* Each project is associated with an eligibility hold by the owner of the project.
* The maximal quota a user can request is restricted by the quota flavor of his/her eligibility.
== List of quota flavors ==
The supported quota packages are described in the table below.
{| class="wikitable"
|+List of supported quota flavors
!quota flavor
!Note
|-
|empty
|Fallback. Every user owns this. User can’t generate costs. See [[Guide: Entitlement & Eligibility#Empty-eligibility|empty-eligibility.]]
|-
|tiny_1
|
|-
|xtiny_1
|
|-
|medium_1
|
|-
|xmedium_1
|
|-
|large_1
|
|-
|xlarge_1
|
|-
|custom
|User can choose the quota to be requested. See [[Guide: Entitlement & Eligibility#Custom-eligibility|custom-eligibility]].
|}
Each quota flavor is associated with resources granted to [[Projects and Quota|projects]].
{| class="wikitable"
|+Resources associated with each quota flavor
!quota flavor
!'''instances'''
!'''cores'''
!'''ram_gb'''
!'''volumes'''
! style="border-right: 3px solid #a2a9b1;" | BEH/Tag
!'''volumes_gb'''
!'''backups'''
!'''backups_gb'''
!'''networks'''
!'''subnets'''
!'''routers'''
!'''floating_ips'''
!'''security_groups'''
!'''snapshots'''
|-
|'''empty'''
|0
|0
|0
|0
| style="border-right: 3px solid #a2a9b1;" |
|0
|0
|0
|0
|0
|0
|0
|20
|0
|-
|'''tiny_1'''
|1
|1
|1
|10
| style="border-right: 3px solid #a2a9b1;" | 4
|100
|30
|300
|10
|10
|1
|0
|20
|10
|-
|'''xtiny_1'''
|2
|2
|2
|10
| style="border-right: 3px solid #a2a9b1;" | 7
|100
|30
|300
|10
|10
|1
|0
|20
|10
|-
|'''medium_1'''
|4
|4
|4
|20
| style="border-right: 3px solid #a2a9b1;" | 14
|200
|60
|600
|10
|10
|1
|1
|20
|20
|-
|'''xmedium_1'''
|8
|8
|8
|20
| style="border-right: 3px solid #a2a9b1;" | 26
|200
|60
|600
|10
|10
|1
|1
|20
|20
|-
|'''large_1'''
|16
|16
|16
|40
| style="border-right: 3px solid #a2a9b1;" | 52
|400
|120
|1200
|20
|20
|2
|2
|20
|40
|-
|'''xlarge_1'''
|32
|32
|32
|40
| style="border-right: 3px solid #a2a9b1;" | 100
|400
|120
|1200
|20
|20
|2
| valign="top" |2
|20
|40
|-
|'''custom'''
|*
|*
|*
|*
| style="border-right: 3px solid #a2a9b1;" |
|*
|*
|*
|*
|*
|*
| valign="top" |*
|*
|*
|}

== Examples ==

=== Project and eligibility examples ===

==== Example project and eligibility 1 ====
In the illustration is a life cycle for a project presented.

# First, ''User I'' registers for the bwCloud-OS. At this moment, he/she is holding one ''Eligibility A''. Automatic is a start project with a quota created. Only ''User I'' is member of this project.
# Later on, the user holds an additional and larger ''Eligibility B'', granted by his/her home organization. After a [[Projects and Quota#How can I request an additional quota?|request for quota change]] more quota is granted, and the link for the associated eligibility is updated.
# ''User II'' holds no eligibility; hence, he/she can login to the bwCloud-OS, but can't use compute resources. ''User I'' wants to share the resources of ''start'' ''project I'' with ''User II''. After the [[Projects and Quota#Can project members be changed?|request for a new project member]], ''User II'' is also able to use compute resources. The former assigned eligibility will be free for use again.

[[File:Example project eligibility.drawio.png|thumb|Relationship between project and eligibility.]]

Guide: Project and Quota

2026-05-29T08:05:45Z

Admin: /* List of quota flavors */

➡️ '''Back to the FAQ for [[Projects and Quota]].'''

Quota defines the resource limits allocated to a project, such as vCPUs, RAM, networks, and storage

== Project and eligibility ==
Before a quota can be set for a project, in advance an [[Guide: Entitlement & Eligibility|entitlement/ eligibility]] needs to be granted to the project owner.

* Each project is associated with an eligibility hold by the owner of the project.
* The maximal quota a user can request is restricted by the quota flavor of his/her eligibility.
== List of quota flavors ==
The supported quota packages are described in the table below.
{| class="wikitable"
|+List of supported quota flavors
!quota flavor
!Note
|-
|empty
|Fallback. Every user owns this. User can’t generate costs. See [[Guide: Entitlement & Eligibility#Empty-eligibility|empty-eligibility.]]
|-
|tiny_1
|
|-
|xtiny_1
|
|-
|medium_1
|
|-
|xmedium_1
|
|-
|large_1
|
|-
|xlarge_1
|
|-
|custom
|User can choose the quota to be requested. See [[Guide: Entitlement & Eligibility#Custom-eligibility|custom-eligibility]].
|}
Each quota flavor is associated with resources granted to [[Projects and Quota|projects]].
{| class="wikitable"
|+Resources associated with each quota flavor
!quota flavor
!'''instances'''
!'''cores'''
!'''ram_gb'''
!'''volumes'''
! style="border-right: 3px solid #a2a9b1;" | BEH/Tag
!'''volumes_gb'''
!'''backups'''
!'''backups_gb'''
!'''networks'''
!'''subnets'''
!'''routers'''
!'''floating_ips'''
!'''security_groups'''
!'''snapshots'''
|-
|'''empty'''
|0
|0
|0
|0
| style="border-right: 3px solid #a2a9b1;" |
|0
|0
|0
|0
|0
|0
|0
|20
|0
|-
|'''tiny_1'''
|1
|1
|1
|10
| style="border-right: 3px solid #a2a9b1;" |4
|100
|30
|300
|10
|10
|1
|0
|20
|10
|-
|'''xtiny_1'''
|2
|2
|2
|10
| style="border-right: 3px solid #a2a9b1;" |7
|100
|30
|300
|10
|10
|1
|0
|20
|10
|}

== Examples ==

=== Project and eligibility examples ===

==== Example project and eligibility 1 ====
In the illustration is a life cycle for a project presented.

# First, ''User I'' registers for the bwCloud-OS. At this moment, he/she is holding one ''Eligibility A''. Automatic is a start project with a quota created. Only ''User I'' is member of this project.
# Later on, the user holds an additional and larger ''Eligibility B'', granted by his/her home organization. After a [[Projects and Quota#How can I request an additional quota?|request for quota change]] more quota is granted, and the link for the associated eligibility is updated.
# ''User II'' holds no eligibility; hence, he/she can login to the bwCloud-OS, but can't use compute resources. ''User I'' wants to share the resources of ''start'' ''project I'' with ''User II''. After the [[Projects and Quota#Can project members be changed?|request for a new project member]], ''User II'' is also able to use compute resources. The former assigned eligibility will be free for use again.

[[File:Example project eligibility.drawio.png|thumb|Relationship between project and eligibility.]]

Guide: Project and Quota

2026-05-29T08:03:16Z

Admin: /* List of quota flavors */

➡️ '''Back to the FAQ for [[Projects and Quota]].'''

Quota defines the resource limits allocated to a project, such as vCPUs, RAM, networks, and storage

== Project and eligibility ==
Before a quota can be set for a project, in advance an [[Guide: Entitlement & Eligibility|entitlement/ eligibility]] needs to be granted to the project owner.

* Each project is associated with an eligibility hold by the owner of the project.
* The maximal quota a user can request is restricted by the quota flavor of his/her eligibility.
== List of quota flavors ==
The supported quota packages are described in the table below.
{| class="wikitable"
|+List of supported quota flavors
!quota flavor
!Note
|-
|empty
|Fallback. Every user owns this. User can’t generate costs. See [[Guide: Entitlement & Eligibility#Empty-eligibility|empty-eligibility.]]
|-
|tiny_1
|
|-
|xtiny_1
|
|-
|medium_1
|
|-
|xmedium_1
|
|-
|large_1
|
|-
|xlarge_1
|
|-
|custom
|User can choose the quota to be requested. See [[Guide: Entitlement & Eligibility#Custom-eligibility|custom-eligibility]].
|}
Each quota flavor is associated with resources granted to [[Projects and Quota|projects]].
{| class="wikitable"
|+Resources associated with each quota flavor
!quota flavor
!'''instances'''
!'''cores'''
!'''ram_gb'''
!'''volumes'''
!BEH/Tag
!'''volumes_gb'''
!'''backups'''
!'''backups_gb'''
!'''networks'''
!'''subnets'''
!'''routers'''
!'''floating_ips'''
!'''security_groups'''
!'''snapshots'''
|-
|'''empty'''
|0
|0
|0
|0
|
|0
|0
|0
|0
|0
|0
|0
|20
|0
|-
|'''tiny_1'''
|1
|1
|1
|10
|4
|100
|30
|300
|10
|10
|1
|0
|20
|10
|-
|'''xtiny_1'''
|2
|2
|2
|10
|7
|100
|30
|300
|10
|10
|1
|0
|20
|10
|-
|'''medium_1'''
|4
|4
|4
|20
|14
|200
|60
|600
|10
|10
|1
|1
|20
|20
|-
|'''xmedium_1'''
|8
|8
|8
|20
|26
|200
|60
|600
|10
|10
|1
|1
|20
|20
|-
|'''large_1'''
|16
|16
|16
|40
|52
|400
|120
|1200
|20
|20
|2
|2
|20
|40
|-
|'''xlarge_1'''
|32
|32
|32
|40
|100
|400
|120
|1200
|20
|20
|2
| valign="top" |2
|20
|40
|-
|'''custom'''
|*
|*
|*
|*
|
|*
|*
|*
|*
|*
|*
| valign="top" |*
|*
|*
|}

== Examples ==

=== Project and eligibility examples ===

==== Example project and eligibility 1 ====
In the illustration is a life cycle for a project presented.

# First, ''User I'' registers for the bwCloud-OS. At this moment, he/she is holding one ''Eligibility A''. Automatic is a start project with a quota created. Only ''User I'' is member of this project.
# Later on, the user holds an additional and larger ''Eligibility B'', granted by his/her home organization. After a [[Projects and Quota#How can I request an additional quota?|request for quota change]] more quota is granted, and the link for the associated eligibility is updated.
# ''User II'' holds no eligibility; hence, he/she can login to the bwCloud-OS, but can't use compute resources. ''User I'' wants to share the resources of ''start'' ''project I'' with ''User II''. After the [[Projects and Quota#Can project members be changed?|request for a new project member]], ''User II'' is also able to use compute resources. The former assigned eligibility will be free for use again.

[[File:Example project eligibility.drawio.png|thumb|Relationship between project and eligibility.]]

Cloud Migration Guide

2026-05-20T12:04:07Z

Admin: /* Prerequisites */

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

{| class="mw-message-box mw-message-box-warning"
| style="vertical-align:middle;" | '''⚠️ IMPORTANT SHUTDOWN NOTICE:'''
The Gen2 infrastructure will be permanently shut down on '''August 31, 2026'''. All projects and data that have not been migrated by this date will be irrevocably deleted. To use Gen3, you must clarify and apply for your entitlements (which are subject to costs) in a timely manner.
|}

{{InANutshell|
<li>There is no automatic migration path: Gen2 and Gen3 are completely separate environments.</li>
<li>Migration requires a new entitlement.</li>
<li>Security Groups and IP addresses will change and must be reconfigured manually.</li>
<li>'''Recommended approach:''' Start a new, fresh instance (VM) in Gen3 and copy your old data over the network (e.g., via 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.

== Important Prerequisites: Entitlements and Quotas ==
The new bwCloud-OS Gen3 will become a paid infrastructure platform. Therefore, it is necessary for each participating university or institution to actively assign the corresponding entitlements to its users. You cannot simply transfer your old projects directly without this authorization.

* '''Missing Entitlement?''' If you have not yet been assigned an entitlement, please get in touch directly with your local institution or university's IT support.
* '''Quota Allocation:''' Please note that the allocation of resource quotas is entirely managed and regulated through your respective institution.

Details can be found [https://wiki.bwcloud-os.de/index.php/Guide:_Entitlement_%26_Eligibility here].

{| class="mw-message-box mw-message-box-notice"
| style="vertical-align:middle;" | '''ℹ️ Note on Group Projects:''' Currently, there is no established process for complex group projects and their corresponding quota allocation. If you require resources for such a project, we kindly ask for a little more patience until the procedures are fully defined.
|}
== 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 Data and VMs=

There are basically two ways to transfer your data to the new bwCloud-OS (Gen3): The rsync method over the network and the snapshot method.

== 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]] and
* OpenStack Client installed, as described [[Programmatic_Access_and_Automation#OpenStack_Client|here]].

=== Procedure ===

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).

Cloud Migration Guide

2026-05-20T12:03:36Z

Admin: /* General Information */

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

{| class="mw-message-box mw-message-box-warning"
| style="vertical-align:middle;" | '''⚠️ IMPORTANT SHUTDOWN NOTICE:'''
The Gen2 infrastructure will be permanently shut down on '''August 31, 2026'''. All projects and data that have not been migrated by this date will be irrevocably deleted. To use Gen3, you must clarify and apply for your entitlements (which are subject to costs) in a timely manner.
|}

{{InANutshell|
<li>There is no automatic migration path: Gen2 and Gen3 are completely separate environments.</li>
<li>Migration requires a new entitlement.</li>
<li>Security Groups and IP addresses will change and must be reconfigured manually.</li>
<li>'''Recommended approach:''' Start a new, fresh instance (VM) in Gen3 and copy your old data over the network (e.g., via 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.

== Important Prerequisites: Entitlements and Quotas ==
The new bwCloud-OS Gen3 will become a paid infrastructure platform. Therefore, it is necessary for each participating university or institution to actively assign the corresponding entitlements to its users. You cannot simply transfer your old projects directly without this authorization.

* '''Missing Entitlement?''' If you have not yet been assigned an entitlement, please get in touch directly with your local institution or university's IT support.
* '''Quota Allocation:''' Please note that the allocation of resource quotas is entirely managed and regulated through your respective institution.

Details can be found [https://wiki.bwcloud-os.de/index.php/Guide:_Entitlement_%26_Eligibility here].

{| class="mw-message-box mw-message-box-notice"
| style="vertical-align:middle;" | '''ℹ️ Note on Group Projects:''' Currently, there is no established process for complex group projects and their corresponding quota allocation. If you require resources for such a project, we kindly ask for a little more patience until the procedures are fully defined.
|}
== 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 Data and VMs=

There are basically two ways to transfer your data to the new bwCloud-OS (Gen3): The rsync method over the network and the snapshot method.

== 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]]
=== Procedure ===

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).

Cloud Migration Guide

2026-05-20T11:59:30Z

Admin:

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

{| class="mw-message-box mw-message-box-warning"
| style="vertical-align:middle;" | '''⚠️ IMPORTANT SHUTDOWN NOTICE:'''
The Gen2 infrastructure will be permanently shut down on '''August 31, 2026'''. All projects and data that have not been migrated by this date will be irrevocably deleted. To use Gen3, you must clarify and apply for your entitlements (which are subject to costs) in a timely manner.
|}

{{InANutshell|
<li>There is no automatic migration path: Gen2 and Gen3 are completely separate environments.</li>
<li>Migration requires a new entitlement.</li>
<li>Security Groups and IP addresses will change and must be reconfigured manually.</li>
<li>'''Recommended approach:''' Start a new, fresh instance (VM) in Gen3 and copy your old data over the network (e.g., via 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.

=== Important Prerequisites: Entitlements and Quotas ===
The new bwCloud-OS Gen3 will become a paid infrastructure platform. Therefore, it is necessary for each participating university or institution to actively assign the corresponding entitlements to its users. You cannot simply transfer your old projects directly without this authorization.

* '''Missing Entitlement?''' If you have not yet been assigned an entitlement, please get in touch directly with your local institution or university's IT support.
* '''Quota Allocation:''' Please note that the allocation of resource quotas is entirely managed and regulated through your respective institution.

Details can be found [https://wiki.bwcloud-os.de/index.php/Guide:_Entitlement_%26_Eligibility here].

{| class="mw-message-box mw-message-box-notice"
| style="vertical-align:middle;" | '''ℹ️ Note on Group Projects:''' Currently, there is no established process for complex group projects and their corresponding quota allocation. If you require resources for such a project, we kindly ask for a little more patience until the procedures are fully defined.
|}
=== 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 Data and VMs=

There are basically two ways to transfer your data to the new bwCloud-OS (Gen3): The rsync method over the network and the snapshot method.

== 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]]
=== Procedure ===

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).

Cloud Migration Guide

2026-05-20T11:59:09Z

Admin:

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

{| class="mw-message-box mw-message-box-warning"
| style="vertical-align:middle;" | '''⚠️ IMPORTANT SHUTDOWN NOTICE:'''
The Gen2 infrastructure will be permanently shut down on '''August 31, 2026'''. All projects and data that have not been migrated by this date will be irrevocably deleted. To use Gen3, you must clarify and apply for your entitlements (which are subject to costs) in a timely manner.
|}

{{InANutshell|
<li>There is no automatic migration path: Gen2 and Gen3 are completely separate environments.</li>
<li>Migration requires a new entitlement.</li>
<li>Security Groups and IP addresses will change and must be reconfigured manually.</li>
<li>'''Recommended approach:''' Start a new, fresh instance (VM) in Gen3 and copy your old data over the network (e.g., via 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.

=== Important Prerequisites: Entitlements and Quotas ===
The new bwCloud-OS Gen3 will become a paid infrastructure platform. Therefore, it is necessary for each participating university or institution to actively assign the corresponding entitlements to its users. You cannot simply transfer your old projects directly without this authorization.

* '''Missing Entitlement?''' If you have not yet been assigned an entitlement, please get in touch directly with your local institution or university's IT support.
* '''Quota Allocation:''' Please note that the allocation of resource quotas is entirely managed and regulated through your respective institution.

Details can be found [https://wiki.bwcloud-os.de/index.php/Guide:_Entitlement_%26_Eligibility here].

{| class="mw-message-box mw-message-box-notice"
| style="vertical-align:middle;" | '''ℹ️ Note on Group Projects:''' Currently, there is no established process for complex group projects and their corresponding quota allocation. If you require resources for such a project, we kindly ask for a little more patience until the procedures are fully defined.
|}

=== 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 Data and VMs=

There are basically two ways to transfer your data to the new bwCloud-OS (Gen3): The rsync method over the network and the snapshot method.

== 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]]

=== Procedure ===

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).

Cloud Migration Guide

2026-05-20T11:56:46Z

Admin: /* Transferring Data and VMs */

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

{| class="mw-message-box mw-message-box-warning"
| style="vertical-align:middle;" | '''⚠️ IMPORTANT SHUTDOWN NOTICE:'''
The Gen2 infrastructure will be permanently shut down on '''August 31, 2026'''. All projects and data that have not been migrated by this date will be irrevocably deleted. To use Gen3, you must clarify and apply for your entitlements (which are subject to costs) in a timely manner.
|}

{{InANutshell|
<li>There is no automatic migration path: Gen2 and Gen3 are completely separate environments.</li>
<li>Migration requires a new entitlement.</li>
<li>Security Groups and IP addresses will change and must be reconfigured manually.</li>
<li>'''Recommended approach:''' Start a new, fresh instance (VM) in Gen3 and copy your old data over the network (e.g., via 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.

=== Important Prerequisites: Entitlements and Quotas ===
The new bwCloud-OS Gen3 will become a paid infrastructure platform. Therefore, it is necessary for each participating university or institution to actively assign the corresponding entitlements to its users. You cannot simply transfer your old projects directly without this authorization.

* '''Missing Entitlement?''' If you have not yet been assigned an entitlement, please get in touch directly with your local institution or university's IT support.
* '''Quota Allocation:''' Please note that the allocation of resource quotas is entirely managed and regulated through your respective institution.

Details can be found [https://wiki.bwcloud-os.de/index.php/Guide:_Entitlement_%26_Eligibility here].

=== 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 Data and VMs=

There are basically two ways to transfer your data to the new bwCloud-OS (Gen3): The rsync method over the network and the snapshot method.

== 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]]

=== Procedure ===

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).

Cloud Migration Guide

2026-05-20T11:56:24Z

Admin: /* Transferring */

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

{| class="mw-message-box mw-message-box-warning"
| style="vertical-align:middle;" | '''⚠️ IMPORTANT SHUTDOWN NOTICE:'''
The Gen2 infrastructure will be permanently shut down on '''August 31, 2026'''. All projects and data that have not been migrated by this date will be irrevocably deleted. To use Gen3, you must clarify and apply for your entitlements (which are subject to costs) in a timely manner.
|}

{{InANutshell|
<li>There is no automatic migration path: Gen2 and Gen3 are completely separate environments.</li>
<li>Migration requires a new entitlement.</li>
<li>Security Groups and IP addresses will change and must be reconfigured manually.</li>
<li>'''Recommended approach:''' Start a new, fresh instance (VM) in Gen3 and copy your old data over the network (e.g., via 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.

=== Important Prerequisites: Entitlements and Quotas ===
The new bwCloud-OS Gen3 will become a paid infrastructure platform. Therefore, it is necessary for each participating university or institution to actively assign the corresponding entitlements to its users. You cannot simply transfer your old projects directly without this authorization.

* '''Missing Entitlement?''' If you have not yet been assigned an entitlement, please get in touch directly with your local institution or university's IT support.
* '''Quota Allocation:''' Please note that the allocation of resource quotas is entirely managed and regulated through your respective institution.

Details can be found [https://wiki.bwcloud-os.de/index.php/Guide:_Entitlement_%26_Eligibility here].

=== 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 Data and VMs=

There are basically two ways to transfer your data to the new bwCloud: The rsync method over the network and the snapshot method.

== 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]]

=== Procedure ===

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).

Cloud Migration Guide

2026-05-20T11:51:07Z

Admin: /* General Information */

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

{| class="mw-message-box mw-message-box-warning"
| style="vertical-align:middle;" | '''⚠️ IMPORTANT SHUTDOWN NOTICE:'''
The Gen2 infrastructure will be permanently shut down on '''August 31, 2026'''. All projects and data that have not been migrated by this date will be irrevocably deleted. To use Gen3, you must clarify and apply for your entitlements (which are subject to costs) in a timely manner.
|}

{{InANutshell|
<li>There is no automatic migration path: Gen2 and Gen3 are completely separate environments.</li>
<li>Migration requires a new entitlement.</li>
<li>Security Groups and IP addresses will change and must be reconfigured manually.</li>
<li>'''Recommended approach:''' Start a new, fresh instance (VM) in Gen3 and copy your old data over the network (e.g., via 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.

=== Important Prerequisites: Entitlements and Quotas ===
The new bwCloud-OS Gen3 will become a paid infrastructure platform. Therefore, it is necessary for each participating university or institution to actively assign the corresponding entitlements to its users. You cannot simply transfer your old projects directly without this authorization.

* '''Missing Entitlement?''' If you have not yet been assigned an entitlement, please get in touch directly with your local institution or university's IT support.
* '''Quota Allocation:''' Please note that the allocation of resource quotas is entirely managed and regulated through your respective institution.

Details can be found [https://wiki.bwcloud-os.de/index.php/Guide:_Entitlement_%26_Eligibility here].

=== 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]]

==== Procedure ====

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).

Cloud Migration Guide

2026-05-20T11:50:41Z

Admin: /* Important Prerequisites: Entitlements and Quotas */

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

{| class="mw-message-box mw-message-box-warning"
| style="vertical-align:middle;" | '''⚠️ IMPORTANT SHUTDOWN NOTICE:'''
The Gen2 infrastructure will be permanently shut down on '''August 31, 2026'''. All projects and data that have not been migrated by this date will be irrevocably deleted. To use Gen3, you must clarify and apply for your entitlements (which are subject to costs) in a timely manner.
|}

{{InANutshell|
<li>There is no automatic migration path: Gen2 and Gen3 are completely separate environments.</li>
<li>Migration requires a new entitlement.</li>
<li>Security Groups and IP addresses will change and must be reconfigured manually.</li>
<li>'''Recommended approach:''' Start a new, fresh instance (VM) in Gen3 and copy your old data over the network (e.g., via 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.

=== Important Prerequisites: Entitlements and Quotas ===
The new bwCloud-OS Gen3 will become a paid infrastructure platform. Therefore, it is necessary for each participating university or institution to actively assign the corresponding entitlements to its users. You cannot simply transfer your old projects directly without this authorization.

* '''Missing Entitlement?''' If you have not yet been assigned an entitlement, please get in touch directly with your local institution or university's IT support.
* '''Quota Allocation:''' Please note that the allocation of resource quotas is entirely managed and regulated through your respective institution.

Details can be found [https://wiki.bwcloud-os.de/index.php/Guide:_Entitlement_%26_Eligibility here].

=== 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]]

==== Procedure ====

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).

Cloud Migration Guide

2026-05-20T11:48: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.
|}

{| class="mw-message-box mw-message-box-warning"
| style="vertical-align:middle;" | '''⚠️ IMPORTANT SHUTDOWN NOTICE:'''
The Gen2 infrastructure will be permanently shut down on '''August 31, 2026'''. All projects and data that have not been migrated by this date will be irrevocably deleted. To use Gen3, you must clarify and apply for your entitlements (which are subject to costs) in a timely manner.
|}

{{InANutshell|
<li>There is no automatic migration path: Gen2 and Gen3 are completely separate environments.</li>
<li>Migration requires a new entitlement.</li>
<li>Security Groups and IP addresses will change and must be reconfigured manually.</li>
<li>'''Recommended approach:''' Start a new, fresh instance (VM) in Gen3 and copy your old data over the network (e.g., via 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.

=== Important Prerequisites: Entitlements and Quotas ===
The new bwCloud-OS Gen3 will become a paid infrastructure platform. Therefore, it is necessary for each participating university or institution to actively assign the corresponding entitlements to its users. You cannot simply transfer your old projects directly without this authorization.

* '''Missing Entitlement?''' If you have not yet been assigned an entitlement, please get in touch directly with your local institution or university's IT support.
* '''Quota Allocation:''' Please note that the allocation of resource quotas is entirely managed and regulated through your respective institution.

=== 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]]

==== Procedure ====

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).

Cloud Migration Guide

2026-05-20T09:09:45Z

Admin:

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

{| class="mw-message-box mw-message-box-warning"
| style="vertical-align:middle;" | '''⚠️ IMPORTANT SHUTDOWN NOTICE:'''
The Gen2 infrastructure will be permanently shut down on '''August 31, 2026'''. All projects and data that have not been migrated by this date will be irrevocably deleted. To use Gen3, you must clarify and apply for your entitlements (which are subject to costs) in a timely manner.
|}

{{InANutshell|
<li>There is no automatic migration path: Gen2 and Gen3 are completely separate environments.</li>
<li>Migration requires a new entitlement.</li>
<li>Security Groups and IP addresses will change and must be reconfigured manually.</li>
<li>'''Recommended approach:''' Start a new, fresh instance (VM) in Gen3 and copy your old data over the network (e.g., via 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]]

==== Procedure ====

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).

Cloud Migration Guide

2026-05-20T09:07:08Z

Admin:

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

{| class="mw-message-box mw-message-box-warning"
| style="vertical-align:middle;" | '''⚠️ IMPORTANT SHUTDOWN NOTICE:'''
The Gen2 infrastructure will be permanently shut down on '''August 31, 2026'''. All projects and data that have not been migrated by this date will be irrevocably deleted. To use Gen3, you must clarify and apply for your entitlements (which are subject to costs) in a timely manner.
|}

{{InANutshell|
<li>There is no automatic migration path: Gen2 and Gen3 are completely separate environments.</li>
<li>Migration requires a new entitlement.</li>
<li>Security Groups and IP addresses will change and must be reconfigured manually.</li>
<li>'''Recommended approach:''' Start a new, fresh instance (VM) in Gen3 and copy your old data over the network (e.g., via rsync).</li>
<li>Using snapshots to transfer VMs is not recommended due to massive file sizes that can severely disrupt the transfer process.</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]]

==== Procedure ====

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).

Cloud Migration Guide

2026-05-20T08:55:13Z

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.

=== 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]]

==== Procedure ====

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).

Cloud Migration Guide

2026-05-18T13:30:39Z

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.

=== 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).

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