<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Hi Sean,<br>
<br>
thanks for the responce, my questions and comments below.<br>
<br>
<div class="moz-cite-prefix">On 6/25/18 9:42 PM, Sean McGinnis
wrote:<br>
<br>
<blockquote type="cite"
cite="mid:20180625184247.GA20692@sm-workstation">
<pre wrap="">Not sure if it's an option for you, but in the Pike release support was added
to be able to extend attached volumes. There are several caveats with this
feature though. I believe it only works with libvirt, and if I remember right,
only newer versions of libvirt. You need to have notifications working for Nova
to pick up that Cinder has extended the volume.</pre>
</blockquote>
Pike release notes states the following: "It is now possible to
signal and perform an online volume size change as of the 2.51
microversion using the volume-extended external event. Nova will
perform the volume extension so the host can detect its new size.
It will also resize the device in QEMU so instance can detect the
new disk size without rebooting. Currently only the <b>libvirt
compute driver with iSCSI and FC volumes supports the online
volume size change</b>." And yes, it doesn't work for me since
I'm using CEPH as backend.<br>
<br>
Queens release notes says nothing on changes. Feature matrix
(<a class="moz-txt-link-freetext" href="https://docs.openstack.org/nova/queens/user/support-matrix.html">https://docs.openstack.org/nova/queens/user/support-matrix.html</a>)
says it's supported on libvirt/x86 without any other further
details. Does anybody know whether this feature implemented in
Queens for other backends except iSCSI and FC?<br>
<br>
Mentioned earlier spec are talking about how to make result of
resize to be visible to VM immediately upon resize, without
restarting VM, while I don't asking for this. My question is how
to resize volume and make it available after restart, see below<br>
<br>
</div>
<blockquote type="cite"
cite="mid:20180625184247.GA20692@sm-workstation">
<blockquote type="cite">
<pre wrap="">In fact, I'm ok with delayed resize (upon power-cycle), and it's not an
issue for me that VM don't detect changes immediately. What I want to
understand is that changes to Cinder (and, thus, underlying changes to CEPH)
are safe for VM while it's in active state.
</pre>
</blockquote>
<pre wrap="">
No, this is not considered safe. You are forcing the volume state to be
availabile when it is in fact not.</pre>
</blockquote>
<br>
In very general case, I agree with you. For example, I can imagine
that allocation of new blocks can fail if volume is declared as
available, but, in particular case of CEPH:<br>
<br>
- in short:<br>
# status of volume in Cinder means nothing to CEPH<br>
<br>
- in details:<br>
# while Cinder do provisioning and maintenance<br>
# kvm/libvirt work directly with CEPH (after got this endpoint from
<-Nova<-Cinder)<br>
# and I see no changes in CEPH's status of volume while it is
available in Cinder:<br>
<br>
* in-use:<br>
<tt>$ rbd info volumes/volume-5474ca4f-40ad-4151-9916-d9b4e9de14eb</tt><tt><br>
</tt><tt>rbd image 'volume-5474ca4f-40ad-4151-9916-d9b4e9de14eb':</tt><tt><br>
</tt><tt> size 20480 MB in 5120 objects</tt><tt><br>
</tt><tt> order 22 (4096 kB objects)</tt><tt><br>
</tt><tt> block_name_prefix: rbd_data.2414a7572c9f46</tt><tt><br>
</tt><tt> format: 2</tt><tt><br>
</tt><tt> features: layering, exclusive-lock, object-map,
fast-diff, deep-flatten</tt><tt><br>
</tt><tt> flags:</tt><tt><br>
</tt><tt> create_timestamp: Mon Jun 25 10:47:03 2018</tt><tt><br>
</tt><tt> parent:
<a class="moz-txt-link-abbreviated" href="mailto:volumes/volume-42edf442-1dbb-4b6e-8593-1fbfbc821a1a@volume-5474ca4f-40ad-4151-9916-d9b4e9de14eb.clone_snap">volumes/volume-42edf442-1dbb-4b6e-8593-1fbfbc821a1a@volume-5474ca4f-40ad-4151-9916-d9b4e9de14eb.clone_snap</a></tt><tt><br>
</tt><tt> overlap: 3072 MB</tt><tt><br>
</tt><br>
* available:<br>
<tt>$ rbd info volumes/volume-5474ca4f-40ad-4151-9916-d9b4e9de14eb</tt><tt><br>
</tt><tt>rbd image 'volume-5474ca4f-40ad-4151-9916-d9b4e9de14eb':</tt><tt><br>
</tt><tt> size 20480 MB in 5120 objects</tt><tt><br>
</tt><tt> order 22 (4096 kB objects)</tt><tt><br>
</tt><tt> block_name_prefix: rbd_data.2414a7572c9f46</tt><tt><br>
</tt><tt> format: 2</tt><tt><br>
</tt><tt> features: layering, exclusive-lock, object-map,
fast-diff, deep-flatten</tt><tt><br>
</tt><tt> flags:</tt><tt><br>
</tt><tt> create_timestamp: Mon Jun 25 10:47:03 2018</tt><tt><br>
</tt><tt> parent:
<a class="moz-txt-link-abbreviated" href="mailto:volumes/volume-42edf442-1dbb-4b6e-8593-1fbfbc821a1a@volume-5474ca4f-40ad-4151-9916-d9b4e9de14eb.clone_snap">volumes/volume-42edf442-1dbb-4b6e-8593-1fbfbc821a1a@volume-5474ca4f-40ad-4151-9916-d9b4e9de14eb.clone_snap</a></tt><tt><br>
</tt><tt> overlap: 3072 MB</tt><br>
<br>
# and, during copying data, CEPH successfully allocates additional
blocks to the volume:<br>
<br>
* before copying (volume is already available in Cinder)<br>
<tt>$ rbd du volumes/volume-5474ca4f-40ad-4151-9916-d9b4e9de14eb</tt><tt><br>
</tt><tt>NAME PROVISIONED
USED</tt><tt><br>
</tt><tt>volume-5474ca4f-40ad-4151-9916-d9b4e9de14eb 20480M <b>2256M</b></tt><br>
<br>
* after copying (while volume is available in Cinder)<br>
<tt>$ rbd du volumes/volume-5474ca4f-40ad-4151-9916-d9b4e9de14eb</tt><tt><br>
</tt><tt>NAME PROVISIONED
USED</tt><tt><br>
</tt><tt>volume-5474ca4f-40ad-4151-9916-d9b4e9de14eb 20480M <b>2560M</b></tt><br>
<br>
# which preserved after back to in-use:<br>
<tt>$ rbd du volumes/volume-5474ca4f-40ad-4151-9916-d9b4e9de14eb</tt><tt><br>
</tt><tt>NAME PROVISIONED
USED</tt><tt><br>
</tt><tt>volume-5474ca4f-40ad-4151-9916-d9b4e9de14eb 20480M <b>2560M</b></tt><tt><br>
$ rbd info volumes/volume-5474ca4f-40ad-4151-9916-d9b4e9de14eb<br>
rbd image 'volume-5474ca4f-40ad-4151-9916-d9b4e9de14eb':<br>
size 20480 MB in 5120 objects<br>
order 22 (4096 kB objects)<br>
block_name_prefix: rbd_data.2414a7572c9f46<br>
format: 2<br>
features: layering, exclusive-lock, object-map, fast-diff,
deep-flatten<br>
flags:<br>
create_timestamp: Mon Jun 25 10:47:03 2018<br>
parent:
<a class="moz-txt-link-abbreviated" href="mailto:volumes/volume-42edf442-1dbb-4b6e-8593-1fbfbc821a1a@volume-5474ca4f-40ad-4151-9916-d9b4e9de14eb.clone_snap">volumes/volume-42edf442-1dbb-4b6e-8593-1fbfbc821a1a@volume-5474ca4f-40ad-4151-9916-d9b4e9de14eb.clone_snap</a><br>
overlap: 3072 MB<br>
</tt><br>
Actually, the only problem with safety I see is possible
administrative race - since volume is available, cloud administrator
or any kind of automation can break dependencies. If this is fully
controlled environment (nobody else can modify it in any way or
reattach it to other instance or make anything else with the
volume), which other kinds of problems can appear in this case?<br>
<br>
Thank you.<br>
<br>
<blockquote type="cite"
cite="mid:20180625184247.GA20692@sm-workstation">
<pre wrap="">You can get some details from the cinder spec:
<a class="moz-txt-link-freetext" href="https://specs.openstack.org/openstack/cinder-specs/specs/pike/extend-attached-volume.html">https://specs.openstack.org/openstack/cinder-specs/specs/pike/extend-attached-volume.html</a>
And the corresponding Nova spec:
<a class="moz-txt-link-freetext" href="http://specs.openstack.org/openstack/nova-specs/specs/pike/implemented/nova-support-attached-volume-extend.html">http://specs.openstack.org/openstack/nova-specs/specs/pike/implemented/nova-support-attached-volume-extend.html</a>
You may also want to read through the mailing list thread if you want to get in
to some of the nitty gritty details behind why certain design choices were
made:
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/pipermail/openstack-dev/2017-April/115292.html">http://lists.openstack.org/pipermail/openstack-dev/2017-April/115292.html</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Volodymyr Litovka
"Vision without Execution is Hallucination." -- Thomas Edison</pre>
</body>
</html>