I've also seen randomly loose connectivity issue - with ESXi and CloudStack 
system VMs. For me, it was not cloudstack related, but something with my 
network and debian.

It was reverse ARP related and I no longer see this issue (since that test env 
has been decommissions), but here is what I would try - as a test - create a 
cronjob on system vms and continuously ping cloudstack management server (or 
something few hops away). Give this couple of hours and see if you lose 
connectivity again.

> -----Original Message-----
> From: Gaspare A Silvestri [mailto:g.silves...@netsons.com]
> Sent: Monday, August 05, 2013 3:15 AM
> To: users@cloudstack.apache.org
> Subject: Re: CS 4.1 + vSphere 5.1 - System VMs issue
> 
> Hello everybody,
> 
> is there anybody who can help me with my previous requests?
> 
> Thanks in advance,
> 
> Gaspare
> 
> On 04/08/2013 12:11, Gaspare A Silvestri wrote:
> > Hello everybody,
> >
> > I've configured the parameters we talked about (Host configured with
> > the CS Management private address), with no luck.
> >
> > If I manually force the gateway for the private and public interfaces
> > on both SSVM and Console Proxy VM, I'm able to interact with the
> > machines, but I'm still not able to interact with the machine's
> > consoles; moreover, the system machines randomly loses their
> connectivity.
> >
> > In your opinion, could I use an external gateway / router (such as
> > pfSense or something similar) to route the traffic between the POD and
> > the Guest networks? IS there any configuration that I'm missing?
> >
> > I rewrite my current situation:
> >
> > /I'm recently having issues about the ability to manage the system VMs
> > (Console Proxy + Secondary Storage VM); I've got the following
> > configuration:
> >
> > * Cloudstack 4.1
> > * VMware vSphere 5.1
> > * Standard networking configuration
> > * vSwitch0 on the public network (Guest network) - Phyisical network
> > connected to a WAN phyisical switch (public IP addresses - 46.x.x.x).
> > * vSwitch1 on the private network (Management + Storage traffic) -
> > Phyisical network connected to a LAN phyisical switch (Private IP
> > addresses - 192.168.x.x)./
> >
> >
> >
> > I look forward to reading from you.
> >
> > Kind regards,
> >
> > Gaspare
> >
> > On 31/07/2013 16:03, Hotmail wrote:
> >> It does indeed have the correct configuration value. I have a MySQL script
> that establishes a number of configuration settings on repeatable basis.
> >>
> >> Noel
> >>
> >> On 2013-07-30, at 13:59, Kelven Yang<kelven.y...@citrix.com>  wrote:
> >>
> >>> Could you check CS global configuration variable "host", make sure
> >>> it point to the IP that management server is listening at (on
> >>> Management network), if you have a management server cluster setup,
> >>> this IP should be the load-balancer IP for the management server
> >>> cluster
> >>>
> >>> Kelven
> >>>
> >>> On 7/29/13 10:14 PM, "Gaspare A Silvestri"<g.silves...@netsons.com>
> wrote:
> >>>
> >>>> Hello everybody,
> >>>>
> >>>> I'm recently having issues about the ability to manage the system
> >>>> VMs (Console Proxy + Secondary Storage VM); I've got the following
> >>>> configuration:
> >>>>
> >>>> * Cloudstack 4.1
> >>>> * VMware vSphere 5.1
> >>>> * Standard networking configuration
> >>>> * vSwitch0 on the public network (Guest network) - Phyisical
> >>>> network connected to a WAN phyisical switch (public IP addresses -
> 46.x.x.x).
> >>>> * vSwitch1 on the private network (Management + Storage traffic) -
> >>>> Phyisical network connected to a LAN phyisical switch (Private IP
> >>>> addresses - 192.168.x.x).
> >>>>
> >>>>
> >>>> I'm able to connect to the System VMs from the Cloudstack
> >>>> Management server using the private assigned IP, and I'm also able
> >>>> to ping them, but I'm not able to connect to the console of both
> >>>> two VMs; it looks like something wrong in my network configuration.
> >>>> Where am I wrong in my activities?
> >>>>
> >>>> Thanks in advance,
> >>>>
> >>>> Gaspare
> >
> >
> > -. Any views or opinions presented are solely those of the author and
> > do not necessarily represent those of the company.

Reply via email to