Bug 1138314
| Summary: | Fail to start vm with payload. | ||
|---|---|---|---|
| Product: | [Retired] oVirt | Reporter: | Ilanit Stein <istein> |
| Component: | ovirt-engine-core | Assignee: | Shahar Havivi <shavivi> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Ilanit Stein <istein> |
| Severity: | urgent | Docs Contact: | |
| Priority: | high | ||
| Version: | 3.5 | CC: | bugs, ecohen, gklein, iheim, mavital, michal.skrivanek, ofrenkel, rbalakri, sherold, s.kieske, yeylon |
| Target Milestone: | --- | Keywords: | AutomationBlocker |
| Target Release: | 3.5.1 | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | virt | ||
| 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:
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2015-01-21 16:05:13 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | Virt | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 1073943, 1147536, 1164308, 1164311 | ||
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/ 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: 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. 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 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. this is not a regression, 2 payloads were never supported (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? (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 (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 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. oVirt 3.5.1 has been released. If problems still persist, please make note of it in this bug report. |
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