Hi Vivek, thank you very much for your time and effort. Your answer is very clear!… I will give it a try and report back!
> On 30 May 2020, at 12:40, Vivek Kumar <vivek.ku...@indiqus.com.INVALID> wrote: > > Hello Po Dragonwarrior- > > So when we deploy CloudStack below are the things you should take care - > > 1- Management Server (Where you install ACS) > 2- POD (Where you install your Hypervisor) > 3- Storage (Primary Storage and Secondary Storage) > > Now Let’s talk about networking - You can chose any IP schema for Management, > POD and storage but it should be routed through each subject. So your > Management network should be reachable to POD network and vice versa. Your > Secondary storage (Where we put our templates, ISO, volumes (Uploaded)) > should be reachable from Management and POD network. > > Your question about Link local IP- > > So in XenServer and KVM, It usages Link Local network for connecting the > systemVMs and Routers, So when any system VM or router gets deployed on the > Hypvervisor, it’s always blank and it needs to be configured as per your > deployment and requirement, So ACS will send command to hypervisor and > hypverior connect to system vm or router via link local IP then it configured > other component inside the router i.e create interface inside the router, > adding IPs, executing the scripts which is there in VR/SYSTEMVM. So there > are two type of system VM - a) Secondary Storage VM, b) Console proxy VM - > > Secondary storage VM needs to communicate with your management server, POD > and secondary storage and public Network , that’s why it is having management > IP, public IP inside the System VM. So when system VM needs to connect > Management, secondary storage or public network it will go via its respective > IP. Other Console proxy VM will be responsible to provide you the console of > VM over public IP, so it will need to have an Public IP. > > > Now let’s talk about Storage, there are two kind of storage we use in > CloudStack - > > 1- Primary Storage (which is store your root and data disk, So when you > deploy your VM through CloudStack, Your disks will be residing inside the > primary storage ). So if you want to use separate network for storage then > you should make sure that your hosts are able to access the storage. You can > also create a L2 networking from your hypvervisor to storage system, ACS > doesn’t bother about this primary storage connectivity it only should be > reachable through you hypervisor. > > 2- Secondary storage should be reachable from both Management network and POD > network. > >> 2. Is it possible for test purposes to deploy cs with advanced zone with the >> following addressing scheme? >> management ip range: 172.16.0.10 - 172.16.0.20, mask: 255.255.255.0, gw >> 172.16.0.254 (No VLAN) >> storage ip range: 172.16.0.30 - 172.16.0.40, mask: >> 255.255.255.0, gw 172.16.0.254 (No VLAN) >> guest ip range. 172.16.0.50 - 172.16.0.60, mask: >> 255.255.255.0, gw 172.16.0.254, (VLAN range 1000-1100) >> pubic ip range 172.16.0.70 - 172.16.0.80, mask: >> 255.255.255.0, gw 172.16.0.254, (No VLAN) > > > You really don’t need to define your guest IP range, IN advance networking if > you are choosing VLAN based ISOLATION then doesn’t matter what network you > use it will always behind your VLAN, That’s why ACS won’t ask you to provide > guest IP range, it will only ask you to define your guest Range, > >> 3. What would be the best solution for the above addressing scheme? >> a. Use two physical network interfaces NIC0: management + storage, >> NIC1: guest + public >> b. Use three physical nics NIC0:management+storage, NIC1:guest, >> NIC2:public >> c. other setup > > > It’s complete depend your requirement, but ideally you should not club you > storage traffic with other traffic. So if you have 2 physical NIC, then > probably you can use your 1st NIC for Management + Guest + Public and 2nd NIC > for storage ( This is primary storage we are talking about,) and if you use 3 > NIC then probably NIC 1 for Management and Guest and NIC2 for public and NIC3 > for Storage, One small suggestion if you are trying to use separate NIC for > storage then put it in different VLAN, i.e 192.168.0.0/24 (You are free to > decide what network to choose), So let’s say 192.168.0.10 is your storage IP > then put a one free IP on your hosts i.e 192.168.0.20. Make sure NIC3 are > connected to the same network as your storage does. > > > Vivek Kumar > Manager - Cloud & DevOps > IndiQus Technologies > 24*7 O +91 11 4055 1411 | M +91 7503460090 > www.indiqus.com <http://indiqus.com/> > > This message is intended only for the use of the individual or entity to > which it is addressed and may contain information that is confidential and/or > privileged. If you are not the intended recipient please delete the original > message and any copy of it from your computer system. You are hereby notified > that any dissemination, distribution or copying of this communication is > strictly prohibited unless proper authorization has been obtained for such > action. If you have received this communication in error, please notify the > sender immediately. Although IndiQus attempts to sweep e-mail and attachments > for viruses, it does not guarantee that both are virus-free and accepts no > liability for any damage sustained as a result of viruses. > >> On 30-May-2020, at 11:08 AM, Po Dragonwarrior <hungr...@gmail.com> wrote: >> >> Hi all, >> >> I am a new cloudstack user and while reading the related documentation some >> questions came up. >> >> 1. As explained in >> https://www.shapeblue.com/a-beginners-guide-to-cloudstack-networking/ >> <https://www.shapeblue.com/a-beginners-guide-to-cloudstack-networking/> the >> (Logical) Management Network is used for ' communication between the >> management server(s) and the system VMs. ‘ which is clear. But, in >> https://www.shapeblue.com/networking-kvm-for-cloudstack-2018-revisit-for-centos7-and-ubuntu-18-04/ >> >> <https://www.shapeblue.com/networking-kvm-for-cloudstack-2018-revisit-for-centos7-and-ubuntu-18-04/> >> it is said that 'CloudStack itself requires internal connectivity from the >> hypervisor host to system VMs (Virtual Routers, SSVM and CPVM) over the link >> local 169.254.0.0/16 subnet. This is done over a host-only bridge “cloud0”, >> which is created by CloudStack when the host is added to a CloudStack zone.’ >> >> So my question is, if the link local subnet is used for the communication >> between the hypervisor host and system vms, then the managent ip range >> address that is declared during the (advanced) zone creation what is it >> used for? Is it for the communication between the physical host and system >> vms?…and if so, what kind of traffic is travelling in this ip range? >> >> 2. Is it possible for test purposes to deploy cs with advanced zone with the >> following addressing scheme? >> management ip range: 172.16.0.10 - 172.16.0.20, mask: 255.255.255.0, gw >> 172.16.0.254 (No VLAN) >> storage ip range: 172.16.0.30 - 172.16.0.40, mask: >> 255.255.255.0, gw 172.16.0.254 (No VLAN) >> guest ip range. 172.16.0.50 - 172.16.0.60, mask: >> 255.255.255.0, gw 172.16.0.254, (VLAN range 1000-1100) >> pubic ip range 172.16.0.70 - 172.16.0.80, mask: >> 255.255.255.0, gw 172.16.0.254, (No VLAN) >> >> 3. What would be the best solution for the above addressing scheme? >> a. Use two physical network interfaces NIC0: management + storage, >> NIC1: guest + public >> b. Use three physical nics NIC0:management+storage, NIC1:guest, >> NIC2:public >> c. other setup >> >> >
