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.

_______________________________________________
freebsd-xen@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-xen
To unsubscribe, send any mail to "freebsd-xen-unsubscr...@freebsd.org"

Reply via email to