> >
> > > >
> > > >
> > > > On Fri, Jan 12, 2018 at 3:07 PM, Simon Weller
> > >
> > > > wrote:
> > > >
> > > > > They do not. They receive a link-local ip address that is used for
> > host
> > > > > a
; On Fri, Jan 12, 2018 at 3:07 PM, Simon Weller >
> > > 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 communicati
t; > agent. Host agent to VR communication is over SSH.
> > >
> > >
> > >
> > > From: Rafael Weingärtner
> > > Sent: Friday, January 12, 2018 1:42 PM
> > > To: dev
> > > Subject: Re: [DISCUSS] running
ied through the host
> > agent. Host agent to VR communication is over SSH.
> >
> >
> >
> > From: Rafael Weingärtner
> > Sent: Friday, January 12, 2018 1:42 PM
> > To: dev
> > Subject: Re: [DISCUSS] running sVM and VR a
t; 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 v
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
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
do
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,
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.
A
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
wrote:
> Hi,
>
> We need to start a architecture discussion about running SystemVM and
> Virtual-Router
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 Citr
11 matches
Mail list logo
