Bug 1008938 - VM cannot start after changing disk type virtio -> virtio-scsi
VM cannot start after changing disk type virtio -> virtio-scsi
Status: CLOSED CURRENTRELEASE
Product: oVirt
Classification: Community
Component: ovirt-engine-webadmin (Show other bugs)
3.3
All All
urgent Severity high
: ---
: 3.3.1
Assigned To: Daniel Erez
Elad
storage
: Reopened
Depends On:
Blocks: 1011800
  Show dependency treegraph
 
Reported: 2013-09-17 07:27 EDT by Markus Stockhausen
Modified: 2016-02-10 13:20 EST (History)
12 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-11-07 03:27:43 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: Storage
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Markus Stockhausen 2013-09-17 07:27:59 EDT
Description of problem:

If one changes the disk type of a VM from virtio to virtio-scsi the VM will not boot afterwards. It fails with error "VM test is down. Exit message: Internal error unexpected address type for SCSI disk"


Version-Release number of selected component (if applicable):

ovirt 3.3.0-4.fc19 


How reproducible:

100%

Steps to Reproduce:
1. stop VM with single virtio disk
2. change disk type to from virtio virtio-scsi (DO NOT detach/attach disk of VM)
3. restart VM

Actual results:

VM does not start

Expected results:

VM starts normally

Additional info:

