<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<div class="moz-cite-prefix">On 11/04/2014 11:10 AM, CrÃstian Viana
wrote:<br>
</div>
<blockquote cite="mid:5458D039.7060604@linux.vnet.ibm.com"
type="cite">
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
On 03-11-2014 14:32, Aline Manera wrote:<br>
<blockquote cite="mid:5457AE25.4020005@linux.vnet.ibm.com"
type="cite">It is like a clone, right? <br>
So the API should be POST
/storagepools/<pool>/storagevolumes/<volumes>/clone
<br>
</blockquote>
<br>
Well, you can see it that way as well but I was influenced by the
libvirt naming used to implement this: <tt>virStorageVolCreateXMLFrom(pool,
xml, flags)</tt>. We can think of it as a clone and change its
API to the one you suggested.<br>
<br>
</blockquote>
<br>
ACK.<br>
<br>
<blockquote cite="mid:5458D039.7060604@linux.vnet.ibm.com"
type="cite">
<blockquote cite="mid:5457AE25.4020005@linux.vnet.ibm.com"
type="cite"> And what about the destination path? Isn't it
needed to do the clone? Even if it is optional. <br>
Because, in the guest clone case the volume can be cloned in a
different pool from the existing one. <br>
</blockquote>
<br>
Using the API I implemented, the destination path was provided by
the pool used to create the new volume:<br>
<br>
<tt>POST /storagepool/<b>mypool</b>/storagevolumes {'volume_path':
'/home/user/image.img'}</tt><br>
<br>
The command above would create a new volume on the pool "mypool",
that's why the destination path wasn't needed.<br>
<br>
But if implement it as a clone, we will need to provide a new
parameter (e.g. "pool") to act as the destination path.<br>
</blockquote>
<br>
Thanks for the explanation.<br>
<br>
</body>
</html>