From owner-freebsd-xen@freebsd.org Wed Mar 2 09:46:58 2016 Return-Path: Delivered-To: freebsd-xen@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 727F9AC1EC8 for ; Wed, 2 Mar 2016 09:46:58 +0000 (UTC) (envelope-from prvs=8628b2c55=roger.pau@citrix.com) Received: from SMTP.CITRIX.COM (smtp.citrix.com [66.165.176.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.citrix.com", Issuer "Verizon Public SureServer CA G14-SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 361BC15FF for ; Wed, 2 Mar 2016 09:46:57 +0000 (UTC) (envelope-from prvs=8628b2c55=roger.pau@citrix.com) X-IronPort-AV: E=Sophos;i="5.22,528,1449532800"; d="scan'208";a="335866652" Subject: Re: Porting the block-iscsi hotplug script To: =?UTF-8?Q?Gustau_P=c3=a9rez?= , FreeBSD XEN References: <553DEB97.5000300@entel.upc.edu> <5540F3FC.80606@citrix.com> <5541FC8A.8080009@citrix.com> <5542365D.10403@entel.upc.edu> <55423ECD.6000404@citrix.com> <5556F21D.2050005@entel.upc.edu> <555EEFBA.5080902@citrix.com> <555EF542.3090002@citrix.com> <555F9B3F.1000600@entel.upc.edu> <55602512.1090702@citrix.com> <56C6FA2F.8040900@gmail.com> <56CAC8CB.8030107@gmail.com> <56CADEDA.4050007@citrix.com> <56CB0057.1060509@gmail.com> <56CB041E.1020009@citrix.com> <56CB2D90.5080809@gmail.com> <56CB34BA.6060809@citrix.com> <56CC24BD.6050609@gmail.com> <56CC32E5.5010101@citrix.com> <56CC7637.3080408@gmail.com> <56CF5668.6090605@citrix.com> <56D0091F.80408@gmail.com> <56D02863.7040100@citrix.com> <56D03D95.9090509@gmail.com> <56D04E5F.8070901@citrix.com> <56D42A28.8050701@gmail.com> <56D434FC.8030905@citrix.com> <56D57110.2060406@gmail.com> <56D587D8.6030702@citrix.com> <56D590EA.609@gmail.com> <56D591BA.4020303@gmail.com> <56D5929F.7040001@citrix.com> <56D5C722.3080205@gmail.com> From: =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Message-ID: <56D6B68D.8080809@citrix.com> Date: Wed, 2 Mar 2016 10:46:53 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <56D5C722.3080205@gmail.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-DLP: MIA1 X-BeenThere: freebsd-xen@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion of the freebsd port to xen - implementation and usage List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2016 09:46:58 -0000 El 1/3/16 a les 17:45, Gustau Pérez ha escrit: > > > El 1/03/16 a les 14:01, Roger Pau Monné ha escrit: >> now it's too messy to understand. Also, make sure your hotplug script >> writes the "physical-device" node, or else blkback is not going to >> attach the disk. > > Hello Roger, > > I tried a PV domain and I can see the physical device in the xenstore > even if the block script does nothing. I wouldn't expect that. Am I > missing anything? There's a little shortcut in libxl to deal with disks that are using the default hotplug script, see: http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=tools/libxl/libxl.c;h=4cdc1690c4d5e5d5b66c896e4c11e813be92b468;hb=HEAD#l2451 libxl does the hotplug script job and already writes the xenstore "physical-device" node on behalf of the hotplug script. This is done to speed up domain creation. You can disable this shortcut by spelling out the hotplug script on each disks configuration line. Using the configuration file you posted in [2] as an example, you will need to change your disk configuration lines so they look like: disk = [ 'vdev=xvda,access=rw,script=block,target=/dev/zvol/dades/debian', 'vdev=xvdb,access=rw,script=block,target=/dev/zvol/dades/debian_1', ] This will prevent libxl from writing the "physical-device" node. > On the other hand, if I attach two disks[2], the xenstored again > complains about one of the disks already declared in the xenstore. > However the store seem to be fine [3]. If I remove that disk from the > definition the domain boots just fine. According to [2], you are assigning the same vdev to both disks (xvda). This is not possible, you should change the second disk definition to: 'phy:/dev/zvol/dades/debian_1,xvdb,rw' Or any other xvd* value that's not xvda. > Finally, out of curiosity, I'd like to ask, do you know why there > are two /local/domain/ branches for a single domain? When I create a > domain I can see there's a /local/domain/0/../../X/ and > /local/domain/X/ (which X seems to be the number of domains executed in > the box). I see the domain information splitted in those two branches. I > understand the X makes it easy to join the information in both branches > and allows the system to identify the domain. Is it to easily list all > the domains and the most important information of them easily without > walking the whole tree? Yes, the hierarchy under /local/domain/X/ is what the guest has write access to, we call this the "frontend". This contains all the information shared by the guest in order to stablish a connection with the backend (that usually runs in Dom0). The other entries inside of /local/domain/0/backend/... are used by the toolstack and the backends (blkback, netback,...) in order to setup the backend. hotplug scripts should only require access to the backend xenstore entries (those under /local/domain/0/backend/...) in order to setup blkback. This article by David Chisnall contains a good high-level description of the architecture if you want to know more: http://www.informit.com/articles/article.aspx?p=1160234 Roger.