Bug 1008938

Summary:	VM cannot start after changing disk type virtio -> virtio-scsi
Product:	[Retired] oVirt	Reporter:	Markus Stockhausen <mst>
Component:	ovirt-engine-webadmin	Assignee:	Daniel Erez <derez>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Elad <ebenahar>
Severity:	high	Docs Contact:
Priority:	urgent
Version:	3.3	CC:	acathrow, amureini, derez, ebenahar, ecohen, iheim, mgoldboi, michal.skrivanek, mst, sbonazzo, sgotliv, yeylon
Target Milestone:	---	Keywords:	Reopened
Target Release:	3.3.1
Hardware:	All
OS:	All
Whiteboard:	storage
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2013-11-07 08:27:43 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	Storage	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	1011800

Description Markus Stockhausen 2013-09-17 11:27:59 UTC

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 14:31:45 UTC

Narkus, please attach VDSM and Engine logs.

Comment 2 Allon Mureinik 2013-09-17 14:32:56 UTC

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 16:11:02 UTC

(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 06:58:19 UTC

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 07:27:26 UTC

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 07:44:49 UTC

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 07:51:16 UTC

So, this is a duplicate see comment 3 and comment 5

Comment 8 Itamar Heim 2013-09-23 07:33:00 UTC

closing as this should be in 3.3 (doing so in bulk, so may be incorrect)

Comment 9 Itamar Heim 2013-09-23 12:27:50 UTC

this isn't in 3.3.0.

Comment 10 Daniel Erez 2013-09-23 12:32:27 UTC

(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 12:35:38 UTC

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 07:08:11 UTC

(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 08:42:55 UTC

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 09:40:00 UTC

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 15:05:40 UTC

(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 08:27:43 UTC

oVirt 3.3.0.1 has been released.