Re: [vdsm] migration progress feature
On Thu, Jul 18, 2013 at 05:29:14AM +0300, Itamar Heim wrote: On 07/18/2013 01:24 AM, Doron Fediuck wrote: - Original Message - | From: Michal Skrivanek mskri...@redhat.com | To: Peter V. Saveliev p...@redhat.com, vdsm-devel@lists.fedorahosted.org Development | vdsm-devel@lists.fedorahosted.org | Sent: Monday, July 8, 2013 5:13:42 PM | Subject: Re: [vdsm] migration progress feature | | | On Jul 4, 2013, at 16:04 , Peter V. Saveliev p...@redhat.com wrote: | | … | | Goal | | | We have to implement a feature, migration progress bar in the UI. This | migration bar should reflect not only the progress, but if the migration | is stalled and so on. | | Tasks | = | | * Get the information from libvirt: it provides job progress in the same | way for all migration-like jobs: migration, suspend, snapshot | * Feed this information to the engine | * Reflect it in the UI | | API status | == | | Libvirt info is OK — it is available for any migration-like job, be it | migration, suspend or snapshot. | | In VDSM, we have an API call, a separate verb to report the migration | progress: migrateStatus() | | But also we have getVmList() call, polled by the engine every several | seconds. | | Proposal | | | We would propose to provide an optional field, `migrateStatus`, in the | report sent by getVmList(). This approach should save a good amount of | traffic and ease the engine side logic. | | Having the separate verb, this can sound weird, but I'm sure that the | optimisation worth it. | | Please, read the patchset [1] and discuss it here. | | From my point of view this makes sense as it doesn't require additional | bandwidth and calls. | Also means no additional complexity in engine. I don't feel comfortable to | add another poll request during migration which makes the logic in engine | more complicated and means even higher traffic between hosts and engine. Not | that it's not doable, I just don't think it's the right way to go. I agree | it's not ideal from purely API point of view...however to me it seems | logical to have it as part of statistics as it is a sort of statistic, and | it doesn't require an extra call. The extra call already exist, it's just | that I think we already have too many. We should start looking into | effective communication, not necessarily clean | | Thanks, | michal | +1 such a feature will be very handy when migrating large guests (8GB+) over sub-optimal network. In such a case the last thing you want to do is additional calls. Re-using the existing calls by extending the statistics makes a lot of sense. i'm also in favor - vm status is treated as an async update based on the stats. vdsm can send this item only for vms which are migrating for example. I oppose the idea of overloading the getVMList(full=False) with migration-related statistics just because Engine happens to be calling this verb frequently. The full=False was born in sin and defies common practices of client/server design. getAllVmStats() was intended to supply all interesting statistics for all running VMs. Adding migration statistics to it makes much more sense. However, the size of its repsonse is quite large already, and I heard that people are afread that calling it more frequestly would degrade Engine's performence. Introducing a new verb, getMigrationStatuses(), would allow Engine to collect this piece of statistics in the exact frequency that it needs it. Coupling this data with the frequently-polled state of VM begs for future complaints that getVMList(full=False) is too heavy, and that we must introduce getVMList(full=False, veryveryskinny=True). Regrads, Dan. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] [Users] oVirt Weekly Meeting Minutes -- 2013-06-17
On Thu, Jul 18, 2013 at 12:29:57PM -0400, Doron Fediuck wrote: - Original Message - | From: Mike Burns mbu...@redhat.com | To: Doron Fediuck dfedi...@redhat.com | Cc: Dan Kenigsberg dan...@redhat.com, vdsm-de...@fedorahosted.org, bo...@ovirt.org, users us...@ovirt.org | Sent: Thursday, July 18, 2013 7:19:13 PM | Subject: Re: [Users] oVirt Weekly Meeting Minutes -- 2013-06-17 | | On 07/18/2013 11:59 AM, Doron Fediuck wrote: | | | - Original Message - | | From: Dan Kenigsberg dan...@redhat.com | | To: Mike Burns mbu...@redhat.com, vdsm-de...@fedorahosted.org | | Cc: bo...@ovirt.org, users us...@ovirt.org | | Sent: Thursday, July 18, 2013 6:31:52 PM | | Subject: Re: [Users] oVirt Weekly Meeting Minutes -- 2013-06-17 | | | | On Wed, Jul 17, 2013 at 11:00:01AM -0400, Mike Burns wrote: | | Minutes: | | http://ovirt.org/meetings/ovirt/2013/ovirt.2013-07-17-14.00.html | | Minutes (text): | | http://ovirt.org/meetings/ovirt/2013/ovirt.2013-07-17-14.00.txt | | Log: | | http://ovirt.org/meetings/ovirt/2013/ovirt.2013-07-17-14.00.log.html | | | | | | #ovirt: oVirt Weekly Meeting | | | | | | | | Meeting started by mburns at 14:00:11 UTC. The full logs are available | | at http://ovirt.org/meetings/ovirt/2013/ovirt.2013-07-17-14.00.log.html | | . | | | | | | | | Meeting summary | | --- | | * agenda and roll call (mburns, 14:00:23) | |* 3.3 status update (mburns, 14:00:30) | |* Workshops and Conferences (mburns, 14:00:47) | |* infra update (mburns, 14:00:50) | |* Other Topics (mburns, 14:00:53) | | | | | | | | | | Action Items | | | | * fsimonce to rebuild vdsm rc2 to include glance | | | | | | I've tagged vdsm with rc2, however minutes later it came to my attention | | (thanks Meni), that Vdsm ties itself into a know when requested to | | create a bridgeless (non-Vm) network. | | | | A fix has been posted, | | | | http://gerrit.ovirt.org/17085/ | | | | but master branch of vdsm is NOT of beta quality | | at the moment. | | Plus we have http://gerrit.ovirt.org/#/c/17044/ to use latest mom. | | Is there an ETA for a more stable vdsm? | mom part should be fine now. It's the network issue Dan reported that is pending now. Actually, the mom part has been pushed immediately after the non-VM-network bugfix... ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
[vdsm] oVirt developer meeting @ KVM Forum
Hi everyone, Put the date in your calendar! The oVirt developer meeting will be held in Edinburgh on October 23rd alongside the KVM Forum. As most of you know, the KVM Forum is happening alongside LinuxCon Europe and CloudOpen Europe in Edinburgh this year, on October 21-23. As we proposed to the oVirt board in January, we would like to take advantage of this gathering of KVM core developers to plan the future of the oVirt project too. In addition to the numerous oVirt presentations which have been proposed both for CloudOpen and the KVM Forum, we will be setting aside one day for developer working sessions. The agenda for these sessions is not (yet) set - we will have subject matter experts leading discussions on the future of their component, where oVirt fits into the broader world of virtualization and the cloud, and how we can grow the community. Among the topics which may be on the table are: * Storage - integration with Gluster, Ceph, Swift, Cinder, NetApp, EMC * Core virtualization - what's missing to make oVirt the best virtualization solution on the market? What's next? How can oVirt best take advantage of the latest KVM features? * Networking - Going beyond Quantum integration: L2 and L3 networking in oVirt * User interface engine - making oVirt nicer to use and easeir to learn * Ecosystem - Integration with OpenStack, CloudStack; migration strategy from vSphere; integration with other 3rd party projects - what is our place in the world? * Community and marketing - Should we add a forum? How can we grow the user base and community of oVirt? (Note, these are just my ideas - topics will be set by session leaders on a specific topic). What next? First, if you are interested in the future of the oVirt project, please plan to attend the developer meeting. If you are active in oVirt, but cannot finance your travel to the event, please send an email to dne...@redhat.com - I can't promise anything, but we do not want budget constraints to be the main reason for someone missing the meeting. Second, if you are interested in leading a working session on one of the topics above, or a different topic which is important to you, please send an email to the Workshop program committee at workshop...@ovirt.org We will keep you posted with schedule updates and more details as plannign advances during the coming weeks. Thanks for your interest, and for your support of oVirt! Regards, Dave Neary. -- Dave Neary - Community Action and Impact Open Source and Standards, Red Hat - http://community.redhat.com Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13 ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] migration progress feature
On 07/21/2013 12:14 PM, Dan Kenigsberg wrote: Introducing a new verb, getMigrationStatuses(), would allow Engine to collect this piece of statistics in the exact frequency that it needs it. Coupling this data with the frequently-polled state of VM begs for future complaints that getVMList(full=False) is too heavy, and that we must introduce getVMList(full=False, veryveryskinny=True). so the most likely outcome is engine would be calling this every time it calls getAllVmStats? ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
