> > Also I have tested earlier 3.0.2 and if you create multiple networks for the > same > account then the VM automatically gets that many IPs and NICs as many > network the VM has. > Then you can use static nat if you need to support multiple websites.
In this scenario where do you terminate the SSL? Could you support more than the max number of NICs per VM(typically 7 or so)? > > Or another solution to this is to have many static nat IPs on the same network > and port forward each IPs port 80 and 443 onto a different port on the VM and > configure apache to listen on different ports for different virtual hosts. > There is always a workaround. I agree this could be a workaround if the software supports SSL on non-standard ports. Some people use Plesk or Cpanel for the host management though and I didn't think these tools could handle this complexity. Anyway as you say it's a workaround -- we could do better with a cleaner solution. -kevin > > Regards > > Tamas Monos DDI > +44(0)2034687012 > Chief Technical Office > +44(0)2034687000 > Veber: The Hosting Specialists Fax +44(0)871 522 7057 > http://www.veber.co.uk > > Follow us on Twitter: www.twitter.com/veberhost Follow us on Facebook: > www.facebook.com/veberhost > > -----Original Message----- > From: Kevin Kluge [mailto:kevin.kl...@citrix.com] > Sent: 26 November 2012 19:03 > To: cloudstack-users@incubator.apache.org > Subject: RE: Multiple IP's to one instance > > > > > I am conflicted on this - I know the limitations with adding additional > interfaces. > > I'd almost argue for requiring number of interfaces/IPs to be set at > > machine instantiation and still handing out addresses to all > > interfaces via DHCP, but not all OSes will handle that cleanly. > > As you probably know CS hands out IPs via DHCP to multiple NICs today, and it > is > challenging to work reliably since different guest OS's have different > behavior > with respect to setting/re-setting the default route in DHCP replies. Today > CloudStack has some knowledge of guest OS to make this work but we've seen > bugs with that where the list of guest OS behavior is not right. Those are > fixable. > But there are other cases (e.g. boot from ISO, a user changes the DHCP client > post-create, or the user upgrades the OS which changes the DHCP client) where > I > don't think there is a reasonable fix. So I think we need at a minimum an > option > to disable DHCP reply on NICs that are not the default route. We should even > consider a behavior change to make that the only option. > > -kevin > >
