Can we not rely on secondary storage for config drive? I'd much rather see it generated dynamically into a temp space during VM start, or (less desirable) even during VM create on primary storage (perhaps in a configdrive) directory where the root disk resides. It just seems like a bad idea to rely on mounting and availability of secondary storage (which by design is supposed to be out of band from running VMs) to have a healthy VM. People put a lot of work into their primary storage for VM availability, not as much for secondary storage.
On Wed, Jul 12, 2017 at 5:01 PM ilya musayev (JIRA) <j...@apache.org> wrote: > > [ > https://issues.apache.org/jira/browse/CLOUDSTACK-9813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16084678#comment-16084678 > ] > > ilya musayev commented on CLOUDSTACK-9813: > ------------------------------------------ > > Hey [~KrisSterckx] [~waegemae] > > The idea of storing config drive on secondary store - is actually bad and > wont be approved by Information Security teams. > > Regards, > ilya > > > Use configdrive for userdata, metadata & password > > -------------------------------------------------- > > > > Key: CLOUDSTACK-9813 > > URL: > https://issues.apache.org/jira/browse/CLOUDSTACK-9813 > > Project: CloudStack > > Issue Type: New Feature > > Security Level: Public(Anyone can view this level - this is the > default.) > > Components: KVM, Network Controller, Secondary Storage, > SystemVM, VMware > > Affects Versions: Future > > Reporter: Eric Waegeman > > Assignee: Kris Sterckx > > > > To avoid the use of an extra VM for the virtual router we implement > configdrive for userdata, metadata & password. > > The configdrive ISO is created on the secondary store and the KVM & > VMware plugins are adapted to accept the configdrive ISO as second cdrom. > > Is applicable for isolated, VPC and shared networks. > > > > -- > This message was sent by Atlassian JIRA > (v6.4.14#64029) >