new systemvm template for master

[Rajani Karuturi]

FYI,

With strongswan[1] and java8[2] changes, a new systemvm template
is required on master.

Latest systemvm template is available at
https://builds.cloudstack.org/job/build-master-systemvm/lastSuccessfulBuild/

Thank you Pierre-Luc Dion for creating the build :)

[1] https://github.com/apache/cloudstack/pull/1741

[2] https://github.com/apache/cloudstack/pull/1888

~ Rajani

http://cloudplatform.accelerite.com/

German CloudStack Meetup

[Jochim, Ingo]

Hi all,

March 2nd we'll have our second meetup of the "german CloudStack user group".
This time it will be in Dresden.
You're very welcome to join this event and help to support the German 
CloudStack community.
At the following link you'll find more information:
https://www.meetup.com/de-DE/german-CloudStack-user-group/events/236901293/
We are planning some very interesting talks. The agenda will get published soon.
We hope to see you there.

Best regards,
Ingo

Re: Error with logs

[Vivek Kumar]

Hello Makrand,

I have set that too.. please find the attached  screen shot.



Vivek Kumar
Virtualization and Cloud Consultant


 
IndiQus Technologies Pvt Ltd 
A-98, LGF, C.R.Park, New Delhi - 110019 
24x7 +91 11 4055 1409 | M +91 7503460090 
www.indiqus.com

