cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pierre-Luc Dion <pd...@cloudops.com>
Subject Re: [DISCUSS] running sVM and VR as HVM on XenServer
Date Fri, 12 Jan 2018 21:56:00 GMT
After some verification with Syed and Khosrow,

We found that we can use xenstore-read / xenstore-write to send data from
dom0 to domU which are in our case  VRs or SVMs. Any reason not using this
approach ?  that way we would not need a architectural change for XenServer
pods, and this would support HVM and PV virtual-router. more test required,
for sure, VR would need to have xentools pre-installed.


*Pierre-Luc DION*
Architecte de Solution Cloud | Cloud Solutions Architect
t 855.652.5683

*CloudOps* Votre partenaire infonuagique* | *Cloud Solutions Experts
420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6
w cloudops.com *|* tw @CloudOps_

On Fri, Jan 12, 2018 at 4:07 PM, Syed Ahmed <sahmed@cloudops.com> wrote:

> KVM uses a VirtIO channel to send information about the IP address and
> other params to the SystemVMs. We could use a similar strategy in XenServer
> using XenStore. This would involve minimal changes to the code while
> keeping backward compatibility.
>
>
>
> On Fri, Jan 12, 2018 at 3:07 PM, Simon Weller <sweller@ena.com.invalid>
> wrote:
>
> > They do not. They receive a link-local ip address that is used for host
> > agent to VR communication. All VR commands are proxied through the host
> > agent. Host agent to VR communication is over SSH.
> >
> >
> > ________________________________
> > From: Rafael Weingärtner <rafaelweingartner@gmail.com>
> > Sent: Friday, January 12, 2018 1:42 PM
> > To: dev
> > Subject: Re: [DISCUSS] running sVM and VR as HVM on XenServer
> >
> > but we are already using this design in vmware deployments (not sure
> about
> > KVM). The management network is already an isolated network only used by
> > system vms and ACS. Unless we are attacked by some internal agent, we are
> > safe from customer attack through management networks. Also, we can (if
> we
> > don't do yet) restrict access only via these management interfaces in
> > system VMs(VRs, SSVM, console proxy and others to come).
> >
> >
> >
> > Can someone confirm if VRs receive management IPs in KVM deployments?
> >
> > On Fri, Jan 12, 2018 at 5:36 PM, Syed Ahmed <sahmed@cloudops.com> wrote:
> >
> > > The reason why we used link local in the first place was to isolate the
> > VR
> > > from directly accessing the management network. This provides another
> > layer
> > > of security in case of a VR exploit. This will also have a side effect
> of
> > > making all VRs visible to each other. Are we okay accepting this?
> > >
> > > Thanks,
> > > -Syed
> > >
> > > On Fri, Jan 12, 2018 at 11:37 AM, Tim Mackey <tmackey@gmail.com>
> wrote:
> > >
> > > > 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
> > > > >
> > > >
> > >
> >
> >
> >
> > --
> > Rafael Weingärtner
> >
>

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