Bug 1138314 - Fail to start vm with payload.
Summary: Fail to start vm with payload.
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: oVirt
Classification: Retired
Component: ovirt-engine-core
Version: 3.5
Hardware: Unspecified
OS: Unspecified
high
urgent
Target Milestone: ---
: 3.5.1
Assignee: Shahar Havivi
QA Contact: Ilanit Stein
URL:
Whiteboard: virt
Depends On:
Blocks: 1073943 rhev35betablocker rhev35rcblocker rhev35gablocker
TreeView+ depends on / blocked
 
Reported: 2014-09-04 13:25 UTC by Ilanit Stein
Modified: 2016-02-10 19:48 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Cause: Cannot have VM-Init and Vm-Payload with the same media, ie if we have Vm-Init as CDROM we cannot have Vm-Payload as CDROM device - Floppy device is permitted - the same is true for the other way around. Consequence: Fix: Result:
Clone Of:
Environment:
Last Closed: 2015-01-21 16:05:13 UTC
oVirt Team: Virt


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
oVirt gerrit 33318 master MERGED engine: cannot set payload and cloud-init on same devices. Never
oVirt gerrit 33679 master MERGED engine: VmPayload needs to inherit from VmDevice Never
oVirt gerrit 33883 ovirt-engine-3.5 MERGED engine: VmPayload needs to inherit from VmDevice Never
oVirt gerrit 33884 ovirt-engine-3.5 MERGED engine: cannot set payload and cloud-init on same devices. Never

Description Ilanit Stein 2014-09-04 13:25:45 UTC
Description of problem:
Start VM with payload fail on libvirtError [1].

[1] Libvirt Error (from vdsm.log):
Thread-72::ERROR::2014-09-04 15:24:23,236::vm::2325::vm.Vm::(_startUnderlyingVm) vmId=`c238c1a9-ffad-4bb6-a4ec-224a19974672`::The vm start process failed
Traceback (most recent call last):
  File "/usr/share/vdsm/virt/vm.py", line 2268, in _startUnderlyingVm
    self._run()
  File "/usr/share/vdsm/virt/vm.py", line 3323, in _run
    self._connection.createXML(domxml, flags),
  File "/usr/lib64/python2.6/site-packages/vdsm/libvirtconnection.py", line 111, in wrapper
    ret = f(*args, **kwargs)
  File "/usr/lib64/python2.6/site-packages/libvirt.py", line 2665, in createXML
    if ret is None:raise libvirtError('virDomainCreateXML() failed', conn=self)
libvirtError: internal error process exited while connecting to monitor: qemu-kvm: -drive file=/var/run/vdsm/payload/c238c1a9-ffad-4bb6-a4ec-224a19974672.683c19ab302401c2d96b4ec4f01570f8.img,if=none,media=cdrom,id=drive-ide0-1-1,readonly=on,format=raw,serial=: Duplicate ID 'drive-ide0-1-1' for drive
 
Version-Release number of selected component (if applicable):
ovirt engine 3.5 rc1.1

How reproducible:
100% on vm payload automation test: 
http://jenkins.qa.lab.tlv.redhat.com:8080/view/Compute/view/3.5-git/view/Virt/job/3.5-git-compute-virt-payloads-nfs/9/
 
Steps to Reproduce:
1. Create a VM
2. Add payload (via REST api):
2014-09-04 14:41:13,961 - MainThread - vms - DEBUG - PUT request content is --  url:/api/vms/b5592610-6cb7-4e0e-a100-cc3206d0f656 body:<vm>
    <payloads>
        <payload type="cdrom">
            <files>
                <file>
                    <name>payload.cdrom</name>
                    <content>complex
payload
for
use</content>
                </file>
            </files>
        </payload>
    </payloads>
</vm>
3. Start VM

Additional Info:
This is a regression, compared to rhevm 3.4

Comment 1 Ilanit Stein 2014-09-04 13:59:02 UTC
Also Failing same payload test, run in CI, for rhevm-3.5:
http://jenkins-ci.eng.lab.tlv.redhat.com/job/rhevm_3.5_automation_infra_one_host_payloads_sanity_nfs_rest_factory/24/testReport/

Comment 2 Omer Frenkel 2014-09-07 13:31:19 UTC
looks like cloud-init and payload can't work together, as cloud-init is implemented with payload, and both are send with 'special' index=3 for ide controller.

Also, i don't think this is a regression from 3.4, if the tests passed in 3.4 its probably because cloud init was not sent, might be because of changes in OS done in 3.5, different order of execution or something similar.

