[ovirt-users] Re: virsh question

2019-02-11 Thread Petr Kotas
Hi Hetz,

with oVirt, the virtual machines that does not run are not present on the
node. You have the storage where are the virtual machines stored. You also
have the engine which stores every virtual machine in its database. It also
knows where the machine should run. This is why you can see the virtual
machine not running on certain node.

Only once you start the virtual machine, it is placed on the destined node.

Hope this helps.

Petr

On Tue, Feb 12, 2019 at 2:54 AM Hetz Ben Hamo  wrote:

> Hi,
>
> I'm trying after connecting to a node to look with virsh what machines are
> available (this is 1 node ovirt)
> Even when using something
> like: qemu://mynode/system?authfile=/etc/ovirt-hosted-engine/virsh_auth.conf
> and running list --all - I see only the running machines.
>
> Looking through the web UI though, I see all the running and not-running
> vm's.
>
> So how can I see all of them?
>
> Thanks
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/WCTFLNLK3ZOGSNMYOBHTIEGZN3IVVVTQ/
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/QDI46HWP4VG742XZC27SI3WBM3BFO522/


[ovirt-users] Re: Windows 10 vs others windows

2018-08-29 Thread Petr Kotas
Hi Carl,

it might happen you are solving the same issue as is discussed within this
thread: "[ovirt-users] Windows vm and cpu type"

Maybe you do not have all flags turned on in the bios?

Best,
Petr

On Tue, Aug 28, 2018 at 5:13 PM carl langlois 
wrote:

> Hi
>
> Why when en try to do a Windows 10 machine i have a error on the cpu guest
> os not supported but not windows 8 or 7?
>
> Thanks,
>
>
>
>
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/GYOFKCJXTUI4ZHU3PHGYT4MYRETZM7G7/
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/23CQU3ICVIDRWSZEMUYUESNEN5A4IPQA/


[ovirt-users] Re: Pool

2018-07-30 Thread Petr Kotas
Hi José,

one more thing. You can delete the VM even when you enabled the `Delete
protection`.
1) Detach the VM from pool
2) Find the VM and in `Edit` disable the `Delete protection`
3) Now you can `Remove` the VM.

Happy to help.
Petr

On Mon, Jul 30, 2018 at 12:27 PM  wrote:

> Hi Petr,
>
> Ok I see.  Many thanks.
>
> José
>
> ------
> *De: *"Petr Kotas" 
> *Para: *supo...@logicworks.pt
> *Cc: *"users" 
> *Enviadas: *Segunda-feira, 30 De Julho de 2018 7:26:30
> *Assunto: *Re: [ovirt-users] Pool
>
> Hi Josá,
>
> yes it is possible, unless you enabled `Delete protection` checkbox while
> creating the pool.
> Then just detach the VM from the pool and delete it afterwards.
>
> https://www.ovirt.org/documentation/admin-guide/chap-Pools/
>
> Petr
>
> On Sun, Jul 29, 2018 at 7:31 PM  wrote:
>
>> I create a pool with 3 VMs, V. 4.2. Now I want to delete just one VM of
>> that pool. Is that possible?
>>
>> Thanks
>>
>> Josá
>>
>> --
>> --
>> Jose Ferradeira
>> http://www.logicworks.pt
>> ___
>> Users mailing list -- users@ovirt.org
>> To unsubscribe send an email to users-le...@ovirt.org
>> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
>> oVirt Code of Conduct:
>> https://www.ovirt.org/community/about/community-guidelines/
>> List Archives:
>> https://lists.ovirt.org/archives/list/users@ovirt.org/message/WB72CNBHZ35O43QKDIJUSIUD4MNQOETK/
>>
>
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/FRGDKWV6ADBFRTPMES2PUYSYJWPBDV3T/


[ovirt-users] Re: Pool

2018-07-29 Thread Petr Kotas
Hi Josá,

yes it is possible, unless you enabled `Delete protection` checkbox while
creating the pool.
Then just detach the VM from the pool and delete it afterwards.

https://www.ovirt.org/documentation/admin-guide/chap-Pools/

Petr

On Sun, Jul 29, 2018 at 7:31 PM  wrote:

> I create a pool with 3 VMs, V. 4.2. Now I want to delete just one VM of
> that pool. Is that possible?
>
> Thanks
>
> Josá
>
> --
> --
> Jose Ferradeira
> http://www.logicworks.pt
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/WB72CNBHZ35O43QKDIJUSIUD4MNQOETK/
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/KQFKMXFNYCGU4SOO5NWICEONQJBJM2DP/


[ovirt-users] Re: vGPU question

2018-07-24 Thread Petr Kotas
Hi Femi,

you should be fine. It will be handled either by scheduler or by pinning to
you gpu node.

Petr

On Tue, Jul 24, 2018 at 6:43 AM femi adegoke 
wrote:

> Planning to build a hyperconverged 3 host w HE oVirt cluster + Gluster.
>
> Is it ok if only one of the hosts has a GPU?
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/SPBHTQBTUSACUGQN6GKITF5IPAREHSJJ/
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/UY5YAAFOGJYMZICPQL5V7YPTZ47ESXOG/


[ovirt-users] Re: Docker best practices

2018-07-18 Thread Petr Kotas

Hi Alex,

would you mind being more specific with your question?

What are you trying to achieve?

Petr


On 16.7.2018 17:42, Николаев Алексей wrote:

Hi, community!
What are best practices to run docker images into oVirt infra: core os 
or something else?



