Date: Tue, 1 Mar 2016 13:15:20 +0100 From: =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= <roger.pau@citrix.com> To: =?UTF-8?Q?Gustau_P=c3=a9rez?= <gustau.perez@gmail.com>, FreeBSD XEN <freebsd-xen@freebsd.org> Subject: Re: Porting the block-iscsi hotplug script Message-ID: <56D587D8.6030702@citrix.com> In-Reply-To: <56D57110.2060406@gmail.com> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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:<iscsi params>
>>
>> Was equivalent to:
>>
>> script=block-iscsi,target=<iscsi params>
>>
>> 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 <xenstore-path>. 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?56D587D8.6030702>