From wudxw at linux.vnet.ibm.com Mon Mar 11 05:08:21 2013 Content-Type: multipart/mixed; boundary="===============6015817898772671372==" MIME-Version: 1.0 From: Mark Wu To: devel at ovirt.org Subject: [Engine-devel] Proposal for support ISO domain on other types of file based storage. Date: Mon, 11 Mar 2013 17:08:13 +0800 Message-ID: <513D9EFD.7000305@linux.vnet.ibm.com> --===============6015817898772671372== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable This is a multi-part message in MIME format. --------------070305010507040809030004 Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed Content-Transfer-Encoding: 7bit Hi guys, Currently, ISO domain is only supported on NFS storage. It could = improve the ease of use if it allows other types of file based storage to store ISO images. After an investigation, I = found there's not any restriction on this idea. So the whole work is removing the limitation on engine side. That means = engine should allow ISO domain could have different storage type from the data center it's attached, like = what we do with nfs ISO domain in SAN DC. I start this idea with localfs. I know local storage can't be seen in = cluster level. But it also provides a choice if no NFS available. VMs can be created on the host which has the ISO repo, = and then be migrated to any other host in the cluster. I have done the initial patches: allow creation ISO domain on localfs = [1] and support import ISO domain on localfs [2] I don't have much experience in java/j2ee/web development and engine = architecture. The patches just work for me. I am not sure if it will bring some potential problems. So any feedback = on the patch or the idea will be appreciated very much. Mark. [1] http://gerrit.ovirt.org/#/c/12687/ [2] http://gerrit.ovirt.org/#/c/12916/ --------------070305010507040809030004 Content-Type: text/html; charset=3DISO-8859-1 Content-Transfer-Encoding: 7bit Hi guys,

Currently, ISO domain is only supported on NFS storage. It could improve the ease of use if it allows other types
of file based storage to store ISO images. After an investigation, I found there's not any restriction on this idea.
So the whole work is removing the limitation on engine side. That means engine should allow ISO domain could
have different storage type from the data center it's attached, like what we do with nfs ISO domain in SAN DC.

I start this idea with localfs. I know local storage can't be seen in cluster level. But it also provides a choice if no
NFS available. VMs can be created on the host which has the ISO repo, and then be migrated to any other host in the cluster.
I have done the initial patches: allow creation ISO domain on localfs [1] and support import ISO domain on localfs [2]
I don't have much experience in java/j2ee/web development and engine architecture. The patches just work for me.
I am not sure if it will bring some potential problems. So any feedback on the patch or the idea will be appreciated very much.<= br>

Mark.

