<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Jun 16, 2016 at 4:20 PM, Kashyap Chamarthy <span dir="ltr"><<a href="mailto:kchamart@redhat.com" target="_blank">kchamart@redhat.com</a>></span> wrote:<br><div>[...] </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> BlockDeviceMapping<br>
> ===============<br>
><br>
> The 'top level' data structure is the block device mapping object. It is a<br>
> NovaObject, persisted in the db. Current code creates a BDM object for<br>
> every disk associated with an instance, whether it is a volume or not. I<br>
> can't confirm (or deny) that this has always been the case, though, so<br>
> there may be instances which still exist which have some BDMs missing.<br>
><br>
> The BDM object describes properties of each disk as specified by the user.<br>
> It is initially created by the user and passed to compute api. Compute api<br>
> transforms and consolidates all BDMs to ensure that all disks, explicit or<br>
> implicit, have a BDM, then persists them.<br>
<br>
</span>What could be an example of an "implicit disk"?<br></blockquote><div><br></div><div>If the flavor defines an ephemeral disk which the user did not specify explicitly, it will be added. Possibly others, I'm not looking at that code right now.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
> Look in nova.objects.block_device<br>
> for all BDM fields, but in essence they contain information like<br>
> (source_type='image', destination_type='local', image_id='<image uuid'>),<br>
> or equivalents describing ephemeral disks, swap disks or volumes, and some<br>
> associated data.<br>
><br>
> Reader note: BDM objects are typically stored in variables called 'bdm'<br>
> with lists in 'bdms', although this is obviously not guaranteed (and<br>
> unfortunately not always true: bdm in libvirt.block_device is usually a<br>
> DriverBlockDevice object). This is a useful reading aid (except when it's<br>
> proactively confounding), as there is also something else typically called<br>
> 'block_device_mapping' which is not a BlockDeviceMapping object.<br>
<br>
</span>[...]<span class=""><br>
<br>
> instance_disk_info<br>
> =============<br>
><br>
> The driver api defines a method get_instance_disk_info, which returns a<br>
> json blob. The compute manager calls this and passes the data over rpc<br>
> between calls without ever looking at it. This is driver-specific opaque<br>
> data. It is also only used by the libvirt driver, despite being part of the<br>
> api for all drivers. Other drivers do not return any data. The most<br>
> interesting aspect of instance_disk_info is that it is generated from the<br>
> libvirt XML, not from nova's state.<br>
><br>
> Reader beware: instance_disk_info is often named 'disk_info' in code, which<br>
> is unfortunate as this clashes with the normal naming of the next<br>
> structure. Occasionally the two are used in the same block of code.<br>
><br>
> instance_disk_info is a list of dicts for some of an instance's disks.<br>
<br>
</span>The above sentence reads a little awkward (maybe it's just me), might<br>
want to rephrase it if you're submitting it as a Gerrit change.<br></blockquote><div><br></div><div>Yeah. I think that's a case of re-editing followed by inadequate proof reading.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
While reading this section, among other places, I was looking at:<br>
_get_instance_disk_info() ("Get the non-volume disk information from the<br>
domain xml") from nova/virt/libvirt/driver.py.<br></blockquote><div><br></div><div>non-volume or Rbd ;) I've become a bit cautious about such docstrings: they aren't always correct :/</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
> Reader beware: Rbd disks (including non-volume disks) and cinder volumes<br>
> are not included in instance_disk_info.<br>
><br>
> The dicts are:<br>
><br>
> {<br>
> 'type': libvirt's notion of the disk's type<br>
> 'path': libvirt's notion of the disk's path<br>
> 'virt_disk_size': The disk's virtual size in bytes (the size the guest<br>
> OS sees)<br>
> 'backing_file': libvirt's notion of the backing file path<br>
> 'disk_size': The file size of path, in bytes.<br>
> 'over_committed_disk_size': As-yet-unallocated disk size, in bytes.<br>
> }<br>
><br>
> disk_info<br>
> =======<br>
><br>
> Reader beware: as opposed to instance_disk_info, which is frequently called<br>
> disk_info.<br>
><br>
> This data structure is actually described pretty well in the comment block<br>
> at the top of libvirt/blockinfo.py. It is internal to the libvirt driver.<br>
> It contains:<br>
><br>
> {<br>
> 'disk_bus': the default bus used by disks<br>
> 'cdrom_bus': the default bus used by cdrom drives<br>
> 'mapping': defined below<br>
> }<br>
><br>
> 'mapping' is a dict which maps disk names to a dict describing how that<br>
> disk should be passed to libvirt. This mapping contains every disk<br>
> connected to the instance, both local and volumes.<br>
<br>
</span>Worth updating exising defintion of 'mapping' in<br>
nova/virt/libvirt/blockinfo.py with your above clearer description<br>
above?<br></blockquote><div><br></div><div>Indubitably.</div><div><br></div><div>Matt</div></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><span style="font-size:12.8px">Matthew Booth</span><br></div><div>Red Hat Engineering, Virtualisation Team</div><div><br></div><div>Phone: +442070094448 (UK)</div><div><br></div></div></div></div></div>
</div></div>