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(a)redhat.com>
wrote:
On 28 Apr 2016, at 14:11, Budur Nagaraju <nbudoor(a)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(a)redhat.com>
wrote:
On 28 Apr 2016, at 14:01, Budur Nagaraju <nbudoor(a)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(a)redhat.com>
wrote:
>
> > On 28 Apr 2016, at 13:49, Budur Nagaraju <nbudoor(a)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(a)redhat.com>
> > wrote:
> >
> >>
> >>> On 28 Apr 2016, at 10:03, Budur Nagaraju <nbudoor(a)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
>
>