[1] http://gerrit.ovirt.= org/#/c/12687/
[2] http://gerrit.ovirt.org/= #/c/12916/
--------------070305010507040809030004-- --===============6015817898772671372== Content-Type: multipart/alternative MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="attachment.bin" VGhpcyBpcyBhIG11bHRpLXBhcnQgbWVzc2FnZSBpbiBNSU1FIGZvcm1hdC4KLS0tLS0tLS0tLS0t LS0wNzAzMDUwMTA1MDcwNDA4MDkwMzAwMDQKQ29udGVudC1UeXBlOiB0ZXh0L3BsYWluOyBjaGFy c2V0PUlTTy04ODU5LTE7IGZvcm1hdD1mbG93ZWQKQ29udGVudC1UcmFuc2Zlci1FbmNvZGluZzog N2JpdAoKSGkgZ3V5cywKCkN1cnJlbnRseSwgSVNPIGRvbWFpbiBpcyBvbmx5IHN1cHBvcnRlZCBv biBORlMgc3RvcmFnZS4gIEl0IGNvdWxkIAppbXByb3ZlIHRoZSBlYXNlIG9mIHVzZSBpZiBpdCBh bGxvd3Mgb3RoZXIgdHlwZXMKb2YgZmlsZSBiYXNlZCBzdG9yYWdlIHRvIHN0b3JlIElTTyBpbWFn ZXMuIEFmdGVyIGFuIGludmVzdGlnYXRpb24sIEkgCmZvdW5kIHRoZXJlJ3Mgbm90IGFueSByZXN0 cmljdGlvbiBvbiB0aGlzIGlkZWEuClNvIHRoZSB3aG9sZSB3b3JrIGlzIHJlbW92aW5nIHRoZSBs aW1pdGF0aW9uIG9uIGVuZ2luZSBzaWRlLiAgVGhhdCBtZWFucyAKZW5naW5lIHNob3VsZCBhbGxv dyBJU08gZG9tYWluIGNvdWxkCmhhdmUgZGlmZmVyZW50IHN0b3JhZ2UgdHlwZSBmcm9tIHRoZSBk YXRhIGNlbnRlciBpdCdzIGF0dGFjaGVkLCBsaWtlIAp3aGF0IHdlIGRvIHdpdGggbmZzIElTTyBk b21haW4gaW4gU0FOIERDLgoKSSBzdGFydCB0aGlzIGlkZWEgd2l0aCBsb2NhbGZzLiBJIGtub3cg bG9jYWwgc3RvcmFnZSBjYW4ndCBiZSBzZWVuIGluIApjbHVzdGVyIGxldmVsLiBCdXQgaXQgYWxz byBwcm92aWRlcyBhIGNob2ljZSBpZiBubwpORlMgYXZhaWxhYmxlLiBWTXMgY2FuIGJlIGNyZWF0 ZWQgb24gdGhlIGhvc3Qgd2hpY2ggaGFzIHRoZSBJU08gcmVwbywgCmFuZCB0aGVuIGJlIG1pZ3Jh dGVkIHRvIGFueSBvdGhlciBob3N0IGluIHRoZSBjbHVzdGVyLgpJIGhhdmUgZG9uZSB0aGUgaW5p dGlhbCBwYXRjaGVzOiBhbGxvdyBjcmVhdGlvbiBJU08gZG9tYWluIG9uIGxvY2FsZnMgClsxXSBh bmQgc3VwcG9ydCBpbXBvcnQgSVNPIGRvbWFpbiBvbiBsb2NhbGZzIFsyXQpJIGRvbid0IGhhdmUg bXVjaCBleHBlcmllbmNlIGluIGphdmEvajJlZS93ZWIgZGV2ZWxvcG1lbnQgYW5kIGVuZ2luZSAK YXJjaGl0ZWN0dXJlLiAgVGhlIHBhdGNoZXMganVzdCB3b3JrIGZvciBtZS4KSSBhbSBub3Qgc3Vy ZSBpZiBpdCB3aWxsIGJyaW5nIHNvbWUgcG90ZW50aWFsIHByb2JsZW1zLiAgU28gYW55IGZlZWRi YWNrIApvbiB0aGUgcGF0Y2ggb3IgIHRoZSBpZGVhIHdpbGwgYmUgYXBwcmVjaWF0ZWQgdmVyeSBt dWNoLgoKCk1hcmsuCgpbMV0gaHR0cDovL2dlcnJpdC5vdmlydC5vcmcvIy9jLzEyNjg3LwpbMl0g aHR0cDovL2dlcnJpdC5vdmlydC5vcmcvIy9jLzEyOTE2LwoKLS0tLS0tLS0tLS0tLS0wNzAzMDUw MTA1MDcwNDA4MDkwMzAwMDQKQ29udGVudC1UeXBlOiB0ZXh0L2h0bWw7IGNoYXJzZXQ9SVNPLTg4 NTktMQpDb250ZW50LVRyYW5zZmVyLUVuY29kaW5nOiA3Yml0Cgo8aHRtbD4KICA8aGVhZD4KCiAg ICA8bWV0YSBodHRwLWVxdWl2PSJjb250ZW50LXR5cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hh cnNldD1JU08tODg1OS0xIj4KICA8L2hlYWQ+CiAgPGJvZHkgYmdjb2xvcj0iI0ZGRkZGRiIgdGV4 dD0iIzAwMDAwMCI+CiAgICBIaSBndXlzLCA8YnI+CiAgICA8YnI+CiAgICBDdXJyZW50bHksIElT TyBkb21haW4gaXMgb25seSBzdXBwb3J0ZWQgb24gTkZTIHN0b3JhZ2UuJm5ic3A7IEl0IGNvdWxk CiAgICBpbXByb3ZlIHRoZSBlYXNlIG9mIHVzZSBpZiBpdCBhbGxvd3Mgb3RoZXIgdHlwZXM8YnI+ CiAgICBvZiBmaWxlIGJhc2VkIHN0b3JhZ2UgdG8gc3RvcmUgSVNPIGltYWdlcy4gQWZ0ZXIgYW4g aW52ZXN0aWdhdGlvbiwmbmJzcDsKICAgIEkgZm91bmQgdGhlcmUncyBub3QgYW55IHJlc3RyaWN0 aW9uIG9uIHRoaXMgaWRlYS48YnI+CiAgICBTbyB0aGUgd2hvbGUgd29yayBpcyByZW1vdmluZyB0 aGUgbGltaXRhdGlvbiBvbiBlbmdpbmUgc2lkZS4mbmJzcDsgVGhhdAogICAgbWVhbnMgZW5naW5l IHNob3VsZCBhbGxvdyBJU08gZG9tYWluIGNvdWxkIDxicj4KICAgIGhhdmUgZGlmZmVyZW50IHN0 b3JhZ2UgdHlwZSBmcm9tIHRoZSBkYXRhIGNlbnRlciBpdCdzIGF0dGFjaGVkLCBsaWtlCiAgICB3 aGF0IHdlIGRvIHdpdGggbmZzIElTTyBkb21haW4gaW4gU0FOIERDLjxicj4KICAgIDxicj4KICAg IEkgc3RhcnQgdGhpcyBpZGVhIHdpdGggbG9jYWxmcy4gSSBrbm93IGxvY2FsIHN0b3JhZ2UgY2Fu J3QgYmUgc2VlbgogICAgaW4gY2x1c3RlciBsZXZlbC4gQnV0IGl0IGFsc28gcHJvdmlkZXMgYSBj aG9pY2UgaWYgbm88YnI+CiAgICBORlMgYXZhaWxhYmxlLiBWTXMgY2FuIGJlIGNyZWF0ZWQgb24g dGhlIGhvc3Qgd2hpY2ggaGFzIHRoZSBJU08KICAgIHJlcG8sIGFuZCB0aGVuIGJlIG1pZ3JhdGVk IHRvIGFueSBvdGhlciBob3N0IGluIHRoZSBjbHVzdGVyLjxicj4KICAgIEkgaGF2ZSBkb25lIHRo ZSBpbml0aWFsIHBhdGNoZXM6IGFsbG93IGNyZWF0aW9uIElTTyBkb21haW4gb24KICAgIGxvY2Fs ZnMgWzFdIGFuZCBzdXBwb3J0IGltcG9ydCBJU08gZG9tYWluIG9uIGxvY2FsZnMgWzJdPGJyPgog ICAgSSBkb24ndCBoYXZlIG11Y2ggZXhwZXJpZW5jZSBpbiBqYXZhL2oyZWUvd2ViIGRldmVsb3Bt ZW50IGFuZCBlbmdpbmUKICAgIGFyY2hpdGVjdHVyZS4mbmJzcDsgVGhlIHBhdGNoZXMganVzdCB3 b3JrIGZvciBtZS48YnI+CiAgICBJIGFtIG5vdCBzdXJlIGlmIGl0IHdpbGwgYnJpbmcgc29tZSBw b3RlbnRpYWwgcHJvYmxlbXMuJm5ic3A7IFNvIGFueQogICAgZmVlZGJhY2sgb24gdGhlIHBhdGNo IG9yJm5ic3A7IHRoZSBpZGVhIHdpbGwgYmUgYXBwcmVjaWF0ZWQgdmVyeSBtdWNoLjxicj4KICAg IDxicj4KICAgIDxicj4KICAgIE1hcmsuPGJyPgogICAgPG1ldGEgaHR0cC1lcXVpdj0iY29udGVu dC10eXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7CiAgICAgIGNoYXJzZXQ9SVNPLTg4NTktMSI+CiAg ICA8YnI+CiAgICBbMV0gPGEgaHJlZj0iaHR0cDovL2dlcnJpdC5vdmlydC5vcmcvIy9jLzEyNjg3 LyI+aHR0cDovL2dlcnJpdC5vdmlydC5vcmcvIy9jLzEyNjg3LzwvYT48YnI+CiAgICBbMl0KICAg IDxtZXRhIGh0dHAtZXF1aXY9ImNvbnRlbnQtdHlwZSIgY29udGVudD0idGV4dC9odG1sOwogICAg ICBjaGFyc2V0PUlTTy04ODU5LTEiPgogICAgPGEgaHJlZj0iaHR0cDovL2dlcnJpdC5vdmlydC5v cmcvIy9jLzEyOTE2LyI+aHR0cDovL2dlcnJpdC5vdmlydC5vcmcvIy9jLzEyOTE2Lzxicj4KICAg IDwvYT4KICA8L2JvZHk+CjwvaHRtbD4KCi0tLS0tLS0tLS0tLS0tMDcwMzA1MDEwNTA3MDQwODA5 MDMwMDA0LS0KCg== --===============6015817898772671372==-- From abaron at redhat.com Sun Mar 17 10:12:57 2013 Content-Type: multipart/mixed; boundary="===============1126352339538060571==" MIME-Version: 1.0 From: Ayal Baron To: devel at ovirt.org Subject: Re: [Engine-devel] Proposal for support ISO domain on other types of file based storage. Date: Sun, 17 Mar 2013 10:12:55 -0400 Message-ID: <819999290.9188868.1363529575167.JavaMail.root@redhat.com> In-Reply-To: 513D9EFD.7000305@linux.vnet.ibm.com --===============1126352339538060571== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable ----- Original Message ----- > = > Hi guys, > = > Currently, ISO domain is only supported on NFS storage. It could > improve the ease of use if it allows other types > of file based storage to store ISO images. After an investigation, I > found there's not any restriction on this idea. > So the whole work is removing the limitation on engine side. That > means engine should allow ISO domain could > have different storage type from the data center it's attached, like > what we do with nfs ISO domain in SAN DC. > = > I start this idea with localfs. I know local storage can't be seen in > cluster level. But it also provides a choice if no > NFS available. VMs can be created on the host which has the ISO repo, > and then be migrated to any other host in the cluster. > I have done the initial patches: allow creation ISO domain on localfs > [1] and support import ISO domain on localfs [2] > I don't have much experience in java/j2ee/web development and engine > architecture. The patches just work for me. > I am not sure if it will bring some potential problems. So any > feedback on the patch or the idea will be appreciated very much. Haven't looked at the patches yet, but wrt the idea, I agree on the need (b= eing able to attach ISOs from anywhere and not just nfs) but I think the wa= y to do this should be by getting rid of the ISO domain type altogether. Basically what we need is: 1. a way to connect to file based storage (let's leave block aside for now)= - this already exists via the connectStorageServer verb 2. a way to list and present a file system tree in gui (give an arbitrary p= ath to vdsm and list content) and possibly filter results by type (vfd, iso= ) - does not exist today. Possibly some security aspects here that need ha= shing out. 3. a way to specify a path to a file when attaching an iso/vfd to a VM - th= is is the way it works today This would devoid the need for isoUploader and allow users to simply manage= an nfs export with files. Next step would be to make connectStorageServer support httpfs [1] and then= we'd be able to mount ISOs directly over http (hopefully this would be suf= ficient to support ISOs stored on S3, swift, glance, etc). [1] http://httpfs.sourceforge.net/ > = > = > Mark. > = > [1] http://gerrit.ovirt.org/#/c/12687/ > [2] http://gerrit.ovirt.org/#/c/12916/ > = > _______________________________________________ > Engine-devel mailing list > Engine-devel(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel >=20 --===============1126352339538060571==-- From wudxw at linux.vnet.ibm.com Sun Mar 17 23:32:07 2013 Content-Type: multipart/mixed; boundary="===============7528070310030252279==" MIME-Version: 1.0 From: Mark Wu To: devel at ovirt.org Subject: Re: [Engine-devel] Proposal for support ISO domain on other types of file based storage. Date: Mon, 18 Mar 2013 11:30:42 +0800 Message-ID: <51468A62.2010602@linux.vnet.ibm.com> In-Reply-To: 819999290.9188868.1363529575167.JavaMail.root@redhat.com --===============7528070310030252279== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On Sun 17 Mar 2013 10:12:55 PM CST, Ayal Baron wrote: > > > ----- Original Message ----- >> >> Hi guys, >> >> Currently, ISO domain is only supported on NFS storage. It could >> improve the ease of use if it allows other types >> of file based storage to store ISO images. After an investigation, I >> found there's not any restriction on this idea. >> So the whole work is removing the limitation on engine side. That >> means engine should allow ISO domain could >> have different storage type from the data center it's attached, like >> what we do with nfs ISO domain in SAN DC. >> >> I start this idea with localfs. I know local storage can't be seen in >> cluster level. But it also provides a choice if no >> NFS available. VMs can be created on the host which has the ISO repo, >> and then be migrated to any other host in the cluster. >> I have done the initial patches: allow creation ISO domain on localfs >> [1] and support import ISO domain on localfs [2] >> I don't have much experience in java/j2ee/web development and engine >> architecture. The patches just work for me. >> I am not sure if it will bring some potential problems. So any >> feedback on the patch or the idea will be appreciated very much. > > Haven't looked at the patches yet, but wrt the idea, I agree on the need = (being able to attach ISOs from anywhere and not just nfs) but I think the = way to do this should be by getting rid of the ISO domain type altogether. I think ISO domain on localfs is useful for a simple setup or demo, = such as oVirt all-in-one. > Basically what we need is: > 1. a way to connect to file based storage (let's leave block aside for no= w) - this already exists via the connectStorageServer verb > 2. a way to list and present a file system tree in gui (give an arbitrary= path to vdsm and list content) and possibly filter results by type (vfd, i= so) - does not exist today. Possibly some security aspects here that need = hashing out. > 3. a way to specify a path to a file when attaching an iso/vfd to a VM - = this is the way it works today > > This would devoid the need for isoUploader and allow users to simply mana= ge an nfs export with files. > Next step would be to make connectStorageServer support httpfs [1] and th= en we'd be able to mount ISOs directly over http (hopefully this would be s= ufficient to support ISOs stored on S3, swift, glance, etc). Actually, we could use the qemu curl backend image support directly. = That means we don't need mount the place storing ISO images. We can = just maintain a list of ISO image with its link, which could be http, = ftp and ssh. > > [1] http://httpfs.sourceforge.net/ > >> >> >> Mark. >> >> [1] http://gerrit.ovirt.org/#/c/12687/ >> [2] http://gerrit.ovirt.org/#/c/12916/ >> >> _______________________________________________ >> Engine-devel mailing list >> Engine-devel(a)ovirt.org >> http://lists.ovirt.org/mailman/listinfo/engine-devel >> > --===============7528070310030252279==-- From abaron at redhat.com Mon Mar 18 02:51:05 2013 Content-Type: multipart/mixed; boundary="===============4401662421889104282==" MIME-Version: 1.0 From: Ayal Baron To: devel at ovirt.org Subject: Re: [Engine-devel] Proposal for support ISO domain on other types of file based storage. Date: Mon, 18 Mar 2013 02:51:03 -0400 Message-ID: <411572396.9297119.1363589463150.JavaMail.root@redhat.com> In-Reply-To: 51468A62.2010602@linux.vnet.ibm.com --===============4401662421889104282== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable ----- Original Message ----- > On Sun 17 Mar 2013 10:12:55 PM CST, Ayal Baron wrote: > > > > > > ----- Original Message ----- > >> > >> Hi guys, > >> > >> Currently, ISO domain is only supported on NFS storage. It could > >> improve the ease of use if it allows other types > >> of file based storage to store ISO images. After an investigation, > >> I > >> found there's not any restriction on this idea. > >> So the whole work is removing the limitation on engine side. That > >> means engine should allow ISO domain could > >> have different storage type from the data center it's attached, > >> like > >> what we do with nfs ISO domain in SAN DC. > >> > >> I start this idea with localfs. I know local storage can't be seen > >> in > >> cluster level. But it also provides a choice if no > >> NFS available. VMs can be created on the host which has the ISO > >> repo, > >> and then be migrated to any other host in the cluster. > >> I have done the initial patches: allow creation ISO domain on > >> localfs > >> [1] and support import ISO domain on localfs [2] > >> I don't have much experience in java/j2ee/web development and > >> engine > >> architecture. The patches just work for me. > >> I am not sure if it will bring some potential problems. So any > >> feedback on the patch or the idea will be appreciated very much. > > > > Haven't looked at the patches yet, but wrt the idea, I agree on the > > need (being able to attach ISOs from anywhere and not just nfs) > > but I think the way to do this should be by getting rid of the ISO > > domain type altogether. > = > I think ISO domain on localfs is useful for a simple setup or demo, > such as oVirt all-in-one. As I said above, I totally agree that we need to be able to attach ISOs on = local host, what I'm saying is that we don't need a local ISO *domain*. Al= l we need is the ability to list the content of a directory on the local ho= st (to be able to choose the ISO) and attach it to the VM. Since the attac= h part already exists then the gap is just the listing issue. > = > > Basically what we need is: > > 1. a way to connect to file based storage (let's leave block aside > > for now) - this already exists via the connectStorageServer verb > > 2. a way to list and present a file system tree in gui (give an > > arbitrary path to vdsm and list content) and possibly filter > > results by type (vfd, iso) - does not exist today. Possibly some > > security aspects here that need hashing out. > > 3. a way to specify a path to a file when attaching an iso/vfd to a > > VM - this is the way it works today > > > > This would devoid the need for isoUploader and allow users to > > simply manage an nfs export with files. > > Next step would be to make connectStorageServer support httpfs [1] > > and then we'd be able to mount ISOs directly over http (hopefully > > this would be sufficient to support ISOs stored on S3, swift, > > glance, etc). > = > Actually, we could use the qemu curl backend image support directly. > That means we don't need mount the place storing ISO images. We can > just maintain a list of ISO image with its link, which could be http, > ftp and ssh. even better! > = > > > > [1] http://httpfs.sourceforge.net/ > > > >> > >> > >> Mark. > >> > >> [1] http://gerrit.ovirt.org/#/c/12687/ > >> [2] http://gerrit.ovirt.org/#/c/12916/ > >> > >> _______________________________________________ > >> Engine-devel mailing list > >> Engine-devel(a)ovirt.org > >> http://lists.ovirt.org/mailman/listinfo/engine-devel > >> > > > = > = >=20 --===============4401662421889104282==-- From shuming at linux.vnet.ibm.com Mon Mar 18 03:12:11 2013 Content-Type: multipart/mixed; boundary="===============8760025910026227707==" MIME-Version: 1.0 From: Shu Ming To: devel at ovirt.org Subject: Re: [Engine-devel] Proposal for support ISO domain on other types of file based storage. Date: Mon, 18 Mar 2013 15:11:20 +0800 Message-ID: <5146BE18.2000306@linux.vnet.ibm.com> In-Reply-To: 51468A62.2010602@linux.vnet.ibm.com --===============8760025910026227707== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Mark Wu : > On Sun 17 Mar 2013 10:12:55 PM CST, Ayal Baron wrote: >> >> >> ----- Original Message ----- >>> >>> Hi guys, >>> >>> Currently, ISO domain is only supported on NFS storage. It could >>> improve the ease of use if it allows other types >>> of file based storage to store ISO images. After an investigation, I >>> found there's not any restriction on this idea. >>> So the whole work is removing the limitation on engine side. That >>> means engine should allow ISO domain could >>> have different storage type from the data center it's attached, like >>> what we do with nfs ISO domain in SAN DC. >>> >>> I start this idea with localfs. I know local storage can't be seen in >>> cluster level. But it also provides a choice if no >>> NFS available. VMs can be created on the host which has the ISO repo, >>> and then be migrated to any other host in the cluster. >>> I have done the initial patches: allow creation ISO domain on localfs >>> [1] and support import ISO domain on localfs [2] >>> I don't have much experience in java/j2ee/web development and engine >>> architecture. The patches just work for me. >>> I am not sure if it will bring some potential problems. So any >>> feedback on the patch or the idea will be appreciated very much. >> >> Haven't looked at the patches yet, but wrt the idea, I agree on the = >> need (being able to attach ISOs from anywhere and not just nfs) but I = >> think the way to do this should be by getting rid of the ISO domain = >> type altogether. > > I think ISO domain on localfs is useful for a simple setup or demo, = > such as oVirt all-in-one. > >> Basically what we need is: >> 1. a way to connect to file based storage (let's leave block aside = >> for now) - this already exists via the connectStorageServer verb >> 2. a way to list and present a file system tree in gui (give an = >> arbitrary path to vdsm and list content) and possibly filter results = >> by type (vfd, iso) - does not exist today. Possibly some security = >> aspects here that need hashing out. >> 3. a way to specify a path to a file when attaching an iso/vfd to a = >> VM - this is the way it works today >> >> This would devoid the need for isoUploader and allow users to simply = >> manage an nfs export with files. >> Next step would be to make connectStorageServer support httpfs [1] = >> and then we'd be able to mount ISOs directly over http (hopefully = >> this would be sufficient to support ISOs stored on S3, swift, glance, = >> etc). > > Actually, we could use the qemu curl backend image support directly. = > That means we don't need mount the place storing ISO images. We can = > just maintain a list of ISO image with its link, which could be http, = > ftp and ssh. That will be fine to start a VM on a existing extern ISO image. I also = would like to maintain a ISO image cache on the local host to avoid to = re-streaming the ISO image from the ISO image repositories every time. = That will be helpful for people who is suffered from the network bottleneck. > >> >> [1] http://httpfs.sourceforge.net/ >> >>> >>> >>> Mark. >>> >>> [1] http://gerrit.ovirt.org/#/c/12687/ >>> [2] http://gerrit.ovirt.org/#/c/12916/ >>> >>> _______________________________________________ >>> Engine-devel mailing list >>> Engine-devel(a)ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>> >> > > > _______________________________________________ > Engine-devel mailing list > Engine-devel(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > -- = --- =E8=88=92=E6=98=8E Shu Ming Open Virtualization Engineerning; CSTL, IBM Corp. Tel: 86-10-82451626 Tieline: 9051626 E-mail: shuming(a)cn.ibm.com or shumi= ng(a)linux.vnet.ibm.com Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District, B= eijing 100193, PRC --===============8760025910026227707==-- From wudxw at linux.vnet.ibm.com Mon Mar 18 04:36:56 2013 Content-Type: multipart/mixed; boundary="===============8136993221343815966==" MIME-Version: 1.0 From: Mark Wu To: devel at ovirt.org Subject: Re: [Engine-devel] Proposal for support ISO domain on other types of file based storage. Date: Mon, 18 Mar 2013 16:36:44 +0800 Message-ID: <5146D21C.3050300@linux.vnet.ibm.com> In-Reply-To: 411572396.9297119.1363589463150.JavaMail.root@redhat.com --===============8136993221343815966== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On 03/18/2013 02:51 PM, Ayal Baron wrote: > > ----- Original Message ----- >> On Sun 17 Mar 2013 10:12:55 PM CST, Ayal Baron wrote: >>> >>> ----- Original Message ----- >>>> Hi guys, >>>> >>>> Currently, ISO domain is only supported on NFS storage. It could >>>> improve the ease of use if it allows other types >>>> of file based storage to store ISO images. After an investigation, >>>> I >>>> found there's not any restriction on this idea. >>>> So the whole work is removing the limitation on engine side. That >>>> means engine should allow ISO domain could >>>> have different storage type from the data center it's attached, >>>> like >>>> what we do with nfs ISO domain in SAN DC. >>>> >>>> I start this idea with localfs. I know local storage can't be seen >>>> in >>>> cluster level. But it also provides a choice if no >>>> NFS available. VMs can be created on the host which has the ISO >>>> repo, >>>> and then be migrated to any other host in the cluster. >>>> I have done the initial patches: allow creation ISO domain on >>>> localfs >>>> [1] and support import ISO domain on localfs [2] >>>> I don't have much experience in java/j2ee/web development and >>>> engine >>>> architecture. The patches just work for me. >>>> I am not sure if it will bring some potential problems. So any >>>> feedback on the patch or the idea will be appreciated very much. >>> Haven't looked at the patches yet, but wrt the idea, I agree on the >>> need (being able to attach ISOs from anywhere and not just nfs) >>> but I think the way to do this should be by getting rid of the ISO >>> domain type altogether. >> I think ISO domain on localfs is useful for a simple setup or demo, >> such as oVirt all-in-one. > As I said above, I totally agree that we need to be able to attach ISOs o= n local host, what I'm saying is that we don't need a local ISO *domain*. = All we need is the ability to list the content of a directory on the local = host (to be able to choose the ISO) and attach it to the VM. Since the att= ach part already exists then the gap is just the listing issue. Got it. Thanks for your explanation! > >>> Basically what we need is: >>> 1. a way to connect to file based storage (let's leave block aside >>> for now) - this already exists via the connectStorageServer verb >>> 2. a way to list and present a file system tree in gui (give an >>> arbitrary path to vdsm and list content) and possibly filter >>> results by type (vfd, iso) - does not exist today. Possibly some >>> security aspects here that need hashing out. >>> 3. a way to specify a path to a file when attaching an iso/vfd to a >>> VM - this is the way it works today >>> >>> This would devoid the need for isoUploader and allow users to >>> simply manage an nfs export with files. >>> Next step would be to make connectStorageServer support httpfs [1] >>> and then we'd be able to mount ISOs directly over http (hopefully >>> this would be sufficient to support ISOs stored on S3, swift, >>> glance, etc). >> Actually, we could use the qemu curl backend image support directly. >> That means we don't need mount the place storing ISO images. We can >> just maintain a list of ISO image with its link, which could be http, >> ftp and ssh. > even better! > >>> [1] http://httpfs.sourceforge.net/ >>> >>>> >>>> Mark. >>>> >>>> [1] http://gerrit.ovirt.org/#/c/12687/ >>>> [2] http://gerrit.ovirt.org/#/c/12916/ >>>> >>>> _______________________________________________ >>>> Engine-devel mailing list >>>> Engine-devel(a)ovirt.org >>>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>>> >> >> --===============8136993221343815966==-- From abaron at redhat.com Mon Mar 18 04:44:51 2013 Content-Type: multipart/mixed; boundary="===============1773471248369523589==" MIME-Version: 1.0 From: Ayal Baron To: devel at ovirt.org Subject: Re: [Engine-devel] Proposal for support ISO domain on other types of file based storage. Date: Mon, 18 Mar 2013 04:43:08 -0400 Message-ID: <1599625604.9482831.1363596188030.JavaMail.root@redhat.com> In-Reply-To: 5146BE18.2000306@linux.vnet.ibm.com --===============1773471248369523589== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable ----- Original Message ----- > Mark Wu : > > On Sun 17 Mar 2013 10:12:55 PM CST, Ayal Baron wrote: > >> > >> > >> ----- Original Message ----- > >>> > >>> Hi guys, > >>> > >>> Currently, ISO domain is only supported on NFS storage. It could > >>> improve the ease of use if it allows other types > >>> of file based storage to store ISO images. After an > >>> investigation, I > >>> found there's not any restriction on this idea. > >>> So the whole work is removing the limitation on engine side. That > >>> means engine should allow ISO domain could > >>> have different storage type from the data center it's attached, > >>> like > >>> what we do with nfs ISO domain in SAN DC. > >>> > >>> I start this idea with localfs. I know local storage can't be > >>> seen in > >>> cluster level. But it also provides a choice if no > >>> NFS available. VMs can be created on the host which has the ISO > >>> repo, > >>> and then be migrated to any other host in the cluster. > >>> I have done the initial patches: allow creation ISO domain on > >>> localfs > >>> [1] and support import ISO domain on localfs [2] > >>> I don't have much experience in java/j2ee/web development and > >>> engine > >>> architecture. The patches just work for me. > >>> I am not sure if it will bring some potential problems. So any > >>> feedback on the patch or the idea will be appreciated very much. > >> > >> Haven't looked at the patches yet, but wrt the idea, I agree on > >> the > >> need (being able to attach ISOs from anywhere and not just nfs) > >> but I > >> think the way to do this should be by getting rid of the ISO > >> domain > >> type altogether. > > > > I think ISO domain on localfs is useful for a simple setup or demo, > > such as oVirt all-in-one. > > > >> Basically what we need is: > >> 1. a way to connect to file based storage (let's leave block aside > >> for now) - this already exists via the connectStorageServer verb > >> 2. a way to list and present a file system tree in gui (give an > >> arbitrary path to vdsm and list content) and possibly filter > >> results > >> by type (vfd, iso) - does not exist today. Possibly some security > >> aspects here that need hashing out. > >> 3. a way to specify a path to a file when attaching an iso/vfd to > >> a > >> VM - this is the way it works today > >> > >> This would devoid the need for isoUploader and allow users to > >> simply > >> manage an nfs export with files. > >> Next step would be to make connectStorageServer support httpfs [1] > >> and then we'd be able to mount ISOs directly over http (hopefully > >> this would be sufficient to support ISOs stored on S3, swift, > >> glance, > >> etc). > > > > Actually, we could use the qemu curl backend image support > > directly. > > That means we don't need mount the place storing ISO images. We can > > just maintain a list of ISO image with its link, which could be > > http, > > ftp and ssh. > = > That will be fine to start a VM on a existing extern ISO image. I > also > would like to maintain a ISO image cache on the local host to avoid > to > re-streaming the ISO image from the ISO image repositories every > time. > That will be helpful for people who is suffered from the network > bottleneck. We have a similar requirement for glance support (not limited to ISOs, rath= er to all read-only images) so that should be tackled with a broader soluti= on. > = > > > >> > >> [1] http://httpfs.sourceforge.net/ > >> > >>> > >>> > >>> Mark. > >>> > >>> [1] http://gerrit.ovirt.org/#/c/12687/ > >>> [2] http://gerrit.ovirt.org/#/c/12916/ > >>> > >>> _______________________________________________ > >>> Engine-devel mailing list > >>> Engine-devel(a)ovirt.org > >>> http://lists.ovirt.org/mailman/listinfo/engine-devel > >>> > >> > > > > > > _______________________________________________ > > Engine-devel mailing list > > Engine-devel(a)ovirt.org > > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > = > = > -- > --- > =E8=88=92=E6=98=8E Shu Ming > Open Virtualization Engineerning; CSTL, IBM Corp. > Tel: 86-10-82451626 Tieline: 9051626 E-mail: shuming(a)cn.ibm.com or > shuming(a)linux.vnet.ibm.com > Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian > District, Beijing 100193, PRC > = > = >=20 --===============1773471248369523589==-- From wudxw at linux.vnet.ibm.com Mon Mar 18 04:47:49 2013 Content-Type: multipart/mixed; boundary="===============4987556704115565225==" MIME-Version: 1.0 From: Mark Wu To: devel at ovirt.org Subject: Re: [Engine-devel] Proposal for support ISO domain on other types of file based storage. Date: Mon, 18 Mar 2013 16:47:43 +0800 Message-ID: <5146D4AF.2080505@linux.vnet.ibm.com> In-Reply-To: 5146BE18.2000306@linux.vnet.ibm.com --===============4987556704115565225== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On 03/18/2013 03:11 PM, Shu Ming wrote: > Mark Wu : >> On Sun 17 Mar 2013 10:12:55 PM CST, Ayal Baron wrote: >>> >>> >>> ----- Original Message ----- >>>> >>>> Hi guys, >>>> >>>> Currently, ISO domain is only supported on NFS storage. It could >>>> improve the ease of use if it allows other types >>>> of file based storage to store ISO images. After an investigation, I >>>> found there's not any restriction on this idea. >>>> So the whole work is removing the limitation on engine side. That >>>> means engine should allow ISO domain could >>>> have different storage type from the data center it's attached, like >>>> what we do with nfs ISO domain in SAN DC. >>>> >>>> I start this idea with localfs. I know local storage can't be seen in >>>> cluster level. But it also provides a choice if no >>>> NFS available. VMs can be created on the host which has the ISO repo, >>>> and then be migrated to any other host in the cluster. >>>> I have done the initial patches: allow creation ISO domain on localfs >>>> [1] and support import ISO domain on localfs [2] >>>> I don't have much experience in java/j2ee/web development and engine >>>> architecture. The patches just work for me. >>>> I am not sure if it will bring some potential problems. So any >>>> feedback on the patch or the idea will be appreciated very much. >>> >>> Haven't looked at the patches yet, but wrt the idea, I agree on the = >>> need (being able to attach ISOs from anywhere and not just nfs) but = >>> I think the way to do this should be by getting rid of the ISO = >>> domain type altogether. >> >> I think ISO domain on localfs is useful for a simple setup or demo, = >> such as oVirt all-in-one. >> >>> Basically what we need is: >>> 1. a way to connect to file based storage (let's leave block aside = >>> for now) - this already exists via the connectStorageServer verb >>> 2. a way to list and present a file system tree in gui (give an = >>> arbitrary path to vdsm and list content) and possibly filter results = >>> by type (vfd, iso) - does not exist today. Possibly some security = >>> aspects here that need hashing out. >>> 3. a way to specify a path to a file when attaching an iso/vfd to a = >>> VM - this is the way it works today >>> >>> This would devoid the need for isoUploader and allow users to simply = >>> manage an nfs export with files. >>> Next step would be to make connectStorageServer support httpfs [1] = >>> and then we'd be able to mount ISOs directly over http (hopefully = >>> this would be sufficient to support ISOs stored on S3, swift, = >>> glance, etc). >> >> Actually, we could use the qemu curl backend image support directly. = >> That means we don't need mount the place storing ISO images. We can = >> just maintain a list of ISO image with its link, which could be http, = >> ftp and ssh. > > That will be fine to start a VM on a existing extern ISO image. I also = > would like to maintain a ISO image cache on the local host to avoid to = > re-streaming the ISO image from the ISO image repositories every time. = > That will be helpful for people who is suffered from the network = > bottleneck. I think this problem could be avoided by using VM template. It will = significantly reduce the number of access on remote ISO images. > >> >>> >>> [1] http://httpfs.sourceforge.net/ >>> >>>> >>>> >>>> Mark. >>>> >>>> [1] http://gerrit.ovirt.org/#/c/12687/ >>>> [2] http://gerrit.ovirt.org/#/c/12916/ >>>> >>>> _______________________________________________ >>>> Engine-devel mailing list >>>> Engine-devel(a)ovirt.org >>>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>>> >>> >> >> >> _______________________________________________ >> Engine-devel mailing list >> Engine-devel(a)ovirt.org >> http://lists.ovirt.org/mailman/listinfo/engine-devel >> > > --===============4987556704115565225==-- From wudxw at linux.vnet.ibm.com Mon Mar 18 05:15:16 2013 Content-Type: multipart/mixed; boundary="===============5973011299248973153==" MIME-Version: 1.0 From: Mark Wu To: devel at ovirt.org Subject: Re: [Engine-devel] Proposal for support ISO domain on other types of file based storage. Date: Mon, 18 Mar 2013 17:14:42 +0800 Message-ID: <5146DB02.2030006@linux.vnet.ibm.com> In-Reply-To: 1599625604.9482831.1363596188030.JavaMail.root@redhat.com --===============5973011299248973153== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable This is a multi-part message in MIME format. --------------090705080902000503070107 Content-Type: text/plain; charset=3DUTF-8; format=3Dflowed Content-Transfer-Encoding: 8bit On 03/18/2013 04:43 PM, Ayal Baron wrote: > > ----- Original Message ----- >> Mark Wu : >>> On Sun 17 Mar 2013 10:12:55 PM CST, Ayal Baron wrote: >>>> >>>> ----- Original Message ----- >>>>> Hi guys, >>>>> >>>>> Currently, ISO domain is only supported on NFS storage. It could >>>>> improve the ease of use if it allows other types >>>>> of file based storage to store ISO images. After an >>>>> investigation, I >>>>> found there's not any restriction on this idea. >>>>> So the whole work is removing the limitation on engine side. That >>>>> means engine should allow ISO domain could >>>>> have different storage type from the data center it's attached, >>>>> like >>>>> what we do with nfs ISO domain in SAN DC. >>>>> >>>>> I start this idea with localfs. I know local storage can't be >>>>> seen in >>>>> cluster level. But it also provides a choice if no >>>>> NFS available. VMs can be created on the host which has the ISO >>>>> repo, >>>>> and then be migrated to any other host in the cluster. >>>>> I have done the initial patches: allow creation ISO domain on >>>>> localfs >>>>> [1] and support import ISO domain on localfs [2] >>>>> I don't have much experience in java/j2ee/web development and >>>>> engine >>>>> architecture. The patches just work for me. >>>>> I am not sure if it will bring some potential problems. So any >>>>> feedback on the patch or the idea will be appreciated very much. >>>> Haven't looked at the patches yet, but wrt the idea, I agree on >>>> the >>>> need (being able to attach ISOs from anywhere and not just nfs) >>>> but I >>>> think the way to do this should be by getting rid of the ISO >>>> domain >>>> type altogether. >>> I think ISO domain on localfs is useful for a simple setup or demo, >>> such as oVirt all-in-one. >>> >>>> Basically what we need is: >>>> 1. a way to connect to file based storage (let's leave block aside >>>> for now) - this already exists via the connectStorageServer verb >>>> 2. a way to list and present a file system tree in gui (give an >>>> arbitrary path to vdsm and list content) and possibly filter >>>> results >>>> by type (vfd, iso) - does not exist today. Possibly some security >>>> aspects here that need hashing out. >>>> 3. a way to specify a path to a file when attaching an iso/vfd to >>>> a >>>> VM - this is the way it works today >>>> >>>> This would devoid the need for isoUploader and allow users to >>>> simply >>>> manage an nfs export with files. >>>> Next step would be to make connectStorageServer support httpfs [1] >>>> and then we'd be able to mount ISOs directly over http (hopefully >>>> this would be sufficient to support ISOs stored on S3, swift, >>>> glance, >>>> etc). >>> Actually, we could use the qemu curl backend image support >>> directly. >>> That means we don't need mount the place storing ISO images. We can >>> just maintain a list of ISO image with its link, which could be >>> http, >>> ftp and ssh. >> That will be fine to start a VM on a existing extern ISO image. I >> also >> would like to maintain a ISO image cache on the local host to avoid >> to >> re-streaming the ISO image from the ISO image repositories every >> time. >> That will be helpful for people who is suffered from the network >> bottleneck. > We have a similar requirement for glance support (not limited to ISOs, ra= ther to all read-only images) so that should be tackled with a broader solu= tion. In that case, I suppose qemu's copy-on-read + httpfs (you mentioned = above) could help. It can avoid accessing the same backing file sectors = repeatedly. But the copied content can't be shared by multiple VM using the same = backend image. > >>>> [1] http://httpfs.sourceforge.net/ >>>> >>>>> >>>>> Mark. >>>>> >>>>> [1] http://gerrit.ovirt.org/#/c/12687/ >>>>> [2] http://gerrit.ovirt.org/#/c/12916/ >>>>> >>>>> _______________________________________________ >>>>> Engine-devel mailing list >>>>> Engine-devel(a)ovirt.org >>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>>>> >>> >>> _______________________________________________ >>> Engine-devel mailing list >>> Engine-devel(a)ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>> >> >> -- >> --- >> =E8=88=92=E6=98=8E Shu Ming >> Open Virtualization Engineerning; CSTL, IBM Corp. >> Tel: 86-10-82451626 Tieline: 9051626 E-mail: shuming(a)cn.ibm.com or >> shuming(a)linux.vnet.ibm.com >> Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian >> District, Beijing 100193, PRC >> >> >> --------------090705080902000503070107 Content-Type: text/html; charset=3DUTF-8 Content-Transfer-Encoding: 8bit

On 03/18/2013 04:43 PM, Ayal Baron wrote:


----- Original Message -----

Mark Wu :

On Sun 17 Mar 2013 10:12:55 PM CST, Ayal Baron wro=
te:


----- Original Message -----

Hi guys,

Currently, ISO domain is only supported on NFS storage. It could
improve the ease of use if it allows other types
of file based storage to store ISO images. After an
investigation, I
found there's not any restriction on this idea.
So the whole work is removing the limitation on engine side. That
means engine should allow ISO domain could
have different storage type from the data center it's attached,
like
what we do with nfs ISO domain in SAN DC.

I start this idea with localfs. I know local storage can't be
seen in
cluster level. But it also provides a choice if no
NFS available. VMs can be created on the host which has the ISO
repo,
and then be migrated to any other host in the cluster.
I have done the initial patches: allow creation ISO domain on
localfs
[1] and support import ISO domain on localfs [2]
I don't have much experience in java/j2ee/web development and
engine
architecture. The patches just work for me.
I am not sure if it will bring some potential problems. So any
feedback on the patch or the idea will be appreciated very much.

Haven't looked at the patches yet, but wrt the idea, I agree on
the
need (being able to attach ISOs from anywhere and not just nfs)
but I
think the way to do this should be by getting rid of the ISO
domain
type altogether.

I think ISO domain on localfs is useful for a simple setup or demo,
such as oVirt all-in-one.

Basically what we need is:
1. a way to connect to file based storage (let's leave block aside
for now) - this already exists via the connectStorageServer verb
2. a way to list and present a file system tree in gui (give an
arbitrary path to vdsm and list content) and possibly filter
results
by type (vfd, iso) - does not exist today. Possibly some security
aspects here that need hashing out.
3. a way to specify a path to a file when attaching an iso/vfd to
a
VM - this is the way it works today

This would devoid the need for isoUploader and allow users to
simply
manage an nfs export with files.
Next step would be to make connectStorageServer support httpfs [1]
and then we'd be able to mount ISOs directly over http (hopefully
this would be sufficient to support ISOs stored on S3, swift,
glance,
etc).

Actually, we could use the qemu curl backend image support
directly.
That means we don't need mount the place storing ISO images. We can
just maintain a list of ISO image with its link, which could be
http,
ftp and ssh.

That will be fine to start a VM on a existing extern ISO image. I
also
would like to maintain a ISO image cache on the local host to avoid
to
re-streaming the ISO image from the ISO image repositories every
time.
That will be helpful for people who is suffered from the network
bottleneck.

We have a similar requirement for glance support (not limited to ISOs, rath=
er to all read-only images) so that should be tackled with a broader soluti=
on.

In that case,=C2=A0 I suppose qemu's copy-on-read + httpfs (you mention= ed above) could help.=C2=A0 It can avoid accessing the same backing file sectors repeatedly.
But the copied content can't be shared by multiple VM using the same backend image.

[1] http://httpfs.sourceforge.net/


Mark.

[1] http://gerrit.ovirt.org/#/c/12687/
[2] http://gerrit.ovirt.org/#/c/12916/

_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel<=
/a>


_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel<=
/a>


--
---
=E8=88=92=E6=98=8E Shu Ming
Open Virtualization Engineerning; CSTL, IBM Corp.
Tel: 86-10-82451626  Tieline: 9051626 E-mail: shuming(a)cn.ibm.com or
shuming(a)linux.vnet.ibm.com
Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian
District, Beijing 100193, PRC

--------------090705080902000503070107-- --===============5973011299248973153== Content-Type: multipart/alternative MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="attachment.bin" VGhpcyBpcyBhIG11bHRpLXBhcnQgbWVzc2FnZSBpbiBNSU1FIGZvcm1hdC4KLS0tLS0tLS0tLS0t LS0wOTA3MDUwODA5MDIwMDA1MDMwNzAxMDcKQ29udGVudC1UeXBlOiB0ZXh0L3BsYWluOyBjaGFy c2V0PVVURi04OyBmb3JtYXQ9Zmxvd2VkCkNvbnRlbnQtVHJhbnNmZXItRW5jb2Rpbmc6IDhiaXQK Ck9uIDAzLzE4LzIwMTMgMDQ6NDMgUE0sIEF5YWwgQmFyb24gd3JvdGU6Cj4KPiAtLS0tLSBPcmln aW5hbCBNZXNzYWdlIC0tLS0tCj4+IE1hcmsgV3UgOgo+Pj4gT24gU3VuIDE3IE1hciAyMDEzIDEw OjEyOjU1IFBNIENTVCwgQXlhbCBCYXJvbiB3cm90ZToKPj4+Pgo+Pj4+IC0tLS0tIE9yaWdpbmFs IE1lc3NhZ2UgLS0tLS0KPj4+Pj4gSGkgZ3V5cywKPj4+Pj4KPj4+Pj4gQ3VycmVudGx5LCBJU08g ZG9tYWluIGlzIG9ubHkgc3VwcG9ydGVkIG9uIE5GUyBzdG9yYWdlLiBJdCBjb3VsZAo+Pj4+PiBp bXByb3ZlIHRoZSBlYXNlIG9mIHVzZSBpZiBpdCBhbGxvd3Mgb3RoZXIgdHlwZXMKPj4+Pj4gb2Yg ZmlsZSBiYXNlZCBzdG9yYWdlIHRvIHN0b3JlIElTTyBpbWFnZXMuIEFmdGVyIGFuCj4+Pj4+IGlu dmVzdGlnYXRpb24sIEkKPj4+Pj4gZm91bmQgdGhlcmUncyBub3QgYW55IHJlc3RyaWN0aW9uIG9u IHRoaXMgaWRlYS4KPj4+Pj4gU28gdGhlIHdob2xlIHdvcmsgaXMgcmVtb3ZpbmcgdGhlIGxpbWl0 YXRpb24gb24gZW5naW5lIHNpZGUuIFRoYXQKPj4+Pj4gbWVhbnMgZW5naW5lIHNob3VsZCBhbGxv dyBJU08gZG9tYWluIGNvdWxkCj4+Pj4+IGhhdmUgZGlmZmVyZW50IHN0b3JhZ2UgdHlwZSBmcm9t IHRoZSBkYXRhIGNlbnRlciBpdCdzIGF0dGFjaGVkLAo+Pj4+PiBsaWtlCj4+Pj4+IHdoYXQgd2Ug ZG8gd2l0aCBuZnMgSVNPIGRvbWFpbiBpbiBTQU4gREMuCj4+Pj4+Cj4+Pj4+IEkgc3RhcnQgdGhp cyBpZGVhIHdpdGggbG9jYWxmcy4gSSBrbm93IGxvY2FsIHN0b3JhZ2UgY2FuJ3QgYmUKPj4+Pj4g c2VlbiBpbgo+Pj4+PiBjbHVzdGVyIGxldmVsLiBCdXQgaXQgYWxzbyBwcm92aWRlcyBhIGNob2lj ZSBpZiBubwo+Pj4+PiBORlMgYXZhaWxhYmxlLiBWTXMgY2FuIGJlIGNyZWF0ZWQgb24gdGhlIGhv c3Qgd2hpY2ggaGFzIHRoZSBJU08KPj4+Pj4gcmVwbywKPj4+Pj4gYW5kIHRoZW4gYmUgbWlncmF0 ZWQgdG8gYW55IG90aGVyIGhvc3QgaW4gdGhlIGNsdXN0ZXIuCj4+Pj4+IEkgaGF2ZSBkb25lIHRo ZSBpbml0aWFsIHBhdGNoZXM6IGFsbG93IGNyZWF0aW9uIElTTyBkb21haW4gb24KPj4+Pj4gbG9j YWxmcwo+Pj4+PiBbMV0gYW5kIHN1cHBvcnQgaW1wb3J0IElTTyBkb21haW4gb24gbG9jYWxmcyBb Ml0KPj4+Pj4gSSBkb24ndCBoYXZlIG11Y2ggZXhwZXJpZW5jZSBpbiBqYXZhL2oyZWUvd2ViIGRl dmVsb3BtZW50IGFuZAo+Pj4+PiBlbmdpbmUKPj4+Pj4gYXJjaGl0ZWN0dXJlLiBUaGUgcGF0Y2hl cyBqdXN0IHdvcmsgZm9yIG1lLgo+Pj4+PiBJIGFtIG5vdCBzdXJlIGlmIGl0IHdpbGwgYnJpbmcg c29tZSBwb3RlbnRpYWwgcHJvYmxlbXMuIFNvIGFueQo+Pj4+PiBmZWVkYmFjayBvbiB0aGUgcGF0 Y2ggb3IgdGhlIGlkZWEgd2lsbCBiZSBhcHByZWNpYXRlZCB2ZXJ5IG11Y2guCj4+Pj4gSGF2ZW4n dCBsb29rZWQgYXQgdGhlIHBhdGNoZXMgeWV0LCBidXQgd3J0IHRoZSBpZGVhLCBJIGFncmVlIG9u Cj4+Pj4gdGhlCj4+Pj4gbmVlZCAoYmVpbmcgYWJsZSB0byBhdHRhY2ggSVNPcyBmcm9tIGFueXdo ZXJlIGFuZCBub3QganVzdCBuZnMpCj4+Pj4gYnV0IEkKPj4+PiB0aGluayB0aGUgd2F5IHRvIGRv IHRoaXMgc2hvdWxkIGJlIGJ5IGdldHRpbmcgcmlkIG9mIHRoZSBJU08KPj4+PiBkb21haW4KPj4+ PiB0eXBlIGFsdG9nZXRoZXIuCj4+PiBJIHRoaW5rIElTTyBkb21haW4gb24gbG9jYWxmcyBpcyB1 c2VmdWwgZm9yIGEgc2ltcGxlIHNldHVwIG9yIGRlbW8sCj4+PiBzdWNoIGFzIG9WaXJ0IGFsbC1p bi1vbmUuCj4+Pgo+Pj4+IEJhc2ljYWxseSB3aGF0IHdlIG5lZWQgaXM6Cj4+Pj4gMS4gYSB3YXkg dG8gY29ubmVjdCB0byBmaWxlIGJhc2VkIHN0b3JhZ2UgKGxldCdzIGxlYXZlIGJsb2NrIGFzaWRl Cj4+Pj4gZm9yIG5vdykgLSB0aGlzIGFscmVhZHkgZXhpc3RzIHZpYSB0aGUgY29ubmVjdFN0b3Jh Z2VTZXJ2ZXIgdmVyYgo+Pj4+IDIuIGEgd2F5IHRvIGxpc3QgYW5kIHByZXNlbnQgYSBmaWxlIHN5 c3RlbSB0cmVlIGluIGd1aSAoZ2l2ZSBhbgo+Pj4+IGFyYml0cmFyeSBwYXRoIHRvIHZkc20gYW5k IGxpc3QgY29udGVudCkgYW5kIHBvc3NpYmx5IGZpbHRlcgo+Pj4+IHJlc3VsdHMKPj4+PiBieSB0 eXBlICh2ZmQsIGlzbykgLSBkb2VzIG5vdCBleGlzdCB0b2RheS4gUG9zc2libHkgc29tZSBzZWN1 cml0eQo+Pj4+IGFzcGVjdHMgaGVyZSB0aGF0IG5lZWQgaGFzaGluZyBvdXQuCj4+Pj4gMy4gYSB3 YXkgdG8gc3BlY2lmeSBhIHBhdGggdG8gYSBmaWxlIHdoZW4gYXR0YWNoaW5nIGFuIGlzby92ZmQg dG8KPj4+PiBhCj4+Pj4gVk0gLSB0aGlzIGlzIHRoZSB3YXkgaXQgd29ya3MgdG9kYXkKPj4+Pgo+ Pj4+IFRoaXMgd291bGQgZGV2b2lkIHRoZSBuZWVkIGZvciBpc29VcGxvYWRlciBhbmQgYWxsb3cg dXNlcnMgdG8KPj4+PiBzaW1wbHkKPj4+PiBtYW5hZ2UgYW4gbmZzIGV4cG9ydCB3aXRoIGZpbGVz Lgo+Pj4+IE5leHQgc3RlcCB3b3VsZCBiZSB0byBtYWtlIGNvbm5lY3RTdG9yYWdlU2VydmVyIHN1 cHBvcnQgaHR0cGZzIFsxXQo+Pj4+IGFuZCB0aGVuIHdlJ2QgYmUgYWJsZSB0byBtb3VudCBJU09z IGRpcmVjdGx5IG92ZXIgaHR0cCAoaG9wZWZ1bGx5Cj4+Pj4gdGhpcyB3b3VsZCBiZSBzdWZmaWNp ZW50IHRvIHN1cHBvcnQgSVNPcyBzdG9yZWQgb24gUzMsIHN3aWZ0LAo+Pj4+IGdsYW5jZSwKPj4+ PiBldGMpLgo+Pj4gQWN0dWFsbHksIHdlIGNvdWxkIHVzZSB0aGUgcWVtdSBjdXJsIGJhY2tlbmQg aW1hZ2Ugc3VwcG9ydAo+Pj4gZGlyZWN0bHkuCj4+PiBUaGF0IG1lYW5zIHdlIGRvbid0IG5lZWQg bW91bnQgdGhlIHBsYWNlIHN0b3JpbmcgSVNPIGltYWdlcy4gV2UgY2FuCj4+PiBqdXN0IG1haW50 YWluIGEgbGlzdCBvZiBJU08gaW1hZ2Ugd2l0aCBpdHMgbGluaywgd2hpY2ggY291bGQgYmUKPj4+ IGh0dHAsCj4+PiBmdHAgYW5kIHNzaC4KPj4gVGhhdCB3aWxsIGJlIGZpbmUgdG8gc3RhcnQgYSBW TSBvbiBhIGV4aXN0aW5nIGV4dGVybiBJU08gaW1hZ2UuIEkKPj4gYWxzbwo+PiB3b3VsZCBsaWtl IHRvIG1haW50YWluIGEgSVNPIGltYWdlIGNhY2hlIG9uIHRoZSBsb2NhbCBob3N0IHRvIGF2b2lk Cj4+IHRvCj4+IHJlLXN0cmVhbWluZyB0aGUgSVNPIGltYWdlIGZyb20gdGhlIElTTyBpbWFnZSBy ZXBvc2l0b3JpZXMgZXZlcnkKPj4gdGltZS4KPj4gVGhhdCB3aWxsIGJlIGhlbHBmdWwgZm9yIHBl b3BsZSB3aG8gaXMgc3VmZmVyZWQgZnJvbSB0aGUgbmV0d29yawo+PiBib3R0bGVuZWNrLgo+IFdl IGhhdmUgYSBzaW1pbGFyIHJlcXVpcmVtZW50IGZvciBnbGFuY2Ugc3VwcG9ydCAobm90IGxpbWl0 ZWQgdG8gSVNPcywgcmF0aGVyIHRvIGFsbCByZWFkLW9ubHkgaW1hZ2VzKSBzbyB0aGF0IHNob3Vs ZCBiZSB0YWNrbGVkIHdpdGggYSBicm9hZGVyIHNvbHV0aW9uLgpJbiB0aGF0IGNhc2UsICBJIHN1 cHBvc2UgcWVtdSdzIGNvcHktb24tcmVhZCArIGh0dHBmcyAoeW91IG1lbnRpb25lZCAKYWJvdmUp IGNvdWxkIGhlbHAuICBJdCBjYW4gYXZvaWQgYWNjZXNzaW5nIHRoZSBzYW1lIGJhY2tpbmcgZmls ZSBzZWN0b3JzIApyZXBlYXRlZGx5LgpCdXQgdGhlIGNvcGllZCBjb250ZW50IGNhbid0IGJlIHNo YXJlZCBieSBtdWx0aXBsZSBWTSB1c2luZyB0aGUgc2FtZSAKYmFja2VuZCBpbWFnZS4KCj4KPj4+ PiBbMV0gaHR0cDovL2h0dHBmcy5zb3VyY2Vmb3JnZS5uZXQvCj4+Pj4KPj4+Pj4KPj4+Pj4gTWFy ay4KPj4+Pj4KPj4+Pj4gWzFdIGh0dHA6Ly9nZXJyaXQub3ZpcnQub3JnLyMvYy8xMjY4Ny8KPj4+ Pj4gWzJdIGh0dHA6Ly9nZXJyaXQub3ZpcnQub3JnLyMvYy8xMjkxNi8KPj4+Pj4KPj4+Pj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPj4+Pj4gRW5naW5l LWRldmVsIG1haWxpbmcgbGlzdAo+Pj4+PiBFbmdpbmUtZGV2ZWxAb3ZpcnQub3JnCj4+Pj4+IGh0 dHA6Ly9saXN0cy5vdmlydC5vcmcvbWFpbG1hbi9saXN0aW5mby9lbmdpbmUtZGV2ZWwKPj4+Pj4K Pj4+Cj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+ Pj4gRW5naW5lLWRldmVsIG1haWxpbmcgbGlzdAo+Pj4gRW5naW5lLWRldmVsQG92aXJ0Lm9yZwo+ Pj4gaHR0cDovL2xpc3RzLm92aXJ0Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2VuZ2luZS1kZXZlbAo+ Pj4KPj4KPj4gLS0KPj4gLS0tCj4+IOiIkuaYjiBTaHUgTWluZwo+PiBPcGVuIFZpcnR1YWxpemF0 aW9uIEVuZ2luZWVybmluZzsgQ1NUTCwgSUJNIENvcnAuCj4+IFRlbDogODYtMTAtODI0NTE2MjYg IFRpZWxpbmU6IDkwNTE2MjYgRS1tYWlsOiBzaHVtaW5nQGNuLmlibS5jb20gb3IKPj4gc2h1bWlu Z0BsaW51eC52bmV0LmlibS5jb20KPj4gQWRkcmVzczogMy9GIFJpbmcgQnVpbGRpbmcsIFpob25n R3VhbkN1biBTb2Z0d2FyZSBQYXJrLCBIYWlkaWFuCj4+IERpc3RyaWN0LCBCZWlqaW5nIDEwMDE5 MywgUFJDCj4+Cj4+Cj4+CgoKLS0tLS0tLS0tLS0tLS0wOTA3MDUwODA5MDIwMDA1MDMwNzAxMDcK Q29udGVudC1UeXBlOiB0ZXh0L2h0bWw7IGNoYXJzZXQ9VVRGLTgKQ29udGVudC1UcmFuc2Zlci1F bmNvZGluZzogOGJpdAoKPGh0bWw+CiAgPGhlYWQ+CiAgICA8bWV0YSBjb250ZW50PSJ0ZXh0L2h0 bWw7IGNoYXJzZXQ9VVRGLTgiIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSI+CiAgPC9oZWFkPgog IDxib2R5IGJnY29sb3I9IiNGRkZGRkYiIHRleHQ9IiMwMDAwMDAiPgogICAgPGRpdiBjbGFzcz0i bW96LWNpdGUtcHJlZml4Ij5PbiAwMy8xOC8yMDEzIDA0OjQzIFBNLCBBeWFsIEJhcm9uCiAgICAg IHdyb3RlOjxicj4KICAgIDwvZGl2PgogICAgPGJsb2NrcXVvdGUKICAgICAgY2l0ZT0ibWlkOjE1 OTk2MjU2MDQuOTQ4MjgzMS4xMzYzNTk2MTg4MDMwLkphdmFNYWlsLnJvb3RAcmVkaGF0LmNvbSIK ICAgICAgdHlwZT0iY2l0ZSI+CiAgICAgIDxwcmUgd3JhcD0iIj4KCi0tLS0tIE9yaWdpbmFsIE1l c3NhZ2UgLS0tLS0KPC9wcmU+CiAgICAgIDxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPgogICAgICAg IDxwcmUgd3JhcD0iIj5NYXJrIFd1IDoKPC9wcmU+CiAgICAgICAgPGJsb2NrcXVvdGUgdHlwZT0i Y2l0ZSI+CiAgICAgICAgICA8cHJlIHdyYXA9IiI+T24gU3VuIDE3IE1hciAyMDEzIDEwOjEyOjU1 IFBNIENTVCwgQXlhbCBCYXJvbiB3cm90ZToKPC9wcmU+CiAgICAgICAgICA8YmxvY2txdW90ZSB0 eXBlPSJjaXRlIj4KICAgICAgICAgICAgPHByZSB3cmFwPSIiPgoKLS0tLS0gT3JpZ2luYWwgTWVz c2FnZSAtLS0tLQo8L3ByZT4KICAgICAgICAgICAgPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+CiAg ICAgICAgICAgICAgPHByZSB3cmFwPSIiPgpIaSBndXlzLAoKQ3VycmVudGx5LCBJU08gZG9tYWlu IGlzIG9ubHkgc3VwcG9ydGVkIG9uIE5GUyBzdG9yYWdlLiBJdCBjb3VsZAppbXByb3ZlIHRoZSBl YXNlIG9mIHVzZSBpZiBpdCBhbGxvd3Mgb3RoZXIgdHlwZXMKb2YgZmlsZSBiYXNlZCBzdG9yYWdl IHRvIHN0b3JlIElTTyBpbWFnZXMuIEFmdGVyIGFuCmludmVzdGlnYXRpb24sIEkKZm91bmQgdGhl cmUncyBub3QgYW55IHJlc3RyaWN0aW9uIG9uIHRoaXMgaWRlYS4KU28gdGhlIHdob2xlIHdvcmsg aXMgcmVtb3ZpbmcgdGhlIGxpbWl0YXRpb24gb24gZW5naW5lIHNpZGUuIFRoYXQKbWVhbnMgZW5n aW5lIHNob3VsZCBhbGxvdyBJU08gZG9tYWluIGNvdWxkCmhhdmUgZGlmZmVyZW50IHN0b3JhZ2Ug dHlwZSBmcm9tIHRoZSBkYXRhIGNlbnRlciBpdCdzIGF0dGFjaGVkLApsaWtlCndoYXQgd2UgZG8g d2l0aCBuZnMgSVNPIGRvbWFpbiBpbiBTQU4gREMuCgpJIHN0YXJ0IHRoaXMgaWRlYSB3aXRoIGxv Y2FsZnMuIEkga25vdyBsb2NhbCBzdG9yYWdlIGNhbid0IGJlCnNlZW4gaW4KY2x1c3RlciBsZXZl bC4gQnV0IGl0IGFsc28gcHJvdmlkZXMgYSBjaG9pY2UgaWYgbm8KTkZTIGF2YWlsYWJsZS4gVk1z IGNhbiBiZSBjcmVhdGVkIG9uIHRoZSBob3N0IHdoaWNoIGhhcyB0aGUgSVNPCnJlcG8sCmFuZCB0 aGVuIGJlIG1pZ3JhdGVkIHRvIGFueSBvdGhlciBob3N0IGluIHRoZSBjbHVzdGVyLgpJIGhhdmUg ZG9uZSB0aGUgaW5pdGlhbCBwYXRjaGVzOiBhbGxvdyBjcmVhdGlvbiBJU08gZG9tYWluIG9uCmxv Y2FsZnMKWzFdIGFuZCBzdXBwb3J0IGltcG9ydCBJU08gZG9tYWluIG9uIGxvY2FsZnMgWzJdCkkg ZG9uJ3QgaGF2ZSBtdWNoIGV4cGVyaWVuY2UgaW4gamF2YS9qMmVlL3dlYiBkZXZlbG9wbWVudCBh bmQKZW5naW5lCmFyY2hpdGVjdHVyZS4gVGhlIHBhdGNoZXMganVzdCB3b3JrIGZvciBtZS4KSSBh bSBub3Qgc3VyZSBpZiBpdCB3aWxsIGJyaW5nIHNvbWUgcG90ZW50aWFsIHByb2JsZW1zLiBTbyBh bnkKZmVlZGJhY2sgb24gdGhlIHBhdGNoIG9yIHRoZSBpZGVhIHdpbGwgYmUgYXBwcmVjaWF0ZWQg dmVyeSBtdWNoLgo8L3ByZT4KICAgICAgICAgICAgPC9ibG9ja3F1b3RlPgogICAgICAgICAgICA8 cHJlIHdyYXA9IiI+CkhhdmVuJ3QgbG9va2VkIGF0IHRoZSBwYXRjaGVzIHlldCwgYnV0IHdydCB0 aGUgaWRlYSwgSSBhZ3JlZSBvbgp0aGUKbmVlZCAoYmVpbmcgYWJsZSB0byBhdHRhY2ggSVNPcyBm cm9tIGFueXdoZXJlIGFuZCBub3QganVzdCBuZnMpCmJ1dCBJCnRoaW5rIHRoZSB3YXkgdG8gZG8g dGhpcyBzaG91bGQgYmUgYnkgZ2V0dGluZyByaWQgb2YgdGhlIElTTwpkb21haW4KdHlwZSBhbHRv Z2V0aGVyLgo8L3ByZT4KICAgICAgICAgIDwvYmxvY2txdW90ZT4KICAgICAgICAgIDxwcmUgd3Jh cD0iIj4KSSB0aGluayBJU08gZG9tYWluIG9uIGxvY2FsZnMgaXMgdXNlZnVsIGZvciBhIHNpbXBs ZSBzZXR1cCBvciBkZW1vLApzdWNoIGFzIG9WaXJ0IGFsbC1pbi1vbmUuCgo8L3ByZT4KICAgICAg ICAgIDxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPgogICAgICAgICAgICA8cHJlIHdyYXA9IiI+QmFz aWNhbGx5IHdoYXQgd2UgbmVlZCBpczoKMS4gYSB3YXkgdG8gY29ubmVjdCB0byBmaWxlIGJhc2Vk IHN0b3JhZ2UgKGxldCdzIGxlYXZlIGJsb2NrIGFzaWRlCmZvciBub3cpIC0gdGhpcyBhbHJlYWR5 IGV4aXN0cyB2aWEgdGhlIGNvbm5lY3RTdG9yYWdlU2VydmVyIHZlcmIKMi4gYSB3YXkgdG8gbGlz dCBhbmQgcHJlc2VudCBhIGZpbGUgc3lzdGVtIHRyZWUgaW4gZ3VpIChnaXZlIGFuCmFyYml0cmFy eSBwYXRoIHRvIHZkc20gYW5kIGxpc3QgY29udGVudCkgYW5kIHBvc3NpYmx5IGZpbHRlcgpyZXN1 bHRzCmJ5IHR5cGUgKHZmZCwgaXNvKSAtIGRvZXMgbm90IGV4aXN0IHRvZGF5LiBQb3NzaWJseSBz b21lIHNlY3VyaXR5CmFzcGVjdHMgaGVyZSB0aGF0IG5lZWQgaGFzaGluZyBvdXQuCjMuIGEgd2F5 IHRvIHNwZWNpZnkgYSBwYXRoIHRvIGEgZmlsZSB3aGVuIGF0dGFjaGluZyBhbiBpc28vdmZkIHRv CmEKVk0gLSB0aGlzIGlzIHRoZSB3YXkgaXQgd29ya3MgdG9kYXkKClRoaXMgd291bGQgZGV2b2lk IHRoZSBuZWVkIGZvciBpc29VcGxvYWRlciBhbmQgYWxsb3cgdXNlcnMgdG8Kc2ltcGx5Cm1hbmFn ZSBhbiBuZnMgZXhwb3J0IHdpdGggZmlsZXMuCk5leHQgc3RlcCB3b3VsZCBiZSB0byBtYWtlIGNv bm5lY3RTdG9yYWdlU2VydmVyIHN1cHBvcnQgaHR0cGZzIFsxXQphbmQgdGhlbiB3ZSdkIGJlIGFi bGUgdG8gbW91bnQgSVNPcyBkaXJlY3RseSBvdmVyIGh0dHAgKGhvcGVmdWxseQp0aGlzIHdvdWxk IGJlIHN1ZmZpY2llbnQgdG8gc3VwcG9ydCBJU09zIHN0b3JlZCBvbiBTMywgc3dpZnQsCmdsYW5j ZSwKZXRjKS4KPC9wcmU+CiAgICAgICAgICA8L2Jsb2NrcXVvdGU+CiAgICAgICAgICA8cHJlIHdy YXA9IiI+CkFjdHVhbGx5LCB3ZSBjb3VsZCB1c2UgdGhlIHFlbXUgY3VybCBiYWNrZW5kIGltYWdl IHN1cHBvcnQKZGlyZWN0bHkuClRoYXQgbWVhbnMgd2UgZG9uJ3QgbmVlZCBtb3VudCB0aGUgcGxh Y2Ugc3RvcmluZyBJU08gaW1hZ2VzLiBXZSBjYW4KanVzdCBtYWludGFpbiBhIGxpc3Qgb2YgSVNP IGltYWdlIHdpdGggaXRzIGxpbmssIHdoaWNoIGNvdWxkIGJlCmh0dHAsCmZ0cCBhbmQgc3NoLgo8 L3ByZT4KICAgICAgICA8L2Jsb2NrcXVvdGU+CiAgICAgICAgPHByZSB3cmFwPSIiPgpUaGF0IHdp bGwgYmUgZmluZSB0byBzdGFydCBhIFZNIG9uIGEgZXhpc3RpbmcgZXh0ZXJuIElTTyBpbWFnZS4g SQphbHNvCndvdWxkIGxpa2UgdG8gbWFpbnRhaW4gYSBJU08gaW1hZ2UgY2FjaGUgb24gdGhlIGxv Y2FsIGhvc3QgdG8gYXZvaWQKdG8KcmUtc3RyZWFtaW5nIHRoZSBJU08gaW1hZ2UgZnJvbSB0aGUg SVNPIGltYWdlIHJlcG9zaXRvcmllcyBldmVyeQp0aW1lLgpUaGF0IHdpbGwgYmUgaGVscGZ1bCBm b3IgcGVvcGxlIHdobyBpcyBzdWZmZXJlZCBmcm9tIHRoZSBuZXR3b3JrCmJvdHRsZW5lY2suCjwv cHJlPgogICAgICA8L2Jsb2NrcXVvdGU+CiAgICAgIDxwcmUgd3JhcD0iIj4KV2UgaGF2ZSBhIHNp bWlsYXIgcmVxdWlyZW1lbnQgZm9yIGdsYW5jZSBzdXBwb3J0IChub3QgbGltaXRlZCB0byBJU09z LCByYXRoZXIgdG8gYWxsIHJlYWQtb25seSBpbWFnZXMpIHNvIHRoYXQgc2hvdWxkIGJlIHRhY2ts ZWQgd2l0aCBhIGJyb2FkZXIgc29sdXRpb24uPC9wcmU+CiAgICA8L2Jsb2NrcXVvdGU+CiAgICBJ biB0aGF0IGNhc2UswqAgSSBzdXBwb3NlIHFlbXUncyBjb3B5LW9uLXJlYWQgKyBodHRwZnMgKHlv dSBtZW50aW9uZWQKICAgIGFib3ZlKSBjb3VsZCBoZWxwLsKgIEl0CiAgICA8bWV0YSBodHRwLWVx dWl2PSJjb250ZW50LXR5cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD1VVEYtOCI+CiAg ICBjYW4gYXZvaWQgYWNjZXNzaW5nIHRoZSBzYW1lIGJhY2tpbmcgZmlsZSBzZWN0b3JzIHJlcGVh dGVkbHkuIDxicj4KICAgIEJ1dCB0aGUgY29waWVkIGNvbnRlbnQgY2FuJ3QgYmUgc2hhcmVkIGJ5 IG11bHRpcGxlIFZNIHVzaW5nIHRoZSBzYW1lCiAgICBiYWNrZW5kIGltYWdlLjxicj4KICAgIDxi cj4KICAgIDxibG9ja3F1b3RlCiAgICAgIGNpdGU9Im1pZDoxNTk5NjI1NjA0Ljk0ODI4MzEuMTM2 MzU5NjE4ODAzMC5KYXZhTWFpbC5yb290QHJlZGhhdC5jb20iCiAgICAgIHR5cGU9ImNpdGUiPgog ICAgICA8cHJlIHdyYXA9IiI+Cgo8L3ByZT4KICAgICAgPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+ CiAgICAgICAgPHByZSB3cmFwPSIiPgo8L3ByZT4KICAgICAgICA8YmxvY2txdW90ZSB0eXBlPSJj aXRlIj4KICAgICAgICAgIDxwcmUgd3JhcD0iIj4KPC9wcmU+CiAgICAgICAgICA8YmxvY2txdW90 ZSB0eXBlPSJjaXRlIj4KICAgICAgICAgICAgPHByZSB3cmFwPSIiPgpbMV0gPGEgY2xhc3M9Im1v ei10eHQtbGluay1mcmVldGV4dCIgaHJlZj0iaHR0cDovL2h0dHBmcy5zb3VyY2Vmb3JnZS5uZXQv Ij5odHRwOi8vaHR0cGZzLnNvdXJjZWZvcmdlLm5ldC88L2E+Cgo8L3ByZT4KICAgICAgICAgICAg PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+CiAgICAgICAgICAgICAgPHByZSB3cmFwPSIiPgoKTWFy ay4KClsxXSA8YSBjbGFzcz0ibW96LXR4dC1saW5rLWZyZWV0ZXh0IiBocmVmPSJodHRwOi8vZ2Vy cml0Lm92aXJ0Lm9yZy8jL2MvMTI2ODcvIj5odHRwOi8vZ2Vycml0Lm92aXJ0Lm9yZy8jL2MvMTI2 ODcvPC9hPgpbMl0gPGEgY2xhc3M9Im1vei10eHQtbGluay1mcmVldGV4dCIgaHJlZj0iaHR0cDov L2dlcnJpdC5vdmlydC5vcmcvIy9jLzEyOTE2LyI+aHR0cDovL2dlcnJpdC5vdmlydC5vcmcvIy9j LzEyOTE2LzwvYT4KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fCkVuZ2luZS1kZXZlbCBtYWlsaW5nIGxpc3QKPGEgY2xhc3M9Im1vei10eHQtbGluay1hYmJy ZXZpYXRlZCIgaHJlZj0ibWFpbHRvOkVuZ2luZS1kZXZlbEBvdmlydC5vcmciPkVuZ2luZS1kZXZl bEBvdmlydC5vcmc8L2E+CjxhIGNsYXNzPSJtb3otdHh0LWxpbmstZnJlZXRleHQiIGhyZWY9Imh0 dHA6Ly9saXN0cy5vdmlydC5vcmcvbWFpbG1hbi9saXN0aW5mby9lbmdpbmUtZGV2ZWwiPmh0dHA6 Ly9saXN0cy5vdmlydC5vcmcvbWFpbG1hbi9saXN0aW5mby9lbmdpbmUtZGV2ZWw8L2E+Cgo8L3By ZT4KICAgICAgICAgICAgPC9ibG9ja3F1b3RlPgogICAgICAgICAgICA8cHJlIHdyYXA9IiI+Cjwv cHJlPgogICAgICAgICAgPC9ibG9ja3F1b3RlPgogICAgICAgICAgPHByZSB3cmFwPSIiPgoKX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KRW5naW5lLWRldmVs IG1haWxpbmcgbGlzdAo8YSBjbGFzcz0ibW96LXR4dC1saW5rLWFiYnJldmlhdGVkIiBocmVmPSJt YWlsdG86RW5naW5lLWRldmVsQG92aXJ0Lm9yZyI+RW5naW5lLWRldmVsQG92aXJ0Lm9yZzwvYT4K PGEgY2xhc3M9Im1vei10eHQtbGluay1mcmVldGV4dCIgaHJlZj0iaHR0cDovL2xpc3RzLm92aXJ0 Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2VuZ2luZS1kZXZlbCI+aHR0cDovL2xpc3RzLm92aXJ0Lm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2VuZ2luZS1kZXZlbDwvYT4KCjwvcHJlPgogICAgICAgIDwvYmxv Y2txdW90ZT4KICAgICAgICA8cHJlIHdyYXA9IiI+CgotLQotLS0K6IiS5piOIFNodSBNaW5nCk9w ZW4gVmlydHVhbGl6YXRpb24gRW5naW5lZXJuaW5nOyBDU1RMLCBJQk0gQ29ycC4KVGVsOiA4Ni0x MC04MjQ1MTYyNiAgVGllbGluZTogOTA1MTYyNiBFLW1haWw6IDxhIGNsYXNzPSJtb3otdHh0LWxp bmstYWJicmV2aWF0ZWQiIGhyZWY9Im1haWx0bzpzaHVtaW5nQGNuLmlibS5jb20iPnNodW1pbmdA Y24uaWJtLmNvbTwvYT4gb3IKPGEgY2xhc3M9Im1vei10eHQtbGluay1hYmJyZXZpYXRlZCIgaHJl Zj0ibWFpbHRvOnNodW1pbmdAbGludXgudm5ldC5pYm0uY29tIj5zaHVtaW5nQGxpbnV4LnZuZXQu aWJtLmNvbTwvYT4KQWRkcmVzczogMy9GIFJpbmcgQnVpbGRpbmcsIFpob25nR3VhbkN1biBTb2Z0 d2FyZSBQYXJrLCBIYWlkaWFuCkRpc3RyaWN0LCBCZWlqaW5nIDEwMDE5MywgUFJDCgoKCjwvcHJl PgogICAgICA8L2Jsb2NrcXVvdGU+CiAgICAgIDxwcmUgd3JhcD0iIj4KPC9wcmU+CiAgICA8L2Js b2NrcXVvdGU+CiAgICA8YnI+CiAgPC9ib2R5Pgo8L2h0bWw+CgotLS0tLS0tLS0tLS0tLTA5MDcw NTA4MDkwMjAwMDUwMzA3MDEwNy0tCgo= --===============5973011299248973153==-- From abaron at redhat.com Mon Mar 18 06:11:50 2013 Content-Type: multipart/mixed; boundary="===============4588010047064879989==" MIME-Version: 1.0 From: Ayal Baron To: devel at ovirt.org Subject: Re: [Engine-devel] Proposal for support ISO domain on other types of file based storage. Date: Mon, 18 Mar 2013 06:11:48 -0400 Message-ID: <359707274.9513714.1363601508250.JavaMail.root@redhat.com> In-Reply-To: 5146DB02.2030006@linux.vnet.ibm.com --===============4588010047064879989== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable ----- Original Message ----- > = > On 03/18/2013 04:43 PM, Ayal Baron wrote: > = > = > ----- Original Message ----- > = > Mark Wu : > = > On Sun 17 Mar 2013 10:12:55 PM CST, Ayal Baron wrote: > = > ----- Original Message ----- > = > Hi guys, > = > Currently, ISO domain is only supported on NFS storage. It could > improve the ease of use if it allows other types > of file based storage to store ISO images. After an > investigation, I > found there's not any restriction on this idea. > So the whole work is removing the limitation on engine side. That > means engine should allow ISO domain could > have different storage type from the data center it's attached, > like > what we do with nfs ISO domain in SAN DC. > = > I start this idea with localfs. I know local storage can't be > seen in > cluster level. But it also provides a choice if no > NFS available. VMs can be created on the host which has the ISO > repo, > and then be migrated to any other host in the cluster. > I have done the initial patches: allow creation ISO domain on > localfs > [1] and support import ISO domain on localfs [2] > I don't have much experience in java/j2ee/web development and > engine > architecture. The patches just work for me. > I am not sure if it will bring some potential problems. So any > feedback on the patch or the idea will be appreciated very much. > Haven't looked at the patches yet, but wrt the idea, I agree on > the > need (being able to attach ISOs from anywhere and not just nfs) > but I > think the way to do this should be by getting rid of the ISO > domain > type altogether. I think ISO domain on localfs is useful for a simple > setup or demo, > such as oVirt all-in-one. > = > Basically what we need is: > 1. a way to connect to file based storage (let's leave block aside > for now) - this already exists via the connectStorageServer verb > 2. a way to list and present a file system tree in gui (give an > arbitrary path to vdsm and list content) and possibly filter > results > by type (vfd, iso) - does not exist today. Possibly some security > aspects here that need hashing out. > 3. a way to specify a path to a file when attaching an iso/vfd to > a > VM - this is the way it works today > = > This would devoid the need for isoUploader and allow users to > simply > manage an nfs export with files. > Next step would be to make connectStorageServer support httpfs [1] > and then we'd be able to mount ISOs directly over http (hopefully > this would be sufficient to support ISOs stored on S3, swift, > glance, > etc). Actually, we could use the qemu curl backend image support > directly. > That means we don't need mount the place storing ISO images. We can > just maintain a list of ISO image with its link, which could be > http, > ftp and ssh. That will be fine to start a VM on a existing extern ISO > image. I > also > would like to maintain a ISO image cache on the local host to avoid > to > re-streaming the ISO image from the ISO image repositories every > time. > That will be helpful for people who is suffered from the network > bottleneck. We have a similar requirement for glance support (not > limited to ISOs, rather to all read-only images) so that should be > tackled with a broader solution. In that case, I suppose qemu's > copy-on-read + httpfs (you mentioned above) could help. It can avoid > accessing the same backing file sectors repeatedly. > But the copied content can't be shared by multiple VM using the same > backend image. Sounds like an rfe for qemu. Basically we need to try and split the storage part in qemu to a separate p= rocess to enable such capabilities. > = > = > = > = > = > = > = > = > = > [1] http://httpfs.sourceforge.net/ > = > Mark. > = > [1] http://gerrit.ovirt.org/#/c/12687/ [2] > http://gerrit.ovirt.org/#/c/12916/ > _______________________________________________ > Engine-devel mailing list Engine-devel(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > _______________________________________________ > Engine-devel mailing list Engine-devel(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel -- > --- > =E8=88=92=E6=98=8E Shu Ming > Open Virtualization Engineerning; CSTL, IBM Corp. > Tel: 86-10-82451626 Tieline: 9051626 E-mail: shuming(a)cn.ibm.com or > shuming(a)linux.vnet.ibm.com Address: 3/F Ring Building, ZhongGuanCun > Software Park, Haidian > District, Beijing 100193, PRC >=20 --===============4588010047064879989==--