[pve-devel] [PATCH qemu-server 1/1] fix #1905: Allow moving unused disks

Filip Schauer f.schauer at proxmox.com
Tue Mar 5 14:12:39 CET 2024


After a bit of research, here is a more descriptive commit message:


Allow moving unused disks to another storage

In the past, moving unused disks to another storage was prohibited due
to oversights in the handling of unused disks. This commit rectifies
this limitation by allowing the movement of unused disks.

Historical context:
* 16 Sep 2010 r5164 qemu-server/pve2: The disknames sub was removed.
* 17 Sep 2010 r5170 qemu-server/pve2: Unused disks were introduced.
* 28 Jan 2011 r5461 qemu-server/pve2: The same disknames sub that was
   removed in r5164 was brought back. Since unused disks were not around
   yet in r5164 the disknames sub did not consider unused disks.
* 6-8 Aug 2012 c1175c92..f91b2e45 qemu-server.git: Disk resize was
   introduced. In commit c1175c92 in sub qemu_block_resize unused disks
   were not taken into account and in commit 2f48a4f5 (8 Aug 2012) the
   resize API call was changed to only allow disks matching the ones in
   the disknames sub. Since sub disknames did not contain any unused
   disks, those were not allowed at all in the resize API call.
* 27 May 2013 586bfa78 qemu-server.git: Disk move was introduced. The
   API call implementation borrowed heavily from disk resize, including
   the behaviour of not taking unused disks into account. Thus, unused
   disk could not be moved, which persists to this day.

In summary, this behaviour was introduced because the handling of unused
disks was overlooked and it was never changed.

There is no inherent reason why unused disks should be restricted from
being moved to another storage. These disks cannot use the
qemu_drive_mirror, but they can still be moved with qemu_img_convert,
the same way as any other disk of a stopped VM.


On 19/02/2024 13:22, Thomas Lamprecht wrote:
> Am 19/02/2024 um 12:11 schrieb Filip Schauer:
>> Allow moving unused/detached disks to another storage.
> this is a repetition of the commit subject, while that is on it's
> own OK, I'd rather see a description about why this is OK to do, i.e.,
> why was the original check added, what changed since then, what are
> the drawbacks, e.g., as the QEMU block-mirror cannot be used I imagine
> only a limited set of source storage to target storage can be used
> for this?




More information about the pve-devel mailing list