Hi Martin, thank you. Definitely I want to propose patch to libvirt-guests, but this weekend I am taking family holiday, so be patient and wait little bit more.
Regards, Marek On Wed, Sep 23, 2015 at 3:12 PM, Martin Kletzander <mklet...@redhat.com> wrote: > On Wed, Sep 23, 2015 at 11:39:29AM +0200, Marek Lukács wrote: > >> Hi Martin, >> >> thank you for your reply. Please check my comments. >> >> On Wed, Sep 23, 2015 at 10:50 AM, Martin Kletzander <mklet...@redhat.com> >> wrote: >> >> On Tue, Sep 22, 2015 at 07:33:30AM +0200, Marek Lukács wrote: >>> >>> Hi, >>>> >>>> It will be nice feature to have configuration option >>>> ALWAYS_START="$uri:$name $uri:name ..." in libvirt-guests >>>> configuration file. >>>> >>>> If ON_BOOT is "start" and if ALWAYS_START is not empty, it iterates >>>> over the ALWAYS_START and starts guests with same conditions (delays >>>> etc.) before it starts guests from LISTFILE. >>>> >>>> >>>> To be honest, I don't think that's _exactly_ what you want _just_ from >>> libvirt itself; let me explain. >>> >>> Benefits: >>> >>>> - guests are started with delays >>>> >>>> >>> Delays that are done due to the guests are not something we should >>> handle. Guests and mainly the applications inside them should handle >>> this gracefully. Just delaying the starts is still error-prone. >>> >>> >> I fully understand this and fully agree with you. Production application >> has to handle this gracefully. But still I see a space for doing it in >> environments where it is not so necessary to configure application so >> gracefully, like development or testing environments. Delays are fine for >> many not production environments, where applications are not in production >> state. >> >> >> - guests are started after host failure >>> >>>> >>>> >>> That's what libvirt-guests does already. And if you want some domains >>> to be started on every start, there's the 'autostart' parameter for >>> domains. >>> >>> >> No, libvirt-guests only starts those domains which has been running before >> "service" libvirt-guests has been stopped. In case of host failure, there >> is no LISTFILE in filesystem, as it has not been generated by >> libvirt-guests stop mechanism. >> >> > Oh, so here is what I have misunderstood. Well, just misread, of > course libvirt-guests doesn't handle host failures. > > But probably I do not understand "script" libvirt-guests correctly and why >> it is in libvirt. I will be happy, if you will give me more details, why >> there is this script, even if libvirt has 'autostart' parameter for >> domains. >> >> - For what usage is libvirt-guests designed? >> > > My interpretation is that it is there in order for you to be able to > shutdown and boot later without losing the machines you were running. > > Autostart says that particular domain should be started every time the > daemon is started. Basically says that particular guest should be > running on the host all the time. > > - Why it supports delays? >> > > Because most of the time you'll want to resume from managed save and > you might cause a big load in case you're starting bunch of machines > because all of those will start loading everything from disk and so > on. > > - Why to have libvirt-guests if there is 'autostart' domain parameter? >> > > It does two different things. Domain with autostart will be started > every time daemon (actually not even the computer) is started, but > libvirt-guests will stop/save domains that are running when the > computer is being shut down and start/resume them when it is starting > back. > > - For who is libvirt-guests and who should use 'autostart' domain >> parameter? >> >> > Well, libvirt-guests was added by a guy who was too lazy to clean up > his machine before rebooting (sorry Jirka, I had to). But you get the > picture. Use it for whatever you like and whatever suits you. I'm > not even against adding what you suggested, I just wanted to make sure > you're not relying on the script for something critical as my > understanding of it that it is not very error prone. > > > >> - guests are started in specific order (for example complex >>> >>>> environment, when DB should be started before other guest, etc.) >>>> >>>> >>>> Again, same as the first point. This should be handled gracefully in >>> the application itself or at least worked around in the guest (not >>> starting DB-related app before DB is accessible). >>> >>> Anyway, if you *really* want this, then the easiest thing to do is >>> creating a service that starts before libvirt-guests, but after >>> libvirt, which is just something similar to "local", so it just runs a >>> script that does: >>> >>> for i in domain_one some_other_domain database_dom >>> do >>> virsh start "$i" >>> sleep 60 # or you can try connecting to make sure it started >>> done >>> >>> or something similar. However, you might still propose a simple patch >>> for the feature you described. >>> >>> >> For me it is no problem to design my own script to handle my needs. I have >> spent some time googling, if there is already a tool for it. I found only >> similar questions, so I got feeling, that I am not the only one with >> similar requirements. >> >> Script libvirt-guests in my eyes handles very similar task. It starts >> domains with delays, it starts domains what has been running at previous >> stop, but do not handle situation in case of host failure and do not >> starts >> domain in specific order. I prefer and I think, that it is better to not >> create new script no one knows about, but to modify existing one everybody >> knows about. But again, maybe I do not understand why and for what >> libvirt-guests is. >> >> > Well, there is no reference purpose and as I said I'm not even against > adding your option there. And if we get it into libvirt-guests, > others might use it. Would you mind proposing it as a patch? It > could be pretty straightforward, I guess. > > Have a nice day, > Martin > > > Anyway, much easier in case of testing and development environments is to >> set start sequence in /etc/rc.local and forget about script like >> libvirt-guests, if it does not have features I described. >> >> >> Regards, >>> >>>> >>>> Marek Lukács >>>> >>>> -- >>>> libvir-list mailing list >>>> libvir-list@redhat.com >>>> https://www.redhat.com/mailman/listinfo/libvir-list >>>> >>>> >>>
-- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list