[ovirt-users] Re: Drive letter / scsi id not consistent

Hi Nathan, Sounds like a UI problem. Can you post a screenshot just to make sure I'm following? Best wishes, Greg On Thu, Jul 19, 2018 at 8:02 PM Nathan March <nathan(a)shadow.sh&gt; wrote: > Hi, > > Managing disks in the ovirt gui seems completely error prone since the > GUI ordering does not seem to be used in any practical way. The scsi ID's > are not exposed via the GUI either, so if you have 2 drives of the same > size on NFS there's no way to identify which is which without resorting to > dumping the xml. > > I see in the xml that the target dev is correct and matches up with the > GUI's drive order, but the scsi unit seems to be generated based on the > order of last activated: > > <disk type='file' device='disk' snapshot='no'> > <driver name='qemu' type='raw' cache='none' error_policy='stop' > io='threads'/> > <source file='/rhev/data-center/mnt/10.1.32.10:_sas01/2060a19f- > f26c-4dba-a559-83541a4d0c7a/images/b622cde9-ffc4-487b- > 8038-f7cb7fbc00a1/7240b4b2-5ab1-40ab-99bb-09c69fd835f6'/> > <backingStore/> > <target dev='sda' bus='scsi'/> > <serial>b622cde9-ffc4-487b-8038-f7cb7fbc00a1</serial> > <boot order='1'/> > <alias name='ua-b622cde9-ffc4-487b-8038-f7cb7fbc00a1'/> > <address type='drive' controller='0' bus='0' target='0' unit='1'/> > </disk> > <disk type='file' device='disk' snapshot='no'> > <driver name='qemu' type='raw' cache='none' error_policy='stop' > io='threads'/> > <source file='/rhev/data-center/mnt/10.1.32.10:_sas01/2060a19f- > f26c-4dba-a559-83541a4d0c7a/images/86765f60-4240-44f4- > b437-f22b2cc3df1a/482a363e-461a-4f37-876c-43ceb529a93a'/> > <backingStore/> > <target dev='sdb' bus='scsi'/> > <serial>86765f60-4240-44f4-b437-f22b2cc3df1a</serial> > <alias name='ua-86765f60-4240-44f4-b437-f22b2cc3df1a'/> > <address type='drive' controller='0' bus='0' target='0' unit='0'/> > </disk> > <disk type='file' device='disk' snapshot='no'> > <driver name='qemu' type='raw' cache='none' error_policy='stop' > io='threads'/> > <source file='/rhev/data-center/mnt/10.1.32.10:_sas01/2060a19f- > f26c-4dba-a559-83541a4d0c7a/images/0b020d24-3dea-4be7- > 931a-9c25ccfeec48/7e3957ff-a3bf-4080-a7b6-ddad7f63a299'/> > <backingStore/> > <target dev='sdc' bus='scsi'/> > <serial>0b020d24-3dea-4be7-931a-9c25ccfeec48</serial> > <alias name='scsi0-0-0-3'/> > <address type='drive' controller='0' bus='0' target='0' unit='3'/> > </disk> > > After deactivating the other 2 disks and rebooting the machine, sda has > now become unit 3: > > <target dev='sda' bus='scsi'/> > <serial>b622cde9-ffc4-487b-8038-f7cb7fbc00a1</serial> > <boot order='1'/> > <alias name='ua-b622cde9-ffc4-487b-8038-f7cb7fbc00a1'/> > <address type='drive' controller='0' bus='0' target='0' unit='3'/> > > and then I shutdown, activated the extra 2 drives, booted it back up but > now I'm still on unit 3: > > <disk type='file' device='disk' snapshot='no'> > <driver name='qemu' type='raw' cache='none' error_policy='stop' > io='threads'/> > <source file='/rhev/data-center/mnt/10.1.32.10:_sas01/2060a19f- > f26c-4dba-a559-83541a4d0c7a/images/b622cde9-ffc4-487b- > 8038-f7cb7fbc00a1/7240b4b2-5ab1-40ab-99bb-09c69fd835f6'/> > <backingStore/> > <target dev='sda' bus='scsi'/> > <serial>b622cde9-ffc4-487b-8038-f7cb7fbc00a1</serial> > <boot order='1'/> > <alias name='ua-b622cde9-ffc4-487b-8038-f7cb7fbc00a1'/> > <address type='drive' controller='0' bus='0' target='0' unit='3'/> > </disk> > <disk type='file' device='disk' snapshot='no'> > <driver name='qemu' type='raw' cache='none' error_policy='stop' > io='threads'/> > <source file='/rhev/data-center/mnt/10.1.32.10:_sas01/2060a19f- > f26c-4dba-a559-83541a4d0c7a/images/86765f60-4240-44f4- > b437-f22b2cc3df1a/482a363e-461a-4f37-876c-43ceb529a93a'/> > <backingStore/> > <target dev='sdb' bus='scsi'/> > <serial>86765f60-4240-44f4-b437-f22b2cc3df1a</serial> > <alias name='ua-86765f60-4240-44f4-b437-f22b2cc3df1a'/> > <address type='drive' controller='0' bus='0' target='0' unit='0'/> > </disk> > <disk type='file' device='disk' snapshot='no'> > <driver name='qemu' type='raw' cache='none' error_policy='stop' > io='threads'/> > <source file='/rhev/data-center/mnt/10.1.32.10:_sas01/2060a19f- > f26c-4dba-a559-83541a4d0c7a/images/0b020d24-3dea-4be7- > 931a-9c25ccfeec48/7e3957ff-a3bf-4080-a7b6-ddad7f63a299'/> > <backingStore/> > <target dev='sdc' bus='scsi'/> > <serial>0b020d24-3dea-4be7-931a-9c25ccfeec48</serial> > <alias name='ua-0b020d24-3dea-4be7-931a-9c25ccfeec48'/> > <address type='drive' controller='0' bus='0' target='0' unit='1'/> > </disk> > > I managed to get things into the correct state by shutting down the VM, > deactivating all the disks, then activating them in the order I want them > to show up. This sets the correct order of unit 0 for sda, unit 1 for sdb, > unit 2 for sdc. > > Is there some way to make ovirt treat this in a sane way and always > expose the scsi devices in the same order as the GUI (and the "target dev" > field)? > > Cheers! > > Nathan > _______________________________________________ > Users mailing list -- users(a)ovirt.org > To unsubscribe send an email to users-leave(a)ovirt.org > Privacy Statement: https://www.ovirt.org/site/privacy-policy/ > oVirt Code of Conduct: https://www.ovirt.org/community/about/community- > guidelines/ > List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/ > message/F7SQIFHHPR52NS6U52UY7LYUUMOQOSEQ/ > -- GREG SHEREMETA SENIOR SOFTWARE ENGINEER - TEAM LEAD - RHV UX Red Hat NA <https://www.redhat.com/> gshereme(a)redhat.com IRC: gshereme <https://red.ht/sig>