From owner-freebsd-xen@freebsd.org Tue Mar 1 12:15:57 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 AB427AB64C2 for ; Tue, 1 Mar 2016 12:15:57 +0000 (UTC) (envelope-from prvs=8619cf47e=roger.pau@citrix.com) Received: from SMTP02.CITRIX.COM (smtp02.citrix.com [66.165.176.63]) (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 574151759 for ; Tue, 1 Mar 2016 12:15:56 +0000 (UTC) (envelope-from prvs=8619cf47e=roger.pau@citrix.com) X-IronPort-AV: E=Sophos;i="5.22,523,1449532800"; d="scan'208";a="342173222" Subject: Re: Porting the block-iscsi hotplug script To: =?UTF-8?Q?Gustau_P=c3=a9rez?= , FreeBSD XEN References: <553DEB97.5000300@entel.upc.edu> <5540A053.4080409@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> From: =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= Message-ID: <56D587D8.6030702@citrix.com> Date: Tue, 1 Mar 2016 13:15:20 +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: <56D57110.2060406@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: Tue, 01 Mar 2016 12:15:57 -0000 El 1/3/16 a les 11:38, Gustau Pérez ha escrit: > > > El 29/02/16 a les 13:09, Roger Pau Monné ha escrit: >> As we spoke previously, HVM domains don't support hotplug scripts. Or >> are you trying to get them to work? (ie: you have performed other >> changes in order to enable this?) > > You're completely right about the HVM domain support for hotpluging. > The thing, when I first tried xen to see if it was stable, I did the > test with an HVM domain and xen complained about the block script not > being available. So I assumed that even the domain was an HVM, the > hotplug was being called. Yes, hotplug scripts are also being called for HVM domains, it's just that the disk command line passed to QEMU when using hotplug scripts is wrong and QEMU fails to starts, and the domain creation of course fails. >>> * I see the device has a type (phy, file, iscsi) in the definition of >>> the domain, but I'm not sure how to check its type in the block >>> script (I can check if the file is a block device or a regular file, >>> but what about iscsi?, check if the target param is set?) >> This is confusing, and refers to the backend that's used to handle the >> disk. In your case backend in always 'phy', which means blkback. The >> 'phy' backend is the only one that supports hotplug scripts. >> >> In the past, some prefixes (like iscsi) where shortcuts for block >> scripts, so the line: >> >> iscsi: >> >> Was equivalent to: >> >> script=block-iscsi,target= >> >> This is not recommended anymore, so just forget about the prefixes. > > Thank you for the explanation. I would said to me this may some some > love, but perhaps I'm wrong. We have deprecated the usage of all those prefixes, so I would just ignore them completely and only use the default syntax. >>> * Also. I have a domain defined with two disks. In the block script I >>> try to execute xenstore-ls and I'd expect to see two disks there, >>> but there's only the first one. I assume this is because the block >>> script is called for each disk in the domain definition >> Yes, the block script is called for each disk, the first argument (the >> xenstore backend path) is going to be different for each invocation. > > I'd assume this would lead to two different branches (or paths) in > the xenstore tree. Yes, if you have two different disks in your configuration file you will have two different paths in xenstore in order to describe them. >> >>> Finally, I ended having a disk defined in the xenstore >>> (/var/db/xenstore) which I can't remove. I removed xen-tools and removed >>> /var/db/xen{store} but it keeps complaining. I'd have expected that the >>> store was under /var/db/ but perhaps I'm missing something. >> Weird, you should be able to remove the disk entries in xenstore by >> using xenstore-rm . Rebooting the host will also >> completely clear the xenstore database. Can you paste the error message >> that you are seeing? >> > I tried deleting the xen-tools package and then deleting > /var/db/xen*. After that I rebooted (there was two xenstore processes, > I'd say one is the kernel side process and the other the user space > process, whose binary is installed by the xen-tools port). Finally I > installed the xen-tools. But the error remains. The error can be found > at [1]. Hm, this is weird. First things first, you should only have one xenstored process running in Dom0, so when doing a ps aux you should see: root 675 0.0 0.1 23100 2548 - I 12:21 0:00.69 /usr/local/sbin/xenstored --pid-file... But only one of those lines, if you have more than one, something is clearly wrong. Can you check if you maybe have duplicated init scripts in /etc/rc.d and /usr/local/etc/rc.d? Then, can you paste the output of `xenstore-ls -fp` before creating the domain that's giving you the error? If you can paste the config file of the domain that might also help tracking this down. Roger.