There isn't anything I can think of wrt reliability. If the usage is limited to VR boot, then I don't see anything on the surface to limit performance.
In other words, xenstore as a solution seems a reasonable approach. -tim On Mon, Jan 15, 2018 at 8:26 PM, Pierre-Luc Dion <pd...@cloudops.com> wrote: > Hi Tim, > > As long as it work, since it's only used to for the initial instruction set > at the VR boot so eth0 can be configure, I think xenstore would work just > fine. > unless you are saying we could just not rely on xenstore in terms of > reliability? > > > *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 7:34 PM, Tim Mackey <tmac...@gmail.com> wrote: > > > > 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 ? > > > > xenstore has had some issues in the past. The most notable of which were > > limitations on the number of event channels in use, followed by overall > > performance impact. iirc, the event channel stuff was fully resolved with > > XenServer 6.5, but they do speak to a need to test if there are any > changes > > to the maximum number of VMs which can be reliably supported. It also > > limits legacy support (in case that matters). > > > > Architecturally I think this is a reasonable approach to the problem. One > > other thing to note is that xapi replicates xenstore information to all > > members of a pool. That might impact RVRs. > > > > -tim > > > > [1] "xenstore is not a high-performance facility and should beused only > for > > small amounts of control plane data." > > https://xenbits.xen.org/docs/4.6-testing/misc/xenstore.txt > > > > On Fri, Jan 12, 2018 at 4:56 PM, Pierre-Luc Dion <pd...@cloudops.com> > > wrote: > > > > > 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 <sah...@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 > <swel...@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 <rafaelweingart...@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 <sah...@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 <tmac...@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 < > > > > > > > rafaelweingart...@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 < > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > Rafael Weingärtner > > > > > > > > > > > > > > >
