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