- Devel - oVirt List Archives

[Engine-devel] RFC: Writeup on VDSM-libstoragemgmt integration
by Deepak C Shetty 26 Jun '12

26 Jun '12

Hello All, I have a draft write-up on the VDSM-libstoragemgmt integration. I wanted to run this thru' the mailing list(s) to help tune and crystallize it, before putting it on the ovirt wiki. I have run this once thru Ayal and Tony, so have some of their comments incorporated. I still have few doubts/questions, which I have posted below with lines ending with '?' Comments / Suggestions are welcome & appreciated. thanx, deepak [Ccing engine-devel and libstoragemgmt lists as this stuff is relevant to them too] -------------------------------------------------------------------------------------------------------------- 1) Background: VDSM provides high level API for node virtualization management. It acts in response to the requests sent by oVirt Engine, which uses VDSM to do all node virtualization related tasks, including but not limited to storage management. libstoragemgmt aims to provide vendor agnostic API for managing external storage array. It should help system administrators utilizing open source solutions have a way to programmatically manage their storage hardware in a vendor neutral way. It also aims to facilitate management automation, ease of use and take advantage of storage vendor supported features which improve storage performance and space utilization. Home Page: http://sourceforge.net/apps/trac/libstoragemgmt/ libstoragemgmt (LSM) today supports C and python plugins for talking to external storage array using SMI-S as well as native interfaces (eg: netapp plugin ) Plan is to grow the SMI-S interface as needed over time and add more vendor specific plugins for exploiting features not possible via SMI-S or have better alternatives than using SMI-S. For eg: Many of the copy offload features require to use vendor specific commands, which justifies the need for a vendor specific plugin. 2) Goals: 2a) Ability to plugin external storage array into oVirt/VDSM virtualization stack, in a vendor neutral way. 2b) Ability to list features/capabilities and other statistical info of the array 2c) Ability to utilize the storage array offload capabilities from oVirt/VDSM. 3) Details: LSM will sit as a new repository engine in VDSM. VDSM Repository Engine WIP @ http://gerrit.ovirt.org/#change,192 Current plan is to have LSM co-exist with VDSM on the virtualization nodes. *Note : 'storage' used below is generic. It can be a file/nfs-export for NAS targets and LUN/logical-drive for SAN targets. VDSM can use LSM and do the following... - Provision storage - Consume storage 3.1) Provisioning Storage using LSM Typically this will be done by a Storage administrator. oVirt/VDSM should provide storage admin the - ability to list the different storage arrays along with their types (NAS/SAN), capabilities, free/used space. - ability to provision storage using any of the array capabilities (eg: thin provisioned lun or new NFS export ) - ability to manage the provisioned storage (eg: resize/delete storage) Once the storage is provisioned by the storage admin, VDSM will have to refresh the host(s) for them to be able to see the newly provisioned storage. 3.1.1) Potential flows: Mgmt -> vdsm -> lsm: create LUN + LUN Mapping / Zoning / whatever is needed to make LUN available to list of hosts passed by mgmt Mgmt -> vdsm: getDeviceList (refreshes host and gets list of devices) Repeat above for all relevant hosts (depending on list passed earlier, mostly relevant when extending an existing VG) Mgmt -> use LUN in normal flows. 3.1.2) How oVirt Engine will know which LSM to use ? Normally the way this works today is that user can choose the host to use (default today is SPM), however there are a few flows where mgmt will know which host to use: 1. extend storage domain (add LUN to existing VG) - Use SPM and make sure *all* hosts that need access to this SD can see the new LUN 2. attach new LUN to a VM which is pinned to a specific host - use this host 3. attach new LUN to a VM which is not pinned - use a host from the cluster the VM belongs to and make sure all nodes in cluster can see the new LUN Flows for which there is no clear candidate (Maybe we can use the SPM host itself which is the default ?) 1. create a new disk without attaching it to any VM 2. create a LUN for a new storage domain 3.2) Consuming storage using LSM Typically this will be done by a virtualization administrator oVirt/VDSM should allow virtualization admin to - Create a new storage domain using the storage on the array. - Be able to specify whether VDSM should use the storage offload capability (default) or override it to use its own internal logic. 4) VDSM potential changes: 4.1) How to represent a VM disk, 1 LUN = 1 VMdisk or 1 LV = 1 VMdisk ? which bring another question...1 array == 1 storage domain OR 1 LUN/nfs-export on the array == 1 storage domain ? Pros & Cons of each... 1 array == 1 storage domain - Each new vmdisk (aka volume) will be a new lun/file on the array. - Easier to exploit offload capabilities, as they are available at the LUN/File granularity - Will there be any issues where there will be too many LUNs/Files ... any maxluns limit on linux hosts that we might hit ? -- VDSM has been tested with 1K LUNs and it worked fine - ayal - Storage array limitations on the number of LUNs can be a downside here. - Would it be ok to share the array for hosting another storage domain if need be ? -- Provided the existing domain is not utilising all of the free space -- We can create new LUNs and hand it over to anyone needed ? -- Changes needed in VDSM to work with raw LUNs, today it only has support for consuming LUNs via VG/LV. 1 LUN/nfs-export on the array == 1 storage domain - How to represent a new vmdisk (aka vdsm volume) if its a LUN provisioned using SAN target ? -- Will it be VG/LV as is done today for block domains ? -- If yes, then it will be difficult to exploit offload capabilities, as they are at LUN level, not at LV level. - Each new vmdisk will be a new file on the nfs-export, assuming offload capability is available at the file level, so this should work for NAS targets ? - Can use the storage array for hosting multiple storage domains. -- Provision one more LUN and use it for another storage domain if need be. - VDSM already supports this today, as part of block storage domains for LUNs case. Note that we will allow user to do either one of the two options above, depending on need. 4.2) Storage domain metadata will also include the features/capabilities of the storage array as reported by LSM. - Capabilities (taken via LSM) will be stored in the domain metadata during storage domain create flow. - Need changes in oVirt engine as well ( see 'oVirt Engine potential changes' section below ) 4.3) VDSM to poll LSM for array capabilities on a regular basis ? Per ayal: - If we have a 'storage array' entity in oVirt Engine (see 'oVirt Engine potential changes' section below ) then we can have a 'refresh capabilities' button/verb. - We can periodically query the storage array. - Query LSM before running operations (sounds redundant to me, but if it's cheap enough it could be simplest). Probably need a combination of 1+2 (query at very low frequency - 1/hour or 1/day + refresh button) 5) oVirt Engine potential changes - as described by ayal : - We will either need a new 'storage array' entity in engine to keep credentials, or, in case of storage array as storage domain, just keep this info as part of the domain at engine level. - Have a 'storage array' entity in oVirt Engine to support 'refresh capabilities' as a button/verb. - When user during storage provisioning, selects a LUN exported from a storage array (via LSM), the oVirt Engine would know from then onwards that this LUN is being served via LSM. It would then be able to query the capabilities of the LUN and show it to the virt admin during storage consumption flow. 6) Potential flows: - Create snapshot flow -- VDSM will check the snapshot offload capability in the domain metadata -- If available, and override is not configured, it will use LSM to offload LUN/File snapshot -- If override is configured or capability is not available, it will use its internal logic to create snapshot (qcow2). - Copy/Clone vmdisk flow -- VDSM will check the copy offload capability in the domain metadata -- If available, and override is not configured, it will use LSM to offload LUN/File copy -- If override is configured or capability is not available, it will use its internal logic to create snapshot (eg: dd cmd in case of LUN). 7) LSM potential changes: - list features/capabilities of the array. Eg: copy offload, thin prov. etc. - list containers (aka pools) (present in LSM today) - Ability to list different types of arrays being managed, their capabilities and used/free space - Ability to create/list/delete/resize volumes ( LUN or exports, available in LSM as of today) - Get monitoring info with object (LUN/snapshot/volume) as optional parameter for specific info. eg: container/pool free/used space, raid type etc. Need to make sure above info is listed in a coherent way across arrays (number of LUNs, raid type used? free/total per container/pool, per LUN?. Also need I/O statistics wherever possible.

10 24

Re: [Engine-devel] Forking unit tests
by Allon Mureinik 26 Jun '12

26 Jun '12

----- Original Message ----- > From: "Allon Mureinik" <amureini(a)redhat.com> > To: "Mike Kolesnik" <mkolesni(a)redhat.com> > Sent: Thursday, June 14, 2012 12:12:54 PM > Subject: Re: Forking unit tests > > > > ----- Original Message ----- > > From: "Mike Kolesnik" <mkolesni(a)redhat.com> > > To: "Allon Mureinik" <amureini(a)redhat.com> > > Cc: "Laszlo Hornyak" <lhornyak(a)redhat.com>, "engine-devel" > > <engine-devel(a)ovirt.org> > > Sent: Wednesday, June 13, 2012 1:28:36 PM > > Subject: Re: Forking unit tests > > > > > Hi guys, > > > > > > If you're using settings.xml as published in Building the oVirt > > > Engine page, you'd see we're forking for every test, in every > > > subproject. > > > This behaviour was introduced to handle memory leaks in PowerMock > > > we > > > use in some subprojects, but is redundant in others. > > > > > > Over the past month or so I've been working on removing PowerMock > > > from as many places as possible (many thanks to mkolesni and > > > lhornyak!), and we've got to the stage that forking is only > > > needed > > > in to subprojects - bll and resttypes. > > > > +1 - great job! > 10x! > > > > > Would it be possible to have this as a parameter (defaul true) that > > can be overridden, such as -Dengine.forkTests=false ? > couldn't find a good way to do it <forkMode> doesn't seem to work > when given a property as a value, sorry. > :-( Take a look at http://gerrit.ovirt.org/#/c/5653/1. Once it is merged, you could user -Dengine.powermock.fork=one to stop forking. > > > > > > The forking was defined explicitly in those two projects, so if > > > you > > > want to speed up your tests, just take the latest version of > > > settings.xml from > > > http://ovirt.org/wiki/Building_oVirt_engine#Maven_personal_settings. > > > > > > > > > -Allon > > > > > >

1 1

Re: [Engine-devel] 3.1 Release Notes
by Steve Gordon 25 Jun '12

25 Jun '12

Hi guys, As you all know we have a new release coming up shortly, and as discussed in the sync meeting last week I'm getting ready to prepare the release notes for it. To do that I need some help though, as it currently stands there are no bugs against the oVirt project with a target release of 3.1 and the ovirt_requires_release_note? flag set. If you are the maintainer of one of the sub-projects please ensure that you flag all notable features/fixes included in the 3.1* release with ovirt_requires_release_notes? and, ideally, add a brief description in the technical notes field. If you don't have access to set the flag for some reason then please reply to this email with a list of bugs instead. I know you've all been working very hard on this release, but without your input into this process I can not hope to accurately capture and highlight your efforts in the release notes. Thanks, Steve * I have assumed target release = 3.1 is the best flag to use in Bugzilla to determine which bugs are likely to be included in the release - if there is a better value to filter on please let me know.

1 0

[Engine-devel] GWT 2.4.0 and the oVirt Engine
by Schoenbrun, Dustin 25 Jun '12

25 Jun '12

--_000_CC06582EA7BFdustinschoenbrunnetappcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hey All, I was looking at doing some work with extending the oVirt Engine GUI but so= me of the functionality that I need (such as dynamic creation of tabs) is o= nly supported in GWT 2.4.0. What sort of steps would have to be taken to u= pdate the Engine to GWT 2.4.0? Also, what would be the easiest way of debu= gging and testing these updates through Eclipse, for example. Thanks in ad= vance! -- Dustin --_000_CC06582EA7BFdustinschoenbrunnetappcom_ Content-Type: text/html; charset="us-ascii" Content-ID: <F9935FC195A9C747A2F421B1612BDAC7(a)tahoe.netapp.com> Content-Transfer-Encoding: quoted-printable <html> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > </head> <body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-lin= e-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-fami= ly: Calibri, sans-serif; "> <div> <div> <div>Hey All,</div> <div><br> </div> <div>I was looking at doing some work with extending the oVirt Engine GUI b= ut some of the functionality that I need (such as dynamic creation of tabs)= is only supported in GWT 2.4.0.  What sort of steps would have to be = taken to update the Engine to GWT 2.4.0?  Also, what would be the easiest way of debugging and testing these u= pdates through Eclipse, for example.  Thanks in advance!</div> <div><br> </div> <div> <div> <div>-- Dustin</div> <div><br> </div> </div> </div> </div> </div> </body> </html> --_000_CC06582EA7BFdustinschoenbrunnetappcom_--

3 5

[Engine-devel] 3.1 bugs
by Itamar Heim 24 Jun '12

24 Jun '12

I have moved all MODIFIED bugs to ON_QA with target release of 3.1[1] This will allow to easily distinguish them from bugs fixed from now on, and will allow reporters to try and verify the fix, should they choose to. Plan is to close them currentrelease when 3.1 is released. Thanks, Itamar

1 0

[Engine-devel] IMPORTANT: engine_3.1 branch created
by Ofer Schreiber 21 Jun '12

21 Jun '12

Hey, I created the engine_3.1 branch on gerrit.ovirt.org, based on commit 6ef9f873ab88a35c8ec5afdcbbab7541c0d54c4e (masayag: "core: Remove trailing comma from network names list", pushed Wed Jun 20 10:16:57 2012 +0300). Any new critical bug fix, should be cherry-picked into engine_3.1 branch (by pushing the cherry-pick to refs/for/engine_3.1). If you have a critical fix merged after this commit, please make sure it's cherry-picked properly. Thanks, -- Ofer Schreiber oVirt Release Manager

1 1

[Engine-devel] [virt-node] VDSM as a general purpose virt host manager
by Saggi Mizrahi 21 Jun '12

21 Jun '12

There is an important discussion starting about the future of the VDSM API on vdsm-devel. If you want to be involved in the future of the VDSM API don't miss out and join vdsm-devel. To sign up go to https://fedorahosted.org/mailman/listinfo/vdsm-devel There growing need for a way to more easily reuse of the functionality of VDSM in order to service projects other than Ovirt-Engine. Originally VDSM was created as a proprietary agent for the sole purpose of serving the then proprietary version of what is known as ovirt-engine. Red Hat, after acquiring the technology, pressed on with it's commitment to open source ideals and released the code. But just releasing code into the wild doesn't build a community or makes a project successful. Further more when building open source software you should aspire to build reusable components instead of monolithic stacks. We would like to expose a stable, documented, well supported API. This gives us a chance to rethink the VDSM API from the ground up. There is already work in progress of making the internal logic of VDSM separate enough from the API layer so we could continue feature development and bug fixing while designing the API of the future. In order to achieve this though we need to do several things: 1. Declare API supportability guidelines 2. Decide on an API transport (e.g. REST, ZMQ, AMQP) 3. Make the API easily consumable (e.g. proper docs, example code, extending the API, etc) 4. Implement the API itself All of these are dependent on one another and the permutations are endless. This is why I think we should try and work on each one separately. All discussions will be done openly on the mailing list and until the final version comes out nothing is set in stone. If you think you have anything to contribute to this process, please do so either by commenting on the discussions or by sending code/docs/whatever patches. Once the API solidifies it will be quite difficult to change fundamental things, so speak now or forever hold your peace. Note that this is just an introductory email. There will be a quick follow up email to kick start the discussions. Don't forget to sign up to the vdsm-devel mailing list.

2 1

[Engine-devel] Questions about ovirt engine
by Shu Ming 19 Jun '12

19 Jun '12

Hi, I created a VM in my engine. And I found that every time I run the VM after shutdown, the VM uuid was changed to a different not while the VM itself was not changed including the VM name. Why doesn't engine keep the UUID for a VM and use the UUID every time the VM starts? How can I persistent my setting to a VM with "vdsClient", like the password set by the "setVmTicket" command? -- Shu Ming<shuming(a)linux.vnet.ibm.com> IBM China Systems and Technology Laboratory

2 1

[Engine-devel] 'deactivate' disk - what's the use case?
by Yaniv Kaul 18 Jun '12

18 Jun '12

I'm wondering what's the usefulness of having dual action of attach + activate to get a disk properly attached and working in a VM (and the deactivate and detach counterparts). The only reason I can think of is that we've annoyed the user by this useless dual action when working with storage domains in a data center for ages, and we wish to remain consistent and annoy the user in the disks scenario as well, but there may be a reason I'm not aware of. TIA, Y.

5 9

[Engine-devel] Version number changed to 3.1.0 (removing the _0001 suffix)
by Juan Hernandez 18 Jun '12

18 Jun '12

Hello, Please note that the suffix _0001 has been removed from the artifact versions and from the RPM version. This shouldn't be a problem, but if you find issues please let me know. Also take extra care when merging changes to any POM files, as you may be undoing the change for that particular POM file. Thanks in advance, Juan Hernandez -- Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta 3ºD, 28016 Madrid, Spain Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 - Red Hat S.L.

1 0