vdsm-devel July 2013

vdsm-devel@lists.stg.fedorahosted.org

22 participants
17 discussions

Re: [vdsm] [Users] [ATN] oVirt 3.3 release, moving to RC [3.3 branching, blockers review]
by Dan Kenigsberg 30 Jul '13

30 Jul '13

On Tue, Jul 30, 2013 at 06:05:46PM +0300, Moran Goldboim wrote: > We would like to go a head on oVirt 3.3 release process and issue an RC > > for tomorrow meeting: > > Maintainers/ Package owners > ================== > -branch your git repo (master) with 3.3 branch (making master ready for 3.4) > -for tomorrow meeting, overview [1], see if you have any changes to it > -if you don't have any blockers under your component, please branch > 3.3 with RC1 branch > > | > -master > | > -engine_3.3 > | > -RC1 > | > -engine_3.2 > ... > > Users > ==== > with your experience from test day and with nightlies, if you feel > there are additional candidates to block this version for please add > it to the tracker bug [1]. > > Suggested Schedule > ============ > Wed Jul 31st - review of blockers for the version and component readiness > Mon Aug 5th - RC1 release > Wed Aug 7th - Release readiness review (in case of blockers an RC2 > will be issued) > > Thanks. > > [1]*Bug 918494* <https://bugzilla.redhat.com/show_bug.cgi?id=918494> > -Tracker: oVirt 3.3 release I've just tagged vdsm-4.12.0 and branched ovirt-3.3 branch for the vdsm repository starting at git has 620343d6317c849fc985a5083cebb68c995f7c15. Expect a deluge of non-ovirt-3.3 merges to the master branch soon. Future ovirt-3.3 fixes would have to be backported and cherry-picked. Dan.

1 0

vdsm-sync meeting July 30th 2013
by asegurap＠redhat.com 30 Jul '13

30 Jul '13

Hi everybody, There were only two attendants (including myself) in the sync meeting yesterday so this will be fast to read. Here are the notes: - Vinzenz needs reviews for his "vdsm: Do not fail releasing a VM due to agent stopping errors" and "vdsm: Reduce the migration progress timeout" http://gerrit.ovirt.org/#/c/17072 http://gerrit.ovirt.org/#/c/16602

1 0

Exploiting domain specific offload features
by M. Mohan Kumar 25 Jul '13

25 Jul '13

Hello, We are adding features such as server offloaded cloning, snapshot of the files(ie VM disks) and zeroed vm disk allocation in GlusterFS. As of now only BD xlator supports offloaded cloning & snapshot. Server offloaded zeroing of VM disks is supported both by posix and BD xlator. The initial approach is to use xattr interface to trigger this offload features such as # setfattr -n "clone" -v "path-to-new-clone-file" path-to-source-file will create clone of path-to-source-file in path-to-new-clone-file. Cloning is done in GlusterFS server side and its kind of server offloaded copy. Similarly snapshot can also be taken using setfattr approach. GlusterFS storage domain is already part of VDSM and we want to exploit offload features provided by GlusterFS through VDSM. Is there any way to exploit these features from VDSM as of now?

4 6

Linking to bugs from oVirt wiki
by Allon Mureinik 24 Jul '13

24 Jul '13

Hi guys, Since a lot of us will be busy opening bugs as part of the oVirt Test Day, I cooeked up a quick template to help adding Bugzilla links. You can just use {BZ|number} in your wiki markup, and you'll get a user-friendly link to Bugzilla with the given number (e.g., {BZ|123} will create a link to http://bugzilla.redhat.com/123) Enjoy, Allon

1 1

migration progress feature
by peet＠redhat.com 22 Jul '13

22 Jul '13

… 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. Thanks. [1] http://gerrit.ovirt.org/#/c/15125/ -- Peter V. Saveliev

5 7

oVirt developer meeting @ KVM Forum
by Dave Neary 21 Jul '13

21 Jul '13

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 dneary(a)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-pc(a)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

1 0

Re: [vdsm] [Users] oVirt Weekly Meeting Minutes -- 2013-06-17
by Dan Kenigsberg 21 Jul '13

21 Jul '13

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.

3 4

VDSM / Guest Agent: Introduction of API versioning
by Vinzenz Feenstra 17 Jul '13

17 Jul '13

Hi, with the increased number of version we're supporting and going to support it's going to be time for the introduction of protocol versioning. The motivation for this is, that currently if VDSM is sending a message to the guest agent which is not known, it will end up being logged as error on the guest agent side. If the guest agent is sending a message to VDSM which VDSM does not know about this is logged as error as well. While one could argue, that we should remove the error level or remove the logging all together it will not work for older versions though. My proposed solution is as follows: By default the guest agent supposes API version 0, which means all until this time implemented messages are supported. The same should be supposed from the VDSM side, by default the API version shall be 0. Once we're adding a new message (this is the case of FQDN reporting http://gerrit.ovirt.org/#/c/16572/ ) we're going to increase the version with a new release. Messages which are requiring a higher API version, are not supposed to be sent via the VIO Channels. The negotiation of the used API version would work like this: VDSM sends the refresh command on connect to the guest agent VIO Channel with the apiVersion argument. Older version of the guest agent are ignoring these additional parameters, as they are not expected however it won't fail either on them. If the guest agent is retrieving an API Version it will either use it, or if it is higher than the maximum known version it will use the guest agent's version. This version is sent as a separate message back to VDSM which then in turn will set the value to the value retrieved by the guest agent. (As long it is greater than 0) Here are the proposed patch sets: Guest Side PatchSet: http://gerrit.ovirt.org/#/c/16995 VDSM Side PatchSet: http://gerrit.ovirt.org/#/c/17004/ Please let me know your thoughts about this. In my opinion are those changes pretty safe and straight forward, and it will allow us to avoid unnecessary messages to be sent between guest and host Regards, -- Regards, Vinzenz Feenstra | Senior Software Engineer RedHat Engineering Virtualization R & D Phone: +420 532 294 625 IRC: vfeenstr or evilissimo Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