___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/UB4H3Y7VYQ6R2AOISLLVIBM6WQ425GEP/


___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/LPU5UFVFXWAG6OGUVD4GEHDLYI5UV2LI/


[ovirt-users] Re: Guest Agent Console

2018-07-18 Thread Petr Kotas

Hi,

I have never done anything more then install the guest agent and it worked.


Best,

Petr


On 18.7.2018 08:41, Hari Prasanth Loganathan wrote:

Hi Team,

A Quick question,

As per this document 
(https://www.ovirt.org/documentation/vmm-guide/chap-Installing_Linux_Virtual_Machines/), 



If I Install the common package - |ovirt-engine-guest-agent-common 
using the apt-get / yum

|
|
|install ovirt-engine-guest-agent-common |
| _*Will it also install the drivers mentioned in it?*_

virtio-net, virtio-block, virtio-scsi, virtio-serial, virtio-baloon, qxl


Thanks,
Hari

DISCLAIMER- *MSysTechnologies LLC*

This email message, contents and its attachments may contain 
confidential, proprietary or legally privileged information and is 
intended solely for the use of the individual or entity to whom it is 
actually intended. If you have erroneously received this message, 
please permanently delete it immediately and notify the sender. If you 
are not the intended recipient of the email message,you are notified 
strictly not to disseminate,distribute or copy this e-mail.E-mail 
transmission cannot be guaranteed to be secure or error-free as 
Information could be intercepted, corrupted, lost, destroyed, 
incomplete or contain viruses and MSysTechnologies LLC accepts no 
liability for the contents and integrity of this mail or for any 
damage caused by the limitations of the e-mail transmission.




___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/XPOAVTYLR5B3PTCUZBXA7PHPU6I5HLKE/


___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/UYOHEIJ7F4BBP356G3BUJBAJ3IMESJHH/


Re: [ovirt-users] Importing Libvirt Kvm Vms to oVirt Status: Released in oVirt 4.2 using ssh - Failed to communicate with the external provider

2018-02-08 Thread Petr Kotas
You can generate one :). There are different guides for different platforms.

The link I sent is the good start on where to put the keys and how to set
it up.

Petr

On Thu, Feb 8, 2018 at 3:09 PM, maoz zadok  wrote:

