in ovirt-engine master branch, it's now possible  to use GWT Super
Dev Mode  to debug oVirt web applications (WebAdmin, UserPortal):
Please refer to commit msg  for details on GWT Super Dev Mode.
In general, SDM is good for "iterative" development when one changes
UI code and wants to see the change reflected in browser very quickly
(compared to existing GWT debug mechanism, aka Classic Dev Mode).
On the other hand, SDM does *not* allow using Java IDE to debug UI
Existing (Java IDE based) debug mechanism still works as expected,
the Super Dev Mode is just an alternative.
Note on SDM usage by Scott: it's almost easier to run in Chrome's
incognito mode so cached JS and mapped sources aren't an issue.
Hello, now I have defined a custom property named 'A' in oVirt Engine. Administrator is responsible for entering the value (and arbitrary string ) of 'A' before starting the VM. After an users trys to start the VM in oVirt, VDSM will add the value of 'A' in the qemu:arg of libvirt domain xml, so that the value of 'A' will be added into the QEMU Cmd as a param. However, just like the password of VNC or SPICE, I want to hide the value of 'A' in '*' format in both Libvirt domain xml and QEMU Cmd, So could you please tell me how to achieve it? Thank you very much and happy 2016.
lucas castro <lucascastroborges(a)gmail.com> writes:
> Who is working on ovirt debian porting,
I'm working on inclusion of Vdsm into Debian. ovirt-guest-agent is
already included in Debian (packaged by another Debian maintainer). I'm
not aware about any plans to package Engine for Debian nor I plan to do
There are also Vdsm Debian packages provided by oVirt at
http://resources.ovirt.org/pub/ovirt-3.6/debian/, but I don't recommend
using them if you are going to use packages from standard Debian
distribution once they are ready. While the packages to be included in
Debian started from those provided by oVirt, there are many fixes in
them and upgrading from oVirt repository packages to packages from
Debian is not supported (may change if there is strong demand for that).
So mixing those is likely to cause troubles.
As for Vdsm in Debian, I've already uploaded most of the supporting
packages (Python libraries, MoM) to Debian unstable. Vdsm itself is in
One blocker is old version of sanlock package in Debian and missing
sanlock-python package. I wrote to the Debian package maintainer a few
days ago, no response so far. In the meantime, it's possible to use
sanlock packages by oVirt from the URL mentioned above. (Please note I
can't simply upload Debian package of another maintainer without his
consent, so we must be patient.)
> And how can I help ?
If you'd like to help with Vdsm packaging in Debian, you can do so in
any of the following ways:
- Providing input on your needs.
- Providing feedback on what to do with /rhev/data-center mounts
directory in Vdsm. It's FHS incompatible and must be changed for
Debian (the current location in the package is
/run/vdsm/rhev/data-center). The unpleasant thing is that AFAIK
migrations are not possible with current Vdsm across machines with
mounts at different locations, so we should be careful.
- Testing vdsm* packages once they are ready. They're not yet but once
they are, testing them will be very welcome.
- Providing feedback on the packaging. The git repository is on Alioth:
https://anonscm.debian.org/cgit/collab-maint/vdsm.git/ . BTW, if
anybody needs commit access (and doesn't have it) to the repository,
tell me. Just please coordinate with me in any case so that we avoid
duplicate work or conflicting plans.
- The `vdsm*' packages are currently lintian clean, but completely
untested, even installation may not work. If you'd like to check the
installation and to fix contingent bugs preventing it, it's welcome.
You'll also need safelease
(https://anonscm.debian.org/cgit/collab-maint/safelease.git/), not yet
in Debian but ready to upload, I'll do so soon.
- Testing whether all the Vdsm related packages from unstable
(python-cpopen, python-threading, ioprocess, safelease, mom, vdsm*)
work on Debian 8 (jessie) as well. Ideally, they might work
unchanged, but in case they don't we may be considering backporting
- You can also review patches in debian/patches. Maybe some of the
changes should be incorporated upstream, maybe some of them should be