cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Mackey <tmac...@gmail.com>
Subject Re: [DISCUSS] running sVM and VR as HVM on XenServer
Date Fri, 12 Jan 2018 16:37:34 GMT
dom0 already has a DHCP server listening for requests on internal
management networks. I'd be wary trying to manage it from an external
service like cloudstack lest it get reset upon XenServer patch. This alone
makes me favor option #2. I also think option #2 simplifies network design
for users.

Agreed on making this as consistent across flows as possible.



On Fri, Jan 12, 2018 at 9:44 AM, Rafael Weingärtner <
rafaelweingartner@gmail.com> wrote:

> 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 <pdion@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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message