On 08/06/16 11:54 +0200, Alexis HAUSER wrote: I'm not sure about first part, but it should be accessible from engine's hypervisor using QEMU console. You can list VMs running on the host with $ virsh -r list and connect to the console $ virsh console vm_id

Wouldn't there be another way to access console from the hypervisor to the hosted-engine (without X) ?

I can't see it with "virsh list" but I can see it with vdsClient -s 0 list However the status id "Down" with "exitMessage = Failed to acquire lock: No space left on device" I can't actually run the VM anymore since I changed the VLAN of ovirtmgmt...

Actually I found my answer : it was just a problem on the NFS share, no relationship with ovirt itself, sorry about that.

Actually, this isn't very clear. After changing the ovirtmgmt VLAN, I wasn't able to access the web interface anymore (or even to ping the FQDN of the hosted-engine VM). After trying a lot of different things with no success, I decided to reboot the hypervisor. I don't know if this reboot was a wrong idea, but I started to realize the VM wasn't really started : - hosted-engine --vm-status was showing as if the VM was started but with "unkown stale data" - vdsClient -s 0 list was showing the VM as down with "exitMessage = Failed to acquire lock: No space left on device" I tried everything about maintenance mode / stopping VM / starting it with ovirt commands, but the VM was not starting, it was crashing with this error message above (and unreachable from network of course) I found out there was an option in hosted-engine command to reinitialze lockspace but I still had the same error. Before deleting everything on my NFS data domain, I tried to delete the file called __DIRECT_IO_TEST__ which seems to be a lock file (there is no documentation at all concerning this, from what I can see) and I've been lucky : the VM started again, with a good status and was accessible. So there are 3 points I don't understand : 1) On the hypervisor, every config file and configuration I could get related to ovirtmgmt didn't have any VLAN option : does it mean from the moment I changed this VLAN option on the VM its link with the hypervisor has been cut and the information about the VLAN in the VM didn't come back to the hypervisor ? 2) The fact hosted-engine --reinitialize-lockspace didn't reinitialize-lockspace correctly and had to do it manually...And only deleting this file manually make everything work again.... 3) After this file was deleted, why I was able to ping and contact again my VM while it was still configured on another wrong VLAN, I should have lost connectivity completely Maybe some of these behaviors are bugs, but it's hard to guess what part to be able to fill a new bug report...