[virt-tools-list] [virt-manager] Disk target generation for new machines

[Martin Kletzander]

On 07/09/2013 02:50 PM, Cole Robinson wrote:
> On 07/09/2013 06:18 AM, Martin Kletzander wrote:
>> Hi,
>>
>> I'm trying to fix one problem in VMM and after several hours, I came to
>> a conclusion that I'll ask on a list for hints.  When creating new
>> machine, we create a disk without bus/target and thus there is a
>> conflict in case user adds one more disk with the default bus.  The
>> problem is that the new disk gets generates target like 'vda' (neither
>> target nor bus are known for the default disk, so the targets that
>> should be skipped contain only '[None, None]').
>>
>> I managed to "fix" it simply by the following patch (which should be
>> applied anyway, since it fixes one apparent problem itself), but the
>> problem with the approach is that the default disk gets generated after
>> all the other disks ('vdb' if you add one disk).  Removing all the
>> targets is obviously not a choice.
>>
> 
> Yeah this stuff is a mess. This stuff was originally made complicated by the
> virtinst/virt-manager split so going forward we have an option to clean it up.
> 
> virt-manager is also fundamentally lacking an important bit here which is
> reordering disks in the UI. There's a couple bugs that this feature will solve
> at least.
> 
> So this is caused by virt-manager-New VM->customize->addhw->disk ? It's hacky,
> but you could pass a value vmmDetails.is_customize_dialog to vmmAddHardware,
> and if set, don't generate a target for any added disk device. Then it's just
> integrated into the set_defaults fold.
> 
> And if the patch below is still valuable, please post it as a top level mail
> with reproducer steps because I can't quite tell what it fixes by inspection.
> 

Thanks a lot for such quick response.  I couldn't think about anything
else, so I couldn't stop poking around that and in the meantime found
out a way to solve it with few lines.  You can have a look at that, I
think it's a bit less hacky.  Sorry I did it another way, then.

The patch might be still valuable (first going through the assigned
controller targets and then generating the rest), but I can't think of
any reproducer, it was more like a "for the future" or "in case
something gets changed" type of patch.

>> But when the additional disk gets added, all the data for the default
>> disk is already visible in the guest XML.  So I'm wondering where the
>> problem is.  Either we should be calling redefine_cached() somewhere to
>> get the data back into structures or something.  I can't seem to find
>> where the disk gets its 'bus' property set.
>>
> 
> bus property is set from Guest.set_defaults.
> 

Yes, that's the place I was looking for :)

Have a nice day,
Martin