RE: Missing bridge/device network configuration

2024-07-11 Thread Piotr Pisz
, the network label remained unchanged (even though I > provided the appropriate names). > Is it possible to update it without deleting the zone? > > Piotr > > -Original Message- > From: Wei ZHOU > Sent: Thursday, July 11, 2024 10:40 AM > To: users@cloudstack.

Re: Missing bridge/device network configuration

2024-07-11 Thread Wei ZHOU
ned unchanged (even though I > provided the appropriate names). > Is it possible to update it without deleting the zone? > > Piotr > > -Original Message- > From: Wei ZHOU > Sent: Thursday, July 11, 2024 10:40 AM > To: users@cloudstack.apache.org > Subje

Re: Missing bridge/device network configuration

2024-07-11 Thread Jithin Raju
Yes, you can update them against the traffic types for KVM in the physical networks of the zone. -Jithin From: Piotr Pisz Date: Thursday, 11 July 2024 at 2:32 PM To: users@cloudstack.apache.org Subject: RE: Missing bridge/device network configuration Yes, that is the reason. When creating the

RE: Missing bridge/device network configuration

2024-07-11 Thread Piotr Pisz
@cloudstack.apache.org Subject: Re: Missing bridge/device network configuration In addition to what Rohit said, it looks like there are some bridges already created. you can update the traffic label of physical networks to guest0 , public0 or ceph0. The default traffic labels are cloudbr0/cloudbr1 which

Re: Missing bridge/device network configuration

2024-07-11 Thread Wei ZHOU
In addition to what Rohit said, it looks like there are some bridges already created. you can update the traffic label of physical networks to guest0 , public0 or ceph0. The default traffic labels are cloudbr0/cloudbr1 which might not be what you plan to use. -Wei On Thu, Jul 11, 2024 at 10:22 AM

Re: Missing bridge/device network configuration

2024-07-11 Thread Rohit Yadav
Piotr, I see you don't have a cloudbr0 or similar bridge which is default. If you want to use custom bridge, then you need to configure your zone's physical network's traffic type with such traffic labels before adding the KVM host. You can cross-check this against the KVM host (where it failed