On 11/06/2013 11:15 PM, i iordanov wrote:
Hi Christophe,
This one may turn out to not be an actual issue.
I had gotten used to the functionality offered by oVirt Live 0.8 (I
think it bundles oVirt 3.0) where I was able to attach as user
"admin@internal" to virtual machines created in the Administrative
Console (rather than in the User Console).
It appears that oVirt 3.2 and 3.3 either do not allow this anymore or
something else is amiss. One may not attach to such machines despite
them being reported at /api/vms.
To make a long story short, I made one of these machines a Template
and created a VM based on it in the User Console of admin@internal.
After that, I was able to connect!
Do you think there is still anything wrong? Should we be able to
attach to those vms (e.g. win and winbak)?
(if you see a behavior change in ovirt, you an also ask/cc on
users@xxxxxxxxx)
in 3.0 we only allowed admin access to the API.
in 3.1 we added user level access. main difference is users only get
entities they have permissions with User Role on.
an user with admin role can ask to get 'all', or just "me as a user" -
all VMs which that admin has a User Role to.
to not break api backward compatibility, default mode of the API
remained 'admin mode', so you need to pass to the API "filter=true" to
behave as a user.
(we don't like this, and will try to come up with a better solution).
i assume from Christophe next reply govirt (sensibly, as its geared for
user access) default to user mode api.
so you have two options - move to admin mode in govirt, or easier (and
probably more consistent if you are aiming your solution for users
rather than admins), give admin@internal a UserRole on the VMs, not an
Admin Role.
HTH,
ITamar
Cheers,
iordan
On Wed, Nov 6, 2013 at 4:22 AM, Christophe Fergeau <cfergeau@xxxxxxxxxx> wrote:
On Tue, Nov 05, 2013 at 06:03:21PM -0600, i iordanov wrote:
What I have done is manually navigated to https://FQDN/api/vms in
order to attach the output I get there for you to see if you can spot
why libgovirt fails to look up the VMs. The call failed with name set
to both "win" and "winbak".
This code is happily parsed by the attached test program, so I'm not sure
parsing is at fault. You can look at the REST calls by setting the
REST_DEBUG env variable to 'proxy'
Christophe
_______________________________________________
Spice-devel mailing list
Spice-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/spice-devel