Re: [PATCH] qemuDomainChangeDiskLive: Modify 'startupPolicy' before changing source
On Mon, Sep 13, 2021 at 14:30:45 +0300, Nir Soffer wrote:
On Mon, Sep 13, 2021 at 11:04 AM Peter Krempa
<pkrempa(a)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(a)redhat.com> wrote:
[...]
> > Do we have a way to switch from file to block with current
libvirt
> > (centos 8 stream, rhel 8.4) without this patch, or do we need to wait
> > until this fix is available? (rhel 8.5?)
>
> You can issue two separate update calls. One updating the startup policy
> first and then the second one updating the source.
If the second call fails, this leave us with half of the change.
Based on what you write below, where you state that you actually make
sure that the image exists it seems that it should not be a problem at
all.
Specifically just removing startupPolicy has no guest visible change so
it's allowed on migration and other cases.
Just removing it from an empty drive has no effect other than recording
it in the libvirt metadata.
Removing it from a full cdrom could have semantic effects on migration
but they are removed by oVirt actually checking before. Same for start
of a new VM where you always re-define the XML anyways.
> 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.
> 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.
Speaking of live migration you can remove it from the destination XML,
since startup policy is exempt from the ABI stability check ... well
technically it's not even ABI.
The only case where it could be a problem is when upgrading existing
host as the running VMs would still have it.