9:18 a.m.
--_000_D290AD8432118048947689BA3AE8A9B3094E3FDCSACEXCMBX04PRDh_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Hi All,
I've been working on a bit of functionality for the engine that will allow =
a user to query a domain for new disk images (GetUnregisteredImagesQuery) f=
or which the engine was previously unaware and a separate command to regist=
er those images (ImportImageCommand). These commands will be exposed throug=
h the REST API.
This functionality is needed as we are developing an extension/plugin to oV=
irt that will allow a NetApp storage controller to handle cloning the actua=
l disks outside of oVirt and need to import them once they are cloned. We'l=
l be using other existing APIs to attach the disk to the necessary VM once =
the disk is cloned. On the NetApp side, we'll ensure the disk is coalesced =
before cloning so as to avoid the issues of registering snapshots.
GetUnregisteredImagesQuery will be accessible through the disks resource co=
llection on a storage domain. A "disks" resource collection does not yet ex=
ist and will need to be added. To access the unregistered images, a paramet=
er (maybe "unregistered=3Dtrue") would be passed. So the path to "GET"
the =
unregistered disk images on a domain would be something like /api/storagedo=
mains/f0dbcb33-69d3-4899-9352-8e8a02f01bbd/disks?unregistered=3Dtrue. This =
will return a list of disk images that can be each used as input to the Imp=
ortImageCommand to get them added to oVirt.
ImportImageCommand will be accessible through "POST"ing a disk to /api/disk=
s?import=3Dtrue. The disk will be added to the oVirt DB based on the inform=
ation supplied and afterward would be available to attach to a VM.
When querying for unregistered disk images, the GetUnregisteredImagesQuery =
command will use the getImagesList() VDSM command. Currently this only repo=
rts the GUIDs of all disk images in a domain. I had been using the getVolum=
esList() and getVolumeInfo() VDSM commands to fill in the information so th=
at valid disk image objects could be registered in oVirt. It seems these tw=
o functions are set to be removed since they are too invasive into the inte=
rnal VDSM workings. The VDSM team will need to either return more informati=
on about each disk as part of the getImagesList() function or add a new fun=
ction getImageInfo() that will give the same information for a given image =
GUID.
Note that much of this work had originally been submitted under patch http:=
//gerrit.ovirt.org/#/c/9603/. After several reviews it was found to be lack=
ing in its design and was using deprecated APIs that did not yet have repla=
cements. I'm reworking the code now to conform to this design and asking fo=
r further input from the VDSM, core, and restapi teams to ensure we can get=
this done quickly and correctly as it is needed for the 3.2 release.
-Chris
Chris Morrissey
Software Engineer
NetApp Inc.
919.476.4428
--_000_D290AD8432118048947689BA3AE8A9B3094E3FDCSACEXCMBX04PRDh_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
<html xmlns:v=3D"urn:schemas-microsoft-com:vml"
xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word"
=
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml"
xmlns=3D"http:=
//www.w3.org/TR/REC-html40" <head <meta http-equiv=3D"Content-Type"
content=3D"text/html; charset=3Dus-ascii"=
<meta name=3D"Generator" content=3D"Microsoft
Word 14 (filtered medium)" <style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:windowtext;}
span.EmailStyle18
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" / </xml><![endif]--><!--[if gte mso
9]><xml <o:shapelayout
v:ext=3D"edit" <o:idmap v:ext=3D"edit"
data=3D"1" /
</o:shapelayout></xml><![endif]--
</head <body lang=3D"EN-US"
link=3D"blue" vlink=3D"purple" <div
class=3D"WordSection1" <p
class=3D"MsoNormal">Hi All,<o:p></o:p></p <p
class=3D"MsoNormal"><o:p> </o:p></p <p class=3D"MsoNormal">I’ve been
working on a bit of functionality fo=
r the engine that will allow a user to query a domain for new disk images (=
GetUnregisteredImagesQuery) for which the engine was previously unaware and=
a separate command to register those images
(ImportImageCommand). These commands will be exposed through the REST API.=
<o:p></o:p></p <p
class=3D"MsoNormal"><o:p> </o:p></p <p class=3D"MsoNormal">This functionality is
needed as we are developing an=
extension/plugin to oVirt that will allow a NetApp storage controller to h=
andle cloning the actual disks outside of oVirt and need to import them onc=
e they are cloned. We’ll be using
other existing APIs to attach the disk to the necessary VM once the disk i=
s cloned. On the NetApp side, we’ll ensure the disk is coalesced befo=
re cloning so as to avoid the issues of registering
snapshots.<o:p></o:p></=
p <p
class=3D"MsoNormal"><o:p> </o:p></p <p
class=3D"MsoNormal">GetUnregisteredImagesQuery will be accessible throug=
h the disks resource collection on a storage domain. A “disks” =
resource collection does not yet exist and will need to be added. To access=
the unregistered images, a parameter (maybe “unregistered=3DtrueR=
21;)
would be passed. So the path to “GET” the unregistered disk im=
ages on a domain would be something like /api/storagedomains/f0dbcb33-69d3-=
4899-9352-8e8a02f01bbd/disks?unregistered=3Dtrue. This will return a list o=
f disk images that can be each used as input to
the ImportImageCommand to get them added to oVirt.<o:p></o:p></p <p
class=3D"MsoNormal"><o:p> </o:p></p <p class=3D"MsoNormal">ImportImageCommand will
be accessible through “=
;POST”ing a disk to /api/disks?import=3Dtrue. The disk will be added =
to the oVirt DB based on the information supplied and afterward would be av=
ailable to attach to a VM.<o:p></o:p></p <p
class=3D"MsoNormal"><o:p> </o:p></p <p class=3D"MsoNormal">When querying for
unregistered disk images, the GetU=
nregisteredImagesQuery command will use the getImagesList() VDSM command. C=
urrently this only reports the GUIDs of all disk images in a domain. I had =
been using the getVolumesList() and
getVolumeInfo() VDSM commands to fill in the information so that valid dis=
k image objects could be registered in oVirt. It seems these two functions =
are set to be removed since they are too invasive into the internal VDSM wo=
rkings. The VDSM team will need
to either return more information about each disk as part of the getImages=
List() function or add a new function getImageInfo() that will give the sam=
e information for a given image GUID.<o:p></o:p></p <p
class=3D"MsoNormal"><o:p> </o:p></p <p class=3D"MsoNormal">Note that much of this
work had originally been subm=
itted under patch
<a
href=3D"http://gerrit.ovirt.org/#/c/9603/">http://gerrit.ovi...
603/</a>. After several reviews it was found to be lacking in its design an=
d was using deprecated APIs that did not yet have replacements. I’m r=
eworking the code now to conform to this
design and asking for further input from the VDSM, core, and restapi teams=
to ensure we can get this done quickly and correctly as it is needed for t=
he 3.2 release.<o:p></o:p></p <p
class=3D"MsoNormal"><o:p> </o:p></p <p
class=3D"MsoNormal">-Chris<o:p></o:p></p <p
class=3D"MsoNormal"><o:p> </o:p></p <p class=3D"MsoNormal"><b>Chris
Morrissey<o:p></o:p></b></p <p
class=3D"MsoNormal">Software Engineer<o:p></o:p></p <p class=3D"MsoNormal">NetApp
Inc.<o:p></o:p></p <p
class=3D"MsoNormal">919.476.4428<o:p></o:p></p <p
class=3D"MsoNormal"><o:p> </o:p></p </div
</body </html
--_000_D290AD8432118048947689BA3AE8A9B3094E3FDCSACEXCMBX04PRDh_--
8 a.m.
This is a multi-part message in MIME format.
--------------050809030206070109060801
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
2012-12-20 23:18, Morrissey, Christopher:
Hi All,
I've been working on a bit of functionality for the engine that will
allow a user to query a domain for new disk images
(GetUnregisteredImagesQuery) for which the engine was previously
unaware and a separate command to register those images
(ImportImageCommand). These commands will be exposed through the REST API.
This functionality is needed as we are developing an extension/plugin
to oVirt that will allow a NetApp storage controller to handle cloning
the actual disks outside of oVirt and need to import them once they
are cloned. We'll be using other existing APIs to attach the disk to
the necessary VM once the disk is cloned. On the NetApp side, we'll
ensure the disk is coalesced before cloning so as to avoid the issues
of registering snapshots.
I am just curious about how the third party tool like NetApp to make
sure the disk of a running VM coalesced before cloning? By an agent in
the VM to flush file-system cache out to the disk?
GetUnregisteredImagesQuery will be accessible through the disks
resource collection on a storage domain. A "disks" resource collection
does not yet exist and will need to be added. To access the
unregistered images, a parameter (maybe "unregistered=true") would be
passed. So the path to "GET" the unregistered disk images on a domain
would be something like
/api/storagedomains/f0dbcb33-69d3-4899-9352-8e8a02f01bbd/disks?unregistered=true.
This will return a list of disk images that can be each used as input
to the ImportImageCommand to get them added to oVirt.
ImportImageCommand will be accessible through "POST"ing a disk to
/api/disks?import=true. The disk will be added to the oVirt DB based
on the information supplied and afterward would be available to attach
to a VM.
When querying for unregistered disk images, the
GetUnregisteredImagesQuery command will use the getImagesList() VDSM
command. Currently this only reports the GUIDs of all disk images in a
domain. I had been using the getVolumesList() and getVolumeInfo() VDSM
commands to fill in the information so that valid disk image objects
could be registered in oVirt. It seems these two functions are set to
be removed since they are too invasive into the internal VDSM
workings. The VDSM team will need to either return more information
about each disk as part of the getImagesList() function or add a new
function getImageInfo() that will give the same information for a
given image GUID.
Here is the project proposal for floating disk in oVirt. I think
unregistered images are also floating disks.
http://www.ovirt.org/Features/DetailedFloatingDisk
Note that much of this work had originally been submitted under patch
http://gerrit.ovirt.org/#/c/9603/. After several reviews it was found
to be lacking in its design and was using deprecated APIs that did not
yet have replacements. I'm reworking the code now to conform to this
design and asking for further input from the VDSM, core, and restapi
teams to ensure we can get this done quickly and correctly as it is
needed for the 3.2 release.
-Chris
*Chris Morrissey*
Software Engineer
NetApp Inc.
919.476.4428
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
--
---
?? Shu Ming
Open Virtualization Engineerning; CSTL, IBM Corp.
Tel: 86-10-82451626 Tieline: 9051626 E-mail: shuming(a)cn.ibm.com or
shuming(a)linux.vnet.ibm.com
Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District, Beijing 100193,
PRC
--------------050809030206070109060801
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">2012-12-20 23:18, Morrissey,
Christopher:<br>
</div>
<blockquote
cite="mid:D290AD8432118048947689BA3AE8A9B3094E3FDC@SACEXCMBX04-PRD.hq.netapp.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<meta name="Generator" content="Microsoft Word 14 (filtered
medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:windowtext;}
span.EmailStyle18
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
<div class="WordSection1">
<p class="MsoNormal">Hi All,<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">I’ve been working on a bit of
functionality
for the engine that will allow a user to query a domain for
new disk images (GetUnregisteredImagesQuery) for which the
engine was previously unaware and a separate command to
register those images (ImportImageCommand). These commands
will be exposed through the REST API.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">This functionality is needed as we are
developing an extension/plugin to oVirt that will allow a
NetApp storage controller to handle cloning the actual disks
outside of oVirt and need to import them once they are cloned.
We’ll be using other existing APIs to attach the disk to the
necessary VM once the disk is cloned. On the NetApp side,
we’ll ensure the disk is coalesced before cloning so as to
avoid the issues of registering snapshots.</p>
</div>
</blockquote>
I am just curious about how the third party tool like NetApp to
make sure the disk of a running VM coalesced before cloning? By an
agent in the VM to flush file-system cache out to the disk?<br>
<br>
<blockquote
cite="mid:D290AD8432118048947689BA3AE8A9B3094E3FDC@SACEXCMBX04-PRD.hq.netapp.com"
type="cite">
<div class="WordSection1">
<p class="MsoNormal"><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">GetUnregisteredImagesQuery will be
accessible through the disks resource collection on a storage
domain. A “disks” resource collection does not yet exist
and
will need to be added. To access the unregistered images, a
parameter (maybe “unregistered=true”) would be passed. So
the
path to “GET” the unregistered disk images on a domain
would
be something like
/api/storagedomains/f0dbcb33-69d3-4899-9352-8e8a02f01bbd/disks?unregistered=true.
This will return a list of disk images that can be each used
as input to the ImportImageCommand to get them added to
oVirt.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">ImportImageCommand will be accessible
through “POST”ing a disk to /api/disks?import=true. The
disk
will be added to the oVirt DB based on the information
supplied and afterward would be available to attach to a
VM.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">When querying for unregistered disk images,
the GetUnregisteredImagesQuery command will use the
getImagesList() VDSM command. Currently this only reports the
GUIDs of all disk images in a domain. I had been using the
getVolumesList() and getVolumeInfo() VDSM commands to fill in
the information so that valid disk image objects could be
registered in oVirt. It seems these two functions are set to
be removed since they are too invasive into the internal VDSM
workings. The VDSM team will need to either return more
information about each disk as part of the getImagesList()
function or add a new function getImageInfo() that will give
the same information for a given image GUID.</p>
</div>
</blockquote>
<br>
Here is the project proposal for floating disk in oVirt. I think
unregistered images are also floating disks.<br>
<a class="moz-txt-link-freetext"
href="http://www.ovirt.org/Features/DetailedFloatingDisk">ht...
<br>
<blockquote
cite="mid:D290AD8432118048947689BA3AE8A9B3094E3FDC@SACEXCMBX04-PRD.hq.netapp.com"
type="cite">
<div class="WordSection1">
<p class="MsoNormal"><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Note that much of this work had originally
been submitted under patch
<a moz-do-not-send="true"
href="http://gerrit.ovirt.org/#/c/9603/">http://gerrit.ovirt...;.
After several reviews it was found to be lacking in its design
and was using deprecated APIs that did not yet have
replacements. I’m reworking the code now to conform to this
design and asking for further input from the VDSM, core, and
restapi teams to ensure we can get this done quickly and
correctly as it is needed for the 3.2 release.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">-Chris<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><b>Chris
Morrissey<o:p></o:p></b></p>
<p class="MsoNormal">Software
Engineer<o:p></o:p></p>
<p class="MsoNormal">NetApp Inc.<o:p></o:p></p>
<p
class="MsoNormal">919.476.4428<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Engine-devel mailing list
<a class="moz-txt-link-abbreviated"
href="mailto:Engine-devel@ovirt.org">Engine-devel@ovirt.org</a>
<a class="moz-txt-link-freetext"
href="http://lists.ovirt.org/mailman/listinfo/engine-devel">...
</pre>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="72">--
---
舒明 Shu Ming
Open Virtualization Engineerning; CSTL, IBM Corp.
Tel: 86-10-82451626 Tieline: 9051626 E-mail: <a
class="moz-txt-link-abbreviated"
href="mailto:shuming@cn.ibm.com">shuming@cn.ibm.com</a> or <a
class="moz-txt-link-abbreviated"
href="mailto:shuming@linux.vnet.ibm.com">shuming@linux.vnet.ibm.com</a>
Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District, Beijing 100193,
PRC</pre>
</body>
</html>
--------------050809030206070109060801--
10:57 a.m.
New subject: [Engine-devel] [vdsm] FW: Querying for and registering unknown disk images on a storage domain
On 12/23/2012 04:00 PM, Shu Ming wrote:
2012-12-20 23:18, Morrissey, Christopher:
>
> Hi All,
>
> I’ve been working on a bit of functionality for the engine that will
> allow a user to query a domain for new disk images
> (GetUnregisteredImagesQuery) for which the engine was previously
> unaware and a separate command to register those images
> (ImportImageCommand). These commands will be exposed through the REST API.
>
> This functionality is needed as we are developing an extension/plugin
> to oVirt that will allow a NetApp storage controller to handle cloning
> the actual disks outside of oVirt and need to import them once they
> are cloned. We’ll be using other existing APIs to attach the disk to
> the necessary VM once the disk is cloned. On the NetApp side, we’ll
> ensure the disk is coalesced before cloning so as to avoid the issues
> of registering snapshots.
>
I am just curious about how the third party tool like NetApp to make
sure the disk of a running VM coalesced before cloning? By an agent in
the VM to flush file-system cache out to the disk?
I'd expect either a livesnapshot before, or doing this on a VM which is
down.
> GetUnregisteredImagesQuery will be accessible through the disks
> resource collection on a storage domain. A “disks” resource collection
> does not yet exist and will need to be added. To access the
> unregistered images, a parameter (maybe “unregistered=true”) would be
> passed. So the path to “GET” the unregistered disk images on a domain
> would be something like
> /api/storagedomains/f0dbcb33-69d3-4899-9352-8e8a02f01bbd/disks?unregistered=true.
> This will return a list of disk images that can be each used as input
> to the ImportImageCommand to get them added to oVirt.
>
> ImportImageCommand will be accessible through “POST”ing a disk to
> /api/disks?import=true. The disk will be added to the oVirt DB based
> on the information supplied and afterward would be available to attach
> to a VM.
>
> When querying for unregistered disk images, the
> GetUnregisteredImagesQuery command will use the getImagesList() VDSM
> command. Currently this only reports the GUIDs of all disk images in a
> domain. I had been using the getVolumesList() and getVolumeInfo() VDSM
> commands to fill in the information so that valid disk image objects
> could be registered in oVirt. It seems these two functions are set to
> be removed since they are too invasive into the internal VDSM
> workings. The VDSM team will need to either return more information
> about each disk as part of the getImagesList() function or add a new
> function getImageInfo() that will give the same information for a
> given image GUID.
>
Here is the project proposal for floating disk in oVirt. I think
unregistered images are also floating disks.
http://www.ovirt.org/Features/DetailedFloatingDisk
floating disks are disks the engine is aware of, but not associated to
any VM.
the scan domain feature is to add "orphan" disks - disks on the storage
the engine isn't aware of to begin with.
3:44 p.m.
New subject: [Engine-devel] [vdsm] FW: Querying for and registering unknown disk images on a storage domain
-Chris
-----Original Message-----
From: Itamar Heim [mailto:iheim@redhat.com]
Sent: Sunday, December 23, 2012 11:58 AM
To: Shu Ming
Cc: Morrissey, Christopher; engine-devel(a)ovirt.org; vdsm-
devel(a)lists.fedorahosted.org
Subject: Re: [vdsm] [Engine-devel] FW: Querying for and registering
unknown disk images on a storage domain
On 12/23/2012 04:00 PM, Shu Ming wrote:
> 2012-12-20 23:18, Morrissey, Christopher:
>>
>> Hi All,
>>
>> I’ve been working on a bit of functionality for the engine that will
>> allow a user to query a domain for new disk images
>> (GetUnregisteredImagesQuery) for which the engine was previously
>> unaware and a separate command to register those images
>> (ImportImageCommand). These commands will be exposed through the
REST API.
>>
>> This functionality is needed as we are developing an extension/plugin
>> to oVirt that will allow a NetApp storage controller to handle
>> cloning the actual disks outside of oVirt and need to import them
>> once they are cloned. We’ll be using other existing APIs to attach
>> the disk to the necessary VM once the disk is cloned. On the NetApp
>> side, we’ll ensure the disk is coalesced before cloning so as to
>> avoid the issues of registering snapshots.
>>
> I am just curious about how the third party tool like NetApp to make
> sure the disk of a running VM coalesced before cloning? By an agent in
> the VM to flush file-system cache out to the disk?
I'd expect either a livesnapshot before, or doing this on a VM which is down.
Yes, we were planning on only allowing this type of operation on a VM which has been
stopped and if it is not a template, we would create a template in the background which
would ensure the disk is coalesced. All of this being done through the REST API which from
what I can tell is currently possible.
>
>> GetUnregisteredImagesQuery will be accessible through the disks
>> resource collection on a storage domain. A “disks” resource
>> collection does not yet exist and will need to be added. To access
>> the unregistered images, a parameter (maybe “unregistered=true”)
>> would be passed. So the path to “GET” the unregistered disk images on
>> a domain would be something like
>> /api/storagedomains/f0dbcb33-69d3-4899-9352-
8e8a02f01bbd/disks?unregistered=true.
>> This will return a list of disk images that can be each used as input
>> to the ImportImageCommand to get them added to oVirt.
>>
>> ImportImageCommand will be accessible through “POST”ing a disk to
>> /api/disks?import=true. The disk will be added to the oVirt DB based
>> on the information supplied and afterward would be available to
>> attach to a VM.
>>
>> When querying for unregistered disk images, the
>> GetUnregisteredImagesQuery command will use the getImagesList()
VDSM
>> command. Currently this only reports the GUIDs of all disk images in
>> a domain. I had been using the getVolumesList() and getVolumeInfo()
>> VDSM commands to fill in the information so that valid disk image
>> objects could be registered in oVirt. It seems these two functions
>> are set to be removed since they are too invasive into the internal
>> VDSM workings. The VDSM team will need to either return more
>> information about each disk as part of the getImagesList() function
>> or add a new function getImageInfo() that will give the same
>> information for a given image GUID.
>>
>
> Here is the project proposal for floating disk in oVirt. I think
> unregistered images are also floating disks.
> http://www.ovirt.org/Features/DetailedFloatingDisk
floating disks are disks the engine is aware of, but not associated to any VM.
the scan domain feature is to add "orphan" disks - disks on the storage the
engine isn't aware of to begin with.
4130
days inactive
4143
days old
3 comments
3 participants
participants (3)
-
Itamar Heim -
Morrissey, Christopher -
Shu Ming