Open Stack

On Mon, Sep 26, 2016 at 09:31:39PM +0800, Alex Xu wrote:
> 2016-09-23 20:38 GMT+08:00 Daniel P. Berrange <berrange at redhat.com>:
> 
> > On Fri, Sep 23, 2016 at 07:32:36AM -0500, Matt Riedemann wrote:
> > > On 9/23/2016 3:54 AM, Daniel P. Berrange wrote:
> > > > On Thu, Sep 22, 2016 at 01:54:21PM -0500, Matt Riedemann wrote:
> > > > > Sergey is working on a spec to use the standardized virt driver
> > instance
> > > > > diagnostics in the os-diagnostics API. A question came up during
> > review of
> > > > > the spec about how to define a disk 'id':
> > > > >
> > > > > https://review.openstack.org/#/c/357884/2/specs/ocata/
> > approved/restore-vm-diagnostics.rst at 140
> > > > >
> > > > > The existing diagnostics code doesn't set a disk id in the list of
> > disk
> > > > > dicts, but I think with at least libvirt we can set that to the
> > target
> > > > > device from the disk device xml.
> > > > >
> > > > > The xenapi code for getting this info is a bit confusing for me at
> > least,
> > > > > but it looks like it's possible to get the disks, but the id might
> > need to
> > > > > be parsed out (as a side note, it looks like the cpu/memory/disk
> > diagnostics
> > > > > are not even populated in the get_instance_diagnostics method for
> > xen).
> > > > >
> > > > > vmware is in the same boat as xen, it's not fully implemented:
> > > > >
> > > > > https://github.com/openstack/nova/blob/
> > 64cbd7c51a5a82b965dab53eccfaecba45be9c27/nova/virt/
> > vmwareapi/vmops.py#L1561
> > > > >
> > > > > Hyper-v and Ironic virt drivers haven't implemented
> > get_instance_diagnostics
> > > > > yet.
> > > >
> > > > The key value of this field (which we should call "device_name", not
> > "id"),
> > > > is to allow the stats data to be correlated with the entries in the
> > block
> > > > device mapping list used to configure storage when bootin the VM. As
> > such
> > > > we should declare its value to match the corresponding field in BDM.
> > > >
> > > > Regards,
> > > > Daniel
> > > >
> > >
> > > Well, except that we don't want people specifying a device name in the
> > block
> > > device list when creating a server, and the libvirt driver ignores that
> > > altogether. In fact, I think Dan Smith was planning on adding a
> > microversion
> > > in Ocata to remove that field from the server create request since we
> > can't
> > > guarantee it's what you'll end up with for all virt drivers.
> >
> > We don't want people specifying it, but we should report the auto-allocated
> > names back when you query the data after instance creation, don't we ? If
> > we don't, then there's no way for users to correlate the disks that they
> > requested with the instance diagnostic stats, which severely limits their
> > usefulness.
> >
> 
> So what use-case for this API? I thought it is used by admin user to
> diagnose the cloud. If that is the right use-case, we can expose the disk
> image path in the API for admin user to correlate the disks. In the
> libvirt, it would looks like
> "/opt/stack/data/nova/instances/cbc7985c-434d-4ec3-8d96-d99ad6afb618/disk".
> As this is admin-only API, and for diagnostics, this info is safe to expose
> in this API.

You can't assume that all disks have a local path in the filesystem.
Any disks using a QEMU built-in network client (eg rbd) will not
appear there.


Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|