Description of problem:
Start VM with payload fail on libvirtError .
 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
File "/usr/share/vdsm/virt/vm.py", line 3323, in _run
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
100% on vm payload automation test:
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>
3. Start VM
This is a regression, compared to rhevm 3.4
Also Failing same payload test, run in CI, for rhevm-3.5:
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.
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?
I have a use case:
as stated in BZ 1138564 Comment 3:
(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.
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?
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
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
(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
its is working, please check documentation
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.
this is not a regression, 2 payloads were never supported
(In reply to Omer Frenkel from comment #9)
> its is working, please check documentation
> 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?
(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.
> afaik in this use case you need one payload for cloud-init and one for the
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
(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
As mentioned above this automation blocker bug, also for rhevm 3.4.
Would you please fix it for 3.4 as well?
oVirt 3.5.1 has been released. If problems still persist, please make note of it in this bug report.