[one-users] VMWare Server 2.0 and non-persistent images to minimize copy when deploying
Tino Vazquez
tinova at opennebula.org
Wed Mar 2 04:25:33 PST 2011
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
>
>
>
>
More information about the Users
mailing list