[one-users] VMWare Server 2.0 and non-persistent images to minimize copy when deploying

[Manish Sapariya]

Tino,
Thanks for confirmation.
Here is the bug which I think blocking my use case.

https://bugzilla.redhat.com/show_bug.cgi?id=508662

Thanks and Regards,
Manish


On 3/1/2011 4:55 PM, Tino Vazquez wrote:
> Hi Manish,
>
> About the tm_dummy error, you will need to restart oned after setting
> uncommenting the following in $ONE_LOCATION/etc/oned.conf:
>
> --
> TM_MAD = [
>      name       = "tm_dummy",
>      executable = "one_tm",
>      arguments  = "tm_dummy/tm_dummy.conf" ]
> --
>
> After looking at the non-persistent problem you are having, I now see
> that you are completely right. If libvirt doesn't flag those disks
> correctly, we have a problem. Could you please send me the link of the
> libvirt feature bug you mention? We can then investigate a workaround.
>
> Regards,
>
> -Tino
>
> --
> Constantino Vázquez Blanco, MSc
> OpenNebula Major Contributor
> www.OpenNebula.org | @tinova79
>
>
>
> On Tue, Mar 1, 2011 at 7:37 AM, Manish Sapariya<manish at gslab.com>  wrote:
>> As a alternative I also tried hacking the code
>> to get the same effect as you have suggested.
>>
>> 1. I changed my nfs clone.sh to do nothing, but
>> to create empty directory.
>> 2. I changed the remotes/vmware/deploy to modify
>>     the deployment.0 to refer to my non-persistent
>>     disk instead of one which ON creates.
>> 3. With above changes when I deploy, ON creates the
>>     VM and starts it as well.
>>      - The first VM runs fine.
>>      - The second VM however fails, because ESX says
>>        the image is already in use. This happes because
>>        libvirt fails to mark the disk that it creates
>>        as non-persistent.
>>      - If I change that attribute of the failed VM, ESX
>>        is able to run the VM.
>>
>> So I think I will run into this same issue with the approach
>> you suggested as well. I believe this is the inherent lack
>> of support for non-persistent image by libvirtd. I checked
>> the libvirt documenation and they have one feature bug open
>> to support non-persistent disks.
>>
>> Could you please confirm if my understanding is correct
>> or am I missing certain subtle point?
>>
>> Thanks and Regards,
>> Manish
>>
>> On 2/28/2011 8:21 PM, Tino Vazquez wrote:
>>
>> Hi Manish,
>>
>> You can avoid the copy of the image if you:
>>
>>   1) Use the dummy TM drivers
>>   1) Stop using the image catalog, and input the SOURCE of the disks
>> with the following format
>>
>>         [DATASTORE] relative/path/to/disk
>>
>> The path is relative wrt the DATASTORE.
>>
>> hope it helps,
>>
>> -Tino
>>
>> --
>> Constantino Vázquez Blanco, MSc
>> OpenNebula Major Contributor
>> www.OpenNebula.org | @tinova79
>>
>>
>>
>> On Wed, Feb 23, 2011 at 1:39 PM, Manish Sapariya<manish at gslab.com>  wrote:
>>
>> Hi,
>> We have are using OpenNebula 1.4 using following kind of setup.
>> The non-persistent disk that I used in OpenNebula 1.4 is not
>> working in 2.0.
>>
>> The reason it worked with 1.4 is that it copied the directory as
>> it is without looking into the directory. My .vmx file was modified
>> to had a link to non-persistent disk and hence the solution was working.
>>
>> 2.0 specifically copies the vmdk file and then creates a deployment
>> file. And hence my 1.4 solution is not working with 2.0.
>>
>> My question is, can I tell opennebula to use specific image on
>> hypervisor, instead of making a copy of vmdk and using that as the
>> instance disk.
>>
>> Thanks and Regards,
>> Manish
>>
>> On 9/27/2010 5:02 PM, Manish Sapariya wrote:
>>
>> Hi All,
>> I thought somebody will find this useful and hence
>> sharing it here.
>>
>> We are using opennebula based setup to test our
>> collaboration product. We have home grown test framework
>> which can run clients on different machines to execute
>> test scenarios. Things were fine until we had only few
>> users in our test. However as I added more users in test,
>> the VMs deploying started taking too long because of the
>> image copying. My frontend is on FC8, with big SATA disk.
>> The datastore is expored using CIFS. The VMWare Hypervisors
>> mount the datastore using CIFS to run the VMs.
>>
>> To minimize the copy of the whole disk on deploy, we
>> followed solution detailed in 1, which is briefly mentioned
>> as below.
>>
>> - Create your base image, call it basevm.
>> - Modify the disk settings to non-persistent.
>> - Now create another VM, clone1 , using the disk of
>>    basevm.
>>    - Set the new disk as non-persistent.
>> - Create the vm template pointing to clone1. Note that
>>    both the basevm and clone1 images should be in your
>>    exported datastore path.
>> - Deploy as many VMs as you like, with just few MBs of
>>    data to copied.
>>
>> Hope this helps somebody.
>>
>> 1. http://communities.vmware.com/thread/15339
>>
>>
>> --
>> Thanks and Regards,
>> Manish
>>
>> --
>> This message has been scanned for viruses and
>> dangerous content by MailScanner, and is
>> believed to be clean.
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.opennebula.org
>> http://lists.opennebula.org/listinfo.cgi/users-opennebula.org
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.opennebula.org
>> http://lists.opennebula.org/listinfo.cgi/users-opennebula.org
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opennebula.org/pipermail/users-opennebula.org/attachments/20110302/0d1a0ee9/attachment-0003.htm>