> Using the command line on the engine machine (as root) works fine. I
> don't use ssh key from the agent GUI but the authentication section (with
> root user and password),
> I think that it's a bug, I manage to migrate with TCP but I just want to
> let you know.
>
> is it possible to use ssh-key from the agent GUI? how can I get the key?
>
> On Thu, Feb 8, 2018 at 2:51 PM, Petr Kotas  wrote:
>
>> Hi Maoz,
>>
>> it looks like cannot connect due to wrong setup of ssh keys. Which linux
>> are you using?
>> The guide for setting the ssh connection to  libvirt is here:
>> https://wiki.libvirt.org/page/SSHSetup
>>
>> May it helps?
>>
>> Petr
>>
>> On Wed, Feb 7, 2018 at 10:53 PM, maoz zadok  wrote:
>>
>>> Hello there,
>>>
>>> I'm following https://www.ovirt.org/develop/
>>> release-management/features/virt/KvmToOvirt/ guide in order to import
>>> VMS from Libvirt to oVirt using ssh.
>>>  URL:  "qemu+ssh://host1.example.org/system"
>>>
>>> and get the following error:
>>> Failed to communicate with the external provider, see log for additional
>>> details.
>>>
>>>
>>> *oVirt agent log:*
>>>
>>> *- Failed to retrieve VMs information from external server
>>> qemu+ssh://XXX.XXX.XXX.XXX/system*
>>> *- VDSM XXX command GetVmsNamesFromExternalProviderVDS failed: Cannot
>>> recv data: Host key verification failed.: Connection reset by peer*
>>>
>>>
>>>
>>> *remote host sshd DEBUG log:*
>>> *Feb  7 16:38:29 XXX sshd[110005]: Connection from XXX.XXX.XXX.147 port
>>> 48148 on XXX.XXX.XXX.123 port 22*
>>> *Feb  7 16:38:29 XXX sshd[110005]: debug1: Client protocol version 2.0;
>>> client software version OpenSSH_7.4*
>>> *Feb  7 16:38:29 XXX sshd[110005]: debug1: match: OpenSSH_7.4 pat
>>> OpenSSH* compat 0x0400*
>>> *Feb  7 16:38:29 XXX sshd[110005]: debug1: Local version string
>>> SSH-2.0-OpenSSH_7.4*
>>> *Feb  7 16:38:29 XXX sshd[110005]: debug1: Enabling compatibility mode
>>> for protocol 2.0*
>>> *Feb  7 16:38:29 XXX sshd[110005]: debug1: SELinux support disabled
>>> [preauth]*
>>> *Feb  7 16:38:29 XXX sshd[110005]: debug1: permanently_set_uid: 74/74
>>> [preauth]*
>>> *Feb  7 16:38:29 XXX sshd[110005]: debug1: list_hostkey_types:
>>> ssh-rsa,rsa-sha2-512,rsa-sha2-256,ecdsa-sha2-nistp256,ssh-ed25519 [preauth]*
>>> *Feb  7 16:38:29 XXX sshd[110005]: debug1: SSH2_MSG_KEXINIT sent
>>> [preauth]*
>>> *Feb  7 16:38:29 XXX sshd[110005]: debug1: SSH2_MSG_KEXINIT received
>>> [preauth]*
>>> *Feb  7 16:38:29 XXX sshd[110005]: debug1: kex: algorithm:
>>> curve25519-sha256 [preauth]*
>>> *Feb  7 16:38:29 XXX sshd[110005]: debug1: kex: host key algorithm:
>>> ecdsa-sha2-nistp256 [preauth]*
>>> *Feb  7 16:38:29 XXX sshd[110005]: debug1: kex: client->server cipher:
>>> chacha20-poly1...@openssh.com  MAC:
>>>  compression: none [preauth]*
>>> *Feb  7 16:38:29 XXX sshd[110005]: debug1: kex: server->client cipher:
>>> chacha20-poly1...@openssh.com  MAC:
>>>  compression: none [preauth]*
>>> *Feb  7 16:38:29 XXX sshd[110005]: debug1: kex: curve25519-sha256
>>> need=64 dh_need=64 [preauth]*
>>> *Feb  7 16:38:29 XXX sshd[110005]: debug1: kex: curve25519-sha256
>>> need=64 dh_need=64 [preauth]*
>>> *Feb  7 16:38:29 XXX sshd[110005]: debug1: expecting
>>> SSH2_MSG_KEX_ECDH_INIT [preauth]*
>>> *Feb  7 16:38:29 XXX sshd[110005]: debug1: rekey after 134217728 blocks
>>> [preauth]*
>>> *Feb  7 16:38:29 XXX sshd[110005]: debug1: SSH2_MSG_NEWKEYS sent
>>> [preauth]*
>>> *Feb  7 16:38:29 XXX sshd[110005]: debug1: expecting SSH2_MSG_NEWKEYS
>>> [preauth]*
>>> *Feb  7 16:38:29 XXX sshd[110005]: Connection closed by XXX.XXX.XXX.147
>>> port 48148 [preauth]*
>>> *Feb  7 16:38:29 XXX sshd[110005]: debug1: do_cleanup [preauth]*
>>> *Feb  7 16:38:29 XXX sshd[110005]: debug1: do_cleanup*
>>> *Feb  7 16:38:29 XXX sshd[110005]: debug1: Killing privsep child 110006*
>>> *Feb  7 16:38:29 XXX sshd[109922]: debug1: Forked child 110007.*
>>> *Feb  7 16:38:29 XXX sshd[110007]: debug1: Set /proc/self/oom_score_adj
>>> to 0*
>>> *Feb  7 16:38:29 XXX sshd[11000

Re: [ovirt-users] Importing Libvirt Kvm Vms to oVirt Status: Released in oVirt 4.2 using ssh - Failed to communicate with the external provider

2018-02-08 Thread Petr Kotas
Hi Maoz,

it looks like cannot connect due to wrong setup of ssh keys. Which linux
are you using?
The guide for setting the ssh connection to  libvirt is here:
https://wiki.libvirt.org/page/SSHSetup

May it helps?

Petr

On Wed, Feb 7, 2018 at 10:53 PM, maoz zadok  wrote:

> Hello there,
>
> I'm following https://www.ovirt.org/develop/release-management/features/
> virt/KvmToOvirt/ guide in order to import VMS from Libvirt to oVirt using
> ssh.
>  URL:  "qemu+ssh://host1.example.org/system"
>
> and get the following error:
> Failed to communicate with the external provider, see log for additional
> details.
>
>
> *oVirt agent log:*
>
> *- Failed to retrieve VMs information from external server
> qemu+ssh://XXX.XXX.XXX.XXX/system*
> *- VDSM XXX command GetVmsNamesFromExternalProviderVDS failed: Cannot recv
> data: Host key verification failed.: Connection reset by peer*
>
>
>
> *remote host sshd DEBUG log:*
> *Feb  7 16:38:29 XXX sshd[110005]: Connection from XXX.XXX.XXX.147 port
> 48148 on XXX.XXX.XXX.123 port 22*
> *Feb  7 16:38:29 XXX sshd[110005]: debug1: Client protocol version 2.0;
> client software version OpenSSH_7.4*
> *Feb  7 16:38:29 XXX sshd[110005]: debug1: match: OpenSSH_7.4 pat OpenSSH*
> compat 0x0400*
> *Feb  7 16:38:29 XXX sshd[110005]: debug1: Local version string
> SSH-2.0-OpenSSH_7.4*
> *Feb  7 16:38:29 XXX sshd[110005]: debug1: Enabling compatibility mode for
> protocol 2.0*
> *Feb  7 16:38:29 XXX sshd[110005]: debug1: SELinux support disabled
> [preauth]*
> *Feb  7 16:38:29 XXX sshd[110005]: debug1: permanently_set_uid: 74/74
> [preauth]*
> *Feb  7 16:38:29 XXX sshd[110005]: debug1: list_hostkey_types:
> ssh-rsa,rsa-sha2-512,rsa-sha2-256,ecdsa-sha2-nistp256,ssh-ed25519 [preauth]*
> *Feb  7 16:38:29 XXX sshd[110005]: debug1: SSH2_MSG_KEXINIT sent [preauth]*
> *Feb  7 16:38:29 XXX sshd[110005]: debug1: SSH2_MSG_KEXINIT received
> [preauth]*
> *Feb  7 16:38:29 XXX sshd[110005]: debug1: kex: algorithm:
> curve25519-sha256 [preauth]*
> *Feb  7 16:38:29 XXX sshd[110005]: debug1: kex: host key algorithm:
> ecdsa-sha2-nistp256 [preauth]*
> *Feb  7 16:38:29 XXX sshd[110005]: debug1: kex: client->server cipher:
> chacha20-poly1...@openssh.com  MAC:
>  compression: none [preauth]*
> *Feb  7 16:38:29 XXX sshd[110005]: debug1: kex: server->client cipher:
> chacha20-poly1...@openssh.com  MAC:
>  compression: none [preauth]*
> *Feb  7 16:38:29 XXX sshd[110005]: debug1: kex: curve25519-sha256 need=64
> dh_need=64 [preauth]*
> *Feb  7 16:38:29 XXX sshd[110005]: debug1: kex: curve25519-sha256 need=64
> dh_need=64 [preauth]*
> *Feb  7 16:38:29 XXX sshd[110005]: debug1: expecting
> SSH2_MSG_KEX_ECDH_INIT [preauth]*
> *Feb  7 16:38:29 XXX sshd[110005]: debug1: rekey after 134217728 blocks
> [preauth]*
> *Feb  7 16:38:29 XXX sshd[110005]: debug1: SSH2_MSG_NEWKEYS sent [preauth]*
> *Feb  7 16:38:29 XXX sshd[110005]: debug1: expecting SSH2_MSG_NEWKEYS
> [preauth]*
> *Feb  7 16:38:29 XXX sshd[110005]: Connection closed by XXX.XXX.XXX.147
> port 48148 [preauth]*
> *Feb  7 16:38:29 XXX sshd[110005]: debug1: do_cleanup [preauth]*
> *Feb  7 16:38:29 XXX sshd[110005]: debug1: do_cleanup*
> *Feb  7 16:38:29 XXX sshd[110005]: debug1: Killing privsep child 110006*
> *Feb  7 16:38:29 XXX sshd[109922]: debug1: Forked child 110007.*
> *Feb  7 16:38:29 XXX sshd[110007]: debug1: Set /proc/self/oom_score_adj to
> 0*
> *Feb  7 16:38:29 XXX sshd[110007]: debug1: rexec start in 5 out 5 newsock
> 5 pipe 7 sock 8*
> *Feb  7 16:38:29 XXX sshd[110007]: debug1: inetd sockets after dupping: 3,
> 3*
> *Feb  7 16:38:29 XXX sshd[110007]: Connection from XXX.XXX.XXX.147 port
> 48150 on XXX.XXX.XXX.123 port 22*
> *Feb  7 16:38:29 XXX sshd[110007]: debug1: Client protocol version 2.0;
> client software version OpenSSH_7.4*
> *Feb  7 16:38:29 XXX sshd[110007]: debug1: match: OpenSSH_7.4 pat OpenSSH*
> compat 0x0400*
> *Feb  7 16:38:29 XXX sshd[110007]: debug1: Local version string
> SSH-2.0-OpenSSH_7.4*
> *Feb  7 16:38:29 XXX sshd[110007]: debug1: Enabling compatibility mode for
> protocol 2.0*
> *Feb  7 16:38:29 XXX sshd[110007]: debug1: SELinux support disabled
> [preauth]*
> *Feb  7 16:38:29 XXX sshd[110007]: debug1: permanently_set_uid: 74/74
> [preauth]*
> *Feb  7 16:38:29 XXX sshd[110007]: debug1: list_hostkey_types:
> ssh-rsa,rsa-sha2-512,rsa-sha2-256,ecdsa-sha2-nistp256,ssh-ed25519 [preauth]*
> *Feb  7 16:38:29 XXX sshd[110007]: debug1: SSH2_MSG_KEXINIT sent [preauth]*
> *Feb  7 16:38:29 XXX sshd[110007]: debug1: SSH2_MSG_KEXINIT received
> [preauth]*
> *Feb  7 16:38:29 XXX sshd[110007]: debug1: kex: algorithm:
> curve25519-sha256 [preauth]*
> *Feb  7 16:38:29 XXX sshd[110007]: debug1: kex: host key algorithm:
> ecdsa-sha2-nistp256 [preauth]*
> *Feb  7 16:38:29 XXX sshd[110007]: debug1: kex: client->server cipher:
> chacha20-poly1...@openssh.com  MAC:
>  compression: none [preauth]*
> *Feb  7 16:38:29 XXX sshd[110007]: debug1: kex: server->client cipher:
> chacha20-poly1...@openssh.com  MAC:
>  compression: none [preauth]*

Re: [ovirt-users] Issue with 4.2.1 RC and SSL

2018-02-08 Thread Petr Kotas
Hi Stack,

have you tried it on other linux distributions? Scientific is not
officially supported.

My guess based on your log is there are somewhere missing certificates,
maybe different path?.
You can check the paths by the documentation:
https://www.ovirt.org/develop/release-management/features/infra/pki/#vdsm

Hope this helps.

Petr



On Thu, Feb 8, 2018 at 1:13 AM, ~Stack~  wrote:

> Greetings,
>
> I was having a lot of issues with 4.2 and 95% of them are in the change
> logs for 4.2.1. Since this is a new build, I just blew everything away
> and started from scratch with the RC release.
>
> The very first thing that I did after the engine-config was to set up my
> SSL cert. I followed the directions from here:
> https://www.ovirt.org/documentation/admin-guide/appe-oVirt_and_SSL/
>
> Logged in the first time to the web interface and everything worked! Great.
>
> Install my hosts (also completely fresh installs - Scientific Linux 7
> fully updated) and none would finish the install...
>
>
> I can send the full host debug log if you want, however, I'm pretty sure
> that the problem is because of the SSL somewhere. I've cut/pasted the
> relevant part.
>
> Any advice/help, please?
>
> Thanks!
> ~Stack~
>
>
> 2018-02-07 16:56:21,697-0600 DEBUG otopi.plugins.otopi.dialog.machine
> dialog.__logString:204 DIALOG:SEND   **%EventEnd STAGE misc METHOD
> otopi.plugins.ovirt_host_deploy.tune.tuned.Plugin._misc (None)
> 2018-02-07 16:56:21,698-0600 DEBUG otopi.context
> context._executeMethod:128 Stage misc METHOD
> otopi.plugins.ovirt_host_deploy.vdsm.vdsmid.Plugin._store_id
> 2018-02-07 16:56:21,698-0600 DEBUG otopi.plugins.otopi.dialog.machine
> dialog.__logString:204 DIALOG:SEND   **%EventStart STAGE misc METHOD
> otopi.plugins.ovirt_host_deploy.vdsm.vdsmid.Plugin._store_id (None)
> 2018-02-07 16:56:21,699-0600 DEBUG otopi.transaction
> transaction._prepare:61 preparing 'File transaction for '/etc/vdsm/vdsm.id
> ''
> 2018-02-07 16:56:21,699-0600 DEBUG otopi.filetransaction
> filetransaction.prepare:183 file '/etc/vdsm/vdsm.id' missing
> 2018-02-07 16:56:21,705-0600 DEBUG otopi.plugins.otopi.dialog.machine
> dialog.__logString:204 DIALOG:SEND   **%EventEnd STAGE misc METHOD
> otopi.plugins.ovirt_host_deploy.vdsm.vdsmid.Plugin._store_id (None)
> 2018-02-07 16:56:21,706-0600 DEBUG otopi.context
> context._executeMethod:128 Stage misc METHOD
> otopi.plugins.ovirt_host_deploy.vdsmhooks.hooks.Plugin._hooks
> 2018-02-07 16:56:21,706-0600 DEBUG otopi.plugins.otopi.dialog.machine
> dialog.__logString:204 DIALOG:SEND   **%EventStart STAGE misc METHOD
> otopi.plugins.ovirt_host_deploy.vdsmhooks.hooks.Plugin._hooks (None)
> 2018-02-07 16:56:21,707-0600 DEBUG otopi.plugins.otopi.dialog.machine
> dialog.__logString:204 DIALOG:SEND   **%EventEnd STAGE misc METHOD
> otopi.plugins.ovirt_host_deploy.vdsmhooks.hooks.Plugin._hooks (None)
> 2018-02-07 16:56:21,707-0600 DEBUG otopi.context
> context._executeMethod:128 Stage misc METHOD
> otopi.plugins.ovirt_host_common.vdsm.pki.Plugin._misc
> 2018-02-07 16:56:21,708-0600 DEBUG otopi.plugins.otopi.dialog.machine
> dialog.__logString:204 DIALOG:SEND   **%EventStart STAGE misc METHOD
> otopi.plugins.ovirt_host_common.vdsm.pki.Plugin._misc (None)
> 2018-02-07 16:56:21,708-0600 DEBUG otopi.plugins.otopi.dialog.machine
> dialog.__logString:204 DIALOG:SEND   ### Setting up PKI
> 2018-02-07 16:56:21,709-0600 DEBUG
> otopi.plugins.ovirt_host_common.vdsm.pki plugin.executeRaw:813 execute:
> ('/usr/bin/openssl', 'req', '-new', '-newkey', 'rsa:2048', '-nodes',
> '-subj', '/', '-keyout', '/tmp/tmpQkrIuV.tmp'), executable='None',
> cwd='None', env=None
> 2018-02-07 16:56:21,756-0600 DEBUG
> otopi.plugins.ovirt_host_common.vdsm.pki plugin.executeRaw:863
> execute-result: ('/usr/bin/openssl', 'req', '-new', '-newkey',
> 'rsa:2048', '-nodes', '-subj', '/', '-keyout', '/tmp/tmpQkrIuV.tmp'), rc=0
> 2018-02-07 16:56:21,757-0600 DEBUG otopi.plugins.otopi.dialog.machine
> dialog.__logString:204 DIALOG:SEND   ###
> 2018-02-07 16:56:21,757-0600 DEBUG otopi.plugins.otopi.dialog.machine
> dialog.__logString:204 DIALOG:SEND   ###
> 2018-02-07 16:56:21,757-0600 DEBUG otopi.plugins.otopi.dialog.machine
> dialog.__logString:204 DIALOG:SEND   ### Please issue VDSM
> certificate based on this certificate request
> 2018-02-07 16:56:21,757-0600 DEBUG otopi.plugins.otopi.dialog.machine
> dialog.__logString:204 DIALOG:SEND   ###
> 2018-02-07 16:56:21,757-0600 DEBUG otopi.plugins.otopi.dialog.machine
> dialog.__logString:204 DIALOG:SEND   ***D:MULTI-STRING
> VDSM_CERTIFICATE_REQUEST --=451b80dc-996f-432e-9e4f-2b29ef6d1141=--
> 2018-02-07 16:56:21,757-0600 DEBUG otopi.plugins.otopi.dialog.machine
> dialog.__logString:204 DIALOG:SEND   -BEGIN CERTIFICATE
> REQUEST-
> 2018-02-07 16:56:21,757-0600 DEBUG otopi.plugins.otopi.dialog.machine
> dialog.__logString:204 DIALOG:SEND
> MIICRTCCAS0CAQAwADCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMZm
> 2018-02-07 16:56:21,7

Re: [ovirt-users] After realizing HA migration, the virtual machine can still get the virtual machine information by using the "vdsm-client host getVMList" instruction on the host before the migration

2018-02-08 Thread Petr Kotas
Hi Pym,

the feature is know in testing. I am not sure when it will be released, but
I hope for sooner date.

Petr

On Tue, Feb 6, 2018 at 12:36 PM, Pym  wrote:

> Thank you very much for your help, so is this patch released now? Where
> can I get this patch?
>
>
>
>
>
>
> At 2018-02-05 20:52:04, "Petr Kotas"  wrote:
>
> Hi,
>
> I have experimented on the issue and figured out the reason for the
> original issue.
>
> You are right, that the vm1 is not properly stopped. This is due to the
> known issue in the graceful shutdown introduced in the ovirt 4.2.
> The vm on the host in shutdown are killed, but are not marked as stopped.
> This results in the behavior you have observed.
>
> Luckily, the patch is already done and present in the latest ovirt.
> However, be ware that gracefully shutting down the host, will result in
> graceful shutdown of
> the VMs. This result in engine not migrating them, since they have been
> terminated gracefully.
>
> Hope this helps.
>
> Best,
> Petr
>
>
> On Fri, Feb 2, 2018 at 6:00 PM, Simone Tiraboschi 
> wrote:
>
>>
>>
>> On Thu, Feb 1, 2018 at 1:06 PM, Pym  wrote:
>>
>>> The environment on my side may be different from the link. My VM1 can be
>>> used normally after it is started on host2, but there is still information
>>> left on host1 that is not cleaned up.
>>>
>>> Only the interface and background can still get the information of vm1
>>> on host1, but the vm2 has been successfully started on host2, with the HA
>>> function.
>>>
>>> I would like to ask a question, whether the UUID of the virtual machine
>>> is stored in the database or where is it maintained? Is it not successfully
>>> deleted after using the HA function?
>>>
>>>
>> I just encounter a similar behavior:
>> after a reboot of the host 'vdsm-client Host getVMFullList' is still
>> reporting an old VM that is not visible with 'virsh -r list --all'.
>>
>> I filed a bug to track it:
>> https://bugzilla.redhat.com/show_bug.cgi?id=1541479
>>
>>
>>
>>>
>>>
>>>
>>>
>>>  2018-02-01 16:12:16,"Simone Tiraboschi"  :
>>>
>>>
>>>
>>> On Thu, Feb 1, 2018 at 2:21 AM, Pym  wrote:
>>>
>>>>
>>>> I checked the vm1, he is keep up state, and can be used, but on host1
>>>> has after shutdown is a suspended vm1, this cannot be used, this is the
>>>> problem now.
>>>>
>>>> In host1, you can get the information of vm1 using the "vdsm-client
>>>> Host getVMList", but you can't get the vm1 information using the "virsh
>>>> list".
>>>>
>>>>
>>> Maybe a side effect of https://bugzilla.redhat.com
>>> /show_bug.cgi?id=1505399
>>>
>>> Arik?
>>>
>>>
>>>
>>>>
>>>>
>>>>
>>>>  2018-02-01 07:16:37,"Simone Tiraboschi"  :
>>>>
>>>>
>>>>
>>>> On Wed, Jan 31, 2018 at 12:46 PM, Pym  wrote:
>>>>
>>>>> Hi:
>>>>>
>>>>> The current environment is as follows:
>>>>>
>>>>> Ovirt-engine version 4.2.0 is the source code compilation and
>>>>> installation. Add two hosts, host1 and host2, respectively. At host1, a
>>>>> virtual machine is created on vm1, and a vm2 is created on host2 and HA is
>>>>> configured.
>>>>>
>>>>> Operation steps:
>>>>>
>>>>> Use the shutdown -r command on host1. Vm1 successfully migrated to
>>>>> host2.
>>>>> When host1 is restarted, the following situation occurs:
>>>>>
>>>>> The state of the vm2 will be shown in two images, switching from up
>>>>> and pause.
>>>>>
>>>>> When I perform the "vdsm-client Host getVMList" in host1, I will get
>>>>> the information of vm1. When I execute the "vdsm-client Host getVMList" in
>>>>> host2, I will get the information of vm1 and vm2.
>>>>> When I do "virsh list" in host1, there is no virtual machine
>>>>> information. When I execute "virsh list" at host2, I will get information
>>>>> of vm1 and vm2.
>>>>>
>>>>> How to solve this problem?
>>>>>
>>>>> Is it the case that vm1 did not remove the information on host1 during
>>>>> the migration, or any other reason?
>>>>>
>>>>
>>>> Did you also check if your vms always remained up?
>>>> In 4.2 we have libvirt-guests service on the hosts which tries to
>>>> properly shutdown the running VMs on host shutdown.
>>>>
>>>>
>>>>>
>>>>> Thank you.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ___
>>>>> Users mailing list
>>>>> Users@ovirt.org
>>>>> http://lists.ovirt.org/mailman/listinfo/users
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>> ___
>> Users mailing list
>> Users@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/users
>>
>>
>
>
>
>
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


Re: [ovirt-users] vdsmd fails after upgrade 4.1 -> 4.2

2018-02-05 Thread Petr Kotas
Hi Frank,

can you please send a vdsm logs? The 4.2 release added the little different
deployment from the engine.
Now the ansible is also called. Although I am not sure if this is your case.

I would go for entirely removing the vdsm and installing it from scratch if
it is possible for you.
This could solve your issue.

Looking forward to hear from you.

Petr

On Mon, Feb 5, 2018 at 2:49 PM, Frank Rothenstein <
f.rothenst...@bodden-kliniken.de> wrote:

> Hi,
>
> I'm currently stuck - after upgrading 4.1 to 4.2 I cannot start the
> host-processes.
> systemctl start vdsmd fails with following lines in journalctl:
>
> 
>
> Feb 05 14:40:15 glusternode1.bodden-kliniken.net
> vdsmd_init_common.sh[10414]: vdsm: Running wait_for_network
> Feb 05 14:40:15 glusternode1.bodden-kliniken.net
> vdsmd_init_common.sh[10414]: vdsm: Running run_init_hooks
> Feb 05 14:40:15 glusternode1.bodden-kliniken.net
> vdsmd_init_common.sh[10414]: vdsm: Running check_is_configured
> Feb 05 14:40:15 glusternode1.bodden-kliniken.net
> sasldblistusers2[10440]: DIGEST-MD5 common mech free
> Feb 05 14:40:16 glusternode1.bodden-kliniken.net
> vdsmd_init_common.sh[10414]: Error:
> Feb 05 14:40:16 glusternode1.bodden-kliniken.net
> vdsmd_init_common.sh[10414]: One of the modules is not configured to
> work with VDSM.
> Feb 05 14:40:16 glusternode1.bodden-kliniken.net
> vdsmd_init_common.sh[10414]: To configure the module use the following:
> Feb 05 14:40:16 glusternode1.bodden-kliniken.net
> vdsmd_init_common.sh[10414]: 'vdsm-tool configure [--module module-
> name]'.
> Feb 05 14:40:16 glusternode1.bodden-kliniken.net
> vdsmd_init_common.sh[10414]: If all modules are not configured try to
> use:
> Feb 05 14:40:16 glusternode1.bodden-kliniken.net
> vdsmd_init_common.sh[10414]: 'vdsm-tool configure --force'
> Feb 05 14:40:16 glusternode1.bodden-kliniken.net
> vdsmd_init_common.sh[10414]: (The force flag will stop the module's
> service and start it
> Feb 05 14:40:16 glusternode1.bodden-kliniken.net
> vdsmd_init_common.sh[10414]: afterwards automatically to load the new
> configuration.)
> Feb 05 14:40:16 glusternode1.bodden-kliniken.net
> vdsmd_init_common.sh[10414]: abrt is already configured for vdsm
> Feb 05 14:40:16 glusternode1.bodden-kliniken.net
> vdsmd_init_common.sh[10414]: lvm is configured for vdsm
> Feb 05 14:40:16 glusternode1.bodden-kliniken.net
> vdsmd_init_common.sh[10414]: libvirt is not configured for vdsm yet
> Feb 05 14:40:16 glusternode1.bodden-kliniken.net
> vdsmd_init_common.sh[10414]: Current revision of multipath.conf
> detected, preserving
> Feb 05 14:40:16 glusternode1.bodden-kliniken.net
> vdsmd_init_common.sh[10414]: Modules libvirt are not configured
> Feb 05 14:40:16 glusternode1.bodden-kliniken.net
> vdsmd_init_common.sh[10414]: vdsm: stopped during execute
> check_is_configured task (task returned with error code 1).
> Feb 05 14:40:16 glusternode1.bodden-kliniken.net systemd[1]:
> vdsmd.service: control process exited, code=exited status=1
> Feb 05 14:40:16 glusternode1.bodden-kliniken.net systemd[1]: Failed to
> start Virtual Desktop Server Manager.
> -- Subject: Unit vdsmd.service has failed
> -- Defined-By: systemd
> -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
> --
> -- Unit vdsmd.service has failed.
> --
> -- The result is failed.
> Feb 05 14:40:16 glusternode1.bodden-kliniken.net systemd[1]: Dependency
> failed for MOM instance configured for VDSM purposes.
> -- Subject: Unit mom-vdsm.service has failed
>
> 
>
> The suggested "vdsm-tool configure --force" runs w/o errors, the
> following restart of vdsmd shows the same error.
>
> Any hints on that topic?
>
> Frank
>
>
>
> Frank Rothenstein
>
> Systemadministrator
> Fon: +49 3821 700 125 <+49%203821%20700125>
> Fax: +49 3821 700 190 <+49%203821%20700190>
> Internet: www.bodden-kliniken.de
> E-Mail: f.rothenst...@bodden-kliniken.de
>
>
> _
> BODDEN-KLINIKEN Ribnitz-Damgarten GmbH
> Sandhufe 2
> 18311 Ribnitz-Damgarten
>
> Telefon: 03821-700-0
> Telefax: 03821-700-240
>
> E-Mail: i...@bodden-kliniken.de
> Internet: http://www.bodden-kliniken.de
>
> Sitz: Ribnitz-Damgarten, Amtsgericht: Stralsund, HRB 2919, Steuer-Nr.:
> 079/133/40188
> Aufsichtsratsvorsitzende: Carmen Schröter, Geschäftsführer: Dr. Falko
> Milski, MBA
>
> Der Inhalt dieser E-Mail ist ausschließlich für den bezeichneten
> Adressaten bestimmt. Wenn Sie nicht der
> vorgesehene Adressat dieser E-Mail oder dessen Vertreter sein sollten,
> beachten Sie bitte, dass jede
> Form der Veröffentlichung, Vervielfältigung oder Weitergabe des Inhalts
> dieser E-Mail unzulässig ist.
> Wir bitten Sie, sofort den Absender zu informieren und die E-Mail zu
> löschen.
>
>   © BODDEN-KLINIKEN Ribnitz-Damgarten GmbH 2017
> *** Virenfrei durch Kerio Mail Server und SOPHOS Antivirus ***
>
>
> ___
> Users mailing list
> Users@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
>
>
__

