Hi, I''m looking for some definite info about when it''s allowed to restart the various Xen daemons (xend, xenstored and xenconsoled). Up to now I worked with the assumption that I can restart them while guest domains are running on the host and there''s no harm done. Indeed there wasn''t, until now, when on restart one of my domains became Domain-Unnamed (but kept on working), while the others disappeared and didn''t ping anymore... (I''ve got the domain info dump from xm dmesg and the xend logs if anybody can debug this. I''m using Xen 3.2.1.) -- Thanks, Feri. _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On Tue, Oct 21, 2008 at 11:50:28PM +0200, Ferenc Wagner wrote:> I''m looking for some definite info about when it''s allowed to restart > the various Xen daemons (xend, xenstored and xenconsoled).You cannot restart xenstored at all, it will break basic functionality. The other two can often be restarted but will cause issues sometimes. You can''t restart any qemu-dm processes. regards john _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On Tue, 2008-10-21 at 23:50 +0200, Ferenc Wagner wrote:> Hi, > > I''m looking for some definite info about when it''s allowed to restart > the various Xen daemons (xend, xenstored and xenconsoled). > > Up to now I worked with the assumption that I can restart them while > guest domains are running on the host and there''s no harm done. > Indeed there wasn''t, until now, when on restart one of my domains > became Domain-Unnamed (but kept on working), while the others > disappeared and didn''t ping anymore... > > (I''ve got the domain info dump from xm dmesg and the xend logs if > anybody can debug this. I''m using Xen 3.2.1.)One thing you never (ever) want to re-start is xenstored. Xend however can usually be re-started without issue. Think of xenstored as something like "/proc as a service". Xen itself does not care about the name of your guest, it only needs its ID, flags, etc. If you look in /usr/include/xen/domctl.h , in particular the type xc_domaininfo_t , you''ll see how much the userland tools rely on xenstore .. not just for storage, but watches. This keeps the bloat out of Xen itself and in userspace where it belongs. That''s one of the reasons why Xen is a well designed modern highly efficient microkernel. To make the store persistent, many small writes/reads to dom-0''s disk would be needed and would be a disaster. That''s why its all done in memory. Nevermind i/o wait and latency :) As far as I know, there is no way to export / import the contents of the store on a graceful re-start. Trying to do the same while handling a segmentation fault would be at (best) questionable. In all reality, I have seen xend crash, but never xenstored. The only practical reason for including stuff to dump and re-import its contents would be a graceful restart .. but why would you re-start it if its running fine? :) Cheers, --Tim _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Sorry for top posting, this comment in xenstore/xenstored_core.c is relevant: /* XXX When we make xenstored able to restart, this will have to become cleverer, checking for existing domains and not removing the corresponding entries, but for now xenstored cannot be restarted without losing all the registered watches, which breaks all the backend drivers anyway. We can therefore get away with just clearing /local and expecting Xend to put the appropriate entries back in. When this change is made it is important to note that dom0''s entries must be cleaned up on reboot _before_ this daemon starts, otherwise the backend drivers and dom0''s balloon driver will pick up stale entries. In the case of the balloon driver, this can be fatal. */ So, at least (for a while), the store is transient. I dug that up after double checking what --preserve-local did. In all reality, you''ll lose xend prior to losing xenstored. Sorry for not double checking before replying :) Cheers, --Tim On Wed, 2008-10-22 at 15:33 +0800, Tim Post wrote:> On Tue, 2008-10-21 at 23:50 +0200, Ferenc Wagner wrote: > > Hi, > > > > I''m looking for some definite info about when it''s allowed to restart > > the various Xen daemons (xend, xenstored and xenconsoled). > > > > Up to now I worked with the assumption that I can restart them while > > guest domains are running on the host and there''s no harm done. > > Indeed there wasn''t, until now, when on restart one of my domains > > became Domain-Unnamed (but kept on working), while the others > > disappeared and didn''t ping anymore... > > > > (I''ve got the domain info dump from xm dmesg and the xend logs if > > anybody can debug this. I''m using Xen 3.2.1.) > > One thing you never (ever) want to re-start is xenstored. Xend however > can usually be re-started without issue. > > Think of xenstored as something like "/proc as a service". Xen itself > does not care about the name of your guest, it only needs its ID, flags, > etc. If you look in /usr/include/xen/domctl.h , in particular the type > xc_domaininfo_t , you''ll see how much the userland tools rely on > xenstore .. not just for storage, but watches. This keeps the bloat out > of Xen itself and in userspace where it belongs. That''s one of the > reasons why Xen is a well designed modern highly efficient microkernel. > > To make the store persistent, many small writes/reads to dom-0''s disk > would be needed and would be a disaster. That''s why its all done in > memory. Nevermind i/o wait and latency :) As far as I know, there is no > way to export / import the contents of the store on a graceful re-start. > Trying to do the same while handling a segmentation fault would be at > (best) questionable. > > In all reality, I have seen xend crash, but never xenstored. The only > practical reason for including stuff to dump and re-import its contents > would be a graceful restart .. but why would you re-start it if its > running fine? :) > > Cheers, > --Tim > > > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xensource.com > http://lists.xensource.com/xen-users_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
John Levon <levon@movementarian.org> writes:> On Tue, Oct 21, 2008 at 11:50:28PM +0200, Ferenc Wagner wrote: > >> I''m looking for some definite info about when it''s allowed to restart >> the various Xen daemons (xend, xenstored and xenconsoled). > > You cannot restart xenstored at all, it will break basic functionality. > The other two can often be restarted but will cause issues sometimes. > > You can''t restart any qemu-dm processes.Tim Post <echo@echoreply.us> writes:> On Tue, 2008-10-21 at 23:50 +0200, Ferenc Wagner wrote: > >> I''m looking for some definite info about when it''s allowed to restart >> the various Xen daemons (xend, xenstored and xenconsoled). >> >> Up to now I worked with the assumption that I can restart them while >> guest domains are running on the host and there''s no harm done. >> Indeed there wasn''t, until now, when on restart one of my domains >> became Domain-Unnamed (but kept on working), while the others >> disappeared and didn''t ping anymore... >> >> (I''ve got the domain info dump from xm dmesg and the xend logs if >> anybody can debug this. I''m using Xen 3.2.1.) > > One thing you never (ever) want to re-start is xenstored. Xend however > can usually be re-started without issue.Thanks both of you for the quick and detailed answers!> In all reality, I have seen xend crash, but never xenstored. The only > practical reason for including stuff to dump and re-import its contents > would be a graceful restart .. but why would you re-start it if its > running fine? :)Because I upgraded it or a library used by it. :) -- Cheers, Feri. _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On Wed, Oct 22, 2008 at 9:52 AM, Tim Post <echo@echoreply.us> wrote:> Sorry for top posting, this comment in xenstore/xenstored_core.c is > relevant: > > /* XXX When we make xenstored able to restart, this will have > to become cleverer, checking for existing domains and not > removing the corresponding entries, but for now xenstored > cannot be restarted without losing all the registered > watches, which breaks all the backend drivers anyway. We > can therefore get away with just clearing /local and > expecting Xend to put the appropriate entries back in. > > When this change is made it is important to note that > dom0''s entries must be cleaned up on reboot _before_ this > daemon starts, otherwise the backend drivers and dom0''s > balloon driver will pick up stale entries. In the case of > the balloon driver, this can be fatal. > */ > > So, at least (for a while), the store is transient. I dug that up after > double checking what --preserve-local did. In all reality, you''ll lose > xend prior to losing xenstored. >Hi all, sorry for replaying to an old thread, but actually I see xenstored exiting from time to time while xend (fortunately) keep running. The result is that: - VM keep running - I loose every control on them from dom0, i.e. ''xm <commands>'' do not work I cannot migrate them to another host I''ve in cluster. In similar cases -- when xenstored crashes/exits, xend keep running -- do you know if there is a method to restart xenstored ? I would need a way to regain control of the VMs to at least migrate them ... Regards,> > Sorry for not double checking before replying :) > > Cheers, > --Tim > > On Wed, 2008-10-22 at 15:33 +0800, Tim Post wrote: > > On Tue, 2008-10-21 at 23:50 +0200, Ferenc Wagner wrote: > > > Hi, > > > > > > I''m looking for some definite info about when it''s allowed to restart > > > the various Xen daemons (xend, xenstored and xenconsoled). > > > > > > Up to now I worked with the assumption that I can restart them while > > > guest domains are running on the host and there''s no harm done. > > > Indeed there wasn''t, until now, when on restart one of my domains > > > became Domain-Unnamed (but kept on working), while the others > > > disappeared and didn''t ping anymore... > > > > > > (I''ve got the domain info dump from xm dmesg and the xend logs if > > > anybody can debug this. I''m using Xen 3.2.1.) > > > > One thing you never (ever) want to re-start is xenstored. Xend however > > can usually be re-started without issue. > > > > Think of xenstored as something like "/proc as a service". Xen itself > > does not care about the name of your guest, it only needs its ID, flags, > > etc. If you look in /usr/include/xen/domctl.h , in particular the type > > xc_domaininfo_t , you''ll see how much the userland tools rely on > > xenstore .. not just for storage, but watches. This keeps the bloat out > > of Xen itself and in userspace where it belongs. That''s one of the > > reasons why Xen is a well designed modern highly efficient microkernel. > > > > To make the store persistent, many small writes/reads to dom-0''s disk > > would be needed and would be a disaster. That''s why its all done in > > memory. Nevermind i/o wait and latency :) As far as I know, there is no > > way to export / import the contents of the store on a graceful re-start. > > Trying to do the same while handling a segmentation fault would be at > > (best) questionable. > > > > In all reality, I have seen xend crash, but never xenstored. The only > > practical reason for including stuff to dump and re-import its contents > > would be a graceful restart .. but why would you re-start it if its > > running fine? :) > > > > Cheers, > > --Tim > > > > > > > > _______________________________________________ > > Xen-users mailing list > > Xen-users@lists.xensource.com > > http://lists.xensource.com/xen-users > > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xensource.com > http://lists.xensource.com/xen-users >_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users