[Users] Thin provisioning extending while "Make template" still a bug?

[Adrian Gibanel]

----- Mensaje original -----

> De: "Maor Lipchuk" <mlipchuk at redhat.com>
> Para: "Adrian Gibanel" <adrian.gibanel at btactic.com>
> CC: "users" <users at ovirt.org>
> Enviados: Jueves, 17 de Enero 2013 15:52:24
> Asunto: Re: [Users] Thin provisioning extending while "Make template"
> still a bug?

> Hi Adrian,
> Sorry for the late respond.

Don't worry. 

> Please see inline comments,
> and feel free if there are any more questions, or other issues which
> you
> want us to address to.

> p.s. Since some of the responds were in different threads, I gathered
> all of them to this email.

> > 3) About the attached logs the virtual machine made from template
> > was
> > finally made at:
> > 2012/12/22 17:21
> > Logs are from 16:17 to 17:21 aproximately and I might reuse them to
> > ask why it takes so long to make the virtual machine while checking
> > the storage image at /home/storage (its size) it would seem that
> > the >
> copy has finished.
> > I think that the "Make vm from template" task started about 30
> > minutes or 40 minutes before it being finished. Well, that's the
> > average time it takes for me.
> Since you are creating a server the default behaviour is to clone
> your
> disks, which means engine calls copyImage to the SPM.
> From what I saw in the logs your template have two disks, which one
> of
> them is 1920 GB, this is why it took 30 minutes to copy it.

It's 1920 GB but the actual data copied to it is only 1 GB. I'm used to other methods of saving virtual images (instead of sparse I mean) and as the original file is only 1 GB the copy doesn't last too much. 

> If you want your copy to be faster, you can change the default in the
> resource allocation tab to use thin instead of clone when you add a
> new
> server.
> although, take in notice that when you will use thin provisioning,
> the
> server will be based on the template and you will not be able to
> remove
> the template until the VM will be removed.

The thing is that if you select Clone (the default behaviour) then at the botton it says: 

Alias | Virtual Size | Allocation | Target 
First | 1920 GB | Thin Prov | local_storage 
Seco | 1 GB | Preallocat | local_storage 

so I thought: 

If it lasts so much it means that someone it treats both hard disks as Preallocat no matter its particular disk allocation setup. 
But as you say later in the email each one of it is treated ok. 

So I think the problem is just the sparse method of saving the virtual images which makes read of big files to take an eternity even if a very few sectors are actually written. 

> On 12/24/2012 01:51 AM, Adrian Gibanel wrote:> I've just noticed that
> I
> made a typo.
> > This is the right template disk allocation policy table
> > (The fix is that second hard disk is preallocated instead of being
> Thin Prov)
> >
> > Alias | Virtual Size | Allocation | Target
> > First | 1920 GB | Thin Prov | local_storage
> > Seco | 1 GB | Preallocat | local_storage
> I took a look in your logs, and it seems that when you create a VM
> from
> template the passing arguments are preallocated for one image and
> sparse
> for the other, so it seems that this is fit with the allocation
> policy
> table you sent.

I'm going to send a message about how to move virtual images between hosts. It's kind of related to this. 

-- 

Adrián Gibanel 
I.T. Manager 

+34 675 683 301 
www.btactic.com 

Ens podeu seguir a/Nos podeis seguir en: 

i 

Abans d´imprimir aquest missatge, pensa en el medi ambient. El medi ambient és cosa de tothom. / Antes de imprimir el mensaje piensa en el medio ambiente. El medio ambiente es cosa de todos. 

AVIS: 
El contingut d'aquest missatge i els seus annexos és confidencial. Si no en sou el destinatari, us fem saber que està prohibit utilitzar-lo, divulgar-lo i/o copiar-lo sense tenir l'autorització corresponent. Si heu rebut aquest missatge per error, us agrairem que ho feu saber immediatament al remitent i que procediu a destruir el missatge . 

AVISO: 
El contenido de este mensaje y de sus anexos es confidencial. Si no es el destinatario, les hacemos saber que está prohibido utilizarlo, divulgarlo y/o copiarlo sin tener la autorización correspondiente. Si han recibido este mensaje por error, les agradeceríamos que lo hagan saber inmediatamente al remitente y que procedan a destruir el mensaje . 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/users/attachments/20130119/8e0f0560/attachment-0001.html>