<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<font size="+1"><tt>Yes, you are right.<br>
<br>
I create one VMWare disk image and then mark the<br>
disk as non-persistent. When deploying VMs I specify<br>
this same image in all VMs and they all create their<br>
respective REDO files (please refer to the 1, for details)<br>
in respective directories. With this mechanism, I am<br>
able to avoid actual copy of the VMWare disks for subsequent<br>
VM instances, and essentially achieving network boot like <br>
functionality.<br>
</tt></font>
<pre wrap="">1. <a class="moz-txt-link-freetext" href="http://communities.vmware.com/thread/15339">http://communities.vmware.com/thread/15339</a></pre>
<font size="+1"><tt> </tt></font>
<pre class="moz-signature" cols="72">Thanks and Regards,
Manish</pre>
<br>
On 3/2/2011 5:55 PM, Tino Vazquez wrote:
<blockquote
cite="mid:AANLkTimAT8u_cs72hCdeT3kzzReiQN5wzzmmt5wFrevM@mail.gmail.com"
type="cite">
<pre wrap="">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
<a class="moz-txt-link-abbreviated" href="http://www.OpenNebula.org">www.OpenNebula.org</a> | @tinova79
On Wed, Mar 2, 2011 at 7:49 AM, Manish Sapariya <a class="moz-txt-link-rfc2396E" href="mailto:manish@gslab.com"><manish@gslab.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Tino,
Thanks for confirmation.
Here is the bug which I think blocking my use case.
<a class="moz-txt-link-freetext" href="https://bugzilla.redhat.com/show_bug.cgi?id=508662">https://bugzilla.redhat.com/show_bug.cgi?id=508662</a>
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
<a class="moz-txt-link-abbreviated" href="http://www.OpenNebula.org">www.OpenNebula.org</a> | @tinova79
On Tue, Mar 1, 2011 at 7:37 AM, Manish Sapariya <a class="moz-txt-link-rfc2396E" href="mailto:manish@gslab.com"><manish@gslab.com></a> 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
<a class="moz-txt-link-abbreviated" href="http://www.OpenNebula.org">www.OpenNebula.org</a> | @tinova79
On Wed, Feb 23, 2011 at 1:39 PM, Manish Sapariya <a class="moz-txt-link-rfc2396E" href="mailto:manish@gslab.com"><manish@gslab.com></a> 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. <a class="moz-txt-link-freetext" href="http://communities.vmware.com/thread/15339">http://communities.vmware.com/thread/15339</a>
--
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
<a class="moz-txt-link-abbreviated" href="mailto:Users@lists.opennebula.org">Users@lists.opennebula.org</a>
<a class="moz-txt-link-freetext" href="http://lists.opennebula.org/listinfo.cgi/users-opennebula.org">http://lists.opennebula.org/listinfo.cgi/users-opennebula.org</a>
_______________________________________________
Users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Users@lists.opennebula.org">Users@lists.opennebula.org</a>
<a class="moz-txt-link-freetext" href="http://lists.opennebula.org/listinfo.cgi/users-opennebula.org">http://lists.opennebula.org/listinfo.cgi/users-opennebula.org</a>
</pre>
</blockquote>
</blockquote>
</body>
</html>