Comments from David Kovalsky on 15/Oct/12: Please sync with Filip Škola on the state of dynamic ESX guests so we have the same interface. Even if the features are developed in parallel, they should be tested / staged together.

Most of the work for this feature was already done by Steven Lawrance, but his patch needs some work in light of bug 655009.

In 0.10 PRD review request in Vault, bpeck commented:
I would add that RHEVM scheduling should be able to be easily disabled by the admins in case unforeseen issues pop up.  I worry that the new feature could have a negative impact on scheduling if the queue backs up.

Is this use case covered in 0.10?

https://vault-stage.englab.nay.redhat.com/Vault/showRequest/1104

(In reply to comment #3)
> In 0.10 PRD review request in Vault, bpeck commented:
> I would add that RHEVM scheduling should be able to be easily disabled by
> the admins in case unforeseen issues pop up.  I worry that the new feature
> could have a negative impact on scheduling if the queue backs up.
> 
> Is this use case covered in 0.10?

That's a good point. The current version of the patch does not have a simple "off" switch. I will need to add something.

Have uncovered a few issues with Steve's patch..

Setting to ON_DEV as this is now merged, although there are still a few small issues that need to be sorted out.

(In reply to comment #9)
> Setting to ON_DEV as this is now merged, although there are still a few
> small issues that need to be sorted out.

Namely:

* typo in destroy_vm
* ks_appends come after install_done therefore never run, due to RHEV reboot
* exception handling in beakerd.virt_recipes explodes if exception happened in flush
* MAC addresses need to be allocated, the same way as for guestrecipes
* RHEL3 may not need to be excluded (RHEV docs claim it is supported, but probably not with virtio devices)

(In reply to comment #10)
> * typo in destroy_vm

http://git.beaker-project.org/cgit/beaker/commit/?id=a28a2426cbf

> * ks_appends come after install_done therefore never run, due to RHEV reboot

http://gerrit.beaker-project.org/1470

> * exception handling in beakerd.virt_recipes explodes if exception happened
> in flush

http://gerrit.beaker-project.org/1471

> * MAC addresses need to be allocated, the same way as for guestrecipes

http://gerrit.beaker-project.org/1472

A few more issues that need fixing:

* If the kernel or initrd image doesn't exist when we try to start the installation, RHEV silently fails to start the VM. Need to investigate whether the failure is indeed silent or if we can catch it somehow. Not particularly serious since the external watchdog will just get it anyway.

* However... the external watchdog will fail to delete the VM:

2012-11-08 14:25:09,875 bkr.server.model ERROR Failed to destroy vm guest_for_recipe_220, leaked!
Traceback (most recent call last):
  File "/usr/lib/python2.6/site-packages/bkr/server/model.py", line 6005, in release
    manager.destroy_vm(self.system_name)
  File "/usr/lib/python2.6/site-packages/bkr/server/model.py", line 6492, in destroy_vm
    vm.stop()
  File "/usr/lib/python2.6/site-packages/ovirtsdk/infrastructure/brokers.py", line 5313, in stop
    headers={"Correlation-Id":correlation_id})
  File "/usr/lib/python2.6/site-packages/ovirtsdk/infrastructure/proxy.py", line 128, in request
    last=last)
  File "/usr/lib/python2.6/site-packages/ovirtsdk/infrastructure/proxy.py", line 154, in __doRequest
    raise RequestError, response
RequestError: 
status: 400
reason: Bad Request
detail: Cannot stop VM. VM is not running.

Need to handle this case.

(In reply to comment #13)
> * However... the external watchdog will fail to delete the VM:

http://gerrit.beaker-project.org/1479

Any further issues with dynamic RHEV provisioning can be opened as seperate bugs.

This has now been released