I agree, it was probably an afterthought. I was just justifying the desired effect not the flag/workaround.
On Thu, Oct 31, 2013 at 11:46 AM, Darren Shepherd < darren.s.sheph...@gmail.com> wrote: > I just find it annoying setting up a zone with local storage that I have > to turn this setting on. If I have no shared storage, then system VMs > won't deploy with out this parameter. It's just seems like a useless > setting that might have been added because there is something else in the > system that isn't working right. > > Darren > > > On Oct 31, 2013, at 10:52 AM, Kelcey Jamison Damage < > kel...@backbonetechnology.com> wrote: > > > > That's a good point. I know the system VMs are auto created if the > system is aware of their state being either 'Destroyed', 'Expunged'. If the > state is 'Starting', or 'Started'/'Running' then no actions are taken. > > > > In your scenario, the system VM would still be 'Started' in the database > even though communication is lost to the host, so no automatic action would > be taken. > > > > ----- Original Message ----- > > > > From: "Darren Shepherd" <darren.s.sheph...@gmail.com> > > To: dev@cloudstack.apache.org > > Sent: Thursday, October 31, 2013 10:47:41 AM > > Subject: why system.vm.use.local.storage? > > > > Why do we have the configuration system.vm.use.local.storage? Why would > > somebody care if they systemvm is on local storage? I'm guessing the idea > > here is if it's on local storage we can't bring it back in a host failure > > situation? But don't we just recreate the systemvm? > > > > Darren > > >