On Wed, Aug 05, 2026 at 10:47:34AM +0100, Daniel P. Berrangé wrote:
On Wed, Aug 05, 2026 at 10:29:16AM +0100, Richard W.M. Jones wrote:
On Mon, Aug 03, 2026 at 11:54:44AM +0100, Daniel P. Berrangé via Libguestfs wrote:
On Mon, Aug 03, 2026 at 01:45:44PM +0530, Srihari Parimi via Libguestfs wrote:
Hi Richard,
This is a more comprehensive description of the problem, where I respond to the specific issue and questions that you brought up during the discussion last week. I also cover the proposed solution towards the end. Kindly bear with the somewhat longish one
What thread is this all in response to ? AFAICT, there's nothing in the list archives with this subjct.
I believe it's related to this confusing upstream pull request:
https://github.com/libguestfs/virt-v2v/pull/160
- The kernel device discovery (names /dev/sd*) is non-deterministic as it is based on order of driver initialization at the boot time. The order variation is due to asynchronous driver probe, kernel update or VM configuration changes.
Conceptually I agree, but in practice this is does not look like an actual problem. If the original guest before v2v was using device names already, then it must have been OK, unless the guest was already broken in some way.
[Note this is largely unrelated to the PR above.]
We've been discussing if it's a good idea to simply replace any /dev/XdX device reference with a UUID, where possible, for a few reasons:
(1) A kernel upgrade can break an existing working guest.
(2) Admins use device references wrongly, and it mostly works but occasionally breaks. For example it can work fine until you add a second disk and then it becomes intermittently flakey.
(3) It allows you to move devices around or change drivers in future without breaking the guest.
Basically it's just a good idea to use UUIDs to reference filesystems.
I agree, but I'm very sceptical that v2v should be forcing that decision on users during a VM conversion.
The con is that we want to make as few changes as possible, because every change we make in v2v can have unintended consequences when used at the scale of conversions we are doing now.
Yep, there may be reasons an org chose to use device names that we are not aware of.
If an organization has a corporate standard provisioning workflow that uses device names, we should honour that in VMs we convert IMHO.
Sure, I agree. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com nbdkit - Flexible, fast NBD server with plugins https://gitlab.com/nbdkit/nbdkit