From dev-return-110584-archive-asf-public=cust-asf.ponee.io@cloudstack.apache.org Fri Jan 12 22:56:08 2018 Return-Path: X-Original-To: archive-asf-public@eu.ponee.io Delivered-To: archive-asf-public@eu.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by mx-eu-01.ponee.io (Postfix) with ESMTP id 296F4180621 for ; Fri, 12 Jan 2018 22:56:08 +0100 (CET) Received: by cust-asf.ponee.io (Postfix) id 19991160C33; Fri, 12 Jan 2018 21:56:08 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id 38486160C20 for ; Fri, 12 Jan 2018 22:56:07 +0100 (CET) Received: (qmail 23497 invoked by uid 500); 12 Jan 2018 21:56:06 -0000 Mailing-List: contact dev-help@cloudstack.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@cloudstack.apache.org Delivered-To: mailing list dev@cloudstack.apache.org Received: (qmail 23484 invoked by uid 99); 12 Jan 2018 21:56:05 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd1-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 12 Jan 2018 21:56:05 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd1-us-west.apache.org (ASF Mail Server at spamd1-us-west.apache.org) with ESMTP id 4EFA4C09A5 for ; Fri, 12 Jan 2018 21:56:05 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd1-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 1.879 X-Spam-Level: * X-Spam-Status: No, score=1.879 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=2, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=disabled Authentication-Results: spamd1-us-west.apache.org (amavisd-new); dkim=pass (1024-bit key) header.d=cloudops.com Received: from mx1-lw-us.apache.org ([10.40.0.8]) by localhost (spamd1-us-west.apache.org [10.40.0.7]) (amavisd-new, port 10024) with ESMTP id G96X0j3hwF6T for ; Fri, 12 Jan 2018 21:56:03 +0000 (UTC) Received: from mail-oi0-f41.google.com (mail-oi0-f41.google.com [209.85.218.41]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with ESMTPS id 5D2A95F6CD for ; Fri, 12 Jan 2018 21:56:02 +0000 (UTC) Received: by mail-oi0-f41.google.com with SMTP id y141so4887571oia.0 for ; Fri, 12 Jan 2018 13:56:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudops.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=sbTCh0RjbAvgptcnGeSABdTFHVs+gpFb3IQf0Jgy1OI=; b=KdELRdcWM6+Uxiy1nQciAUnl+/1KNUAsxbMbsmdx7aml9+CEK+R4dS9v5P19jz/Nej dHD8gVn3g8cOUkQcww1B8Spx6VC0tLR7ygAC2eHpWIel3XXpUVLjcAB4K+AK10HiEUny DH54uMlZaLW2pQ7rzF7O3DtPLQtSPR4EJ0VoU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=sbTCh0RjbAvgptcnGeSABdTFHVs+gpFb3IQf0Jgy1OI=; b=HgwwtzAnoXuFYVpG+XiALKg+7Mi/JozxAaBP6S3zjgIlnGDEkFJ03rKR7gpHW3k5NN 7sRwHxsp+OFuTY3hHsS4bxsLFpufzIuLAtR43/jdwGzf89Zlxqr+8Ar1Hd9ratz3YRK9 svFc2Hu32p1+AGv4hiVjb9jVvTmCeRcFXBAxKa4XlaWFmISahbBfJ9y7retrX3TGhMM6 fYP4Mq7QUMxLEwJA9PbeSBj8GTeE82ExLI7/RJ+lUSbxicrj3pK9ckkwWXkra0mQZ4mC yBgu1TdbECGcv/yevD0iINCBIbkUYysQqaXcooeD3L0n0H9ya9F7FEnjO0KGZmaaBljw DmVQ== X-Gm-Message-State: AKGB3mJN/u3vxrI7H1L26XG/aceJ9Q6h0JPwEKcgBOJsJpzpFxbK0Ywg SYfYO6v98KOtd7XwcXjMhkjBUd5kjFWFiVahImSHFCGd X-Google-Smtp-Source: ACJfBovO0AJjHFJe/yoMRVR7PVSsEadnpwaRQI5X7L3zXCNThkyMhwEgz8lQx9keqtyTMYyFi2383CGUVWnQhWlMT/g= X-Received: by 10.202.239.86 with SMTP id n83mr14552591oih.350.1515794161206; Fri, 12 Jan 2018 13:56:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.74.202.150 with HTTP; Fri, 12 Jan 2018 13:56:00 -0800 (PST) In-Reply-To: References: From: Pierre-Luc Dion Date: Fri, 12 Jan 2018 16:56:00 -0500 Message-ID: Subject: Re: [DISCUSS] running sVM and VR as HVM on XenServer To: dev Content-Type: multipart/alternative; boundary="94eb2c096f24881f1b05629b54eb" --94eb2c096f24881f1b05629b54eb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 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 XenServ= er > 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 > 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=C3=A4rtner > > 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 b= y > > system vms and ACS. Unless we are attacked by some internal agent, we a= re > > 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 wrote= : > > > > > The reason why we used link local in the first place was to isolate t= he > > 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 effec= t > 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 > wrote: > > > > > > > dom0 already has a DHCP server listening for requests on internal > > > > management networks. I'd be wary trying to manage it from an extern= al > > > > service like cloudstack lest it get reset upon XenServer patch. Thi= s > > > 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=C3=A4rtner < > > > > 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 System= VM > > 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 t= o > > > 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 existi= ng > > > cloud > > > > > > could be complex. > > > > > > > > > > > > Cheers, > > > > > > > > > > > > > > > > > > Pierre-Luc > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > Rafael Weing=C3=A4rtner > > > > > > > > > > > > > > > > > > > > -- > > Rafael Weing=C3=A4rtner > > > --94eb2c096f24881f1b05629b54eb--