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

Re: [Xen-users] xenstore /vm/$uuid cleared on domU reboot - bug or feature

On Thu, 2014-04-24 at 14:20 +0200, Jacek Konieczny wrote:
> Hi,
> I need to provide some data to my domUs from dom0. I decided to use
> xenstore for that and I put my data under /vm/$uuid/ â I assumed that
> is a good place, as the domU can easily locate this data and it is said
> to 'not change even on migration'.
> The http://wiki.xen.org/wiki/XenStore_Reference states:

Sadly that page looks like it is sore need of cleaning up, the
distinction it tries to draw between /local and /vm was perhaps the
intention a decade ago when xenstore was invented but it never really
materialised in that form. I'm sorry about that.

> > The /vm path stores configuration information for a domain. This
> > information doesn't change and is indexed by the domain's UUID.
> Unfortunately, I found this not being true. The information does change,
> on a domU restart. The path is the same (provided I use static UUID in
> the xl cfg file), but all old contents is gone.
> Is that expected?

Yes. I think this is probably down to a silly syntactic quibble:

A "domain" in Xen is strictly speaking a one off entity which is
created, lives for a while, and is then destroyed, it is never restarted
and has no other lifecycle.

A "guest" in Xen is a (mostly conceptual, i.e. in the toolstack's brain)
thing which can be instantiated as a domain, and when that domain dies
the "guest" can be "rebooted" by the creation of a new "domain".

This distinction is mostly irrelevant to most end users but it crops up
in cases like this where you think about properties which span reboots
etc. It doesn't help that the terminology is also pretty sloppily used
in many places (including by myself most of the time).

Given that distinction "configuration information for a domain" takes on
a different meaning unfortunately and it would be expected for it to
disappear when the domain was destroyed.

> Should I use some other location in the xenstore for my data? What is
> are the 'best practices' here?

I don't think there are any locations in xenstore which are preserved
for the complete lifetime of a domain^Wguest.

What sort of information is it that you need to store? Is it dynamic or
is it constant?

> Using own 'root' namespace for my per-domU data would have some
> inconvenieces, like that I will need to remove it when the VM is
> _finally_ gone.

That's right.

It is quite likely that your need is going to have to be solved at the
toolstack i.e. "guest" layer, where that sort of lifecycle of create,
reboot, shutdown exists as a concept.


Xen-users mailing list



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