[Engine-devel] FW: Querying for and registering unknown disk images on a storage domain

--_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.ovirt.org/#/c/9= 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_--

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@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@cn.ibm.com or shuming@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">http://www.ovirt.org/Features/DetailedFloatingDisk</a><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">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.org/#/c/9603/</a>. 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">http://lists.ovirt.org/mailman/listinfo/engine-devel</a> </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--

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.

-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@ovirt.org; vdsm- devel@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.
participants (3)
-
Itamar Heim
-
Morrissey, Christopher
-
Shu Ming