Comment 3 Itamar Heim 2014-09-10 07:13:13 UTC
we need to resolve this (either we can fix this (iirc, we can attach more than a single ISO these days, could probably be virtio-block for linux guests?)
or we need to block/warn.
not sure what would be the use case to mix payload and cloud-init though.
scott - thoughts?

Comment 4 Sven Kieske 2014-09-10 13:44:18 UTC
I have a use case:

as stated in BZ 1138564 Comment 3:

https://bugzilla.redhat.com/show_bug.cgi?id=1138564#c3


(In reply to Michal Skrivanek from comment #3)
> it was wrong in 3.3, the original intent was to behave as in 3.4
> For generic pushing of files one should use the already existing "vmpayload" 


So if you want to use cloud-init with an attached file (script) in 3.4 or later
you _must_ use 2 vm payloads, one for cloud-init and one for the scriptfile.

So I'd suggest this is a regression and therefore a blocker for 3.5 release.

Comment 5 Sven Kieske 2014-09-18 08:16:56 UTC
Why is this targeted to 3.5.1 and not 3.5
and why is it not listed as a blocker for 3.5 release?

Comment 6 Itamar Heim 2014-09-18 08:41:15 UTC
I auto-set all bugs which have *no* target release to next relevant version. at this point, I auto set to 3.5.1. soon I'll auto-set to 3.6.0.

omer - please review wrt 3.5.0

Comment 7 Omer Frenkel 2014-09-18 08:45:50 UTC
i agree with 3.5.1 because using both payload and cloud-init at the same run is not a common use case, and it is possible to send the payload information as part of the custom script of the cloud-init if needed..

we will not make it on time to 3.5 to check if its possible to make it work together, currently plan is decide payload override cloud-init, as it can only be set with rest, which is more advanced feature
we also want to hear Scott opinion on that as well.

i dont think we should block 3.5 which should already get going..
so next release, 3.5.1, is a good decision

Comment 8 Sven Kieske 2014-09-18 08:55:57 UTC
(In reply to Omer Frenkel from comment #7)
> i agree with 3.5.1 because using both payload and cloud-init at the same run
> is not a common use case, and it is possible to send the payload information
> as part of the custom script of the cloud-init if needed..

Please correct me if I'm wrong, but I think you are wrong, you need to pass
the custom script via the payload function, see https://bugzilla.redhat.com/show_bug.cgi?id=1138314#c4

> we will not make it on time to 3.5 to check if its possible to make it work
> together, currently plan is decide payload override cloud-init, as it can
> only be set with rest, which is more advanced feature
> we also want to hear Scott opinion on that as well.
> 
> i dont think we should block 3.5 which should already get going..
> so next release, 3.5.1, is a good decision

Comment 9 Omer Frenkel 2014-09-18 15:34:34 UTC
its is working, please check documentation
http://www.ovirt.org/Features/vm-init-persistent#Custom_Script

i also verified this with the UI right now,
i was able to inject a file into the guest

BZ 1138564 talks about the fact we changed the way attaching files to cloud init using rest api, but it works.

Comment 10 Michal Skrivanek 2014-09-26 12:00:46 UTC
this is not a regression, 2 payloads were never supported

Comment 11 Sven Kieske 2014-09-26 12:10:32 UTC
(In reply to Omer Frenkel from comment #9)
> its is working, please check documentation
> http://www.ovirt.org/Features/vm-init-persistent#Custom_Script
> 
> i also verified this with the UI right now,
> i was able to inject a file into the guest
> 
> BZ 1138564 talks about the fact we changed the way attaching files to cloud
> init using rest api, but it works.

And what if I use "run-once" and not vm-init-persistent ?
I then do not store my user data in the data base.
afaik in this use case you need one payload for cloud-init and one for the user-data?

I'm not certain, because I can't test this in 3.4 or 3.5 atm.

Could someone please verify this?

Comment 12 Michal Skrivanek 2014-10-07 06:59:20 UTC
(In reply to Sven Kieske from comment #11)
> And what if I use "run-once" and not vm-init-persistent ?
> I then do not store my user data in the data base.

correct

> afaik in this use case you need one payload for cloud-init and one for the
> user-data?

well, the question is what do you really need to do. The custom cloud-init section allows you to generate custom (external) files from within cloud-init.

btw there's also the standalone vdsm fileinject hook which might be useful in your case

Comment 13 Michal Skrivanek 2014-10-07 07:02:35 UTC
(In reply to Itamar Heim from comment #3)
> we need to resolve this (either we can fix this (iirc, we can attach more

we're fixing this anyway, just not urgent as there are other ways how to achieve this

Comment 16 Ilanit Stein 2014-11-05 06:43:18 UTC
Michal,

As mentioned above this automation blocker bug, also for rhevm 3.4.
Would you please fix it for 3.4 as well?

Thanks,
Ilanit.

Comment 19 Sandro Bonazzola 2015-01-21 16:05:13 UTC
oVirt 3.5.1 has been released. If problems still persist, please make note of it in this bug report.


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