> On 15-Feb-2017, at 10:39 PM, Makrand  wrote:
> 
> Under global parameter you need to define the frequency for usage server to
> generate data. I just forgot the name of parameter. Enable paramneter &
> check whats the value for same parameter.
> 
> --
> Makrand
> 
> 
> On Wed, Feb 15, 2017 at 10:04 PM, Vivek Kumar 
> wrote:
> 
>> Hello,
>> 
>> I am using ACS 4.9 with xenserver 6.5, i also have installed usage server
>> and its in running stage , but i can see no error in usage.log and also i
>> am not getting anything in cloud_usage databases.
>> 
>> 
>> 
>> Can Someone please suggest what can be the cause.
>> 
>> *Vivek Kumar*
>> Virtualization and Cloud Consultant
>> 
>> [image: http://www.indiqus.com/images/logo.jpg]  
>> *I*ndi*Q*us Technologies Pvt Ltd
>> A-98, LGF, C.R.Park, New Delhi - 110019
>> *O* +91 11 4055 1409 ( 24*7 Support HelpLine )| *M* +91 7503460090
>> www.indiqus.com  
>> 

Re: Error with logs

[Makrand]

Under global parameter you need to define the frequency for usage server to
generate data. I just forgot the name of parameter. Enable paramneter &
check whats the value for same parameter.

--
Makrand


On Wed, Feb 15, 2017 at 10:04 PM, Vivek Kumar 
wrote:

> Hello,
>
> I am using ACS 4.9 with xenserver 6.5, i also have installed usage server
> and its in running stage , but i can see no error in usage.log and also i
> am not getting anything in cloud_usage databases.
>
>
>
> Can Someone please suggest what can be the cause.
>
> *Vivek Kumar*
> Virtualization and Cloud Consultant
>
> [image: http://www.indiqus.com/images/logo.jpg]  
> *I*ndi*Q*us Technologies Pvt Ltd
> A-98, LGF, C.R.Park, New Delhi - 110019
> *O* +91 11 4055 1409 ( 24*7 Support HelpLine )| *M* +91 7503460090
> www.indiqus.com  
>

Re: Intel v3 and v4 CPUs in the same cluster

[Nando Beifiori]

Thanks for the clarification.

In this specific case v3 is a Haswell-noTSX while v4 is a Broadwell, with
the latter that has 6 more features (according to the cpu_map.xml )

So, I reckon an agent.properties set as follows would work:

guest.cpu.mode=custom
guest.cpu.model=Haswell-noTSX

Thanks again

On 10 February 2017 at 19:07, ilya  wrote:

> https://media.readthedocs.org/pdf/cloudstack-installation/4.
> 8/cloudstack-installation.pdf
>
> Page 76 explains it.. you want for CPU instructions sets to match and be
> consistent if you plan to run v3 and v4 cpus in the same cluster.
>
> Regards
> ilya
>
> On 2/10/17 8:23 AM, Rafael Weingärtner wrote:
> > From my experience, yes it would work.
> >
> > At the end what matter are the CPU capabilities, meaning the instructions
> > tha can be used by operating systems (O.S) and their processes, in this
> > case, VMs can be considered processes in the hypervisor (hypervisors are
> > OS). We normally do the masking to hide features that may only be
> available
> > in one host or other; when you migrate a VM of a host (without masking),
> if
> > the VM ends up in a host that does not have the same CPU features it may
> > crash or present unexpected behaviors.
> >
> > On Fri, Feb 10, 2017 at 11:15 AM, Nando Beifiori <
> nandobeifi...@gmail.com>
> > wrote:
> >
> >> Hi Rafael,
> >>
> >> in this case the hypervisor is KVM and I think it supports masking, but
> let
> >> me check if I got it right:
> >>
> >> if the CPU is not exactly the same the features can be masked using
> >> hypervisor's capabilities.
> >>
> >> Does it mean that if the CPU has the exact same features but different
> >> frequency for example it would work?
> >>
> >> Thanks
> >>
> >> On 10 February 2017 at 15:46, Rafael Weingärtner <
> >> rafaelweingart...@gmail.com> wrote:
> >>
> >>> It depends on your hypervisor.
> >>> For XenServer, you should check the CPU feature you have and if the CPU
> >>> supports masking [1].
> >>>
> >>> xe host-cpu-info
> 
> >>>
> >>> Look for the "features" information, and then check if your hardware
> guy
> >>> can provide a processor with similar features or one that supports
> >> masking
> >>> the same features as your current servers' CPUs.
> >>>
> >>> [1] https://support.citrix.com/article/CTX127059
> >>>
> >>> On Fri, Feb 10, 2017 at 10:28 AM, Nando Beifiori <
> >> nandobeifi...@gmail.com>
> >>> wrote:
> >>>
>  Hi all,
> 
>  quick but very important question: I have a cluster with Intel Xeon
> >>> E5-2667
>  v3 CPUs and I need to add another host, but my provider has replaced
> >> the
> >>> v3
>  with the v4 of the same CPU.
> 
>  The differences are:
> 
> - Lithography (22nm > 14nm)
> - Cache size (20MB > 25MB)
> - Max Memory Bandwidth (68 GB/s > 76.8 GB/s)
> - Intel TSX-NI feature which is present in v4 but not in the v3.
> 
>  Frequency, turbo frequency and cores are exactly the same.
>  Would it be possible to add the new host to the same cluster or should
> >> I
>  create a new cluster or maybe look for a provider that still has the
> v3
>  CPU?
> 
>  Cloudstack version is 4.9 and hosts use Centos 7.2.
> 
>  Thanks in advance
> 
> >>>
> >>>
> >>>
> >>> --
> >>> Rafael Weingärtner
> >>>
> >>
> >
> >
> >
>

Error with logs

[Vivek Kumar]

Hello,

I am using ACS 4.9 with xenserver 6.5, i also have installed usage server
and its in running stage , but i can see no error in usage.log and also i
am not getting anything in cloud_usage databases.



Can Someone please suggest what can be the cause.

*Vivek Kumar*
Virtualization and Cloud Consultant

[image: http://www.indiqus.com/images/logo.jpg]  
*I*ndi*Q*us Technologies Pvt Ltd
A-98, LGF, C.R.Park, New Delhi - 110019
*O* +91 11 4055 1409 ( 24*7 Support HelpLine )| *M* +91 7503460090
www.indiqus.com  

How to install fixes?

[Ivan Derbenev]

Hello!
We currently have CS 4.8, installed from yum repo 
http://cloudstack.apt-get.eu/centos/6/4.8/

We've got a known and already-fixed bug - 
https://issues.apache.org/jira/browse/CLOUDSTACK-9353, it's said it was pushed 
to master branch
However, after the yum update I got nothing to download

Should I upgrade my management server manually, then?
Any info on this? ( I don't need to upgrade to 4.9, I just need current fixes 
for 4.8)

Best Regards
Tech-corps IT Engineer
Ivan Derbenev
Phone: +79633431774

Re: Basic Networking (ACS 4.9) --Allow VMs access from Local Area Network

[John Adams]

Hi Boris,

Thanks for your response. Yes I'm building a basic zone, just for starters.


--John O. Adams

On 15 February 2017 at 16:32, Boris Stoyanov 
wrote:

> Hi John,
>
> Maybe I misunderstood, are you building advanced or basic zone?
>
> Thanks,
> Boris Stoyanov
>
> boris.stoya...@shapeblue.com
> www.shapeblue.com
> @shapeblue
>
>
>
>
> On Feb 15, 2017, at 12:34 PM, John Adams  wrote:
>
> Hi Boris,
>
> I think I'm actually using the Shared network offering. The VMs being
> created are in the same same physical network subnet. Isolation is an
> option but I'm not using that at this point.
>
> Thanks.
>
>
> --John O. Adams
>
> On 15 February 2017 at 11:50, Boris Stoyanov  > wrote:
>
>> Hi John,
>>
>> In isolated networks VMs should be accessed only through the virtual
>> router IP.
>>
>> To access the VM over ssh, you should go to network setting and enable a
>> port on the Virtual Router IP. Then create a port forwarding rule from that
>> enabled port to port 22 on the specific VM within that network. After that
>> try to ssh the enabled port on the VR and you should end-up in the VM
>>
>> PS. In isolated networks you shouldn’t be able to ping the VM, all the
>> traffic goes through the VR.
>>
>> Thanks,
>> Boris Stoyanov
>>
>>
>>
>> boris.stoya...@shapeblue.com
>> www.shapeblue.com
>> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
>> @shapeblue
>>
>>
>>
>> > On Feb 15, 2017, at 8:37 AM, John Adams  wrote:
>> >
>> > Hi all,
>> >
>> > Still learning the ropes in a test environment here. Hitting a little
>> snag
>> > with networking here. The physical network has 2 VLANs. (192.168.10.0
>> and
>> > 192.168.30.0)
>> >
>> > This is my current ACS testing environment:
>> >
>> > 1 management server (Ubuntu 14.04): 192.168.30.14
>> > 2 KVM  Hosts (Ubuntu 14.04): 192.168.10.12 and 192.168.30.12
>> >
>> > With that, I created 2 different zones, each with 1 pod and 1 cluster
>> and 1
>> > host respectively.
>> >
>> > *The good:*
>> > I can create VMs on either of the hosts. I'm able to ping the VMs and
>> even
>> > ssh into them only if I'm on the host or the management server or from
>> the
>> > ACS console itself (within the network).
>> >
>> > *The Issue:*
>> > I can't ssh or even ping the VMs when in the same network outside the
>> host
>> > environment. What could be the problem?
>> >
>> > A. Management Server network config is as below:
>> > -
>> > *auto lo*
>> > *iface lo inet loopback*
>> >
>> > *auto eth0*
>> > *iface eth0 inet static*
>> > *   address 192.168.30.14*
>> > *   netmask 255.255.255.0*
>> > *   gateway 192.168.30.254*
>> >   *dns-nameservers 192.168.30.254 4.2.2.2*
>> >   *#dns-domain cloudstack.et.test.local*
>> > -
>> >
>> > B. The KVM host network configuration is a below:
>> >
>> > Host 1: .10
>> > -
>> >
>> > *# interfaces(5) file used by ifup(8) and ifdown(8)*
>> >
>> > *auto lo*
>> >
>> > *iface lo inet loopback*
>> >
>> > *# The primary network interface*
>> >
>> > *auto em1*
>> >
>> > *iface em1 inet manual*
>> >
>> >
>> > *# Public network*
>> >
>> > *   auto cloudbr0*
>> >
>> > *   iface cloudbr0 inet static*
>> >
>> > *address 192.168.10.12*
>> >
>> > *network 192.168.10.0*
>> >
>> > *netmask 255.255.255.0*
>> >
>> > *gateway 192.168.10.254*
>> >
>> > *broadcast 192.168.10.255*
>> >
>> > *dns-nameservers 192.168.10.254 4.2.2.2*
>> >
>> > *#dns-domain cloudstack.et.test.local*
>> >
>> > *bridge_ports em1*
>> >
>> > *bridge_fd 5*
>> >
>> > *bridge_stp off*
>> >
>> > *bridge_maxwait 1*
>> >
>> >
>> > *# Private network (not in use for now. Just using 1 bridge)*
>> >
>> > *auto cloudbr1*
>> >
>> > *iface cloudbr1 inet manual*
>> >
>> > *bridge_ports none*
>> >
>> > *bridge_fd 5*
>> >
>> > *bridge_stp off*
>> >
>> > *bridge_maxwait 1*
>> > ---
>> >
>> >
>> > Host 2: .30
>> > ---
>> >
>> > *# interfaces(5) file used by ifup(8) and ifdown(8)*
>> >
>> > *auto lo*
>> >
>> > *iface lo inet loopback*
>> >
>> > *# The primary network interface*
>> >
>> > *auto em1*
>> >
>> > *iface em1 inet manual*
>> >
>> >
>> > *# Public network*
>> >
>> > *   auto cloudbr0*
>> >
>> > *   iface cloudbr0 inet static*
>> >
>> > *address 192.168.30.12*
>> >
>> > *network 192.168.30.0*
>> >
>> > *netmask 255.255.255.0*
>> >
>> > *gateway 192.168.30.254*
>> >
>> > *broadcast 192.168.30.255*
>> >
>> > *dns-nameservers 192.168.30.254 4.2.2.2*
>> >
>> > *#dns-domain cloudstack.et.test.local*
>> >
>> > *bridge_ports em1*
>> >
>> > *bridge_fd 5*
>> >
>> > *bridge_stp off*
>> >
>> > *bridge_maxwait 1*
>> >
>> >
>> > *# Private network (not in use for now. Just using 1 bridge)*
>> >
>> > *auto cloudbr1*

Re: Basic Networking (ACS 4.9) --Allow VMs access from Local Area Network

[Boris Stoyanov]

Hi John,

Maybe I misunderstood, are you building advanced or basic zone?

Thanks,
Boris Stoyanov

boris.stoya...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue
  
 

On Feb 15, 2017, at 12:34 PM, John Adams 
> wrote:

Hi Boris,

I think I'm actually using the Shared network offering. The VMs being created 
are in the same same physical network subnet. Isolation is an option but I'm 
not using that at this point.

Thanks.


--John O. Adams

On 15 February 2017 at 11:50, Boris Stoyanov 
> wrote:
Hi John,

In isolated networks VMs should be accessed only through the virtual router IP.

To access the VM over ssh, you should go to network setting and enable a port 
on the Virtual Router IP. Then create a port forwarding rule from that enabled 
port to port 22 on the specific VM within that network. After that try to ssh 
the enabled port on the VR and you should end-up in the VM

PS. In isolated networks you shouldn’t be able to ping the VM, all the traffic 
goes through the VR.

Thanks,
Boris Stoyanov



boris.stoya...@shapeblue.com
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue



> On Feb 15, 2017, at 8:37 AM, John Adams 
> > wrote:
>
> Hi all,
>
> Still learning the ropes in a test environment here. Hitting a little snag
> with networking here. The physical network has 2 VLANs. (192.168.10.0 and
> 192.168.30.0)
>
> This is my current ACS testing environment:
>
> 1 management server (Ubuntu 14.04): 192.168.30.14
> 2 KVM  Hosts (Ubuntu 14.04): 192.168.10.12 and 192.168.30.12
>
> With that, I created 2 different zones, each with 1 pod and 1 cluster and 1
> host respectively.
>
> *The good:*
> I can create VMs on either of the hosts. I'm able to ping the VMs and even
> ssh into them only if I'm on the host or the management server or from the
> ACS console itself (within the network).
>
> *The Issue:*
> I can't ssh or even ping the VMs when in the same network outside the host
> environment. What could be the problem?
>
> A. Management Server network config is as below:
> -
> *auto lo*
> *iface lo inet loopback*
>
> *auto eth0*
> *iface eth0 inet static*
> *   address 192.168.30.14*
> *   netmask 255.255.255.0*
> *   gateway 192.168.30.254*
>   *dns-nameservers 192.168.30.254 4.2.2.2*
>   *#dns-domain cloudstack.et.test.local*
> -
>
> B. The KVM host network configuration is a below:
>
> Host 1: .10
> -
>
> *# interfaces(5) file used by ifup(8) and ifdown(8)*
>
> *auto lo*
>
> *iface lo inet loopback*
>
> *# The primary network interface*
>
> *auto em1*
>
> *iface em1 inet manual*
>
>
> *# Public network*
>
> *   auto cloudbr0*
>
> *   iface cloudbr0 inet static*
>
> *address 192.168.10.12*
>
> *network 192.168.10.0*
>
> *netmask 255.255.255.0*
>
> *gateway 192.168.10.254*
>
> *broadcast 192.168.10.255*
>
> *dns-nameservers 192.168.10.254 4.2.2.2*
>
> *#dns-domain cloudstack.et.test.local*
>
> *bridge_ports em1*
>
> *bridge_fd 5*
>
> *bridge_stp off*
>
> *bridge_maxwait 1*
>
>
> *# Private network (not in use for now. Just using 1 bridge)*
>
> *auto cloudbr1*
>
> *iface cloudbr1 inet manual*
>
> *bridge_ports none*
>
> *bridge_fd 5*
>
> *bridge_stp off*
>
> *bridge_maxwait 1*
> ---
>
>
> Host 2: .30
> ---
>
> *# interfaces(5) file used by ifup(8) and ifdown(8)*
>
> *auto lo*
>
> *iface lo inet loopback*
>
> *# The primary network interface*
>
> *auto em1*
>
> *iface em1 inet manual*
>
>
> *# Public network*
>
> *   auto cloudbr0*
>
> *   iface cloudbr0 inet static*
>
> *address 192.168.30.12*
>
> *network 192.168.30.0*
>
> *netmask 255.255.255.0*
>
> *gateway 192.168.30.254*
>
> *broadcast 192.168.30.255*
>
> *dns-nameservers 192.168.30.254 4.2.2.2*
>
> *#dns-domain cloudstack.et.test.local*
>
> *bridge_ports em1*
>
> *bridge_fd 5*
>
> *bridge_stp off*
>
> *bridge_maxwait 1*
>
>
> *# Private network (not in use for now. Just using 1 bridge)*
>
> *auto cloudbr1*
>
> *iface cloudbr1 inet manual*
>
> *bridge_ports none*
>
> *bridge_fd 5*
>
> *bridge_stp off*
>
> *bridge_maxwait 1*
>
> ---
>
>
> --John O. Adams

Re: Basic Networking (ACS 4.9) --Allow VMs access from Local Area Network

[John Adams]

Hi Boris,

I think I'm actually using the Shared network offering. The VMs being
created are in the same same physical network subnet. Isolation is an
option but I'm not using that at this point.

Thanks.


--John O. Adams

On 15 February 2017 at 11:50, Boris Stoyanov 
wrote:

> Hi John,
>
> In isolated networks VMs should be accessed only through the virtual
> router IP.
>
> To access the VM over ssh, you should go to network setting and enable a
> port on the Virtual Router IP. Then create a port forwarding rule from that
> enabled port to port 22 on the specific VM within that network. After that
> try to ssh the enabled port on the VR and you should end-up in the VM
>
> PS. In isolated networks you shouldn’t be able to ping the VM, all the
> traffic goes through the VR.
>
> Thanks,
> Boris Stoyanov
>
>
>
> boris.stoya...@shapeblue.com
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> @shapeblue
>
>
>
> > On Feb 15, 2017, at 8:37 AM, John Adams  wrote:
> >
> > Hi all,
> >
> > Still learning the ropes in a test environment here. Hitting a little
> snag
> > with networking here. The physical network has 2 VLANs. (192.168.10.0 and
> > 192.168.30.0)
> >
> > This is my current ACS testing environment:
> >
> > 1 management server (Ubuntu 14.04): 192.168.30.14
> > 2 KVM  Hosts (Ubuntu 14.04): 192.168.10.12 and 192.168.30.12
> >
> > With that, I created 2 different zones, each with 1 pod and 1 cluster
> and 1
> > host respectively.
> >
> > *The good:*
> > I can create VMs on either of the hosts. I'm able to ping the VMs and
> even
> > ssh into them only if I'm on the host or the management server or from
> the
> > ACS console itself (within the network).
> >
> > *The Issue:*
> > I can't ssh or even ping the VMs when in the same network outside the
> host
> > environment. What could be the problem?
> >
> > A. Management Server network config is as below:
> > -
> > *auto lo*
> > *iface lo inet loopback*
> >
> > *auto eth0*
> > *iface eth0 inet static*
> > *   address 192.168.30.14*
> > *   netmask 255.255.255.0*
> > *   gateway 192.168.30.254*
> >   *dns-nameservers 192.168.30.254 4.2.2.2*
> >   *#dns-domain cloudstack.et.test.local*
> > -
> >
> > B. The KVM host network configuration is a below:
> >
> > Host 1: .10
> > -
> >
> > *# interfaces(5) file used by ifup(8) and ifdown(8)*
> >
> > *auto lo*
> >
> > *iface lo inet loopback*
> >
> > *# The primary network interface*
> >
> > *auto em1*
> >
> > *iface em1 inet manual*
> >
> >
> > *# Public network*
> >
> > *   auto cloudbr0*
> >
> > *   iface cloudbr0 inet static*
> >
> > *address 192.168.10.12*
> >
> > *network 192.168.10.0*
> >
> > *netmask 255.255.255.0*
> >
> > *gateway 192.168.10.254*
> >
> > *broadcast 192.168.10.255*
> >
> > *dns-nameservers 192.168.10.254 4.2.2.2*
> >
> > *#dns-domain cloudstack.et.test.local*
> >
> > *bridge_ports em1*
> >
> > *bridge_fd 5*
> >
> > *bridge_stp off*
> >
> > *bridge_maxwait 1*
> >
> >
> > *# Private network (not in use for now. Just using 1 bridge)*
> >
> > *auto cloudbr1*
> >
> > *iface cloudbr1 inet manual*
> >
> > *bridge_ports none*
> >
> > *bridge_fd 5*
> >
> > *bridge_stp off*
> >
> > *bridge_maxwait 1*
> > ---
> >
> >
> > Host 2: .30
> > ---
> >
> > *# interfaces(5) file used by ifup(8) and ifdown(8)*
> >
> > *auto lo*
> >
> > *iface lo inet loopback*
> >
> > *# The primary network interface*
> >
> > *auto em1*
> >
> > *iface em1 inet manual*
> >
> >
> > *# Public network*
> >
> > *   auto cloudbr0*
> >
> > *   iface cloudbr0 inet static*
> >
> > *address 192.168.30.12*
> >
> > *network 192.168.30.0*
> >
> > *netmask 255.255.255.0*
> >
> > *gateway 192.168.30.254*
> >
> > *broadcast 192.168.30.255*
> >
> > *dns-nameservers 192.168.30.254 4.2.2.2*
> >
> > *#dns-domain cloudstack.et.test.local*
> >
> > *bridge_ports em1*
> >
> > *bridge_fd 5*
> >
> > *bridge_stp off*
> >
> > *bridge_maxwait 1*
> >
> >
> > *# Private network (not in use for now. Just using 1 bridge)*
> >
> > *auto cloudbr1*
> >
> > *iface cloudbr1 inet manual*
> >
> > *bridge_ports none*
> >
> > *bridge_fd 5*
> >
> > *bridge_stp off*
> >
> > *bridge_maxwait 1*
> >
> > ---
> >
> >
> > --John O. Adams
>
>

Re: Basic Networking (ACS 4.9) --Allow VMs access from Local Area Network

[Boris Stoyanov]

Hi John,

In isolated networks VMs should be accessed only through the virtual router IP. 

To access the VM over ssh, you should go to network setting and enable a port 
on the Virtual Router IP. Then create a port forwarding rule from that enabled 
port to port 22 on the specific VM within that network. After that try to ssh 
the enabled port on the VR and you should end-up in the VM

PS. In isolated networks you shouldn’t be able to ping the VM, all the traffic 
goes through the VR. 

Thanks,
Boris Stoyanov

 

boris.stoya...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue
  
 

> On Feb 15, 2017, at 8:37 AM, John Adams  wrote:
> 
> Hi all,
> 
> Still learning the ropes in a test environment here. Hitting a little snag
> with networking here. The physical network has 2 VLANs. (192.168.10.0 and
> 192.168.30.0)
> 
> This is my current ACS testing environment:
> 
> 1 management server (Ubuntu 14.04): 192.168.30.14
> 2 KVM  Hosts (Ubuntu 14.04): 192.168.10.12 and 192.168.30.12
> 
> With that, I created 2 different zones, each with 1 pod and 1 cluster and 1
> host respectively.
> 
> *The good:*
> I can create VMs on either of the hosts. I'm able to ping the VMs and even
> ssh into them only if I'm on the host or the management server or from the
> ACS console itself (within the network).
> 
> *The Issue:*
> I can't ssh or even ping the VMs when in the same network outside the host
> environment. What could be the problem?
> 
> A. Management Server network config is as below:
> -
> *auto lo*
> *iface lo inet loopback*
> 
> *auto eth0*
> *iface eth0 inet static*
> *   address 192.168.30.14*
> *   netmask 255.255.255.0*
> *   gateway 192.168.30.254*
>   *dns-nameservers 192.168.30.254 4.2.2.2*
>   *#dns-domain cloudstack.et.test.local*
> -
> 
> B. The KVM host network configuration is a below:
> 
> Host 1: .10
> -
> 
> *# interfaces(5) file used by ifup(8) and ifdown(8)*
> 
> *auto lo*
> 
> *iface lo inet loopback*
> 
> *# The primary network interface*
> 
> *auto em1*
> 
> *iface em1 inet manual*
> 
> 
> *# Public network*
> 
> *   auto cloudbr0*
> 
> *   iface cloudbr0 inet static*
> 
> *address 192.168.10.12*
> 
> *network 192.168.10.0*
> 
> *netmask 255.255.255.0*
> 
> *gateway 192.168.10.254*
> 
> *broadcast 192.168.10.255*
> 
> *dns-nameservers 192.168.10.254 4.2.2.2*
> 
> *#dns-domain cloudstack.et.test.local*
> 
> *bridge_ports em1*
> 
> *bridge_fd 5*
> 
> *bridge_stp off*
> 
> *bridge_maxwait 1*
> 
> 
> *# Private network (not in use for now. Just using 1 bridge)*
> 
> *auto cloudbr1*
> 
> *iface cloudbr1 inet manual*
> 
> *bridge_ports none*
> 
> *bridge_fd 5*
> 
> *bridge_stp off*
> 
> *bridge_maxwait 1*
> ---
> 
> 
> Host 2: .30
> ---
> 
> *# interfaces(5) file used by ifup(8) and ifdown(8)*
> 
> *auto lo*
> 
> *iface lo inet loopback*
> 
> *# The primary network interface*
> 
> *auto em1*
> 
> *iface em1 inet manual*
> 
> 
> *# Public network*
> 
> *   auto cloudbr0*
> 
> *   iface cloudbr0 inet static*
> 
> *address 192.168.30.12*
> 
> *network 192.168.30.0*
> 
> *netmask 255.255.255.0*
> 
> *gateway 192.168.30.254*
> 
> *broadcast 192.168.30.255*
> 
> *dns-nameservers 192.168.30.254 4.2.2.2*
> 
> *#dns-domain cloudstack.et.test.local*
> 
> *bridge_ports em1*
> 
> *bridge_fd 5*
> 
> *bridge_stp off*
> 
> *bridge_maxwait 1*
> 
> 
> *# Private network (not in use for now. Just using 1 bridge)*
> 
> *auto cloudbr1*
> 
> *iface cloudbr1 inet manual*
> 
> *bridge_ports none*
> 
> *bridge_fd 5*
> 
> *bridge_stp off*
> 
> *bridge_maxwait 1*
> 
> ---
> 
> 
> --John O. Adams

Re: Moving VMs to particular Hosts

[Marc-Aurèle Brothier]

Erik is correct about the preferred guest os to stick Windows VMs to a set
of hosts. We're not using HA, so I cannot guarantee that they will be
picked up but it should.

On Wed, Feb 15, 2017 at 9:02 AM, Erik Weber  wrote:

> If I recall correctly then CloudStack has a setting for the preferred guest
> os that should run on a host? Should be in host settings.
>
>
> Erik
>
> ons. 15. feb. 2017 kl. 06.13 skrev Makrand :
>
> > Hi,
> >
> > Lets say I've a XENserver resource pool containing 8 hosts in my
> cloudstack
> > setup. I've only handful of windows VM running, lets say on host1. In
> case
> > host1 goes down abruptly, is there any way I can restrict these VMs to
> move
> > (via HA motion) to only host 2,3 or 4 and not to remaining hosts in
> > cluster? Is this doable from cloud stack?
> >
> >
> > Thing is, we only have handful of windows VMs (2008 R2/2012 R2). The way
> > Microsoft licences: If you're expecting your VM to reside on particular
> > host, you should purchase license for that host. This is what the
> Microsoft
> > guy told to my manager. So we are planning to license 4 hosts only. Kind
> of
> > odd licensing policy from MS, I must say.
> >
> >
> >
> > --
> > Makrand
> >
>

Re: Moving VMs to particular Hosts

[Erik Weber]

If I recall correctly then CloudStack has a setting for the preferred guest
os that should run on a host? Should be in host settings.


Erik

ons. 15. feb. 2017 kl. 06.13 skrev Makrand :

> Hi,
>
> Lets say I've a XENserver resource pool containing 8 hosts in my cloudstack
> setup. I've only handful of windows VM running, lets say on host1. In case
> host1 goes down abruptly, is there any way I can restrict these VMs to move
> (via HA motion) to only host 2,3 or 4 and not to remaining hosts in
> cluster? Is this doable from cloud stack?
>
>
> Thing is, we only have handful of windows VMs (2008 R2/2012 R2). The way
> Microsoft licences: If you're expecting your VM to reside on particular
> host, you should purchase license for that host. This is what the Microsoft
> guy told to my manager. So we are planning to license 4 hosts only. Kind of
> odd licensing policy from MS, I must say.
>
>
>
> --
> Makrand
>