Workaround is to detach/reattach disk to VM
Comment 1 Allon Mureinik 2013-09-17 10:31:45 EDT
Narkus, please attach VDSM and Engine logs.
Comment 2 Allon Mureinik 2013-09-17 10:32:56 EDT
Daniel, it's a bit hard to tell without the logs, but can you try to reproduce with http://gerrit.ovirt.org/#/c/18638/ and see if it's related?
Comment 3 Daniel Erez 2013-09-17 12:11:02 EDT
(In reply to Allon Mureinik from comment #2)
> Daniel, it's a bit hard to tell without the logs, but can you try to
> reproduce with http://gerrit.ovirt.org/#/c/18638/ and see if it's related?

Looks like a duplicate of bug 994247 which has been fixed recently with http://gerrit.ovirt.org/17729
Comment 4 Markus Stockhausen 2013-09-18 02:58:19 EDT
Hopefully the right thread this time ...

Hello,

maybe a the contents of the db are better than the logs:

I have a machine with two virtio disks: The vm_device table lists:

device|                          address                           |   alias
------+------------------------------------------------------------+------------
cdrom |{unit=0, bus=1, target=0, controller=0, type=drive}         |ide0-1-0
 disk |{bus=0x00, domain=0x0000, type=pci, slot=0x06, function=0x0}|virtio-disk0
 disk |{bus=0x00, domain=0x0000, type=pci, slot=0x07, function=0x0}|virtio-disk1
 scsi |{bus=0x00, domain=0x0000, type=pci, slot=0x04, function=0x0}|scsi0

Now I reconfigure the second disk to virtio-scsi and try to start the vm. It fails and the table afterwards reads:

device|                           address                          |    alias
------+------------------------------------------------------------+------------
cdrom |{unit=0, bus=1, target=0, controller=0, type=drive}         |ide0-1-0
disk  |{bus=0x00, domain=0x0000, type=pci, slot=0x07, function=0x0}|virtio-disk1
disk  |{bus=0x00, domain=0x0000, type=pci, slot=0x06, function=0x0}|virtio-disk0
scsi  |{bus=0x00, domain=0x0000, type=pci, slot=0x04, function=0x0}|scsi0

Finally I detach and reattach the disk. VM is startable again. The table is now

disk' or device='scsi');"_id='1dec3a15-996b-44ca-9bbc-e86112e244af' and ( type='d
device|                         address                            |   alias
------+------------------------------------------------------------+-----------
cdrom |{unit=0, bus=1, target=0, controller=0, type=drive}         |ide0-1-0
disk  |{unit=0, bus=0, target=0, controller=0, type=drive}         |scsi0-0-0-0
scsi  |{bus=0x00, domain=0x0000, type=pci, slot=0x04, function=0x0}|scsi0
disk  |{bus=0x00, domain=0x0000, type=pci, slot=0x06, function=0x0}|virtio-disk0

I guess the disk change dialogue does not persist the changes correctly.

Markus
Comment 5 Sergey Gotliv 2013-09-18 03:27:26 EDT
I aggree with comment 3. It looks like a duplicate of bug 994247.
Each time user update disk's interface we have to clean device address in DB, otherwise we are trying to run VM with a wrong configuration.

Marcus,

Can you run the same query on DB, after you changed the interface to Virtio-Scsi but before you running the VM

Thanks
Comment 6 Markus Stockhausen 2013-09-18 03:44:49 EDT
As requested a snapshot before/after the disk change 

psql engine postgres -q -n -c "select  boot_order,device,address,alias from vm_device where vm_id='1dec3a15-996b-44ca-9bbc-e86112e244af' and ( type='disk' or device='scsi');"

here the vm_device table before the virtio -> virtio-scsi change:

device|                           address                          |   alias
------+------------------------------------------------------------+-------------
 disk |{bus=0x00, domain=0x0000, type=pci, slot=0x07, function=0x0}|virtio-disk1
 scsi |{bus=0x00, domain=0x0000, type=pci, slot=0x04, function=0x0}|scsi0
 cdrom|{unit=0, bus=1, target=0, controller=0, type=drive}         |ide0-1-0
 disk |{bus=0x00, domain=0x0000, type=pci, slot=0x06, function=0x0}|virtio-disk0

and here 60 seconds after leaving the change dialog but without booting the machine. 

device|                          address                           |  alias
------+------------------------------------------------------------+-----------
 scsi |{bus=0x00, domain=0x0000, type=pci, slot=0x04, function=0x0}|scsi0
 cdrom|{unit=0, bus=1, target=0, controller=0, type=drive}         |ide0-1-0
 disk |{bus=0x00, domain=0x0000, type=pci, slot=0x07, function=0x0}|virtio-disk1
 disk |{bus=0x00, domain=0x0000, type=pci, slot=0x06, function=0x0}|virtio-disk0

I would say. Nothing really changed.
Comment 7 Sergey Gotliv 2013-09-18 03:51:16 EDT
So, this is a duplicate see comment 3 and comment 5
Comment 8 Itamar Heim 2013-09-23 03:33:00 EDT
closing as this should be in 3.3 (doing so in bulk, so may be incorrect)
Comment 9 Itamar Heim 2013-09-23 08:27:50 EDT
this isn't in 3.3.0.
Comment 10 Daniel Erez 2013-09-23 08:32:27 EDT
(In reply to Itamar Heim from comment #9)
> this isn't in 3.3.0.

It should be in 3.3.0 - it's a duplicate of bug 994247 which is already verified.
Comment 11 Itamar Heim 2013-09-23 08:35:38 EDT
i checked the change-id in branch ovirt-engine-3.3.0 and didn't find it.
in order to have it in 3.3.0.1 it should be backported to ovirt-engine-3.3.0 branch.
Comment 12 Sandro Bonazzola 2013-10-07 03:08:11 EDT
(In reply to Allon Mureinik from comment #2)
> Daniel, it's a bit hard to tell without the logs, but can you try to
> reproduce with http://gerrit.ovirt.org/#/c/18638/ and see if it's related?

http://gerrit.ovirt.org/#/c/18638/ seems missing in 3.3.0 branch. Is it needed?
Comment 13 Daniel Erez 2013-10-08 04:42:55 EDT
The relevant fix has already been backported to 3.3 and 3.3.0 branches:
Change-Id: I62605c490da909447f77513e7691d76ddd24ff26
commit (3.3.0.1 branch): 9bc0e4525eaf8431c1b4f9d6a3ce4a2502731ed3
Comment 14 Elad 2013-10-27 05:40:00 EDT
VM start after changing its disk interface from virtIO to virtIO-SCSI


Verified on is19:
vdsm-4.13.0-0.3.beta1.el6ev.x86_64
Comment 15 Elad 2013-10-27 11:05:40 EDT
(In reply to Elad from comment #14)
> VM start after changing its disk interface from virtIO to virtIO-SCSI
> 
> 
> Verified on is19:
> vdsm-4.13.0-0.3.beta1.el6ev.x86_64

It was verified on RHEVM, not oVirt. RHEVM version:
rhevm-3.3.0-0.27.beta1.el6ev.noarch
Comment 16 Sandro Bonazzola 2013-11-07 03:27:43 EST
oVirt 3.3.0.1 has been released.

Note You need to log in before you can comment on or make changes to this bug.