It looks reasonable to manage VRs via management IP network. We should focus on using the same work flow for different deployment scenarios.
On Fri, Jan 12, 2018 at 12:13 PM, Pierre-Luc Dion <pd...@cloudops.com> wrote: > Hi, > > We need to start a architecture discussion about running SystemVM and > Virtual-Router as HVM instances in XenServer. With recent Meltdown-Spectre, > one of the mitigation step is currently to run VMs as HVM on XenServer to > self contain a user space attack from a guest OS. > > Recent hotfix from Citrix XenServer (XS71ECU1009) enforce VMs to start has > HVM. This is currently problematic for Virtual Routers and SystemVM because > CloudStack use PV "OS boot Options" to preconfigure the VR eth0: > cloud_link_local. While using HVM the "OS boot Options" is not accessible > to the VM so the VR fail to be properly configured. > > I currently see 2 potential approaches for this: > 1. Run a dhcpserver in dom0 managed by cloudstack so VR eth0 would receive > is network configuration at boot. > 2. Change the current way of managing VR, SVMs on XenServer, potentiall do > same has with VMware: use pod management networks and assign a POD IP to > each VR. > > I don't know how it's implemented in KVM, maybe cloning KVM approach would > work too, could someone explain how it work on this thread? > > I'd a bit fan of a potential #2 aproach because it could facilitate VR > monitoring and logging, although a migration path for an existing cloud > could be complex. > > Cheers, > > > Pierre-Luc > -- Rafael Weingärtner
