CloudStack: Difference between revisions

From Leo's Notes
This page was last edited on 29 September 2021, at 18:40.
Line 254: Line 254:
On a bare metal node, set up everything outlined in the [[CloudStack#Node setup|Node setup]] section above. The node should have the CloudStack repos, Open vSwitch, SElinux/firewalld, and the networking configured. The agent node must have virtualization enabled on the CPU and KVM should be installed. You should be able to find <code>/dev/kvm</code> on the system.
On a bare metal node, set up everything outlined in the [[CloudStack#Node setup|Node setup]] section above. The node should have the CloudStack repos, Open vSwitch, SElinux/firewalld, and the networking configured. The agent node must have virtualization enabled on the CPU and KVM should be installed. You should be able to find <code>/dev/kvm</code> on the system.


==== CloudStack Agent ====
To set up the node, install the <code>cloudstack-agent</code> package.
To set up the node, install the <code>cloudstack-agent</code> package.


Line 281: Line 282:
}}Start the CloudStack agent. The CloudStack agent should also automatically bring up libvirtd (it's a service dependency).  
}}Start the CloudStack agent. The CloudStack agent should also automatically bring up libvirtd (it's a service dependency).  


===Setup CloudStack===
==== Allow sudo access ====
At this point in the process, your management node should be up and running and it should be serving the CloudStack web UI at http://cloudstack:8080/client. Login using the default <code>admin</code> / <code>password</code> credentials.
Ensure that <code>/etc/sudoers</code> does not require TTY. In the older documentation, CloudStack requires that the 'cloud' user be able to sudo with the addition of <code>Defaults:cloud !requiretty</code>. However, looking at the installation on the CentOS 8 box, the agent actually runs as root, so perhaps root needs to be able to sudo?
 
===Setting up your first zone in CloudStack===
At this point in the process, you should have at least one bare metal host and your management node should be up and running and it should be serving the CloudStack web UI at http://cloudstack:8080/client. Login using the default <code>admin</code> / <code>password</code> credentials.


You will be greeted with a setup wizard. I have had no luck with this and it's better to ignore it. Instead, navigate to zones and manually set up your first zone.  
You will be greeted with a setup wizard. I have had no luck with this and it's better to ignore it. Instead, navigate to zones and manually set up your first zone.  
{| class="wikitable"
|+
!Step
!Description
!Screenshot
|-
|Select the zone type
|Select either basic, advanced, or advanced with security groups.
|[[File:CloudStack - New Zone 1.png|left|thumb]]
|-
|Specify zone details
|We will add the DNS resolvers for the zone and specify the hypervisor type (KVM).
Empty the guest CIDR since we're going to allow users to specify their own.
|[[File:CloudStack - New Zone 2.png|left|thumb]]
|-
|Define the physical networks
|When using the advanced zone, you need to specify the physical networks for the management, storage, and public networks.
These should correspond to the physical network devices on the hypervisor. Because we're using Open vSwitch, we'll need to specify the devices as the OVS bride names for each of the physical networks.
|<gallery>
File:CloudStack - New Zone 3.png
File:CloudStack - New Zone 3a.png
</gallery>
|-
|
|
|[[File:CloudStack - New Zone 4.png|thumb]]
|-
|
|
|[[File:CloudStack - New Zone 5.png|thumb]]
|-
|
|
|[[File:CloudStack - New Zone 6.png|thumb]]
|-
|
|
|[[File:CloudStack - New Zone 7.png|thumb]]
|-
|
|
|[[File:CloudStack - New Zone 8.png|thumb]]
|-
|
|
|[[File:CloudStack - New Zone 9.png|thumb]]
|-
|
|
|[[File:CloudStack - New Zone 10.png|thumb]]
|-
|
|
|[[File:CloudStack - New Zone 11.png|thumb]]
|-
|
|
|[[File:CloudStack - New Zone 12.png|thumb]]
|}


==Configuration==
==Configuration==
Line 303: Line 366:
When creating a new zone, you will be asked which one of these types you would like to use. Be aware of each type's limitations before continuing.
When creating a new zone, you will be asked which one of these types you would like to use. Be aware of each type's limitations before continuing.


=== Service offerings ===
===Service offerings===


==== Deployment planner ====
====Deployment planner====
There are a few deployment techniques that can be used. These are set within a compute offering and cannot be changed after it's been created ('''really?''' can we change it via API?). The options are:
There are a few deployment techniques that can be used. These are set within a compute offering and cannot be changed after it's been created ('''really?''' can we change it via API?). The options are:
{| class="wikitable"
{| class="wikitable"
Line 342: Line 405:
- if you put in a huge number like 9999, deployment would fail though.
- if you put in a huge number like 9999, deployment would fail though.


==== How to implement showback? ====
====How to implement showback?====
Is there a way to implement showback based on resources consumed by account?
Is there a way to implement showback based on resources consumed by account?


==== Monitoring resources? ====
====Monitoring resources?====
Is there a way to monitor resource usage by account, node? Any good way to push VMs into a CMDB like ServiceNow?
Is there a way to monitor resource usage by account, node? Any good way to push VMs into a CMDB like ServiceNow?


==== NetApp integration? ====
====NetApp integration?====
Is it possible to do guest VM snapshots by leveraging NetApp?<br />
Is it possible to do guest VM snapshots by leveraging NetApp?<br />


Line 356: Line 419:
Get started:
Get started:


* Download from: https://github.com/apache/cloudstack-cloudmonkey/releases/tag/6.1.0
*Download from: https://github.com/apache/cloudstack-cloudmonkey/releases/tag/6.1.0
* Documentation at: https://cwiki.apache.org/confluence/display/CLOUDSTACK/CloudStack+cloudmonkey+CLI
*Documentation at: https://cwiki.apache.org/confluence/display/CLOUDSTACK/CloudStack+cloudmonkey+CLI


When you first run CloudMonkey, you will need to set the cloud URL:
When you first run CloudMonkey, you will need to set the cloud URL:
Line 372: Line 435:
Run sync to fetch all the available API calls that your account can use. You can then tab complete any available commands.
Run sync to fetch all the available API calls that your account can use. You can then tab complete any available commands.


=== Cheat sheet ===
===Cheat sheet===
{| class="wikitable"
{| class="wikitable"
!What
!What

Revision as of 18:40, 29 September 2021

Apache CloudStack is open-source cloud computing software. It is used to deploy a infrastructure as a service (IaaS) platform on virtualization technologies such as KVM, VMware, and Xen. This is similar to OpenStack but is significantly simpler to setup and manage (albeit with less features).

This page contains my notes on setting up and using CloudStack 4.15. I am by no means a CloudStack expert so take my notes here with a huge grain of salt and feel free to make corrections.

Installation

The installation is based on CloudStack 4.15 using CentOS 8. The setup described below uses KVM and Open vSwitch. I'm basing the design decisions and approach from the installation guide at http://docs.cloudstack.apache.org/en/latest/quickinstallationguide/qig.html

Overview

I will have 1 management node and a few bare metal nodes. All nodes will have the same processor (Intel something) and memory (24GB).

Each node will have the same network configuration based on OpenVSwitch. There will be only 1 ethernet connection per node with various VLANs trunked to each node. The VLANs are:

Network Vlan Network subnet
Management 11, untagged 172.19.0.0/20
Storage 3205 172.22.0.0/24
Guest 100 - 200 n/a
Public 2 136.159.1.0/24

The network configs for the 4 nodes I'll be using are listed below. There is also a NFS server used for primary storage. The reason for the weird IPs is because this was set up on an existing network.

Node Networks
management Management: 172.19.12.141/20

Storage: 172.22.0.241/24

baremetal1 Management: 172.19.12.142/20

Storage: 172.22.0.242/24

baremetal2 Management: 172.19.12.143/20

Storage: 172.22.0.243/24

baremetal3 Management: 172.19.12.144/20

Storage: 172.22.0.244/24

netapp1 Storage: 172.22.0.19/24

Node setup

Each node will be set up with the following sub-steps.

CloudStack Repos

Install CloudStack repos.

# cat > /etc/yum.repos.d/cloudstack.repo <<EOF
[cloudstack]
name=cloudstack
baseurl=http://download.cloudstack.org/centos/8/4.15/
enabled=1
gpgcheck=0
EOF

Install base packages

Install all other dependencies.

# yum -y install epel-release
# yum -y install bridge-utils net-tools

Install OpenVSwitch from CentOS Extras:

# yum -y install \
http://mirror.centos.org/centos/8/extras/x86_64/os/Packages/centos-release-nfv-openvswitch-1-3.el8.noarch.rpm \
http://mirror.centos.org/centos/8/extras/x86_64/os/Packages/centos-release-nfv-common-1-3.el8.noarch.rpm

Disable SELinux

The system should have SELinux disabled. Use setenforce and edit the selinux config:

# setenforce 0
# vi /etc/selinux/config 
## disable selinux

Disable firewalld

# systemctl stop firewalld
# systemctl disable firewalld

Configure Open vSwitch

# echo "blacklist bridge" >> /etc/modprobe.d/local-blacklist.conf
# echo "install bridge /bin/false" >> /etc/modprobe.d/local-dontload.conf

# systemctl start openvswitch
# systemctl enable openvswitch

We will be using network-scripts to configure the Open vSwitch bridges later. I removed NetworkManager but retained network-scripts to ensure NetworkManager doesn't interfere with my network setup. The install guide leaves NetworkManager around.

I create a 'shared' bridge that's tied to the network interface called nic0. This was done to make it easier to change the bridge setup during my testing but this could be simplified. Each of the physical networks I later set up in CloudStack are its own individual bridge to make it obvious how VMs get connected to the network.

# ovs-vsctl add-br   nic0
# ovs-vsctl add-port nic0 enp4s0f0 tag=11 vlan_mode=native-untagged
# ovs-vsctl set port nic0 trunks=2,11,40-49,3205

# ovs-vsctl add-br management0 nic0 11
# ovs-vsctl add-br cloudbr0 nic0 2
# ovs-vsctl add-br cloudbr1 nic0 100
# ovs-vsctl add-br storage0 nic0 3205

The node's management IP address needs to be removed from the primary network interface and then assigned on the management0 interface. If you're doing this to a node remotely, this might interrupt your connection.

# ip addr del 172.19.12.141/20 dev enp4s0f0
# ip addr add 172.19.12.141/20 dev management0
# ip route add default via 172.19.0.3
# ip addr add 172.22.0.241/24 dev storage0

# ip link set management0 up
# ip link set storage0 up

Network configuration

Once the Open vSwitch bridges are set up, configure the interfaces as follows:

Network Interface Role Configuration
enp4s0f0 primary NIC in the host up on boot; no IP
nic0 network OVS switch that connects to the other bridges to the NIC up on boot; no IP
cloudbr0 public traffic. up on boot; no IP
cloudbr1 guest traffic up on boot; no IP
management0 management traffic up on boot; assigned with management IP
storage0 storage traffic up on boot; assigned with storage network IP

Network configs are applied using network-scripts. The idea here is to have the network interfaces be configured when the system boots automatically. For interfaces that require a static IP address, I used the following network-scripts file. Adjust the device name and IP address as required.

# cat <<EOF > /etc/sysconfig/network-scripts/ifcfg-cloudbr0
DEVICE=cloudbr0
TYPE=Bridge
ONBOOT=yes
BOOTPROTO=static
IPV6INIT=no
IPV6_AUTOCONF=no
DELAY=5
IPADDR=172.16.10.2
GATEWAY=172.16.10.1
NETMASK=255.255.255.0
DNS1=8.8.8.8
DNS2=8.8.4.4
USERCTL=no
NM_CONTROLLED=no
EOF

For devices that don't require a static IP:

cat <<EOF > ifcfg-cloudbr0
DEVICE=cloudbr0
TYPE=OVSBridge
DEVICETYPE=ovs
ONBOOT=yes
BOOTPROTO=none
HOTPLUG=no
NM_CONTROLLED=no
EOF

Once configured, verify that your node comes up with the proper network settings on a reboot.

Management node setup

On the management node, set up the network configs and the CloudStack management packages.

Setup Storage

If you intend to use the management server as the primary and secondary storage, you will need to set up a NFS server. If you intend to use an external NFS server as the primary storage, you can skip this step.

# mkdir -p /export/primary /export/secondary
# yum -y install nfs-utils
# cat > /etc/exports <<EOF
/export/secondary *(rw,async,no_root_squash,no_subtree_check)
/export/primary *(rw,async,no_root_squash,no_subtree_check)
EOF
# systemctl start nfs-server
# systemctl enable nfs-server

CloudStack management services

Install MySQL. MariaDB isn't supported and the installation fails with it.

# rpm -ivh http://repo.mysql.com/mysql80-community-release-el8.rpm
# yum -y install mysql-server
# yum -y install mysql-connector-python

## edit /etc/my.cnf to have the following lines.
cat >> /etc/my.cnf <<EOF
[mysqld]
innodb_rollback_on_timeout=1
innodb_lock_wait_timeout=600
max_connections=350
log-bin=mysql-bin
binlog-format = 'ROW'
EOF

# systemctl enable mysqld
# systemctl start mysqld

Setup CloudStack.

# yum -y install cloudstack-management

# cloudstack-setup-databases cloud:password@localhost --deploy-as=root
# cloudstack-setup-management
# systemctl start cloudstack-management
# systemctl enable cloudstack-management

After starting cloudstack-management for the firs time, it might take from 2-10 minutes for the database to set up completely. During this time, the web interface won't be responsive. In the mean time, you will need to seed the system VM images to the secondary storage. If you are using an external NFS server for your secondary storage, adjust the mount point in the following command accordingly.

## Seed the systemvm into secondary storage
# /usr/share/cloudstack-common/scripts/storage/secondary/cloud-install-sys-tmplt -m /export/secondary -u https://download.cloudstack.org/systemvm/4.15/systemvmtemplate-4.15.1-kvm.qcow2.bz2 -h kvm -F

We will continue the setup process via the web interface after setting up a bare metal node.

Bare metal node setup

You should set up at least one bare metal node which will be used to set up your first zone and pod.

On a bare metal node, set up everything outlined in the Node setup section above. The node should have the CloudStack repos, Open vSwitch, SElinux/firewalld, and the networking configured. The agent node must have virtualization enabled on the CPU and KVM should be installed. You should be able to find /dev/kvm on the system.

CloudStack Agent

To set up the node, install the cloudstack-agent package.

# yum -y install cloudstack-agent

Configure qemu and libvirtd.

## edit /etc/libvirt/qemu.conf 
vnc_listen=0.0.0.0

## edit /etc/libvirt/libvirtd.conf
listen_tls = 0
listen_tcp = 1
tcp_port = "16509"
auth_tcp = "none"
mdns_adv = 0

The CloudStack install guide instructs you to edit the libvirtd arguments to --listen, but this will prevent libvirtd from starting using systemd. Instead, you should skip this step entirely because the CloudStack agent will configure this for you when you add the node to a zone.

## The install guide suggests editing /etc/sysconfig/libvirtd to use the listen flag.
## However, this only works if you're not using systemd or using the libvirtd-tcp socket.
## I skipped this step since the agent will configure this later on.
LIBVIRTD_ARGS="--listen"

Start the CloudStack agent. The CloudStack agent should also automatically bring up libvirtd (it's a service dependency).

Allow sudo access

Ensure that /etc/sudoers does not require TTY. In the older documentation, CloudStack requires that the 'cloud' user be able to sudo with the addition of Defaults:cloud !requiretty. However, looking at the installation on the CentOS 8 box, the agent actually runs as root, so perhaps root needs to be able to sudo?

Setting up your first zone in CloudStack

At this point in the process, you should have at least one bare metal host and your management node should be up and running and it should be serving the CloudStack web UI at http://cloudstack:8080/client. Login using the default admin / password credentials.

You will be greeted with a setup wizard. I have had no luck with this and it's better to ignore it. Instead, navigate to zones and manually set up your first zone.

Step Description Screenshot
Select the zone type Select either basic, advanced, or advanced with security groups.
Specify zone details We will add the DNS resolvers for the zone and specify the hypervisor type (KVM).

Empty the guest CIDR since we're going to allow users to specify their own.

Define the physical networks When using the advanced zone, you need to specify the physical networks for the management, storage, and public networks.

These should correspond to the physical network devices on the hypervisor. Because we're using Open vSwitch, we'll need to specify the devices as the OVS bride names for each of the physical networks.

Configuration

Zone types and security groups

There are 3 types of zones that you can create:

  1. Basic zone - All guest VMs are placed on a single shared flat network. There is no isolation or security policies in place to prevent guest VMs from seeing each other.
  2. Advanced zone - Guest VMs can be placed in one or more VLAN based networks. Guest networks can either be isolated or L2. Isolated networks (depending on the chosen network offering) comes with a virtual router (VR) which offers NAT/SNAT and firewall services and uses one or more public IP addresses. L2 networks are similar but doesn't have a virtual router but instead requires these services to be offered externally. Tenants can also create something called a virtual private cloud (VPC). A VPC is like a regular isolated guest network but with additional features. A VPC allows the user to:
    1. Create multiple subnets (called tiers) which can route with each other
    2. Network traffic between tiers can be controlled through Network ACLs
    3. One or more public IPs can be associated to a VPC.
    4. Like an isolated guest network, all subnets can be NATed out through a single public IP
    5. You can create a private gateway (and therefore static routes) within a VPC
    6. You can create a VPN connection to a VPC
  3. Advanced zone with security groups - Guest VMs are placed on a shared network that is publicly routable. There is no concept of a 'public' network because the guest network should also be public. As a result, there is no ability to create any other kind of guest networks or VPCs. The only benefit here is the ability to define security groups per-VM (which is implemented via IPTables on the bare metal host). Because enabling security groups in a zone will restrict that zone from being able to create isolated guest networks or VPCs, the security group feature only appears useful in an environment where guests only need to connect to the internet.

When creating a new zone, you will be asked which one of these types you would like to use. Be aware of each type's limitations before continuing.

Service offerings

Deployment planner

There are a few deployment techniques that can be used. These are set within a compute offering and cannot be changed after it's been created (really? can we change it via API?). The options are:

Deployment planner Description
First fit Placed on the first host that has sufficient capacity
User dispersing Evenly distributes VMs by account across clusters
User concentrated Opposite of the above.
Implicit dedication requires or prefers (depending on planner mode) a dedicated host
Bare metal requires a bare metal host

More information from CloudStack's documentation on Compute and Disk Service Offerings.

Open-ended questions

Console Proxy via DNS name?

Is it possible to set up console proxy to use a specific DNS name rather than directly using the public IP address that the console proxy was assigned?

This is possibly an issue if the console proxy and web services need to sit behind a reverse proxy (yes, I know, they should have a public IP already).

Compute offerings with 'unlimited' CPU cycles?

Compute offerings require a MHz value assigned. Why is this? Can we just assign a VM entire cores?

- If you read the docs, CPU (in MHz) only has an effect if CPU cap is selected. In all other cases, the value here is something akin to 'cpu shares'.

- if you put in a huge number like 9999, deployment would fail though.

How to implement showback?

Is there a way to implement showback based on resources consumed by account?

Monitoring resources?

Is there a way to monitor resource usage by account, node? Any good way to push VMs into a CMDB like ServiceNow?

NetApp integration?

Is it possible to do guest VM snapshots by leveraging NetApp?

Tools

CloudMonkey

Get started:

When you first run CloudMonkey, you will need to set the cloud URL:

$ cmk
> sync
> set url http://172.19.12.141:8080/client/api
> set username admin
> set password password

The settings are then saved to ~/.cmk/config.

Run sync to fetch all the available API calls that your account can use. You can then tab complete any available commands.

Cheat sheet

What Command
Change output format set display table|json
Create compute offering create serviceoffering name=rcs.c2 displaytext=Medium cpunumber=2 cpuspeed=750 memory=2048 storagetype=shared provisioningtype=thin offerha=false limitcpuuse=false isvolatile=false issystem=false deploymentplanner=UserDispersingPlanner cachemode=none customized=false

Troubleshooting

When you run into issues, check the logs in /var/log/cloudstack/. There's typically a stacktrace which gets generated whenever you encounter an error.

Can't create shared network in a advanced zone using Open vSwitch

Whenever I try creating a shared network in an advanced zone that is using OVS, the step fails with: "Unable to convert network offering with specified id to network profile".

Stack trace shows that the OVS guest network guru isn't able at designing the network because the zone isn't capable of handling this network offering.

2021-09-28 16:36:26,416 DEBUG [c.c.a.ApiServer] (qtp1816147548-400:ctx-291672d1 ctx-3f19296a) (logid:83c45c2a) CIDRs from which account 'Acct[76a1585d-1bf6-11ec-a3c5-8f3e88f01ab1-admin]' is allowed to perform API calls: 0.0.0.0/0,::/0
2021-09-28 16:36:26,439 DEBUG [c.c.u.AccountManagerImpl] (qtp1816147548-400:ctx-291672d1 ctx-3f19296a) (logid:83c45c2a) Access granted to Acct[76a1585d-1bf6-11ec-a3c5-8f3e88f01ab1-admin] to [Network Offering [7-Guest-DefaultSharedNetworkOffering] by AffinityGroupAccessChecker
2021-09-28 16:36:26,517 DEBUG [c.c.n.g.BigSwitchBcfGuestNetworkGuru] (qtp1816147548-400:ctx-291672d1 ctx-3f19296a) (logid:83c45c2a) Refusing to design this network, the physical isolation type is not BCF_SEGMENT
2021-09-28 16:36:26,521 DEBUG [o.a.c.n.c.m.ContrailGuru] (qtp1816147548-400:ctx-291672d1 ctx-3f19296a) (logid:83c45c2a) Refusing to design this network
2021-09-28 16:36:26,524 DEBUG [c.c.n.g.NiciraNvpGuestNetworkGuru] (qtp1816147548-400:ctx-291672d1 ctx-3f19296a) (logid:83c45c2a) Refusing to design this network
2021-09-28 16:36:26,527 DEBUG [o.a.c.n.o.OpendaylightGuestNetworkGuru] (qtp1816147548-400:ctx-291672d1 ctx-3f19296a) (logid:83c45c2a) Refusing to design this network
2021-09-28 16:36:26,530 DEBUG [c.c.n.g.OvsGuestNetworkGuru] (qtp1816147548-400:ctx-291672d1 ctx-3f19296a) (logid:83c45c2a) Refusing to design this network
2021-09-28 16:36:26,536 DEBUG [c.c.n.g.DirectNetworkGuru] (qtp1816147548-400:ctx-291672d1 ctx-3f19296a) (logid:83c45c2a) GRE: VLAN
2021-09-28 16:36:26,536 DEBUG [c.c.n.g.DirectNetworkGuru] (qtp1816147548-400:ctx-291672d1 ctx-3f19296a) (logid:83c45c2a) GRE: VXLAN
2021-09-28 16:36:26,536 INFO  [c.c.n.g.DirectNetworkGuru] (qtp1816147548-400:ctx-291672d1 ctx-3f19296a) (logid:83c45c2a) Refusing to design this network
2021-09-28 16:36:26,539 INFO  [c.c.n.g.DirectNetworkGuru] (qtp1816147548-400:ctx-291672d1 ctx-3f19296a) (logid:83c45c2a) Refusing to design this network
2021-09-28 16:36:26,543 DEBUG [o.a.c.n.g.SspGuestNetworkGuru] (qtp1816147548-400:ctx-291672d1 ctx-3f19296a) (logid:83c45c2a) SSP not configured to be active
2021-09-28 16:36:26,546 DEBUG [c.c.n.g.BrocadeVcsGuestNetworkGuru] (qtp1816147548-400:ctx-291672d1 ctx-3f19296a) (logid:83c45c2a) Refusing to design this network
2021-09-28 16:36:26,549 DEBUG [o.a.c.e.o.NetworkOrchestrator] (qtp1816147548-400:ctx-291672d1 ctx-3f19296a) (logid:83c45c2a) Releasing lock for Acct[76a0531f-1bf6-11ec-a3c5-8f3e88f01ab1-system]
2021-09-28 16:36:26,624 DEBUG [c.c.u.d.T.Transaction] (qtp1816147548-400:ctx-291672d1 ctx-3f19296a) (logid:83c45c2a) Rolling back the transaction: Time = 172 Name =  qtp1816147548-400; called by -TransactionLegacy.rollback:888-TransactionLegacy.removeUpTo:831-TransactionLegacy.close:655-Transaction.execute:38-Transaction.execute:47-NetworkOrches
trator.createGuestNetwork:2572-NetworkOrchestrator.createGuestNetwork:2327-NetworkServiceImpl$4.doInTransaction:1502-NetworkServiceImpl$4.doInTransaction:1450-Transaction.execute:40-NetworkServiceImpl.commitNetwork:1450-NetworkServiceImpl.createGuestNetwork:1366
2021-09-28 16:36:26,667 ERROR [c.c.a.ApiServer] (qtp1816147548-400:ctx-291672d1 ctx-3f19296a) (logid:83c45c2a) unhandled exception executing api command: [Ljava.lang.String;@69a8823d
com.cloud.utils.exception.CloudRuntimeException: Unable to convert network offering with specified id to network profile
        at org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.setupNetwork(NetworkOrchestrator.java:739)
        at org.apache.cloudstack.engine.orchestration.NetworkOrchestrator$10.doInTransaction(NetworkOrchestrator.java:2634)
        at org.apache.cloudstack.engine.orchestration.NetworkOrchestrator$10.doInTransaction(NetworkOrchestrator.java:2572)
        at com.cloud.utils.db.Transaction$2.doInTransaction(Transaction.java:50)
        at com.cloud.utils.db.Transaction.execute(Transaction.java:40)
        at com.cloud.utils.db.Transaction.execute(Transaction.java:47)
...

Could this be due to the fact that this zone is created as an advanced zone which just doesn't support shared networks?