[PATCH] qemuDomainChangeDiskLive: Modify 'startupPolicy' before changing source

[Peter Krempa]

On Mon, Sep 13, 2021 at 13:56:45 +0200, Vojtech Juranek wrote:
> On Monday, 13 September 2021 13:30:45 CEST Nir Soffer wrote:
> > On Mon, Sep 13, 2021 at 11:04 AM Peter Krempa <pkrempa at redhat.com> wrote:
> > > On Fri, Sep 10, 2021 at 22:04:01 +0300, Nir Soffer wrote:
> > > > On Fri, Sep 10, 2021 at 4:35 PM Peter Krempa <pkrempa at redhat.com> wrote:

[...]

> > > On another note, I don't quite understand though why oVirt actually even
> > > uses startup policy in the first place. Since oVirt is already doing a
> > > pretty complicated storage management, checking whether the image file
> > > exists is a trivial operation.
> > 
> > In oVirt we know that the image exists since we prepare it before
> > starting the VM
> > (e.g. activate logical volume), and we will fail the operation if the
> > disk does not
> > exists, so I think this attribute is not needed for our use case and
> > it should be
> > removed.
> 
> +1
> 
> > > Similarly, when migrating you can use the destination XML (which can be
> > > optionally used with the migration API) allows you to update storage
> > > source and even provide empty storage for a cdrom. This can be used to
> > > update paths to storage too. This allows superior flexibility when
> > > compared to startup policy.
> > 
> > Even if we remove startupPolicy in new oVirt version, we have to
> > support migration
> > from an older version using startupPolicy in the xml.
> 
> What is the problem here? The issue happens only when you try to change the 
> CD, not during the migration, so there shouldn't be any problem (I also tried 
> it now and I can migrate VM with block-based CD without any issue). The issue 
> is there only when VM is started with empty CD or file-based CD, as in these 
> cases we added startupPolicy into the XML.

I assume that the problem is that removing 'startupPolicy' being added
to such configs would not fix the problem for older VMs which were
started with 'startupPolicy' being present thus you'd have to have the
code removing it anyways.

Live migration isn't a problem though as I've pointed out in a different
reply as you can drop it from the destination XML as it's not guest ABI.