[one-users] VMWare Server 2.0 and non-persistent images to minimize copy when deploying
Manish Sapariya
manish at gslab.com
Wed Mar 2 04:41:24 PST 2011
Yes, you are right.
I create one VMWare disk image and then mark the
disk as non-persistent. When deploying VMs I specify
this same image in all VMs and they all create their
respective REDO files (please refer to the 1, for details)
in respective directories. With this mechanism, I am
able to avoid actual copy of the VMWare disks for subsequent
VM instances, and essentially achieving network boot like
functionality.
1. http://communities.vmware.com/thread/15339
Thanks and Regards,
Manish
On 3/2/2011 5:55 PM, Tino Vazquez wrote:
> Hi Manish,
>
> I am not familiar with this VMware functionality. This implies various
> VMs running from the same disk, and each storing each changes as
> deltas in separate files. Is this correct?
>
> Regards,
>
> -Tino
>
> --
> Constantino Vázquez Blanco, MSc
> OpenNebula Major Contributor
> www.OpenNebula.org | @tinova79
>
>
>
> On Wed, Mar 2, 2011 at 7:49 AM, Manish Sapariya<manish at gslab.com> wrote:
>> 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/b5204a12/attachment-0003.htm>
More information about the Users
mailing list