Not able to access through console ,SSH, even the migration option is not getting highlighted unable to perform any actions.

To reboot host I need to migrate remaining vms to other host , that is time consuming.

Any commands to kill the process without rebooting  the host?

On Apr 28, 2016 5:42 PM, "Michal Skrivanek" <michal.skrivanek@redhat.com> wrote:

On 28 Apr 2016, at 14:11, Budur Nagaraju <nbudoor@gmail.com> wrote:

Earlier it was working ,now  not able to power on/off  shutdown. deploy in another host etc.



I don’t mean in ovirt, I mean the guest itself. Can you get to the console? Can you ssh to that guest? Does it do anythign?
if so it might be worth trying to save it (e.g. migrate), if not, just kill it from the host…or migrate everything else away and reboot the host

On Apr 28, 2016 5:38 PM, "Michal Skrivanek" <michal.skrivanek@redhat.com> wrote:

On 28 Apr 2016, at 14:01, Budur Nagaraju <nbudoor@gmail.com> wrote:

ovirt node is having 50vms and one  VM is having issues, by restarting libvirt will the  other vms get affect? And am not getting the option to delete.



it will not affect the running VMs, they will keep running
again, does that one VM actually work?

On Apr 28, 2016 5:26 PM, "Michal Skrivanek" <michal.skrivanek@redhat.com> wrote:

> On 28 Apr 2016, at 13:49, Budur Nagaraju <nbudoor@gmail.com> wrote:
>
> Any commands to check the same ?

so does the VM actually work?
what’s the status of the process?

if it works, restart libvirtd (that will induce a vdsm restart as well), and check if it makes any difference. If not then I guess you’re out of luck and you can try to kill the qemu process yourself…or reboot the box

> On Apr 28, 2016 5:10 PM, "Michal Skrivanek" <michal.skrivanek@redhat.com>
> wrote:
>
>>
>>> On 28 Apr 2016, at 10:03, Budur Nagaraju <nbudoor@gmail.com> wrote:
>>>
>>> HI
>>>
>>> One of the vm is showing "?" and  unable to perform any actions below
>> are the logs ,let me know is there any ways to bring it back ?
>>
>> then it’s probably broken in lower layers. check/add vdsm.log from that
>> period, but it is likely that libvirt lost control over the qemu process.
>> You may want to check that particular qemu process if it is alright or .g