<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Sep 13, 2021 at 4:10 PM Peter Krempa <<a href="mailto:pkrempa@redhat.com" target="_blank">pkrempa@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Fri, Sep 10, 2021 at 22:04:01 +0300, Nir Soffer wrote:<br>
> On Fri, Sep 10, 2021 at 4:35 PM Peter Krempa <<a href="mailto:pkrempa@redhat.com" target="_blank">pkrempa@redhat.com</a>> wrote:<br>
> ><br>
> > We don't support all startup policies with all source types so to<br>
> > correctly allow switching from a 'file' based cdrom with 'optional'<br>
> > startup policy to a 'block' based one which doesn't support optional we<br>
> > must update the startup policy field first. Obviously we need to have<br>
> > fallback if the update fails.<br>
> <br>
> Why is there a difference between file and block for startup policy?<br>
<br>
I'm not sure about the historic reasons for why 'block' was not<br>
considered when this was implemented originally.<br></blockquote><div>Hi Peter,</div><div>I searched in the commits history and found the error message """ 'startupPolicy' is only valid for 'file' type volume """ comes from</div><div>43404fee37(<a href="https://listman.redhat.com/archives/libvir-list/2013-April/msg00419.html" target="_blank">https://listman.redhat.com/archives/libvir-list/2013-April/msg00419.html</a>):</div><div>Author: Osier Yang <<a href="mailto:jyang@redhat.com" target="_blank">jyang@redhat.com</a>><br>Date:   Fri Apr 5 03:37:58 2013 +0800<br><br>    Support startupPolicy for 'volume' disk<br>    <br>    "startupPolicy" is only valid for file type storage volume, otherwise<br>    it fails on starting the domain.</div><div><br></div><div>But it's not clear why the author said  "startupPolicy" is not valid for block type.</div><div>Maybe we can have test on <a href="https://listman.redhat.com/archives/libvir-list/2021-September/msg00903.html">https://listman.redhat.com/archives/libvir-list/2021-September/msg00903.html</a> ,</div><div>to see if it fails to start the domain with startupPolicy and block disk type.<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> Is this documented?<br>
<br>
(citation from 'formatdomain.rst' the source for <a href="https://www.libvirt.org/formatdomain.html" rel="noreferrer" target="_blank">https://www.libvirt.org/formatdomain.html</a> )<br>
<br>
   For a "file" or "volume" disk type which represents a cdrom or floppy (the<br>
   ``device`` attribute), it is possible to define policy what to do with the<br>
   disk if the source file is not accessible. (NB, ``startupPolicy`` is not<br>
   valid for "volume" disk unless the specified storage volume is of "file"<br>
   type). This is done by the ``startupPolicy`` attribute ( :since:`since 0.9.7`<br>
   ), accepting these values:<br>
<br>
   ========= =====================================================================<br>
   mandatory fail if missing for any reason (the default)<br>
   requisite fail if missing on boot up, drop if missing on migrate/restore/revert<br>
   optional  drop if missing at any start attempt<br>
   ========= =====================================================================<br>
<br>
   :since:`Since 1.1.2` the ``startupPolicy`` is extended to support hard disks<br>
   besides cdrom and floppy. On guest cold bootup, if a certain disk is not<br>
   accessible or its disk chain is broken, with startupPolicy 'optional' the<br>
   guest will drop this disk. This feature doesn't support migration currently.<br>
<br>
As you can notice only "file" and "volume" (pointing to a file) are<br>
allowed.<br>
<br>
> Do we have a way to switch from file to block with current libvirt<br>
> (centos 8 stream, rhel 8.4) without this patch, or do we need to wait<br>
> until this fix is available? (rhel 8.5?)<br>
<br>
You can issue two separate update calls. One updating the startup policy<br>
first and then the second one updating the source.<br>
<br>
On another note, I don't quite understand though why oVirt actually even<br>
uses startup policy in the first place. Since oVirt is already doing a<br>
pretty complicated storage management, checking whether the image file<br>
exists is a trivial operation.<br>
<br>
Similarly, when migrating you can use the destination XML (which can be<br>
optionally used with the migration API) allows you to update storage<br>
source and even provide empty storage for a cdrom. This can be used to<br>
update paths to storage too. This allows superior flexibility when<br>
compared to startup policy.<br>
<br>
</blockquote></div></div>