It would help if you would explain networking on the KVM side - how many interfaces, bonds or not, vlans or not, bridge names, etc and how did you setup your differetn Traffic across Physical Network inside CloudStack (did you place red circle "Storage" on the right part on Physical Network, or not, etc - I'm talking about UI setup of Zone here)
Each Traffic Type (Management, Guest, Storage, Public) can and should have a KVM traffic label set to it. i.e. it's not "label of the Management Zone", it's label for each Network Traffic Type that you placed (drag and drop via UI, if created via UI...) on the Physical Network during creating the Advanced Zone. Networking (for Advanced Zone specifically) can be a bit of challenge to master and understand how it works, why to define traffic labels, and it works in general - but once that is all mastered, it's pretty straightforward... On Mon, 29 Oct 2018 at 15:23, Raymon van der Meijden < ray...@van-der-meijden.com> wrote: > > The labels of the Management Zone are cloudbr0 on all KVM Hypervisors. > The difference with this hypervisor is that i tried running a cloudbr0:1 > subinterface for the hypervisor to also act as NFS storage on the > secondary IP. > > This secondary IP is also making the connection to the management > server, maybe this is providing the issue. > > I have removed the secondary ip and will try again > > > On 29-10-18 14:51, Andrija Panic wrote: > > Go to Infrastructure --> Zones --> ZONE_NAME --> Physical Networks --> > > NAME_of_SECONDARY_STORAGE_NETWORK - if you used dedicated STORAGE > network, > > otherwise it's shared with the Management Network, so go to this one, and > > than again click on "Storage" button again and make sure KVM traffic > label > > is set to the correct name of the BRIDGE. > > > > as in images: > > https://pasteboard.co/HKHvTZF.png > > https://pasteboard.co/HKHuK5r.png > > > > KVM traffic labels = name of the physical interface on KVM host (usually > > name of the bridge) - so CloudStack will know to which bridge to join the > > SSVM vNIC...so SSVM can contact secondary storage... > > > > > > > > > > On Mon, 29 Oct 2018 at 14:44, Raymon van der Meijden < > > ray...@van-der-meijden.com> wrote: > > > >> Where did you find out these naming issues, so i can double check. > >> Because the places i have found look simular to me > >> > >> > >> On 29-10-18 14:37, Yordan Kostov wrote: > >>> Hello Raymon, > >>> > >>> I had the same issue (SSVMs booting but no OS existing). > >>> At the end I found out that this happened because my network > >> labels were not set correctly so the networks were not allocated > properly > >> no proper connection to the secondary storage was available. This means > >> that the system creates the VM metdata (compute, ram, network > interfaces) > >> but could not fetch the system disks from the secondary storage (so you > see > >> the vms but they are actually empty). > >>> I hope that helps! > >>> > >>> Best regards, > >>> Jordan > >>> > >>> -----Original Message----- > >>> From: Raymon van der Meijden [mailto:ray...@van-der-meijden.com] > >>> Sent: Monday, October 29, 2018 3:24 PM > >>> To: users@cloudstack.apache.org > >>> Subject: System Template not working on second Zone > >>> > >>> > >>> I`m running a cloudstack cluster for some time now and i`m getting the > >> hang of it. So i tried to add an additional Zone (Advanced) but i cannot > >> get the system VM to start. The VM`s are created and a running > according to > >> cloudstack. But when i check the VM using VNC there is no OS available ( > >> Bootdisk not found) > >>> > >>> I think the generation using the template is not working. But i cannot > >> figure out the issue. There is a secondary storage defined for this > zone. > >> (And it seems to be working) And i have placed the template on that > storage. > >>> The management log gives me debug logging, but i cannot find an issue. > >>> > >>> > >>> The creation of the systemtempate when mounted to the new secondary > >> storage. > >>> root@cloud:/mnt/tank/secondary/template/tmpl/1/222# > >>> > >> > /usr/share/cloudstack-common/scripts/storage/secondary/cloud-install-sys-tmplt > >>> -m /mnt/tank/secondary -u > >>> > >> > http://download.cloudstack.org/systemvm/4.11/systemvmtemplate-4.11.1-kvm.qcow2.bz2 > >>> -h kvm -F > >>> --2018-10-29 14:12:07-- > >>> > >> > http://download.cloudstack.org/systemvm/4.11/systemvmtemplate-4.11.1-kvm.qcow2.bz2 > >>> Resolving download.cloudstack.org (download.cloudstack.org)... > >>> 185.27.174.49, 2a00:f10:121:400:403:9cff:fe00:37f > >>> Connecting to download.cloudstack.org > >>> (download.cloudstack.org)|185.27.174.49|:80... connected. > >>> HTTP request sent, awaiting response... 200 OK > >>> Length: 302864294 (289M) [application/x-bzip2] Saving to: > >>> > >> > '/usr/share/cloudstack-common/scripts/storage/secondary/4edec9f7-b516-4bcc-adf8-27d61e01a3d7.qcow2' > >>> > >> > 100%[================================================================================================================================>] > >>> 302,864,294 6.48MB/s in 47s > >>> > >>> 2018-10-29 14:12:54 (6.18 MB/s) - > >>> > >> > '/usr/share/cloudstack-common/scripts/storage/secondary/4edec9f7-b516-4bcc-adf8-27d61e01a3d7.qcow2' > >>> saved [302864294/302864294] > >>> > >>> Uncompressing to > >>> > >> > /usr/share/cloudstack-common/scripts/storage/secondary/4edec9f7-b516-4bcc-adf8-27d61e01a3d7.qcow2.tmp > >>> (type bz2)...could take a long time > >>> Moving to > >>> > >> > /mnt/tank/secondary/template/tmpl/1/224///4edec9f7-b516-4bcc-adf8-27d61e01a3d7.qcow2...could > >>> take a while > >>> Successfully installed system VM template to > >> /mnt/tank/secondary/template/tmpl/1/224/ > >>> > >>> But i think this should actually be /tmpl/10/224 since the id of the > new > >> Zone is 10 (i have created and deleted some in the past) > >>> > >>> > >>> > > > -- Andrija Panić
