From ykaul at redhat.com Sun Feb 19 07:15:45 2012 Content-Type: multipart/mixed; boundary="===============2152915198039328557==" MIME-Version: 1.0 From: Yaniv Kaul To: devel at ovirt.org Subject: Re: [Engine-devel] VM disks Date: Sun, 19 Feb 2012 14:15:42 +0200 Message-ID: <4F40E7EE.5070506@redhat.com> In-Reply-To: 4F3FDAB5.9020203@redhat.com --===============2152915198039328557== 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. --------------050009000602080805050601 Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed Content-Transfer-Encoding: 7bit On 02/18/2012 07:07 PM, Livnat Peer wrote: > Hi, > > These days we are working on various features around VM disks, in the > different threads it was decided that we'll have the ability to attach a > disk to a VM but it will be added as inactive, then the user can > activate it for it to be accessible from within the guest. > > Flow of adding a new disk would be: > - creating the disk > - attaching the disk to the VM > - activating it > > Flow of adding a shared disk (or any other existing disk): > - attach the disk > - activate it > > It seems to me a lot like adding a storage domain and I remember a lot > of rejections on the storage domain flow (mostly about it being too > cumbersome). > After discussing the issue with various people we could not find a good > reason for having a VM disk in attached but inactive mode. And since you probably can't find a good reason to have two steps for = storage domain, lets fix this as well. (Downstream RFE https://bugzilla.redhat.com/show_bug.cgi?id=3D567585 - = discuss only the export domain, but I'm quite sure it's applicable to = other domains as well) Y. > > Of course we can wrap the above steps in one step for specific flows > (add+attach within a VM context for example) but can anyone think on a > good reason to support attached but inactive disk? > > I would suggest that when attaching a disk to a VM it becomes part of > the VM (active) like in 'real' machines. > > > Thank you, Livnat > _______________________________________________ > Engine-devel mailing list > Engine-devel(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel --------------050009000602080805050601 Content-Type: text/html; charset=3DISO-8859-1 Content-Transfer-Encoding: 7bit On 02/18/2012 07:07 PM, Livnat Peer wrote:
Hi,

These days we are working on various features around VM disks, in the
different threads it was decided that we'll have the ability to attach a
disk to a VM but it will be added as inactive, then the user can
activate it for it to be accessible from within the guest.

Flow of adding a new disk would be:
- creating the disk
- attaching the disk to the VM
- activating it

Flow of adding a shared disk (or any other existing disk):
- attach the disk
- activate it

It seems to me a lot like adding a storage domain and I remember a lot
of rejections on the storage domain flow (mostly about it being too
cumbersome).
After discussing the issue with various people we could not find a good
reason for having a VM disk in attached but inactive mode.

And since you probably can't find a good reason to have two steps for storage domain, lets fix this as well.
(Downstream RFE https:= //bugzilla.redhat.com/show_bug.cgi?id=3D567585 - discuss only the export domain, but I'm quite sure it's applicable to other domains as well)
Y.


Of course we can wrap the above steps in one step for specific flows
(add+attach within a VM context for example) but can anyone think on a
good reason to support attached but inactive disk?

I would suggest that when attaching a disk to a VM it becomes part of
the VM (active) like in 'real' machines.


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

--------------050009000602080805050601-- --===============2152915198039328557== Content-Type: multipart/alternative MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="attachment.bin" VGhpcyBpcyBhIG11bHRpLXBhcnQgbWVzc2FnZSBpbiBNSU1FIGZvcm1hdC4KLS0tLS0tLS0tLS0t LS0wNTAwMDkwMDA2MDIwODA4MDUwNTA2MDEKQ29udGVudC1UeXBlOiB0ZXh0L3BsYWluOyBjaGFy c2V0PUlTTy04ODU5LTE7IGZvcm1hdD1mbG93ZWQKQ29udGVudC1UcmFuc2Zlci1FbmNvZGluZzog N2JpdAoKT24gMDIvMTgvMjAxMiAwNzowNyBQTSwgTGl2bmF0IFBlZXIgd3JvdGU6Cj4gSGksCj4K PiBUaGVzZSBkYXlzIHdlIGFyZSB3b3JraW5nIG9uIHZhcmlvdXMgZmVhdHVyZXMgYXJvdW5kIFZN IGRpc2tzLCBpbiB0aGUKPiBkaWZmZXJlbnQgdGhyZWFkcyBpdCB3YXMgZGVjaWRlZCB0aGF0IHdl J2xsIGhhdmUgdGhlIGFiaWxpdHkgdG8gYXR0YWNoIGEKPiBkaXNrIHRvIGEgVk0gYnV0IGl0IHdp bGwgYmUgYWRkZWQgYXMgaW5hY3RpdmUsIHRoZW4gdGhlIHVzZXIgY2FuCj4gYWN0aXZhdGUgaXQg Zm9yIGl0IHRvIGJlIGFjY2Vzc2libGUgZnJvbSB3aXRoaW4gdGhlIGd1ZXN0Lgo+Cj4gRmxvdyBv ZiBhZGRpbmcgYSBuZXcgZGlzayB3b3VsZCBiZToKPiAtIGNyZWF0aW5nIHRoZSBkaXNrCj4gLSBh dHRhY2hpbmcgdGhlIGRpc2sgdG8gdGhlIFZNCj4gLSBhY3RpdmF0aW5nIGl0Cj4KPiBGbG93IG9m IGFkZGluZyBhIHNoYXJlZCBkaXNrIChvciBhbnkgb3RoZXIgZXhpc3RpbmcgZGlzayk6Cj4gLSBh dHRhY2ggdGhlIGRpc2sKPiAtIGFjdGl2YXRlIGl0Cj4KPiBJdCBzZWVtcyB0byBtZSBhIGxvdCBs aWtlIGFkZGluZyBhIHN0b3JhZ2UgZG9tYWluIGFuZCBJIHJlbWVtYmVyIGEgbG90Cj4gb2YgcmVq ZWN0aW9ucyBvbiB0aGUgc3RvcmFnZSBkb21haW4gZmxvdyAobW9zdGx5IGFib3V0IGl0IGJlaW5n IHRvbwo+IGN1bWJlcnNvbWUpLgo+IEFmdGVyIGRpc2N1c3NpbmcgdGhlIGlzc3VlIHdpdGggdmFy aW91cyBwZW9wbGUgd2UgY291bGQgbm90IGZpbmQgYSBnb29kCj4gcmVhc29uIGZvciBoYXZpbmcg YSBWTSBkaXNrIGluIGF0dGFjaGVkIGJ1dCBpbmFjdGl2ZSBtb2RlLgoKQW5kIHNpbmNlIHlvdSBw cm9iYWJseSBjYW4ndCBmaW5kIGEgZ29vZCByZWFzb24gdG8gaGF2ZSB0d28gc3RlcHMgZm9yIApz dG9yYWdlIGRvbWFpbiwgbGV0cyBmaXggdGhpcyBhcyB3ZWxsLgooRG93bnN0cmVhbSBSRkUgaHR0 cHM6Ly9idWd6aWxsYS5yZWRoYXQuY29tL3Nob3dfYnVnLmNnaT9pZD01Njc1ODUgLSAKZGlzY3Vz cyBvbmx5IHRoZSBleHBvcnQgZG9tYWluLCBidXQgSSdtIHF1aXRlIHN1cmUgaXQncyBhcHBsaWNh YmxlIHRvIApvdGhlciBkb21haW5zIGFzIHdlbGwpClkuCgo+Cj4gT2YgY291cnNlIHdlIGNhbiB3 cmFwIHRoZSBhYm92ZSBzdGVwcyBpbiBvbmUgc3RlcCBmb3Igc3BlY2lmaWMgZmxvd3MKPiAoYWRk K2F0dGFjaCB3aXRoaW4gYSBWTSBjb250ZXh0IGZvciBleGFtcGxlKSBidXQgY2FuIGFueW9uZSB0 aGluayBvbiBhCj4gZ29vZCByZWFzb24gdG8gc3VwcG9ydCBhdHRhY2hlZCBidXQgaW5hY3RpdmUg ZGlzaz8KPgo+IEkgd291bGQgc3VnZ2VzdCB0aGF0IHdoZW4gYXR0YWNoaW5nIGEgZGlzayB0byBh IFZNIGl0IGJlY29tZXMgcGFydCBvZgo+IHRoZSBWTSAoYWN0aXZlKSBsaWtlIGluICdyZWFsJyBt YWNoaW5lcy4KPgo+Cj4gVGhhbmsgeW91LCBMaXZuYXQKPiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXwo+IEVuZ2luZS1kZXZlbCBtYWlsaW5nIGxpc3QKPiBF bmdpbmUtZGV2ZWxAb3ZpcnQub3JnCj4gaHR0cDovL2xpc3RzLm92aXJ0Lm9yZy9tYWlsbWFuL2xp c3RpbmZvL2VuZ2luZS1kZXZlbAoKCi0tLS0tLS0tLS0tLS0tMDUwMDA5MDAwNjAyMDgwODA1MDUw NjAxCkNvbnRlbnQtVHlwZTogdGV4dC9odG1sOyBjaGFyc2V0PUlTTy04ODU5LTEKQ29udGVudC1U cmFuc2Zlci1FbmNvZGluZzogN2JpdAoKPGh0bWw+CiAgPGhlYWQ+CiAgICA8bWV0YSBjb250ZW50 PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9SVNPLTg4NTktMSIKICAgICAgaHR0cC1lcXVpdj0iQ29udGVu dC1UeXBlIj4KICA8L2hlYWQ+CiAgPGJvZHkgYmdjb2xvcj0iI0ZGRkZGRiIgdGV4dD0iIzAwMDAw MCI+CiAgICBPbiAwMi8xOC8yMDEyIDA3OjA3IFBNLCBMaXZuYXQgUGVlciB3cm90ZToKICAgIDxi bG9ja3F1b3RlIGNpdGU9Im1pZDo0RjNGREFCNS45MDIwMjAzQHJlZGhhdC5jb20iIHR5cGU9ImNp dGUiPgogICAgICA8cHJlIHdyYXA9IiI+SGksCgpUaGVzZSBkYXlzIHdlIGFyZSB3b3JraW5nIG9u IHZhcmlvdXMgZmVhdHVyZXMgYXJvdW5kIFZNIGRpc2tzLCBpbiB0aGUKZGlmZmVyZW50IHRocmVh ZHMgaXQgd2FzIGRlY2lkZWQgdGhhdCB3ZSdsbCBoYXZlIHRoZSBhYmlsaXR5IHRvIGF0dGFjaCBh CmRpc2sgdG8gYSBWTSBidXQgaXQgd2lsbCBiZSBhZGRlZCBhcyBpbmFjdGl2ZSwgdGhlbiB0aGUg dXNlciBjYW4KYWN0aXZhdGUgaXQgZm9yIGl0IHRvIGJlIGFjY2Vzc2libGUgZnJvbSB3aXRoaW4g dGhlIGd1ZXN0LgoKRmxvdyBvZiBhZGRpbmcgYSBuZXcgZGlzayB3b3VsZCBiZToKLSBjcmVhdGlu ZyB0aGUgZGlzawotIGF0dGFjaGluZyB0aGUgZGlzayB0byB0aGUgVk0KLSBhY3RpdmF0aW5nIGl0 CgpGbG93IG9mIGFkZGluZyBhIHNoYXJlZCBkaXNrIChvciBhbnkgb3RoZXIgZXhpc3RpbmcgZGlz ayk6Ci0gYXR0YWNoIHRoZSBkaXNrCi0gYWN0aXZhdGUgaXQKCkl0IHNlZW1zIHRvIG1lIGEgbG90 IGxpa2UgYWRkaW5nIGEgc3RvcmFnZSBkb21haW4gYW5kIEkgcmVtZW1iZXIgYSBsb3QKb2YgcmVq ZWN0aW9ucyBvbiB0aGUgc3RvcmFnZSBkb21haW4gZmxvdyAobW9zdGx5IGFib3V0IGl0IGJlaW5n IHRvbwpjdW1iZXJzb21lKS4KQWZ0ZXIgZGlzY3Vzc2luZyB0aGUgaXNzdWUgd2l0aCB2YXJpb3Vz IHBlb3BsZSB3ZSBjb3VsZCBub3QgZmluZCBhIGdvb2QKcmVhc29uIGZvciBoYXZpbmcgYSBWTSBk aXNrIGluIGF0dGFjaGVkIGJ1dCBpbmFjdGl2ZSBtb2RlLjwvcHJlPgogICAgPC9ibG9ja3F1b3Rl PgogICAgPGJyPgogICAgQW5kIHNpbmNlIHlvdSBwcm9iYWJseSBjYW4ndCBmaW5kIGEgZ29vZCBy ZWFzb24gdG8gaGF2ZSB0d28gc3RlcHMKICAgIGZvciBzdG9yYWdlIGRvbWFpbiwgbGV0cyBmaXgg dGhpcyBhcyB3ZWxsLjxicj4KICAgIChEb3duc3RyZWFtIFJGRQogICAgPG1ldGEgaHR0cC1lcXVp dj0iY29udGVudC10eXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7CiAgICAgIGNoYXJzZXQ9SVNPLTg4 NTktMSI+CiAgICA8YSBocmVmPSJodHRwczovL2J1Z3ppbGxhLnJlZGhhdC5jb20vc2hvd19idWcu Y2dpP2lkPTU2NzU4NSI+aHR0cHM6Ly9idWd6aWxsYS5yZWRoYXQuY29tL3Nob3dfYnVnLmNnaT9p ZD01Njc1ODU8L2E+CiAgICAtIGRpc2N1c3Mgb25seSB0aGUgZXhwb3J0IGRvbWFpbiwgYnV0IEkn bSBxdWl0ZSBzdXJlIGl0J3MgYXBwbGljYWJsZQogICAgdG8gb3RoZXIgZG9tYWlucyBhcyB3ZWxs KTxicj4KICAgIFkuPGJyPgogICAgPGJyPgogICAgPGJsb2NrcXVvdGUgY2l0ZT0ibWlkOjRGM0ZE QUI1LjkwMjAyMDNAcmVkaGF0LmNvbSIgdHlwZT0iY2l0ZSI+CiAgICAgIDxwcmUgd3JhcD0iIj4K Ck9mIGNvdXJzZSB3ZSBjYW4gd3JhcCB0aGUgYWJvdmUgc3RlcHMgaW4gb25lIHN0ZXAgZm9yIHNw ZWNpZmljIGZsb3dzCihhZGQrYXR0YWNoIHdpdGhpbiBhIFZNIGNvbnRleHQgZm9yIGV4YW1wbGUp IGJ1dCBjYW4gYW55b25lIHRoaW5rIG9uIGEKZ29vZCByZWFzb24gdG8gc3VwcG9ydCBhdHRhY2hl ZCBidXQgaW5hY3RpdmUgZGlzaz8KCkkgd291bGQgc3VnZ2VzdCB0aGF0IHdoZW4gYXR0YWNoaW5n IGEgZGlzayB0byBhIFZNIGl0IGJlY29tZXMgcGFydCBvZgp0aGUgVk0gKGFjdGl2ZSkgbGlrZSBp biAncmVhbCcgbWFjaGluZXMuCgoKVGhhbmsgeW91LCBMaXZuYXQKX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18KRW5naW5lLWRldmVsIG1haWxpbmcgbGlzdAo8 YSBjbGFzcz0ibW96LXR4dC1saW5rLWFiYnJldmlhdGVkIiBocmVmPSJtYWlsdG86RW5naW5lLWRl dmVsQG92aXJ0Lm9yZyI+RW5naW5lLWRldmVsQG92aXJ0Lm9yZzwvYT4KPGEgY2xhc3M9Im1vei10 eHQtbGluay1mcmVldGV4dCIgaHJlZj0iaHR0cDovL2xpc3RzLm92aXJ0Lm9yZy9tYWlsbWFuL2xp c3RpbmZvL2VuZ2luZS1kZXZlbCI+aHR0cDovL2xpc3RzLm92aXJ0Lm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2VuZ2luZS1kZXZlbDwvYT4KPC9wcmU+CiAgICA8L2Jsb2NrcXVvdGU+CiAgICA8YnI+CiAg PC9ib2R5Pgo8L2h0bWw+CgotLS0tLS0tLS0tLS0tLTA1MDAwOTAwMDYwMjA4MDgwNTA1MDYwMS0t Cg== --===============2152915198039328557==--