<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div><div style="direction:ltr;font-size:10pt;font-family:Tahoma">
1.: I have to set FORMAT = "qcow2" so qemu-img create is used to create the image file. But this way I can not specify a filesystem to be created, right? I have to manually format the disk after vm booted (of curse I can use contextualisation to do this part).
Is there a way to tell opennebula to create qcow2 img and then format it with ext3?<br></div></div></blockquote><div><br></div><div style>Exactly, you need to mount the disk and format it within the VM, once booted. We thought about adding an extra TYPE something like qcow2+ext3 but we feel that would be more confusing...</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><div style="direction:ltr;font-size:10pt;font-family:Tahoma">
<br>
2.: The main reason why I want to use qcow2 is thin provisioning in the meaning of empty disk does not use $max_size at our storage. For testing I created a disks like:<br>
<br>
DISK = [ TYPE = "fs",<br>
SIZE = 40000,<br>
FORMAT = "ext3"] <br>
<br>
DISK = [ TYPE = "fs",<br>
SIZE = 40000,<br>
FORMAT = "raw"]<br>
<br>
I saw that even this disks only took ~750Mb on our NFS server. Can someone explain why, I expected that these raw (or raw with ext3 filesystem on it) will take the whole 40k Mb on our storage.<br></div></div></blockquote>
<div><br></div><div style>Maybe that's because you are using a file system with support for sparse files.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div><div style="direction:ltr;font-size:10pt;font-family:Tahoma">
<br>
3.: The transfer manager ist attached to a datastore and not to a image. So I can not put qcow2 and raw images into the same datastore. Is there a reason for that? </div></div></blockquote><div><br></div><div style>Actually you can. You'll have a datastore of type fs (DS_MAD = fs) and using a transfer manager drivers qcow (TM_MAD=qcow2). You can create "raw" files in the datastore. The TM driver will use qemu-img commands, but AFAIK that also handle raw images.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><div style="direction:ltr;font-size:10pt;font-family:Tahoma">
Why can't we attach the tm to a image instead of datastore? </div></div></blockquote><div><br></div><div style>TM is to specify how the images of a datastore are distributed to the hosts. This is related to the storage configuration (shared by all the images in a given datastore) and not to the image itself</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><div style="direction:ltr;font-size:10pt;font-family:Tahoma">
but I can put qcow2 images into shared
tm datastore if the vm template overrides this by setting driver=qcow2, right?<br></div></div></blockquote><div><br></div><div style>Yes driver is an attribute of the image (the image format), you need to add the driver=qcow2 for the qcow2 images.</div>
<div style><br></div><div style>Summary.</div><div style><br></div><div style>1.- Define a fs datastore [1] with the qcow2 transfer driver</div><div style>2.- Create images in it, either register exisiting qcow2 files, or creating datablocks of type qcow2 (to be formatted on the vm) or any other type. Qcow2 images would need DRIVER=qcow2</div>
<div style>3.- Use those files in your VMs with DISK = [...]</div><div style><br></div><div style>NOTE: Volatile disks as the one in your email are created on the fly in the system datastore. [2] </div><div style><br></div>
<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><div style="direction:ltr;font-size:10pt;font-family:Tahoma">
Up to now I only thought about different datastores are different storage locations and different redundancy zones/slas/performance classes. Any clearification is appreciated<br></div></div></blockquote><div><br></div><div style>
Yes, basically datastores are abstractions to manage different storage architectures and configurations. Balancing among different servers, slas and the like are goodies that comes that abstraction. </div><div style><br>
</div>
<div style><br></div><div style>[1] <a href="http://opennebula.org/documentation:rel3.8:fs_ds#using_the_qcow2_transfer_driver">http://opennebula.org/documentation:rel3.8:fs_ds#using_the_qcow2_transfer_driver</a></div><div>
[2] <a href="http://opennebula.org/documentation:rel3.8:system_ds">http://opennebula.org/documentation:rel3.8:system_ds</a></div><div><br></div><div style>Cheers</div><div style><br></div><div style>Ruben</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div><div style="direction:ltr;font-size:10pt;font-family:Tahoma">
<br>
Thanks for your help,<br>
Nils Schröder<br>
</div>
<p></p>
<font size="-2">OHG mit Sitz in Oldenburg; Registergericht Oldenburg HR A 1548; <br>
Persönlich haftende geschäftsführende Gesellschafterin: Neumüller CeWe Color Stiftung, Oldenburg<br>
Vorstand: Dr. Rolf Hollander, Vorsitzender; Harald H. Pirwitz, Felix Thalmann, Frank Zweigle, Dr. Michael Fries;<br>
Geschäftsführer: Dr. Reiner Fageth, Andreas F.L. Heydemann, Dr. Olaf Holzkämper<br>
<br>
Persönlich haftende Gesellschafterin: CeWe Color Holding AG, Oldenburg, Registergericht Oldenburg HR B 2956<br>
Vorstand: Dr. Rolf Hollander, Vorsitzender; Andreas F.L. Heydemann, Dr. Reiner Fageth, Dr. Olaf Holzkämper<br>
Aufsichtsrat: Otto Korte, Vorsitzender<br>
</font>
</div>
<br>_______________________________________________<br>
Users mailing list<br>
<a href="mailto:Users@lists.opennebula.org">Users@lists.opennebula.org</a><br>
<a href="http://lists.opennebula.org/listinfo.cgi/users-opennebula.org" target="_blank">http://lists.opennebula.org/listinfo.cgi/users-opennebula.org</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br>Ruben S. Montero, PhD<br>Project co-Lead and Chief Architect<br>OpenNebula - The Open Source Solution for Data Center Virtualization<br><a href="http://www.OpenNebula.org" target="_blank">www.OpenNebula.org</a> | <a href="mailto:rsmontero@opennebula.org" target="_blank">rsmontero@opennebula.org</a> | @OpenNebula
</div></div>