[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] libxl refactoring, call for discussion



On Wed, 2016-01-27 at 18:20 +0200, Pavlo Suikov wrote:
> Hi Ian,

Please don't top post and please use plain text emails, not html.

> I'll try to make clear domain restart thing first. Currently there are
> only device entries in domain config for frontends with backend paths in
> them, e.g.:
> 
> FrontendDomain.cfg:
> vdevice = [ 'backend=BackendDomain,devid=0,device=/dev/device' ]
> 
> it is parsed only on frontend domain start, and libxl creates both
> frontend and backend xenstore branches from that entry. Problem is, on
> backend domain restart libxl does not re-read this config,

libxl _never_ reads this config. This is an xl configuration file. xl is
one user of libxl, but not the only one (libvirt is another for example).
It is important to keep the distinction in mind when discussing these APIs.

libxl gets libxl_device_disk structs from xl.

>  because it belongs to the frontend domain which is clearly not
> restarted, and as a consequence xenstore backend branches are cleared (on
> backend shutdown) but not filled again, because backend domain does not
> have any entries for this device.

The information regarding which backends a domain has is present in
xenstore (in /local/domain/<domid>/backends) and libxl could make use of
that information when restarting a domain, including following the trail to
the frontend configuration.

If needed libxl could also make a note in a backend domain location when
starting a frontend of anything which it might need in order to restart
that backend. Likewise if anything which libxl needs in order to restart a
backend is missing it should just be added.

I think most of the problem here is just that libxl is not making use of
the information which it already has available when rebooting a domain
which has backends attached.

> What I propose is to add information needed to fill xenstore backend
> branches to backend domains and remove it from frontend domains, so it
> would possibly look like this:
> 
> FrontendDomain.cfg:
> frontend:vdevice = [ 'backend=BackendDomain,devid=0' ]
> 
> BackendDomain.cfg:
> backend:vdevice = ['frontend=FrontendDomain,devid=0,device=/dev/device']

Leaving aside that this proposal is xl specific and not addressing the more
important libxl APIÂIÂdon't think that having to predeclare the set of
backends when starting the backend domain is going to be feasible in the
general case (where domains are created dynamically and in an adhoc way by
users without the foresight afforded to embedded situations).

In any case as described above I think you are solving an issue which
doesn't actually exist.

[...]
> Motivation for this example is the following: if we have, e.g., PV GPU
> which is used in user domain and we have restrictions on graphics
> availability, we can monitor if main device backend hanged and make a
> runtime switch to a fallback device (software rendering) till main
> backend would be restated. Connections are static, they generally do not
> change and do not actually belong to any user domain, so there is no need
> clearing and refilling them on every domain restart.

I think you need to think about this in terms of the underlying libxl APIs
(i.e. libxl_device_<foo>_reconnect() or something) before thinking about
what the xl cfg file format and commands might be like.

> There still is an issue with hoplug devices being non-persistent (xl
> vdevice-attach fills both frontend and backend branches, but restart of
> any of user domains looses this information).

Not since 4.5 (or maybe 4.6), libxl now records such dynamic changes and
they are preserved on reboot (or should be, if not then there is a bug
somewhere).

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.