<div class="gmail_quote">2011/1/14 Jay Pipes <span dir="ltr"><<a href="mailto:jaypipes@gmail.com">jaypipes@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

2011/1/14 Diego Parrilla Santamarķa <<a href="mailto:diego.parrilla.santamaria@gmail.com">diego.parrilla.santamaria@gmail.com</a>>:<br>
<div class="im">> Well... VMX is probably too VMware oriented. My only concern about this kind<br>
> of proprietary parameter file is you don't really have the chance to control<br>
> its lifecycle. New versions, changes... and developers lagging behind of<br>
> this changes. It can be a nightmare.<br>
> But this is more a decision of Product Management than a technical<br>
> decision... from my perspective. From a pure user perspective, the more<br>
> options the better, of course.<br>
> BTW, I think we did a good job in Abicloud about virtual disk formats and<br>
> virtual images: <a href="http://abiquo.org/display/ABI16/Virtual+Images+Introduction" target="_blank">http://abiquo.org/display/ABI16/Virtual+Images+Introduction</a><br>
<br>
</div>Helpful link, thanks Diego :)<br>
<br>
Followup question, based partly on the table of supported disk<br>
formats: instead of the general VMDK as a disk format, should we have<br>
a more broken-down format for, say, sparse VMDK?<br>
<br>
In other words, how fine-grained should the metadata about an image in<br>
Glance be?<br>
<font color="#888888"><br></font></blockquote><meta charset="utf-8"><div class="gmail_quote"><br></div><div class="gmail_quote">Jay,</div><div class="gmail_quote"><br></div><meta charset="utf-8"><div class="gmail_quote">

I think VMDK subtypes are very relevant information and has to be indicated before a deployment. Just an example: if you try to deploy a streamOptimized or even some sparse formats directly to VMware ESXi they won't work, and troubleshooting for newbies can be complicated.</div>

<div class="gmail_quote"><br></div><div class="gmail_quote">I'm not very famliar with Glance yet. So may be some of my asumptions can sound stupid...</div><div class="gmail_quote"><br></div><div class="gmail_quote">I guess that one of the main purpose of Glance is to deal with Object Storage Services (Swift or S3 for example) because they are the best candidates to store virtual images. I think this is a 'necessary evil': such a big images must be stored somewhere.</div>

<div class="gmail_quote"><br></div><div class="gmail_quote">What I don't really get is how Glance is going to deal with all the different virtual images formats supported for the different hypervisors. I mean, who is going to convert from virtual image format X to the virtual image format needed by hypervisor Y? Is Glance responsible for this or the Compute Node? May be if you explain me a little bit how it will work I can be more helpful. I'm still with Austin and I will start to work on the Bexar branch very soon.</div>

<div class="gmail_quote"><br></div><div class="gmail_quote">Regards</div><div class="gmail_quote">Diego</div><div class="gmail_quote"><br></div>-<br>Diego Parrilla<div><a href="http://nubeblog.com/" target="_blank">nubeblog.com</a> | <a href="mailto:nubeblog@nubeblog.com" target="_blank">nubeblog@nubeblog.com</a> | <a href="http://twitter.com/nubeblog" target="_blank">twitter.com/nubeblog</a></div>

<div>+34 649 94 43 29 </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><font color="#888888">
-jay<br>
</font></blockquote></div><br>