Re: [ovirt-users] After realizing HA migration, the virtual machine can still get the virtual machine information by using the "vdsm-client host getVMList" instruction on the host before the migration

2018-02-05 Thread Petr Kotas
Hi,

I have experimented on the issue and figured out the reason for the
original issue.

You are right, that the vm1 is not properly stopped. This is due to the
known issue in the graceful shutdown introduced in the ovirt 4.2.
The vm on the host in shutdown are killed, but are not marked as stopped.
This results in the behavior you have observed.

Luckily, the patch is already done and present in the latest ovirt.
However, be ware that gracefully shutting down the host, will result in
graceful shutdown of
the VMs. This result in engine not migrating them, since they have been
terminated gracefully.

Hope this helps.

Best,
Petr


On Fri, Feb 2, 2018 at 6:00 PM, Simone Tiraboschi 
wrote:

>
>
> On Thu, Feb 1, 2018 at 1:06 PM, Pym  wrote:
>
>> The environment on my side may be different from the link. My VM1 can be
>> used normally after it is started on host2, but there is still information
>> left on host1 that is not cleaned up.
>>
>> Only the interface and background can still get the information of vm1 on
>> host1, but the vm2 has been successfully started on host2, with the HA
>> function.
>>
>> I would like to ask a question, whether the UUID of the virtual machine
>> is stored in the database or where is it maintained? Is it not successfully
>> deleted after using the HA function?
>>
>>
> I just encounter a similar behavior:
> after a reboot of the host 'vdsm-client Host getVMFullList' is still
> reporting an old VM that is not visible with 'virsh -r list --all'.
>
> I filed a bug to track it:
> https://bugzilla.redhat.com/show_bug.cgi?id=1541479
>
>
>
>>
>>
>>
>>
>>  2018-02-01 16:12:16,"Simone Tiraboschi"  :
>>
>>
>>
>> On Thu, Feb 1, 2018 at 2:21 AM, Pym  wrote:
>>
>>>
>>> I checked the vm1, he is keep up state, and can be used, but on host1
>>> has after shutdown is a suspended vm1, this cannot be used, this is the
>>> problem now.
>>>
>>> In host1, you can get the information of vm1 using the "vdsm-client Host
>>> getVMList", but you can't get the vm1 information using the "virsh list".
>>>
>>>
>> Maybe a side effect of https://bugzilla.redhat.com
>> /show_bug.cgi?id=1505399
>>
>> Arik?
>>
>>
>>
>>>
>>>
>>>
>>>  2018-02-01 07:16:37,"Simone Tiraboschi"  :
>>>
>>>
>>>
>>> On Wed, Jan 31, 2018 at 12:46 PM, Pym  wrote:
>>>
 Hi:

 The current environment is as follows:

 Ovirt-engine version 4.2.0 is the source code compilation and
 installation. Add two hosts, host1 and host2, respectively. At host1, a
 virtual machine is created on vm1, and a vm2 is created on host2 and HA is
 configured.

 Operation steps:

 Use the shutdown -r command on host1. Vm1 successfully migrated to
 host2.
 When host1 is restarted, the following situation occurs:

 The state of the vm2 will be shown in two images, switching from up and
 pause.

 When I perform the "vdsm-client Host getVMList" in host1, I will get
 the information of vm1. When I execute the "vdsm-client Host getVMList" in
 host2, I will get the information of vm1 and vm2.
 When I do "virsh list" in host1, there is no virtual machine
 information. When I execute "virsh list" at host2, I will get information
 of vm1 and vm2.

 How to solve this problem?

 Is it the case that vm1 did not remove the information on host1 during
 the migration, or any other reason?

>>>
>>> Did you also check if your vms always remained up?
>>> In 4.2 we have libvirt-guests service on the hosts which tries to
>>> properly shutdown the running VMs on host shutdown.
>>>
>>>

 Thank you.




 ___
 Users mailing list
 Users@ovirt.org
 http://lists.ovirt.org/mailman/listinfo/users


>>>
>>>
>>>
>>>
>>
>>
>>
>>
>>
>
>
> ___
> Users mailing list
> Users@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
>
>
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


Re: [ovirt-users] oVirt install videos or blogs?

2017-08-22 Thread Petr Kotas
There are some scattered on the internet. Are You looking for something
specific? Maybe we can come up with something.

Best,
Petr

On Tue, Aug 22, 2017 at 10:52 AM,  wrote:

> Are there any other resources, blogs or install videos similar to this?
> (see link)
> https://www.ovirt.org/blog/2017/04/up-and-running-with-ovirt
> -4.1-and-gluster-storage/
> ___
> Users mailing list
> Users@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
>
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users