1 0

vdsm sync meeting Monday July 15th
by Dan Kenigsberg 16 Jul '13

16 Jul '13

vdsm sync meeting monday July 15 ================================== Terribly low attendence to the meeting. Showing up can be helpful to getting your patches reviewed! Federico's diskSizeExtend patches are currently being pushed by Ayal after a cursory review by Sergey > + http://gerrit.ovirt.org/#/c/14589 - volume: add the BLOCK_SIZE constant +1 > + http://gerrit.ovirt.org/#/c/14590 - volume: add the extendVolumeSize method > + http://gerrit.ovirt.org/#/c/15614 - vm: add the live diskSizeExtend method +1 Glance upload/download enjoyed several comments from Yeela > + http://gerrit.ovirt.org/#/c/14955 - image: add support to upload/download images - gluster service management verb is in! - Neutron hook patches are in! - so is "multiple gateways" feature! - storage functional tests are in! Thanks, Zhou and reviewers! - Toni has posted a [WIP] about unified network configuration persistence http://gerrit.ovirt.org/16699/ It needs some love and care and rebase on top of http://gerrit.ovirt.org/16847 - No interesting work has been done on the IPv6 patch for ifcfg configurator which requires serious refactoring: http://gerrit.ovirt.org/#/c/11741/1/vdsm/configNetwork.py - Federico says that his "init: restart sanlock groups are missing" http://gerrit.ovirt.org/16742 could have used service-management code by vdsm-tool. Unfortunately, it is inconvenient to re-use one command code in another. Danken prefer to push it to a vdsm-tool "common" module over exposing in site_packages/vdsm/__init__.py. - ovirt-3.3 is going beta oh-so-very-soon. This means that I am about to tag v4.12.0-rc1 after basic tests. I know that I am missing several patches regarding policy paramenters, which needs to get into 3.3. NOW is the time to shout about other release blockers, and THIS is the place. Goodbye, I hope to see more of you in two weeks! Dan.

2 2

Disk monitoring in thin provison with qcow2. Why vdsm choose both passive monitor(VIR_DOMAIN_EVENT_ID_IO_ERROR Event of libvirt) and active monitor(thread calls bolockInfo() function)
by Qixiaozhen 14 Jul '13

14 Jul '13

Hi, all I am very confused with the two ways of disk monitors: passive monitor(VIR_DOMAIN_EVENT_ID_IO_ERROR Event of libvirt) and active monitor(thread calls bolockInfo() function). These ways have the same goal of extending the LV volume in the block storage domain. The node who wants to enlarge its actual disk size would send the extend message to the SPM by the mailbox of the domain. Why we choose both the ways? I think either is OK. The reason is that the two ways would suspend the vm in the process of extending. What's the scene of the passive monitor above? I think that once the active monitor have existed, the passive monitor event would never occur. Can someone help me? Thank you Qi Appendix: 1)VIR_DOMAIN_EVENT_ID_IO_ERROR Event callback -----> passive monitor if cif != None: for ev in (libvirt.VIR_DOMAIN_EVENT_ID_LIFECYCLE, libvirt.VIR_DOMAIN_EVENT_ID_REBOOT, libvirt.VIR_DOMAIN_EVENT_ID_RTC_CHANGE, libvirt.VIR_DOMAIN_EVENT_ID_IO_ERROR_REASON, libvirt.VIR_DOMAIN_EVENT_ID_GRAPHICS, libvirt.VIR_DOMAIN_EVENT_ID_BLOCK_JOB): conn.domainEventRegisterAny(None, ev, __eventCallback, (cif, ev)) def _onAbnormalStop(self, blockDevAlias, err): ...... if err.upper() == 'ENOSPC': for d in self._devices[vm.DISK_DEVICES]: if d.alias == blockDevAlias: ...... capacity, alloc, physical = self._dom.blockInfo(d.path, 0) if physical > (alloc + config.getint('irs', 'volume_utilization_chunk_mb')): ...... self._lvExtend(d.name) 2)create a new thread to sample the statistics in the vm with its running. -----> active monitor def _initVmStats(self): self._vmStats = VmStatsThread(self) self._vmStats.start() self._guestEventTime = self._startTime ---------------------------------------------------------------------- def _highWrite(self): if not self._vm._volumesPrepared: # Avoid queries from storage during recovery process return for vmDrive in self._vm._devices[vm.DISK_DEVICES]: if vmDrive.blockDev and vmDrive.format == 'cow': capacity, alloc, physical = \ self._vm._dom.blockInfo(vmDrive.path, 0) if physical - alloc < self._vm._MIN_DISK_REMAIN: ...... self._vm._onHighWrite(vmDrive.name, alloc) def _onHighWrite(self, block_dev, offset): self.log.info('_onHighWrite: write above watermark on %s offset %s', block_dev, offset) self._lvExtend(block_dev) def _lvExtend(self, block_dev, newsize=None): ...... self.cif.irs.sendExtendMsg(d.poolID, volDict, newsize * 2**20, self._afterLvExtend) ......

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

vdsm-devel July 2013