- Users - oVirt List Archives

Configuring the SRIOV virsh device
by David LeVene 10 Mar '16

10 Mar '16

--_000_BLUPR0301MB1971508A98EC31035499673AE9B30BLUPR0301MB1971_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hey All, Still trying to work through this VMFEX stuff, and I know what I want the f= ile to look like at the end.. but not sure how to achieve it from the doco = written here http://www.ovirt.org/develop/developer-guide/vdsm/hook/vmfex/ and http://www.ovirt.org/develop/release-management/features/network/ucs-integr= ation/ Currently my device looks like this # virsh -r net-dumpxml vdsm-SRIOV <network> <name>vdsm-SRIOV</name> <forward mode=3D'bridge'/> <bridge name=3D'SRIOV'/> </network> I want it looking like this, then the networking will be as it should be! A port group would be a vNIC Profile from the looks of things... <name>vdsm-SRIOV</name> <forward dev=3D'enp6s0f1' mode=3D'passthrough'> = <-- defined as a passthrough device, not a bridge <interface dev=3D'enp6s0f1'/> <interface dev=3D'enp6s0f2'/> <interface dev=3D'enp6s0f3'/> <interface dev=3D'enp6s0f4'/> < .. list of interfaces available to it which would need to be manually i= nputted as a hook> </forward> <portgroup name=3D'ame1-test1'> <virtualport type=3D'802.1Qbh'> <parameters profileid=3D'profile-ame1-test1'/> </virtualport> </portgroup> <portgroup name=3D'ame1-prep1'> <virtualport type=3D'802.1Qbh'> <parameters profileid=3D'profile-ame1-prep1'/> </virtualport> </portgroup> </network> Cheers David This email and any attachments may contain confidential and proprietary inf= ormation of Blackboard that is for the sole use of the intended recipient. = If you are not the intended recipient, disclosure, copying, re-distribution= or other use of any of this information is strictly prohibited. Please imm= ediately notify the sender and delete this transmission if you received thi= s email in error. --_000_BLUPR0301MB1971508A98EC31035499673AE9B30BLUPR0301MB1971_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > <meta name=3D"Generator" content=3D"Microsoft Word 15 (filtered medium)"> <style></style> </head> <body lang=3D"EN-AU" link=3D"#0563C1" vlink=3D"#954F72"> <div class=3D"WordSection1"> Hey All,<o:p></o:p> <o:p> </o:p> Still trying to work through this VMFEX stuff, and I= know what I want the file to look like at the end.. but not sure how to ac= hieve it from the doco written here<o:p></o:p> <o:p> </o:p> <a href=3D"http://www.ovirt.org/develop/developer-gu= ide/vdsm/hook/vmfex/">http://www.ovirt.org/develop/developer-guide/vdsm/hoo= k/vmfex/</a><o:p></o:p> and<o:p></o:p> <a href=3D"http://www.ovirt.org/develop/release-mana= gement/features/network/ucs-integration/">http://www.ovirt.org/develop/rele= ase-management/features/network/ucs-integration/</a><o:p></o:p> <o:p> </o:p> Currently my device looks like this<o:p></o:p> <o:p> </o:p> # virsh -r net-dumpxml vdsm-SRIOV<o:p></o:p> <network><o:p></o:p>   <name>vdsm-SRIOV</name><o:p></o:p= >  <forward mode=3D'bridge'/><o:p></o:p></p= >   <bridge name=3D'SRIOV'/><o:p></o:p> </network><o:p></o:p> <o:p> </o:p> <o:p> </o:p> I want it looking like this, then the networking wil= l be as it should be!<o:p></o:p> A port group would be a vNIC Profile from the looks = of things…<o:p></o:p> <o:p> </o:p>   <name>vdsm-SRIOV</name><o:p></o:p= >   <forward dev=3D'enp6s0f1' mode=3D'passthro= ugh'>           &= nbsp;           &nbs= p;     ß defined as a passthrou= gh device, not a bridge<o:p></o:p>     <interface dev=3D'enp6s0f1'/&g= t;<o:p></o:p>     <interface dev=3D'enp6s0f2'/&g= t;<o:p></o:p>     <interface dev=3D'enp6s0f3'/&g= t;<o:p></o:p>     <interface dev=3D'enp6s0f4'/&g= t;<o:p></o:p> <   .. list of interfaces available to = it which would need to be manually inputted as a hook><o:p></o:p>   </forward><o:p></o:p>   <portgroup name=3D'ame1-test1'><o:p></o= :p>     <virtualport type=3D'802.1Qbh'= ><o:p></o:p>       <parameters profil= eid=3D'profile-ame1-test1'/><o:p></o:p>     </virtualport><o:p></o:p></= p>   </portgroup> <o:p></o:p>   <portgroup name=3D'ame1-prep1'><o:= p></o:p>     <virtualport type=3D'802.1Qbh'= ><o:p></o:p>       <parameters profil= eid=3D'profile-ame1-prep1'/><o:p></o:p>     </virtualport><o:p></o:p></= p>   </portgroup><o:p></o:p> </network><o:p></o:p> <o:p> </o:p> <o:p> </o:p> Cheers<o:p></o:p> David<o:p></o:p> </div> This email and any attachments may contain confidential and proprietary inf= ormation of Blackboard that is for the sole use of the intended recipient. = If you are not the intended recipient, disclosure, copying, re-distribution= or other use of any of this information is strictly prohibited. Please immediately notify the sender and delete th= is transmission if you received this email in error. </body> </html> --_000_BLUPR0301MB1971508A98EC31035499673AE9B30BLUPR0301MB1971_--

2 6

Understand CPU Socket Cores and VCPU
by Taste-Of-IT 10 Mar '16

10 Mar '16

Hello, i have a general Question about Hardware CPU, Socket, Cores and the VCPU, Cores per VSocket and VScoket for virtual Machines. Example i have a single CPU with 4 Cores and 8 Threads. As far as i understand i should configure the virtual machines with that number of socket as the host has. So in this example with max 1 Socket. How is the possibility in VCPUs and VCores? What is the limit in this example? Can i only run max 4 VMs? Thanks for clarifying Taste

2 2

Installation of host hangs and will not finish installation of host
by Jonas Kirk Pedersen 10 Mar '16

10 Mar '16

Im and quite new at using mailing list, but here is my current challenge. I am adding a new host from a fresh install centos 7. Updated with yum -y update and yum install then repo from ovirt v.3.6. Now the installation of the host is stuck at validating for 2 hours. Have tried to restart vdsmd to see if I cant trigger a failure, but no. Did a reboot of the host and that did not help. Now it is powered off and the engine is has registered that there is no connection to the host with error: "VDSM KVM2 command failed: Connection issue null" Is there a way to cancel a running task? -- Jonas Kirk Pedersen ASOM-Net Systemadministrator

2 1

VDSM will not start
by Jonas Kirk Pedersen 10 Mar '16

10 Mar '16

This is a multi-part message in MIME format. --------------080709040101080905010803 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Had a problem where on the host the vdsm service would not start. The following is from #ovirt IRC chat after I emailed the sos report from the host 13:29:06) sbonazzo: jkp looks like an issue while starting supervdsm, I see: (13:29:08) sbonazzo: Mar 9 12:41:30 kvm1 daemonAdapter: OSError: [Errno 2] No such file or directory: '/var/run/vdsm/svdsm.sock' (13:29:08) sbonazzo: Mar 9 12:41:30 kvm1 systemd: start request repeated too quickly for supervdsmd.service (13:29:26) sbonazzo: danken: ybronhei: nsoffer ^^ (13:30:57) sbonazzo: msivak: i see also Mar 9 12:27:18 kvm1 systemd: [/usr/lib/systemd/system/momd.service:11] Unknown lvalue 'Timeout' in section 'Service' (13:31:30) sbonazzo: msivak: maybe epel7 mom should be updated (13:32:33) sbonazzo: after that, vdsm doesn't come up due to Mar 9 12:27:55 kvm1 daemonAdapter: OSError: [Errno 2] No such file or directory: '/var/run/vdsm/svdsm.sock since supervdsmd didn't run (13:34:50) sbonazzo: jkp: can you try to manually start supervdsmd service? (13:35:07) jkp: sbonazzo, it is confirmed that the file is not there. But shouldn't the service create this file -- Yes I'll try (13:35:19) sbonazzo: jkp: yes, it's supposed to (13:39:07) jkp: sbonazzo, still gives me the : OSError: [Errno 2] No such file or directory: '/var/run/vdsm/svdsm.sock' (13:39:35) sbonazzo: jkp does /var/run/vdsm/ exist? (13:40:55) jkp: sbonazzo, yes it contains [root@kvm1 ~]# ls /var/run/vdsm/ lvm sourceRoutes trackedInterfaces v2v Later I received a email Mar 9 10:41:21 kvm1 journal: Module /usr/lib64/libvirt/connection-driver/libvirt_driver_lxc.so not accessible Mar 9 10:41:21 kvm1 journal: The server certificate /etc/pki/vdsm/certs/vdsmcert.pem is not yet active Mar 9 10:41:21 kvm1 systemd: libvirtd.service: main process exited, code=exited, status=6/NOTCONFIGURED Mar 9 10:41:21 kvm1 systemd: Failed to start Virtualization daemon. Mar 9 10:41:21 kvm1 systemd: Dependency failed for Virtual Desktop Server Manager. Mar 9 10:41:21 kvm1 systemd: Dependency failed for MOM instance configured for VDSM purposes. Mar 9 10:41:21 kvm1 systemd: Job mom-vdsm.service/start failed with result 'dependency'. Mar 9 10:41:21 kvm1 systemd: Job vdsmd.service/start failed with result 'dependency'. Mar 9 10:41:21 kvm1 systemd: Dependency failed for Virtual Desktop Server Manager network restoration. Mar 9 10:41:21 kvm1 systemd: Job vdsm-network.service/start failed with result 'dependency'. Mar 9 10:41:21 kvm1 systemd: Unit libvirtd.service entered failed state. Mar 9 10:41:21 kvm1 systemd: libvirtd.service failed. Mar 9 10:41:21 kvm1 systemd-logind: Removed session 4. Mar 9 10:41:21 kvm1 systemd: libvirtd.service holdoff time over, scheduling restart. I see that libvirtd fails to start. It might be due to Engine system clock being deep in the future? What I had failed to notice was that the vdsmcert.pem that was not active. The ntp service running on the Engine was out of sync with a year resulting in that of cause the certificate did not work and then the vdsm would not start. I have a fairly new engine so I removed it and fixed the time issue and all was perfect Thanks for a great help on the chat and on email -- Jonas Kirk Pedersen ASOM-Net Systemadministrator --------------080709040101080905010803 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit <html> <head> <meta http-equiv="content-type" content="text/html; charset=utf-8"> </head> <body text="#000000" bgcolor="#FFFFFF"> Had a problem where on the host the vdsm service would not start. The following is from #ovirt IRC chat after I emailed the sos report from the host 13:29:06) sbonazzo: jkp looks like an issue while starting supervdsm, I see: (13:29:08) sbonazzo: Mar 9 12:41:30 kvm1 daemonAdapter: OSError: [Errno 2] No such file or directory: '/var/run/vdsm/svdsm.sock' (13:29:08) sbonazzo: Mar 9 12:41:30 kvm1 systemd: start request repeated too quickly for supervdsmd.service (13:29:26) sbonazzo: danken: ybronhei: nsoffer ^^ (13:30:57) sbonazzo: msivak: i see also Mar 9 12:27:18 kvm1 systemd: [/usr/lib/systemd/system/momd.service:11] Unknown lvalue 'Timeout' in section 'Service' (13:31:30) sbonazzo: msivak: maybe epel7 mom should be updated (13:32:33) sbonazzo: after that, vdsm doesn't come up due to Mar 9 12:27:55 kvm1 daemonAdapter: OSError: [Errno 2] No such file or directory: '/var/run/vdsm/svdsm.sock since supervdsmd didn't run (13:34:50) sbonazzo: jkp: can you try to manually start supervdsmd service? (13:35:07) jkp: sbonazzo, it is confirmed that the file is not there. But shouldn't the service create this file -- Yes I'll try (13:35:19) sbonazzo: jkp: yes, it's supposed to (13:39:07) jkp: sbonazzo, still gives me the : OSError: [Errno 2] No such file or directory: '/var/run/vdsm/svdsm.sock' (13:39:35) sbonazzo: jkp does /var/run/vdsm/ exist? (13:40:55) jkp: sbonazzo, yes it contains [root@kvm1 ~]# ls /var/run/vdsm/ lvm sourceRoutes trackedInterfaces v2v Later I received a email <pre class="moz-signature" cols="72">Mar 9 10:41:21 kvm1 journal: Module /usr/lib64/libvirt/connection-driver/libvirt_driver_lxc.so not accessible Mar 9 10:41:21 kvm1 journal: The server certificate /etc/pki/vdsm/certs/vdsmcert.pem is not yet active Mar 9 10:41:21 kvm1 systemd: libvirtd.service: main process exited, code=exited, status=6/NOTCONFIGURED Mar 9 10:41:21 kvm1 systemd: Failed to start Virtualization daemon. Mar 9 10:41:21 kvm1 systemd: Dependency failed for Virtual Desktop Server Manager. Mar 9 10:41:21 kvm1 systemd: Dependency failed for MOM instance configured for VDSM purposes. Mar 9 10:41:21 kvm1 systemd: Job mom-vdsm.service/start failed with result 'dependency'. Mar 9 10:41:21 kvm1 systemd: Job vdsmd.service/start failed with result 'dependency'. Mar 9 10:41:21 kvm1 systemd: Dependency failed for Virtual Desktop Server Manager network restoration. Mar 9 10:41:21 kvm1 systemd: Job vdsm-network.service/start failed with result 'dependency'. Mar 9 10:41:21 kvm1 systemd: Unit libvirtd.service entered failed state. Mar 9 10:41:21 kvm1 systemd: libvirtd.service failed. Mar 9 10:41:21 kvm1 systemd-logind: Removed session 4. Mar 9 10:41:21 kvm1 systemd: libvirtd.service holdoff time over, scheduling restart. I see that libvirtd fails to start. It might be due to Engine system clock being deep in the future? </pre> What I had failed to notice was that the vdsmcert.pem that was not active. The ntp service running on the Engine was out of sync with a year resulting in that of cause the certificate did not work and then the vdsm would not start. I have a fairly new engine so I removed it and fixed the time issue and all was perfect Thanks for a great help on the chat and on email <pre class="moz-signature" cols="72"> </pre> <pre class="moz-signature" cols="72">-- Jonas Kirk Pedersen ASOM-Net Systemadministrator </pre> </body> </html> --------------080709040101080905010803--

1 0

The bumpy road to Ceph
by Bond, Darryl 10 Mar '16

10 Mar '16

We intend to migrate off our small Openstack/Ceph cluster to oVirt as it is a better fit for our organisation. We wanted to run oVirt backed on to Ceph storage for quite some time. We waited for the 3.6 development to take it's course and started testing last year. The kolla cinder container implementation changed fundamentally in the middle of the oVirt release process which broke the oVirt 'official' cinder implementation. We had tested oVirt using our Openstack cinder so we knew it basically worked but we didn't want to mix the oVirt and Openstack volumes, ie put oVirt into it's own ceph pool. We waited and waited for the Kolla container ... There didn't seem to be any end in sight, so we chose the following configuration: - Hosted engine on Centos 7.2 with gluster storage - Cinder/Keystone VM on Centos 7.2 using RDO and cinder 'liberty' kept in the same gluster store as the engine and managed by the engine. - Used the oVirt engine Postgres database as the Cinder/Keystone store so we didn't introduce more dependencies with MySQL that Kolla required. (New user and database for the cinder store. Backups exported separate to the engine backups) It's early days yet but here are some observations: - It works very well integrated with oVirt from the point of view of building and managing new VM's - Snapshots and cloning use ceph's features - No simple means to move Vm disks to and from other storage domains. - Not impossible though, it means that you have to delete and import ceph RBD's behind both oVirt and Cinder. It is fairly dangerous as I haven't found a simple way to get the rbd volume name with vdsClient other than 'vdsClient list' running VM's. Openstack at least publishes the volume name (UUID) in the gui, oVirt does not. - Successfully imported VM images from both Openstack and VMWare. - There is a hard dependency between oVirt and Cinder when starting VM's but does not require Cinder to run VMs. Strange really, when the volume name could be stored in oVirt when the volume is created rather than query cinder for each start. Where to from here. Hosting Cinder/Keystone in containers on the engine VM makes sense. We are going to roll our own container(s), given the data will be in the engine Postgres database it should be possible to transition in a clean fassion. Darryl ________________________________ The contents of this electronic message and any attachments are intended only for the addressee and may contain legally privileged, personal, sensitive or confidential information. If you are not the intended addressee, and have received this email, any transmission, distribution, downloading, printing or photocopying of the contents of this message or attachments is strictly prohibited. Any legal privilege or confidentiality attached to this message and attachments is not waived, lost or destroyed by reason of delivery to any person other than intended addressee. If you have received this message and are not the intended addressee you should notify the sender by return email and destroy all copies of the message and any attachments. Unless expressly attributed, the views expressed in this email do not necessarily represent the views of the company.

1 0

Admin lockout
by Clint Boggio 09 Mar '16

09 Mar '16

I had a keyboard problem and entered the wrong password for admin@internal enough times to finally lock the account. How do I recover from this ? OVirt engine 3.6.2

3 3

Re: [ovirt-users] Adding servers after hosted ending servers fail due to incorrect mount options in vdsm
by Nir Soffer 09 Mar '16

09 Mar '16

On Wed, Mar 9, 2016 at 11:22 PM, Bond, Darryl <dbond(a)nrggos.com.au> wrote: > Yes, your last example is the one we are shooting for: > One DC multiple clusters, one being the hosted engine cluster all sharing the same storage, which has to include the hosted engine gluster storage. > The remainder of the storage will be mainly in cinder/ceph Please share your experience with cinder/ceph, we like to get feedback about it. (probably in another thread) > with for export/ISO domains. > Our initial attempt was to attach the new non-hosted engine server to a new cluster but we also tried to add it to the same cluster as the hosted engines with the same result. It just seems to remove the complication of the second cluster to try to get it working in the hosted engine cluster. > > Darryl > > ________________________________________ > From: Nir Soffer <nsoffer(a)redhat.com> > Sent: Wednesday, 9 March 2016 9:50 PM > To: Bond, Darryl; users; Simone Tiraboschi; Roy Golan; Maor Lipchuk > Subject: Re: [ovirt-users] Adding servers after hosted ending servers fail due to incorrect mount options in vdsm > > On Wed, Mar 9, 2016 at 11:48 AM, Bond, Darryl <dbond(a)nrggos.com.au> wrote: >> Nir, >> The run and protect was the line above, I have included it above the rest. >> My comments about not creating a extra data centre agree with yours. I want: >> 1 data centre which includes: >> 1 set of storage domains > > What do you mean by "set of storage domains?" > >> 3 hosted engine ha hosts >> 4 extra hosts > > I don't know about hosted engine limitations, but generally a host can be only > part of one DC and cluster. > > So you can have 3 hosts serving as hosted engine nodes, with their own > storage, used only for hosted engine, and you can have another DC for > vms, using other storage domains. > > Or you can have one DC, with all the storage domains, and several clusters, > one for hosted engine nodes, and one for compute nodes for other vms. > In this case all the nodes will have to connect to all storage domains. > > Pick the setup that fits your needs. > >> >> I cannot activate an additional (non ha) host as it errors mounting the gluster hosted engine domain as it does not pass the -t glusterfs. I don't really care if they didn't (as it is only there for the hosted-engine ha hosts) but that does not seem possible. >> ________________________________________ >> From: Nir Soffer <nsoffer(a)redhat.com> >> Sent: Wednesday, 9 March 2016 6:17 PM >> To: Bond, Darryl; Ala Hino >> Cc: users(a)ovirt.org >> Subject: Re: [ovirt-users] Adding servers after hosted ending servers fail due to incorrect mount options in vdsm >> >> On Wed, Mar 9, 2016 at 7:54 AM, Bond, Darryl <dbond(a)nrggos.com.au> wrote: >>> I have a 3 node 3.6.3 hosted engine cluster (Default) with a number of VMs. The hosted engine is stored on gluster. >>> >>> Adding an additional server to the Default cluster that isn't a hosted-engine ha server fails. >>> >>> Looking at the vdsm.log, the host attempts to mount the gluster as NFS with the gluster options which fails. >>> >>> >> >> Please add the logs above the log you posted, with the string "Run and >> protect, connectStorageServer" >> >> This log contains the arguments received from engine, revealing what >> is going on. >> jsonrpc.Executor/4::INFO::2016-03-09 16:05:02,002::logUtils::48::dispatcher::(wrapper) Run and protect: connectStorageServer(domType=7, spUUID=u'00000001-0001-0001-0001-000000000229', conList=[{u'id': u'19fb9b3b-79c1-48e8-9300-d0d52ddce7b1', u'connection': u'ovirt36-h1:/hosted-engine', u'iqn': u'', u'user': u'', u'tpgt': u'1', u'password': '********', u'port': u''}], options=None) >> > > There must be vfs_type parameter here, with the value "glusterfs". > > Kind of redundant since we have a domType=7, which is glusterfs, but this is the > current API, and we must keep it for backward compatibility. > > The owner of the code sending this value should take a look. > > Nir > >>> jsonrpc.Executor/6::DEBUG::2016-03-09 15:10:01,022::fileUtils::143::Storage.fileUtils::(createdir) Creating directory: /rhev/data-center/mnt/glusterSD/ovirt36-h1:_hosted-engine mode: None >>> jsonrpc.Executor/6::DEBUG::2016-03-09 15:10:01,022::storageServer::357::Storage.StorageServer.MountConnection::(_get_backup_servers_option) Using bricks: ['ovirt36-h1', 'ovirt36-h2', 'ovirt36-h3'] >>> jsonrpc.Executor/6::DEBUG::2016-03-09 15:10:01,022::mount::229::Storage.Misc.excCmd::(_runcmd) /usr/bin/taskset --cpu-list 0-11 /usr/bin/sudo -n /usr/bin/systemd-run --scope --slice=vdsm-glusterfs /usr/bin/mount -o backup-volfile-servers=ovirt36-h2:ovirt36-h3 ovirt36-h1:/hosted-engine /rhev/data-center/mnt/glusterSD/ovirt36-h1:_hosted-engine (cwd None) >> >> -t glusterfs is missing here >> >> This line can be generated only by the GlusterfFSConnection, used when >> connecting >> to gluster storage domain, but this connection type ads the "glustefs" type. >> >>> jsonrpc.Executor/6::ERROR::2016-03-09 15:10:01,042::hsm::2473::Storage.HSM::(connectStorageServer) Could not connect to storageServer >>> Traceback (most recent call last): >>> File "/usr/share/vdsm/storage/hsm.py", line 2470, in connectStorageServer >>> conObj.connect() >>> File "/usr/share/vdsm/storage/storageServer.py", line 236, in connect >>> six.reraise(t, v, tb) >>> File "/usr/share/vdsm/storage/storageServer.py", line 228, in connect >>> self._mount.mount(self.options, self._vfsType, cgroup=self.CGROUP) >>> File "/usr/share/vdsm/storage/mount.py", line 225, in mount >>> return self._runcmd(cmd, timeout) >>> File "/usr/share/vdsm/storage/mount.py", line 241, in _runcmd >>> raise MountError(rc, ";".join((out, err))) >>> MountError: (32, ';Running scope as unit run-18808.scope.\nmount.nfs: an incorrect mount option was specified\n') >>> >>> I noticed the hosted-engine servers perform the same mount but pass the -t glusterfs correctly. >>> >>> A bug or am I doing something wrong?? >>> >>> I do not want to create a new datacentre without the hosted engine storage as I want to use the same storage domains. >> >> Same storage domains? Maybe you mean same bricks? >> >> You cannot use the same storage domain from different DC. You can >> create new gluster volume >> using the same bricks. >> >> Nir >> >> ________________________________ >> >> The contents of this electronic message and any attachments are intended only for the addressee and may contain legally privileged, personal, sensitive or confidential information. If you are not the intended addressee, and have received this email, any transmission, distribution, downloading, printing or photocopying of the contents of this message or attachments is strictly prohibited. Any legal privilege or confidentiality attached to this message and attachments is not waived, lost or destroyed by reason of delivery to any person other than intended addressee. If you have received this message and are not the intended addressee you should notify the sender by return email and destroy all copies of the message and any attachments. Unless expressly attributed, the views expressed in this email do not necessarily represent the views of the company.

1 0

Fwd: Re: Slow after add 2 Nic
by Taste-Of-IT 09 Mar '16

09 Mar '16

Hello, any help for using 2 nics in 2 networks? thx -------- Originalnachricht -------- Betreff: Re: [ovirt-users] Slow after add 2 Nic Datum: 2016-03-08 11:33 Von: Taste-Of-IT <kontakt(a)taste-of-it.de> An: oVirt Userlist <Users(a)ovirt.org> Hello, i simply add the nic and i think CentOS configure these by itself. Ok, i can change that. Short to my intentions. I want to use nic1 for my lan and nic2 for the wan route into the internet. in ovirt i want to install a firewall and configure both nics, nic for lan and nic2 for wan. in the other vm's i want to install only nic1 as bridge and configure the firwall as gateway which also service the dhcp. at all it must be safe that the vms cant break out of this and go around the firewall. so as i understand i would do this: - set in centos nic1 as default gatway wich has 192.168.0.1 as gateway - set in centos nic2 without default route - add in ovirt a new network / nic - create the vm for the firwall and assign nic1 and nic2 - in the other vms i would only assign nic1 is that the way to do or what do you think? thx Taste Am 2016-03-08 09:45, schrieb Yaniv Kaul: > Most likely (we've had something like that in FOSDEM) issue with DNS > resolving. > Make sure all IP addresses are correctly resolved. > Y. > > On Tue, Mar 8, 2016 at 12:44 AM, Taste-Of-IT <kontakt(a)taste-of-it.de> > wrote: > >> Hello, >> i have a question about adding a second Nic. After adding a second >> one the WebGUI and oVirt is very slow. The situation is as follow. >> Each nic has its own network and are seperated from each other. nic1 >> - 192.168.0.x for internal and nic2 192.168.1.x through the wan. if >> i use trace from the client i call the WebGUI, it goes over >> 192.168.0.x, the right way. but if i trace the engine self on >> localhost with its hostname it goes over 192.168.1.x, the wrong way >> and takes longer. >> >> i am not sure if its an ovirt problem or from hostsystem centos, >> but i didnt find any solution. >> >> # ip route show >> default via 192.168.0.3 dev ovirtmgmt >> default via 192.168.1.1 dev enp0s29u1u2c2 proto static metric >> 100 >> 169.254.0.0/16 [1] dev ovirtmgmt scope link metric 1006 >> 192.168.0.0/24 [2] dev ovirtmgmt proto kernel scope link src >> 192.168.0.153 >> 192.168.1.0/24 [3] dev enp0s29u1u2c2 proto kernel scope link >> src 192.168.1.2 metric 100 >> >> thx for help >> Taste >> _______________________________________________ >> Users mailing list >> Users(a)ovirt.org >> http://lists.ovirt.org/mailman/listinfo/users [4] > > > > Links: > ------ > [1] http://169.254.0.0/16 > [2] http://192.168.0.0/24 > [3] http://192.168.1.0/24 > [4] http://lists.ovirt.org/mailman/listinfo/users _______________________________________________ Users mailing list Users(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/users

2 1

changing vm's product serial
by Nathanaël Blanchet 09 Mar '16

09 Mar '16

This is a multi-part message in MIME format. --------------000101010705050708030005 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hi all, We've been using templates for months before we realized that "ocs=20 report" used Serial Number given into "demidecode -t system" to identify=20 a VM as unique. This Serial Number is located into=20 /sys/devices/virtual/dmi/id/product_serial, and we'd really want each vm=20 to have its own Serial Number instead of the template's one. We tried to generate a new id with uuidgen, but it can't be written into=20 the product_serial file. Is there a simple way to do such a thing? Thank you. --=20 Nathana=C3=ABl Blanchet Supervision r=C3=A9seau P=C3=B4le Infrastrutures Informatiques 227 avenue Professeur-Jean-Louis-Viala 34193 MONTPELLIER CEDEX 5 =09 T=C3=A9l. 33 (0)4 67 54 84 55 Fax 33 (0)4 67 54 84 14 blanchet(a)abes.fr --------------000101010705050708030005 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <html> <head> <meta http-equiv=3D"content-type" content=3D"text/html; charset=3Dutf= -8"> </head> <body bgcolor=3D"#FFFFFF" text=3D"#000000"> Hi all, We've been using templates for months before we realized that "ocs report" used Serial Number given into "demidecode -t system" to identify a VM as unique. This Serial Number is located into /sys/devices/virtual/dmi/id/product_serial,=C2=A0 and we'd really want each vm to have its own Serial Number instead of the template's one. We tried to generate a new id with uuidgen, but it can't be written into the product_serial file. Is there a simple way to do such a thing? Thank you. <pre class=3D"moz-signature" cols=3D"72">--=20 Nathana=C3=ABl Blanchet Supervision r=C3=A9seau P=C3=B4le Infrastrutures Informatiques 227 avenue Professeur-Jean-Louis-Viala 34193 MONTPELLIER CEDEX 5 =09 T=C3=A9l. 33 (0)4 67 54 84 55 Fax 33 (0)4 67 54 84 14 <a class=3D"moz-txt-link-abbreviated" href=3D"mailto:blanchet@abes.fr">bl= anchet(a)abes.fr</a> </pre> </body> </html> --------------000101010705050708030005--

2 2

User cannot add a disk to a VM - permission error
by Will Dennis 09 Mar '16

09 Mar '16

Trying to understand the oVirt user permissions system… I have a user who I have granted the “PowerUserRole” role to, with the role description being “User Role, allowed to create VMs, Templates and Disks.” When I log into the User Portal with this user, I try to create a VM with a disk, but when I click the OK button, I get the message, “Cannot add Virtual Machine Disk. The user doesn’t have permissions to attach Disk Profile to the Disk. What other permission(s) do I need to grant this user in order to have it be able to create VMs?

2 2

Logs Error
by Budur Nagaraju 09 Mar '16

09 Mar '16

Getting below logs for some reason, in the engine [root@pscloud ~]# tail -f /var/log/ovirt-engine/engine.log , sharedLocks= ] 2016-02-08 14:28:42,325 INFO [org.ovirt.engine.core.vdsbroker.irsbroker.IrsProxyData] (org.ovirt.thread.pool-8-thread-43) Removing domain fb15c568-f237-4de6-8954-5bcf0de2043f from the domains in maintenance cache 2016-02-08 14:28:42,533 ERROR [org.ovirt.engine.core.bll.GetVdsByVdsIdQuery] (ajp--127.0.0.1-8702-17) Query execution failed due to insufficient permissions. 2016-02-08 14:28:42,605 ERROR [org.ovirt.engine.core.bll.GetVdsByVdsIdQuery] (ajp--127.0.0.1-8702-17) Query execution failed due to insufficient permissions. 2016-02-08 14:28:47,551 ERROR [org.ovirt.engine.core.bll.GetVdsByVdsIdQuery] (ajp--127.0.0.1-8702-3) Query execution failed due to insufficient permissions. 2016-02-08 14:28:47,561 ERROR [org.ovirt.engine.core.bll.GetVdsByVdsIdQuery] (ajp--127.0.0.1-8702-3) Query execution failed due to insufficient permissions. 2016-02-08 14:28:52,511 ERROR [org.ovirt.engine.core.bll.GetVdsByVdsIdQuery] (ajp--127.0.0.1-8702-18) Query execution failed due to insufficient permissions. 2016-02-08 14:28:52,524 ERROR [org.ovirt.engine.core.bll.GetVdsByVdsIdQuery] (ajp--127.0.0.1-8702-18) Query execution failed due to insufficient permissions. 2016-02-08 14:28:57,597 ERROR [org.ovirt.engine.core.bll.GetVdsByVdsIdQuery] (ajp--127.0.0.1-8702-12) Query execution failed due to insufficient permissions. 2016-02-08 14:28:57,608 ERROR [org.ovirt.engine.core.bll.GetVdsByVdsIdQuery] (ajp--127.0.0.1-8702-12) Query execution failed due to insufficient permissions. 2016-02-08 14:29:02,510 ERROR [org.ovirt.engine.core.bll.GetVdsByVdsIdQuery] (ajp--127.0.0.1-8702-17) Query execution failed due to insufficient permissions. 2016-02-08 14:29:02,520 ERROR [org.ovirt.engine.core.bll.GetVdsByVdsIdQuery] (ajp--127.0.0.1-8702-17) Query execution failed due to insufficient permissions. 2016-02-08 14:29:07,539 ERROR [org.ovirt.engine.core.bll.GetVdsByVdsIdQuery] (ajp--127.0.0.1-8702-16) Query execution failed due to insufficient permissions. 2016-02-08 14:29:07,576 ERROR [org.ovirt.engine.core.bll.GetVdsByVdsIdQuery] (ajp--127.0.0.1-8702-16) Query execution failed due to insufficient permissions. 2016-02-08 14:29:12,538 ERROR [org.ovirt.engine.core.bll.GetVdsByVdsIdQuery] (ajp--127.0.0.1-8702-11) Query execution failed due to insufficient permissions. 2016-02-08 14:29:12,548 ERROR [org.ovirt.engine.core.bll.GetVdsByVdsIdQuery] (ajp--127.0.0.1-8702-11) Query execution failed due to insufficient permissions. 2016-02-08 14:29:13,948 INFO [org.ovirt.engine.core.bll.tasks.AsyncTaskManager] (DefaultQuartzScheduler_Worker-14) [5a3093d4] Setting new tasks map. The map contains now 3 tasks 2016-02-08 14:29:14,040 INFO [org.ovirt.engine.core.bll.tasks.AsyncTaskManager] (DefaultQuartzScheduler_Worker-36) [171bad22] Polling and updating Async Tasks: 3 tasks, 2 tasks to poll now 2016-02-08 14:29:14,168 INFO [org.ovirt.engine.core.bll.tasks.AsyncTaskManager] (DefaultQuartzScheduler_Worker-36) [171bad22] Finished polling Tasks, will poll again in 10 seconds. 2016-02-08 14:29:17,568 ERROR [org.ovirt.engine.core.bll.GetVdsByVdsIdQuery] (ajp--127.0.0.1-8702-13) Query execution failed due to insufficient permissions. 2016-02-08 14:29:17,578 ERROR [org.ovirt.engine.core.bll.GetVdsByVdsIdQuery] (ajp--127.0.0.1-8702-13) Query execution failed due to insufficient permissions. 2016-02-08 14:29:22,506 ERROR [org.ovirt.engine.core.bll.GetVdsByVdsIdQuery] (ajp--127.0.0.1-8702-5) Query execution failed due to insufficient permissions. 2016-02-08 14:29:22,530 ERROR [org.ovirt.engine.core.bll.GetVdsByVdsIdQuery] (ajp--127.0.0.1-8702-5) Query execution failed due to insufficient permissions. 2016-02-08 14:29:27,548 ERROR [org.ovirt.engine.core.bll.GetVdsByVdsIdQuery] (ajp--127.0.0.1-8702-14) Query execution failed due to insufficient permissions. 2016-02-08 14:29:27,585 ERROR [org.ovirt.engine.core.bll.GetVdsByVdsIdQuery] (ajp--127.0.0.1-8702-14) Query execution failed due to insufficient permissions. ^C [root@pscloud ~]#

3 5

Storage Issues
by Budur Nagaraju 09 Mar '16

09 Mar '16

HI I have configured two storage Lun through NFS one is Master which is having capacity of 2TB and the other is having 1TB. Now the issue when ever user deploy a vm automatically vm is getting deployed in master lun which is running out of HDD space and the vm is not getting deployed in the other Lun ,is there any setting to do that vm should get deployed in other LUN ? Thanks, Nagaraju

3 5

Re: [ovirt-users] Adding servers after hosted ending servers fail due to incorrect mount options in vdsm
by Nir Soffer 09 Mar '16

09 Mar '16

On Wed, Mar 9, 2016 at 11:48 AM, Bond, Darryl <dbond(a)nrggos.com.au> wrote: > Nir, > The run and protect was the line above, I have included it above the rest. > My comments about not creating a extra data centre agree with yours. I want: > 1 data centre which includes: > 1 set of storage domains What do you mean by "set of storage domains?" > 3 hosted engine ha hosts > 4 extra hosts I don't know about hosted engine limitations, but generally a host can be only part of one DC and cluster. So you can have 3 hosts serving as hosted engine nodes, with their own storage, used only for hosted engine, and you can have another DC for vms, using other storage domains. Or you can have one DC, with all the storage domains, and several clusters, one for hosted engine nodes, and one for compute nodes for other vms. In this case all the nodes will have to connect to all storage domains. Pick the setup that fits your needs. > > I cannot activate an additional (non ha) host as it errors mounting the gluster hosted engine domain as it does not pass the -t glusterfs. I don't really care if they didn't (as it is only there for the hosted-engine ha hosts) but that does not seem possible. > ________________________________________ > From: Nir Soffer <nsoffer(a)redhat.com> > Sent: Wednesday, 9 March 2016 6:17 PM > To: Bond, Darryl; Ala Hino > Cc: users(a)ovirt.org > Subject: Re: [ovirt-users] Adding servers after hosted ending servers fail due to incorrect mount options in vdsm > > On Wed, Mar 9, 2016 at 7:54 AM, Bond, Darryl <dbond(a)nrggos.com.au> wrote: >> I have a 3 node 3.6.3 hosted engine cluster (Default) with a number of VMs. The hosted engine is stored on gluster. >> >> Adding an additional server to the Default cluster that isn't a hosted-engine ha server fails. >> >> Looking at the vdsm.log, the host attempts to mount the gluster as NFS with the gluster options which fails. >> >> > > Please add the logs above the log you posted, with the string "Run and > protect, connectStorageServer" > > This log contains the arguments received from engine, revealing what > is going on. > jsonrpc.Executor/4::INFO::2016-03-09 16:05:02,002::logUtils::48::dispatcher::(wrapper) Run and protect: connectStorageServer(domType=7, spUUID=u'00000001-0001-0001-0001-000000000229', conList=[{u'id': u'19fb9b3b-79c1-48e8-9300-d0d52ddce7b1', u'connection': u'ovirt36-h1:/hosted-engine', u'iqn': u'', u'user': u'', u'tpgt': u'1', u'password': '********', u'port': u''}], options=None) > There must be vfs_type parameter here, with the value "glusterfs". Kind of redundant since we have a domType=7, which is glusterfs, but this is the current API, and we must keep it for backward compatibility. The owner of the code sending this value should take a look. Nir >> jsonrpc.Executor/6::DEBUG::2016-03-09 15:10:01,022::fileUtils::143::Storage.fileUtils::(createdir) Creating directory: /rhev/data-center/mnt/glusterSD/ovirt36-h1:_hosted-engine mode: None >> jsonrpc.Executor/6::DEBUG::2016-03-09 15:10:01,022::storageServer::357::Storage.StorageServer.MountConnection::(_get_backup_servers_option) Using bricks: ['ovirt36-h1', 'ovirt36-h2', 'ovirt36-h3'] >> jsonrpc.Executor/6::DEBUG::2016-03-09 15:10:01,022::mount::229::Storage.Misc.excCmd::(_runcmd) /usr/bin/taskset --cpu-list 0-11 /usr/bin/sudo -n /usr/bin/systemd-run --scope --slice=vdsm-glusterfs /usr/bin/mount -o backup-volfile-servers=ovirt36-h2:ovirt36-h3 ovirt36-h1:/hosted-engine /rhev/data-center/mnt/glusterSD/ovirt36-h1:_hosted-engine (cwd None) > > -t glusterfs is missing here > > This line can be generated only by the GlusterfFSConnection, used when > connecting > to gluster storage domain, but this connection type ads the "glustefs" type. > >> jsonrpc.Executor/6::ERROR::2016-03-09 15:10:01,042::hsm::2473::Storage.HSM::(connectStorageServer) Could not connect to storageServer >> Traceback (most recent call last): >> File "/usr/share/vdsm/storage/hsm.py", line 2470, in connectStorageServer >> conObj.connect() >> File "/usr/share/vdsm/storage/storageServer.py", line 236, in connect >> six.reraise(t, v, tb) >> File "/usr/share/vdsm/storage/storageServer.py", line 228, in connect >> self._mount.mount(self.options, self._vfsType, cgroup=self.CGROUP) >> File "/usr/share/vdsm/storage/mount.py", line 225, in mount >> return self._runcmd(cmd, timeout) >> File "/usr/share/vdsm/storage/mount.py", line 241, in _runcmd >> raise MountError(rc, ";".join((out, err))) >> MountError: (32, ';Running scope as unit run-18808.scope.\nmount.nfs: an incorrect mount option was specified\n') >> >> I noticed the hosted-engine servers perform the same mount but pass the -t glusterfs correctly. >> >> A bug or am I doing something wrong?? >> >> I do not want to create a new datacentre without the hosted engine storage as I want to use the same storage domains. > > Same storage domains? Maybe you mean same bricks? > > You cannot use the same storage domain from different DC. You can > create new gluster volume > using the same bricks. > > Nir > > ________________________________ > > The contents of this electronic message and any attachments are intended only for the addressee and may contain legally privileged, personal, sensitive or confidential information. If you are not the intended addressee, and have received this email, any transmission, distribution, downloading, printing or photocopying of the contents of this message or attachments is strictly prohibited. Any legal privilege or confidentiality attached to this message and attachments is not waived, lost or destroyed by reason of delivery to any person other than intended addressee. If you have received this message and are not the intended addressee you should notify the sender by return email and destroy all copies of the message and any attachments. Unless expressly attributed, the views expressed in this email do not necessarily represent the views of the company.

1 0

ovirt 3.6.3.4 and VLAN are not friends
by Fabrice Bacchella 09 Mar '16

09 Mar '16

I'm trying to bring some VLAN to ovirts hosts. I have one native vlan and two tagged vlan. When the tagged vlan are not configured in ovirt, I can add hosts easily. As soon as I add the two tagged one, every things run amok. New hosts network are broken, network configuration is untouched and the host is marked as non operationnal. In engine.log, I get: 2016-03-09 10:25:34,376 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.HostSetupNetworksVDSCommand] (default task-20) [da910e3] FINISH, HostSetupNetworksVDSCommand, log id: 7c267202 2016-03-09 10:25:34,383 INFO [org.ovirt.vdsm.jsonrpc.client.reactors.ReactorClient] (SSL Stomp Reactor) [] Connecting to nb0104.prod.exalead.com/10.83.17.27 2016-03-09 10:25:34,404 INFO [org.ovirt.vdsm.jsonrpc.client.reactors.ReactorClient] (SSL Stomp Reactor) [] Connecting to nb0104.prod.exalead.com/10.83.17.27 2016-03-09 10:25:36,401 ERROR [org.ovirt.engine.core.vdsbroker.vdsbroker.PollVDSCommand] (default task-20) [da910e3] Error: org.ovirt.engine.core.vdsbroker.xmlrpc.XmlRpcRunTimeException: Connection issues during send request 2016-03-09 10:25:36,401 ERROR [org.ovirt.engine.core.vdsbroker.vdsbroker.PollVDSCommand] (default task-20) [da910e3] Exception: java.util.concurrent.ExecutionException: org.ovirt.engine.core.vdsbroker.xmlrpc.XmlRpcRunTimeException: Connection issues during send request at java.util.concurrent.FutureTask.report(FutureTask.java:122) [rt.jar:1.7.0_95] at java.util.concurrent.FutureTask.get(FutureTask.java:202) [rt.jar:1.7.0_95] at org.ovirt.engine.core.vdsbroker.vdsbroker.FutureVDSCommand.get(FutureVDSCommand.java:72) [vdsbroker.jar:] and a lot of them like that. I even get a : 2016-03-09 10:26:56,830 INFO [org.ovirt.vdsm.jsonrpc.client.reactors.ReactorClient] (SSL Stomp Reactor) [] Connecting to nb0104.prod.exalead.com/10.83.17.27 2016-03-09 10:26:56,830 ERROR [org.ovirt.vdsm.jsonrpc.client.reactors.Reactor] (SSL Stomp Reactor) [] Unable to process messages 2016-03-09 10:26:56,848 ERROR [org.ovirt.engine.core.vdsbroker.vdsbroker.PollVDSCommand] (default task-20) [da910e3] Error: java.lang.NullPointerException 2016-03-09 10:26:56,848 ERROR [org.ovirt.engine.core.vdsbroker.vdsbroker.PollVDSCommand] (default task-20) [da910e3] Exception: java.util.concurrent.ExecutionException: java.lang.NullPointerException at java.util.concurrent.FutureTask.report(FutureTask.java:122) [rt.jar:1.7.0_95] at java.util.concurrent.FutureTask.get(FutureTask.java:202) [rt.jar:1.7.0_95] at org.ovirt.engine.core.vdsbroker.vdsbroker.FutureVDSCommand.get(FutureVDSCommand.java:72) [vdsbroker.jar:] at org.ovirt.engine.core.bll.network.host.HostSetupNetworkPoller.poll(HostSetupNetworkPoller.java:30) [bll.jar:] at org.ovirt.engine.core.bll.network.host.HostSetupNetworksCommand.invokeSetupNetworksCommand(HostSetupNetworksCommand.java:423) [bll.jar:] at org.ovirt.engine.core.bll.network.host.HostSetupNetworksCommand.executeCommand(HostSetupNetworksCommand.java:256) [bll.jar:] .... Caused by: java.lang.NullPointerException at org.ovirt.vdsm.jsonrpc.client.reactors.ReactorClient.connect(ReactorClient.java:121) [vdsm-jsonrpc-java-client.jar:] at org.ovirt.vdsm.jsonrpc.client.JsonRpcClient.getClient(JsonRpcClient.java:114) [vdsm-jsonrpc-java-client.jar:] at org.ovirt.vdsm.jsonrpc.client.JsonRpcClient.call(JsonRpcClient.java:73) [vdsm-jsonrpc-java-client.jar:] at org.ovirt.engine.core.vdsbroker.jsonrpc.FutureMap.<init>(FutureMap.java:87) [vdsbroker.jar:] at org.ovirt.engine.core.vdsbroker.jsonrpc.JsonRpcVdsServer$3.call(JsonRpcVdsServer.java:1016) [vdsbroker.jar:] at org.ovirt.engine.core.vdsbroker.jsonrpc.JsonRpcVdsServer$3.call(JsonRpcVdsServer.java:1012) [vdsbroker.jar:] ... 2016-03-09 10:26:56,860 ERROR [org.ovirt.engine.core.vdsbroker.vdsbroker.PollVDSCommand] (default task-20) [da910e3] Command 'PollVDSCommand(HostName = nb0104, VdsIdVDSCommandParametersBase:{runAsync='true', hostId='8aed4c69-3a1d-4f00-95c4-79bcd3596ef9'})' execution failed: java.util.concurrent.ExecutionException: java.lang.NullPointerException And latter: 2016-03-09 10:37:28,635 WARN [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (DefaultQuartzScheduler_Worker-22) [47d52cbc] Correlation ID: 47d52cbc, Job ID: e1f27868-08c8-488a-b70c-7c9d8f06c08b, Call Stack: null, Custom Event ID: -1, Message: Host nb0104 does not comply with the cluster Default networks, the following networks are missing on host: 'DMZ,Extranet,ovirtmgmt' I try to finish the network configuration manuall, , but some time it works, sometime it fails. When it fails I get a timeout, and operations are not possible any more on the host. I'm getting a: Cannot setup Networks. Another Setup Networks process in progress on the host. Please try later after refreshing the host network capabilities. In engine.log, I get: 2016-03-09 10:38:13,470 WARN [org.ovirt.engine.core.bll.network.host.HostSetupNetworksCommand] (default task-15) [64ef0a3a] CanDoAction of action 'HostSetupNetworks' failed for user FA4@apachesso. Reasons: VAR__ACTION__SETUP,VAR__TYPE__NETWORKS,ACTION_TYPE_FAILED_SETUP_NETWORKS_IN_PROGRESS The lock stay forever until i restart the ovirt-engine. In the host, in mom.log, I got 2016-03-09 10:26:57,960 - mom.vdsmInterface - ERROR - Cannot connect to VDSM! [Errno 111] Connection refused 2016-03-09 10:26:57,960 - mom.GuestManager - INFO - Guest Manager starting: multi-thread 2016-03-09 10:26:57,963 - mom.vdsmInterface - ERROR - Cannot connect to VDSM! [Errno 111] Connection refused I'm running ovirt 3.6.3.4 on Centos 7.2, I reinstalled everything, even the OS, with a empty database.

2 2

Adding servers after hosted ending servers fail due to incorrect mount options in vdsm
by Bond, Darryl 09 Mar '16

09 Mar '16

I have a 3 node 3.6.3 hosted engine cluster (Default) with a number of VMs. The hosted engine is stored on gluster. Adding an additional server to the Default cluster that isn't a hosted-engine ha server fails. Looking at the vdsm.log, the host attempts to mount the gluster as NFS with the gluster options which fails. jsonrpc.Executor/6::DEBUG::2016-03-09 15:10:01,022::fileUtils::143::Storage.fileUtils::(createdir) Creating directory: /rhev/data-center/mnt/glusterSD/ovirt36-h1:_hosted-engine mode: None jsonrpc.Executor/6::DEBUG::2016-03-09 15:10:01,022::storageServer::357::Storage.StorageServer.MountConnection::(_get_backup_servers_option) Using bricks: ['ovirt36-h1', 'ovirt36-h2', 'ovirt36-h3'] jsonrpc.Executor/6::DEBUG::2016-03-09 15:10:01,022::mount::229::Storage.Misc.excCmd::(_runcmd) /usr/bin/taskset --cpu-list 0-11 /usr/bin/sudo -n /usr/bin/systemd-run --scope --slice=vdsm-glusterfs /usr/bin/mount -o backup-volfile-servers=ovirt36-h2:ovirt36-h3 ovirt36-h1:/hosted-engine /rhev/data-center/mnt/glusterSD/ovirt36-h1:_hosted-engine (cwd None) jsonrpc.Executor/6::ERROR::2016-03-09 15:10:01,042::hsm::2473::Storage.HSM::(connectStorageServer) Could not connect to storageServer Traceback (most recent call last): File "/usr/share/vdsm/storage/hsm.py", line 2470, in connectStorageServer conObj.connect() File "/usr/share/vdsm/storage/storageServer.py", line 236, in connect six.reraise(t, v, tb) File "/usr/share/vdsm/storage/storageServer.py", line 228, in connect self._mount.mount(self.options, self._vfsType, cgroup=self.CGROUP) File "/usr/share/vdsm/storage/mount.py", line 225, in mount return self._runcmd(cmd, timeout) File "/usr/share/vdsm/storage/mount.py", line 241, in _runcmd raise MountError(rc, ";".join((out, err))) MountError: (32, ';Running scope as unit run-18808.scope.\nmount.nfs: an incorrect mount option was specified\n') I noticed the hosted-engine servers perform the same mount but pass the -t glusterfs correctly. A bug or am I doing something wrong?? I do not want to create a new datacentre without the hosted engine storage as I want to use the same storage domains. Regards Darryl ________________________________ The contents of this electronic message and any attachments are intended only for the addressee and may contain legally privileged, personal, sensitive or confidential information. If you are not the intended addressee, and have received this email, any transmission, distribution, downloading, printing or photocopying of the contents of this message or attachments is strictly prohibited. Any legal privilege or confidentiality attached to this message and attachments is not waived, lost or destroyed by reason of delivery to any person other than intended addressee. If you have received this message and are not the intended addressee you should notify the sender by return email and destroy all copies of the message and any attachments. Unless expressly attributed, the views expressed in this email do not necessarily represent the views of the company.

3 2

regenerate libvirt-spice keys after libvirtd restart?
by Bill James 08 Mar '16

08 Mar '16

I needed to bounce libvirtd after changing a config in libvirt/qemu.conf so import-to-ovirt.pl, but now my VMs with Spice console complain: libvirtError: internal error: process exited while connecting to monitor: ((null):2791): Spice-Warning **: reds.c:3311:reds_init_ssl: Could not use private key file What is the proper way to sync up the key after restarting libvirtd? I even tried rebooting host and restart ovirt-engine and ovirt-engine setup, didn't help. Work around is just use VNC consoles. But I'd like to get spice working again. centos 7.2 libvirt-client-1.2.17-13.el7_2.2.x86_64 ovirt-engine-3.6.2.6-1.el7.centos.noarch Cloud Services for Business www.j2.com j2 | eFax | eVoice | FuseMail | Campaigner | KeepItSafe | Onebox This email, its contents and attachments contain information from j2 Global, Inc. and/or its affiliates which may be privileged, confidential or otherwise protected from disclosure. The information is intended to be for the addressee(s) only. If you are not an addressee, any disclosure, copy, distribution, or use of the contents of this message is prohibited. If you have received this email in error please notify the sender by reply e-mail and delete the original message and any copies. (c) 2015 j2 Global, Inc. All rights reserved. eFax, eVoice, Campaigner, FuseMail, KeepItSafe, and Onebox are registered trademarks of j2 Global, Inc. and its affiliates.

2 5

Collectd
by Jonas Israelsson 08 Mar '16

08 Mar '16

Greetings. Is the collectd feature on the iso-based nodes supposed to work ? And if so am I supposed to do anything more that adding the server and port via the tui ? I see my collectd configuration end up in the file /etc/default/ovirt Part from that I don't see a single (collectd) byte leaving my nodes. # cat /etc/default/version PRODUCT='oVirt Node Hypervisor' PRODUCT_SHORT='oVirt Node Hypervisor' PRODUCT_CODE= RECIPE_SHA256= RECIPE_RPM= PACKAGE=ovirt-node-iso VERSION=3.6 RELEASE=0.999.201510221205.el7.centos

1 0

Slow after add 2 Nic
by Taste-Of-IT 08 Mar '16

08 Mar '16

Hello, i have a question about adding a second Nic. After adding a second one the WebGUI and oVirt is very slow. The situation is as follow. Each nic has its own network and are seperated from each other. nic1 - 192.168.0.x for internal and nic2 192.168.1.x through the wan. if i use trace from the client i call the WebGUI, it goes over 192.168.0.x, the right way. but if i trace the engine self on localhost with its hostname it goes over 192.168.1.x, the wrong way and takes longer. i am not sure if its an ovirt problem or from hostsystem centos, but i didnt find any solution. # ip route show default via 192.168.0.3 dev ovirtmgmt default via 192.168.1.1 dev enp0s29u1u2c2 proto static metric 100 169.254.0.0/16 dev ovirtmgmt scope link metric 1006 192.168.0.0/24 dev ovirtmgmt proto kernel scope link src 192.168.0.153 192.168.1.0/24 dev enp0s29u1u2c2 proto kernel scope link src 192.168.1.2 metric 100 thx for help Taste

3 3

VM migration by using the Python SDK
by Jean-Pierre Ribeauville 08 Mar '16

08 Mar '16

--_004_1051EFB4D3A1704680C38CCAAC5836D292F1577AWPTXMAIL2ptxaxw_ Content-Type: multipart/alternative; boundary="_000_1051EFB4D3A1704680C38CCAAC5836D292F1577AWPTXMAIL2ptxaxw_" --_000_1051EFB4D3A1704680C38CCAAC5836D292F1577AWPTXMAIL2ptxaxw_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I'm a little bit lost by looking how to migrate a Guest between two nodes o= f a same cluster by using ovirt python API . Is it the good way to start for ovirt engine sources ? Thx for help. Regards, Jean-Pierre RIBEAUVILLE +33 1 4717 2049 [axway_logo_tagline_87px] --_000_1051EFB4D3A1704680C38CCAAC5836D292F1577AWPTXMAIL2ptxaxw_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > <meta name=3D"Generator" content=3D"Microsoft Word 15 (filtered medium)"> <style></style> </head> <body lang=3D"FR" link=3D"#0563C1" vlink=3D"#954F72"> <div class=3D"WordSection1"> Hi,<o:p></o:p> <o:p> </o:p> <o:p> </o:p> I’m a little bit lost by = looking how to migrate a Guest between two nodes of a same cluster by using=   ovirt  python  API .<o:p></o:p> <o:p> </o:p> Is it the good way  to sta= rt for ovirt engine sources ?<o:p></o:p> <o:p> </o:p> Thx for help.<o:p></o:p> <o:p> </o:p> Regards,<o:p></o:p> <o:p> </o:p> Jean-Pierre = RIBEAUVILLE<o:p></o:p> <o:p> <= /o:p> +33 1 4717 2049<o:p></o:p> <o:p> <= /o:p> <img width= =3D"140" height=3D"87" id=3D"Image_x0020_1" src=3D"cid:image001.png@01D1789= 5.39E36880" alt=3D"axway_logo_tagline_87px"><o:p></o:p> <o:p> </o:p> </div> </body> </html> --_000_1051EFB4D3A1704680C38CCAAC5836D292F1577AWPTXMAIL2ptxaxw_-- --_004_1051EFB4D3A1704680C38CCAAC5836D292F1577AWPTXMAIL2ptxaxw_ Content-Type: image/png; name="image001.png" Content-Description: image001.png Content-Disposition: inline; filename="image001.png"; size=11720; creation-date="Mon, 07 Mar 2016 16:17:29 GMT"; modification-date="Mon, 07 Mar 2016 16:17:29 GMT" Content-ID: <image001.png(a)01D17895.39E36880> Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAIwAAABXCAYAAADWOa3SAAAAGXRFWHRTb2Z0d2FyZQBBZG9iZSBJ bWFnZVJlYWR5ccllPAAALWpJREFUeNrsfQmcFMXZ/lvdPefeLNcitwp4EFG88AAJn/eFRo3GHBqv RHOq0XxGE7+oMYlf1E9jzGXEmGjUxCPBKILKIXiAAiIgICjncu29OzszfdT/favenu2ZndldkF0h /60fRff29PRR9dTznlUjPikZDl0tIm4CGKLwCZ4sBgnH4954rAfi/hCQEitU4meGlADSk00eQDXW TS7ABlfAKqwL8O8PPIM+pssA4DHwqILed/AiUTwwxMFrQG/JLRbWOiHhssoWtbW68T6ftpRg/YIQ 4kywxAQwYD8Q2MNBXEkFJhAKCbLCcOVQ3B7juRIcSWCAtCNgBe7OwzOfwjq/FwJ7LzB3t+yHuPgO mOKLYBrDcAsKKAboLeQARjJ1+MBxPDBtCYbtgeXKMO6OM7DaBlxrCwWcB7E+29tF+z5gihEPPwDL uBYZpS+CBVRFUSUMBk2u1GLASB80yCxgobCxEDwhD4yUC2EEjomHDdzgJU6impbwKl7rZvz2u71d tW8C5kxhiV8iWA6GkAaKCAJG+IDJZRjJlUSTp0AjXU+DBmWRQHYSaRdEygOBYEIRjOAjpoIpaRRT eNbP8a87oFd92YcAI+BEETb/CRHDAMsEBA4CxVRVZLFLIcDgYWIZBAxptsJEGLguSPoeV2G4YCY9 CDue1nYN9bUY7v4Piqmjcf9yPLpDfwIRriH+O6N6Y7W5Jkln7u3mngYMdbYlpkAUqSREYDE0UHyG MfxKIMoBTUZ/IYAgg6ApJBRo/O8QaNyMKCOWMrGbQyiiJPNJCLdxEGeGJUzHP2dhTWFF8iF9WRtS DBAfPILfjWqMjzdhbcC6GeuHWKv5717W6g6GkYZRhgyDYOGq2IXFEYGHRFSImYeAkAGMbBNByBzS dtVWOG6GWfQ1EDj0HcdWX8Orb4t6MB97exkeXY31Y+pgvEojs0yqC4+Nl4EyrH2xVvJ2ANb/YnYq ZnBtwvoe1lVYm3th8akBI0mnECJkaVaxtChSACEQRfAyYfwM/wbLyACG+l+y3kIAkcgaYCMppLCi OUQgErgvm2zwGnCn1Z4n094MvN2b2I0ElLoMSe3e+xHz1HLNq8Bj3Z/r0VhPZDfBTqxvMhMle2Gy e0pvC4kixSwEGAJINAQiFlKAEeGQPkaf+eKJhq8CDIIFASMUu+h9r7YFvOom8GoSi2Sr/VdkoVcQ YSsRKBJEj70/sclSrn6pwvo5rIdjPQ5rFOsyrG+xWOsFTJc4xpXLBZkuFrGJCUY8DIJqNKyAA5Gw Ag2xkGIfg/VQTyu3qLQounG31oHz4XbP3Vj3D5mw/4AgmY3gsjv0IBfUw7Mt9z1Uqrn65UCsB2M9 F0iVAviIwZPoBUxHXYOAIYMXRZAQPljiEV1jWCMRMBA0EELQEKh8wJBMQmbyahogNX+ltJdtfkI2 p+/HY4uU7rKbRREXhw4IOGb3qa5ruPrscwjWU7Diy8IS/kz2AiZ3KDveegRNNYqgQQaJIQJKURS3 UTBiMQQNbhE0EA5nAKPEFMqk5Lz3IfnKkrnutsYfIQO9QQz1aYtkBSUttGZr9kyXBdlnP6zDsQ5h 0bbs/wfW6boO48l61DU+IMBo3SWMYgkBU4QGbzyuQRONKqYRIfyspAjc6h3Q/JeZtal3Vt+K5vIj IhJK7+kXEAEAiZ5tu81cCa8jsY5iE389m+s9Wvz3F3sNYFDH8OoS/0Qr6RStt0QUQAwEC4HGiBch aDR4zLJSSL6xGBp/+8JrbnXdN1Fkre7p3uzB4gZEVinWPliLsG5lAPVIiUsBDcjmbjeDxvLaRuoE rANx97n8QxnNl6b086io3gEDIhWClFxiFAJNjAFTVgZGcTE0P/mybJr20p0owu5A0WV3aXgopThz L0QjmrxC9OVOMNhJp0xkfM4EHrAlf2D0PLsUKo1crZ5iFWoocmy+gs38eFEKmhA0ZncCJsUtjY1+ TUTCoYUBgw/oeJud9XXPWqMHXSFIV4n4TBNTYCHwNNz/ZHPi+blX4/EnO9RVXE+Z16jrFKFZfoJR HDsKFekxyGQj8F79UfepkK5bArYXhjSa4glH2q5Mos7SiLXWEbANIbYWB9aKuAtvova0iEC0l8QB nO68uC96Yvjy60wPfl+ShFcRMC4f61aR5Onr98fGPhWIYaSyAF7J+6Bo1XibG34nW53LRUXIEGQR KX1FO0zr75q2NfnqootRRM3JO+QpJJCyCSQV5oDS8639B55m9C06BqLGELTbERRp8BqTAMk0yDRl ydgghaPAhUASwpUxbJSYLWBAUsBBrUKe1IoPnjakZ0lYN9QVcwa6Yh7e4TW828b/NNlHTRpFQOh4 iIR3wg78uKwVthgeFOPxcE8ova4O4VwsPBhIUWPst2vRFH6loB7TklroLN/8Qmh41XnKEkJWIWdc w6/+vDk59/2poji+qP14QzAkUyAqiifEJo+7Ojx2+GnGwBIEpwNuXQPWRtSPmjL5Mkry+9FtFoc+ AP1dQ2mbAq0jSea1sVPIA6pNWXaEbbw+1BHnpHUogLy1r3f3iO8J0RNiS3BBxIF/xNKwFZlluyGh AWuJ7DmBrBgG73mG4N4QYThXJuUZ2Bf/zotyywR7+eafRY4/6GxrRIVFXtyG+56qTs1fgWCJLcpl FK+lFayqyknxL5x7U2ziuJONfiUhr74OnJ07wautU7ElCkYWJl7fXRzYFdmOD8ENmgLo93bIXW9K 86+DXDEMmeYEPHw96DjUv2AfdPNLFjM7ECB3lSbhbWQV5F1UkoTSVSI97AEykGGG4vbYzGCOqgDi j/CZwgVZpjG5KPXGh3+gJ25+bEZtasHKqaIomgUWmUjSuaNLr/vS0/3//uCssusvP8MaNihEx2Vr SrOODwlZUBPmXdEljy41IILkqPlhl0bfegTRX/HQr7G2Yr0a6zk9pZDuSbDUoMi5GUXPHNRTLKkt orDsMd9TdhtfFS2fipLoYtK0qSVFBMk+Yg6BlNsCBXJrlS5T27LM2bjj/NTba74lwqFZGZ2FItMt rZHo5CN/1PeBH08rvvTcw4VlGF5NDbJNM4IlgeKpFTysgMDxkggg0lmwQhLHTkpHs5Xe4ukIt6pp ZCu8tiMgUCXYvG/jA6h9/IdwfGIrtuZgHA1ox1HIczU+2WJ2sp3M5m713g4YAst2ZJabylvh/ZCj 9JTP2hq0sA/GBsezyngrQujErVtlsz0dWWJ5XhM7ZW9IL1o3UYStzZnjNrGGN6L02xc9Vvqtr51I 1pNbvUUBRKYQKCkERxrBYdsqai0dW1tKnqsVYs7Ga2OWgC7jb0Tbs1KUUiJoPAgeg1GGlJEGlFDz Qy5MSVtK3/F0/swM0NHoM0DHh56DvSSdgZRZK8dBRsrsDxAsyywNlr3C04vPcaDns77ksUcZcRWR YhzVD0vbOxn7JZUPNAiWDRn6ROvHKI+fVX7jpY/GT53Y12vELquv1Vl16RSCJqHZJdXaBpw0AcfW OTKcJ5NJ4fSTrvw8YJkDDAUcGQCKvy/745X6IEiqN6JythBBc5xtBj1oFHF+ir2zF4KOBy3+LFmE yjxUZpehKLVkm3glEbTCcvcasPiOuxFtOJFgqCRtT0WkRf/YibK65W788PoOuRBZwhrR/4aSa6f+ MnLoKMPdimxvmG2mtJ1WIPEQMF6CgENiKACatA+aIFgCSeO0z1mbfs1lG/8YnlostYVUTaN0BVJ6 P9TsR7kG5MQl1rHpfQLrNi9pFajnCukiZBr/pSiNwHagBdkyGI4NY6PH5N7lIicrqcq3ZFWjO1KJ JZowJGJI5/3j3/e2tqxESvlDQeXM80ojx466zBpSaThbt4Hyz5im/5liEU+xTFKxTBtoUoqZJCVR pR0WT15bpedw9TN52nzORKjbqswFEuXulQUVx/nYGRVeCCrZhxEoNpvdpPifhPUd6KE4EJnCf0fz +Odo+eCwUeAplXt//IQAY6jGFsz8HgNGeWI9EKURSrv9rbe9pQb1mWfzm9pWY+sLC08GUzwVPXHs RJkUnPbPgHEcpbfIFAKkFRVerL61pGqqTdn1k8SBnwE4tTPzjMwsPlDQKAeXxVHbsWwLT2nvKJrO Slsg8ltaJFopy24U79d2p/ONwPIMg4XcBEX7UKCNwCJdnpqqpqcS/duBDkPl1KiMGUb/oqewpb9Q yNRGhtiaeHL+6S1PzZnmNtSjRdQEbkMDeFQbG3VtagKvuYWsKAQMAidBrINgaVVzHzOJ4krvUUCR SkwRgPznI/d39lZmptO6bSzjBJRgpUBuxDf9APWBUOG2oNSED/akr8Z3MBoZRyOCA8HyVLwNLPuM jZ/x9OLIwpFbmQENcTopn6RTWEJPA8HRKSImvVtxYQOd5oQgb7y2/HJnw46lsdPH3WNUllgkbsAl htEsA6k0mtI2s0tahQNUuIDYhYHiJ4zrpHGpnsnxAREAiwO8DzpKq4hJ80cin4/mXdTYhqEuQ9Tv Fo4B7bZXWHlkJTnUdJYpybtUYF4fOdn+hmC5p6QVzByraB8CjNzgCjHa7xSaJWLhH0YaX5pUYgIC drq3PUGe38e47b+BvfMcMsuWdpZTJATO2h33t0yb+054wv7TrNEDDlRKa4pNaSV+bGYWvVXmuMr7 9ZQCrZRfAgv5XnDrBADi+ADxgZMFGsU2ZNE1tiNBJZokvINvfIptdctkJQLAZmwzHApQa0qYxtHj oCK7HpVwS4pujSh3dyxpI/E3AcXkLf1N84IEpbNhA3jNtouddzuZtiJqXWMOKfs16jQ3efXJ63D4 TM+duIbmNgLBWZCctXK8tXrrT0OHDfquKIoIBZK01lcUUNKcFO7qxHCdIM6gSWvgUMf6jrqMGMqA R+ptAExSg6Um38uSOKLo7hYcEFWe2OMBJrJoXoqm4BG0eqL4IEmVapDdNuQg3VfB4ocGVquG9xud vKZKNCErUKcl8dMW5x/40UJE0/FoNd0LERPMoeVDzWHl/4KQ+Xc8eVg7TZJmMobMJmdD3feTM1ed YC/Z9J7XgNZRC4qg5pTy6mrnHYPFbtuSV1emECyu9uTaBgSAwccgGzT0vCyOyINbX0inoHPfs9xu UzMJIDY3Roxd+MG6r+eRGdiAi23uCB80foe4ZM4myNSV91N7G2Xh36FeE1FMQcpwWQRCB1Z+wRxY /AEC5Fd4XmW7TqK5So63wFm1Y4K9cNNV7qaGaiDxxKwiHUeDxWZWodyXJLIasovNz+I/k5MJA4Dq FDsIIsikty2EDjLdfAV4kyG7LR1gL0ro6gaGAViAjf5JpjO4pg3dMWhCvUcTy0TIuAdCxiHKZ8IK rEe6CDn7BhQVWwf0uR6tqQ+xpe5E4PTN1W3AQq2o1f6j+0ndIc5HNd92dyY2aU9vACwkqlo9xWwK FEbb82ig+Owis0VSm7JLZXZnlotULOMoZadIscB/bv7oHmfQC4rKUACICdinhxpSz21WqyfwUi9I o7fifiOKo2lCDdC2PBXBqzKQXU5TZEVpJG6URCZir1yJnT4M5cRHeFZNZrjpOddJ1E3ekc3pP6Ko W4aAGSI8OQjFEOo4rlJyCSwE2LTPJoYGCf1NVgd5bNP8N21TDBypP7qtkA7j6xB07ZeKHHgBLRZS Qqs8AwbSXG/x6ZJwyTO7KOxiddT+fyRgzouXUUNHsSPP9zNQ1LIddFBCEk3Bm3F03+N5cqzh8ioM AFkxHvACTjaaw1YUioni8FHIStegiXwyAofIYAN+MRkAThqPf4Cs8ijqK89JR1bj3wOx4yuwQ40M MAy9tRksKQWQtv2k1IBxVYfBDATEA/4s/NwaB8orAXgdgbIVlXlKPloccuCVmAObEDhjHAsqSRkW vYDpyNNL5VkcqbcZQozK5KcYyuZejBAY1mrAuWRBEZNYSe1QE2FDD1eyaihTz58eS1gTevkPUWyF zZg50Uu5E6HF3oEM8iaC4ml2x1frabGC+nopgo6mq96FlswBpgvjQwI+nzLgWBzyVeQ6SavIug4P aL8uSLy9Q36PcomaEh7v54rnimT+nJkoTdYOufBKPKUyyMOyrZMJcOR5pc6+vikK42xTvVrvsg75 HXfK0YXd/jfsvx8rdsGmMpVWL17Gxr0qIcAICz+8I9HkRr3F0X4atWqDssk9Xo1BawpBtUDtxq1+ CLJzUPScgyZ6i7Q9WinhfaxzhF5hyrduViEJrLIkPBHHhytXRAcD8G798G4D8Lr98U79kImGodl6 TLUhR20yvFAdyE3VlveCzKOz0LusiLiwMKpXVAzJ9k49ctdvwXf4XnkL/KauCI5JW9AqeiGTz3Hn 7z+Mzft17OrBnqAoqWrspgYTprjMOiTmXX/FMQSOv0adwevCiMziQHlcoBxx1ltZhExxBF6X6mXY V/RJPUqInYaO49QLHQJKcpJDiJK/ESCldQb0rTVk3xrhVdQIGU0w32Cn/0boZUCyXxA/fBtFznJO HehIUBDr0Lv3rkDUOcNQ2Yr2yW9wJP+MFI5BntiJesKJjYbsR7RPjOHqFcYgxM4906+80GHGnBQi a0aiUowhkG4TcMC5WrEl874PXrtPxiknWKklHUVQgEcCMp0a9WlP6y0MFCqUs/uHfABYFfa6BJYg I/XaTF0DDJV7ETRTXRBHhz3h7rRgHHVSjFzuFH8x9Ih1fc8wz2sm60pVv8FlNpVn5a2IQDwIAnGh gPfWZkU3FbCE0uxvoeCox7GaQMfeDjranOXVrcaHfSdqK1D3gmDPhQaChUKFN6KeMgs5BSkfKlKg beww6CCgS0uKBSbAm74JLgKAySORchkmi2WgzXFos3WkzGgImNO0DVhEgUJK9J9zdRKK4cyL2To+ 1quK7DnAyPadOw97/DZs6F/UGXosSxXsExS8RoVRrzKtlkhl8AiZM2U1Z0TnZsZlVvhWoJGZeFHQ g+s76TI+FynVNgcsJIpuyAULfX9O3IFmpD2rFyx7FjCTUkY+9/nDqHFe1yBgaFjFaIRigJDqWB1p VYtoSj2PV4NF8OJRvLhhO4aR6lOCoBQ54gja3PsOZHt0CSS21KDJcaqRT4dW1dwUdMnTNYlZKNs+ 1AuWPQ+Yck/ki4VEkDnWoLK6qlXAyapj1RLvlMOhQaJYhsGjxJGUnDAkOxBJMptd/MAhBAKJQaaR bWyT0/f0lSuISLJMdywLECzrQ17Gz5I9DtSCiLSuiz/Jnwqto0e5vWuV2sQDg6+HVr1aPNFhgLYU 0JPLmNxCSJh0vRJ+ZfIxdjYroYyfTbJboSNncymrZ4K92TLjZtLvRQseUTyviIl2J7PwhpzrVvDz 0vcbofNc5mJuB1oZNzevRH07XCRhR5UrzmkGOZ0slFahw/Wt5F2lvwHUfsKvQp+T6LAGzudrJPk6 ZP1QZqd/ffLgJplh8oDlKqxP5Lr8l0VcWJMfLFdwoxEw3sb6ItYnub6MlabSkC/oNGrV1yKOv7LV QbhZwT6ixws05jisK0Gb9L/ANqLGn86d9ZsugGUePxc9w4gOziWgvMTX/VUALD/Fug30Ump0redB T+Aj3Y7mmNNSJDTrc3TgWudj3cL1i10glsf4vk8XWjNMYIM1jHaNJHbEea1S/hWr7mRl2mrzVnV0 pkIWGLKB4e9D5m8fJD7QknyMgNIqvXzKLfAIvwTrozmMCDWoVH2I5nMBMUTzkGIMkG9ipV9coUUP j8L6PdCLANFSZNOjUpz0dDwNM9G6iknxJn+HOus8rBfl6UQCxUB8hQ0Ilh8uD7mepQFD5b+YzQoV WjdvLD8bLbVyRAfn0iqfx/H+HwOsORXrdu1HU21zNIOYZkPcyyxH7z+LGRZ4kLToaAqc1QlYDud7 UHmxUJYgLWPY2gflx2DXcFab3pc98D5ypLjNBGlYAVFkaq1FiSKl9MpsESGDYikn49/Px3WkzFhK LhR0ydO0kEtBL0jYTnMnMdSMNy8w1/gmZol8S4otYtFGzEMObRx9cvazsTRMTqmk8R/hJSeDnvh2 Gze2n9H3Y6zHkl6O7XFZnSGrN+mMun+yqV/FHTKtA8AAX4/EzWlYnylw7td4O4+rD5gLmF3yibL5 /BmBejADjibvbeZrnM0AK+5AdF7AY5JE9h8KMQxJCnL2wzjHUEE77MjbUTycgUzwsWIbxQS8DbKI aGOO3P0g4xCL+N9PshhyCoPlb8wGb+2mw20tdLz+3HrWZaj0oVmIS5GtKPaEAGxgYFA5lMEHPIJv 5v0b0CCbXYP/NRpq4FDIYyF/dkqBew7jz0gsPMDHCJjxPOcODrDbr3P6aXUnes+Hgf3ywL4vYkkM Hlngu/3ZsABm2sZCgCG6oqhgvAIb72AEDXfmDHyycaiEPoQiI63FSFvH+9vc2tquehldxc4vevyy ikcBUW3BqR8mfOofFPh6gK7J7aNE4mrLBT0xBf4R8PV8l8FyP4sk0hV+TedRLKq1LYfXF5snsSKa Wy7kkf08AybBnTc6z7nnsb5D+tQLu/Be9HzX5uh/fnklYGFeWuD75zFLkn72O1/85ys2D/Zy2hmL gBnQNgmM6PNbJG8RPM+7et6iUk6TnJuSLFBTDBAHOs07Wccd8zlo0wcKxn82oExaE3Z2xYyOMVsQ zS/A+r+BzxJ+wyxElkmJjNV3CyunxfxM45m5vu0z3GrLC/bILB54VdzwueUc3s7gDvEXlz4qz7Ne B20g7GzJ/DJmjBtZHF2QQwR+aWClmMpEtrRyx+FlvP+MD66OFsqlhhvqz+s51rbUNtDRy7khSMH6 LVshWV7dYO1CaeQXuJj1hQcAIN0ZWLYgWGajkprsPAZUwZ30OHf8MtYtaOHmu1hxpKJW+47gAHkX Qaiz/NXxzcwqfqcAD5zt/tBdm50rvC5g9p+e8ywEClqm/hNoyxB8h7dT8yjso1kHe7TAuw1l0fEK izgSh/ewmL0ncF7uSuZ/4u0oVm6D5VTWz5I+u3QGmOV8IcUI+6ECPN4x82Xar2TLYwzLYJKxb/IL FhoNaR5Vi9k8vpQ7bgroifKd/vCEDxZKhkpDh5n4YdY11jCdf5lNRAL559l/8RCP5EyjppFZxtgm DHIN4PCJYPESLCcFdajJqVAuaH1ldxLWQYHjFwV0M1+BfpO3R+ZYVt8MjPLcTMJ+3JkfcedP4n77 GVtc4yB7yZZcPe5tFvv5xNJXeEsi8/2gM6tQoVmA1/iym0TTEQiYnajUrTG8fAnUrTxaZnP7FbPS 5C9D6qsaCXZQ7WBa3OWsyFDXwUIf/Z31II/f5RcM8iDxFbG8B99aIE/zSQgAWjmhWZt+P+HrkC71 KusgP8BKFtECAthEtKpGYxutQdHE1trrPOIHMRs/xIqnD5iguH2dgdyPxeVsFsmTuW0fyHm3ISzO DuL2vJfN7eo8TrdCgCH2+AvoHy+bzG1gM9D8Z3wk14VRqKzhhxkcNI8no2iqwkbsZIVmySN1LdPj bG7k2Uy9q5kudxkstLpEPQJ2XtzOrALeQbmCO9lXbL/GimOulIwEBk8zoXoAMstxaUvpXWzN3Mqf 38WNuZTb7z76Pn2nDFn4Ky2RYEL6TgZsUCxNZhHyZs7oJ9G2hPdP5O11fI/p3JbBcjf3z3a+5h2Q f5GkaEAvbc3z+Yu8PZgB6rOLwXrYrK4CppmRe1pQxSZRcDI2JFlPPbo2BvWy66pwxMoY8bjXlSi0 30nvsbeyUAkCppUsHfLBjEBlH5mmipnBZHq+l8/7QcCh9l01XPF7x2PbjEGWSYl2HTKRGff0gIjJ LXMDekvfgGJ8bx7WmBQwd5d04tb3NYt8on4pt49vuUVZbEM+namzX4f4JzdGZiDTXcsQLKdiwxTL Pbc8peSf98stXjoNbiIBTnMzmJEIjLrpBhg5dSqkGxvBcTq9e1cZrDhAja2U/zslGfLfjZxeB4Be 2fvGwHdmMp0DO+nG+yzzVWQZr41l5jGrlbA/5yxuxpfzPIcvokayVTaQmfmtDp69s1Sf0kDXpQu0 kT+YjuFQQX/WL5/eVcD8m83CM3Jt7n4ImjPtkJrY/mmZxqNJ+hT5DofBS6UUQFRNJqFkzGjY74Lz od+UybD/d66D0qOPgkmTToGJk0+Dyr79IZVKgo2gsmmeVHvAzeQtKYBX52noATmNSmZ0+mBUdikR HPdvCVgtN+YRC7ewLkYKM/1sskksMwEH0/6uqR06Wgz8g8+/itvzBdajcstqtpz6swUGfN187P8G 75OPakIe/0v/HGed24HVOYO7ldjyzoBjr92IFJ+UDO+sP59ixfW8XPcxPVUtNtDLaH7WiF2fSUgi xkuloWjkcBhyycUQHVQFTStWQGLDRjAQPPTrKFXnng1WPM4rO7iKcQzThHA4As3NjTD39Zfh3Xfm gzAMqNm5HeVJC4RC4aCF9K+At3Udm9MeK3Y7uZG+4iv3CSFPub45NvMrLeFzW4R8joH1WMAnkVtu Zf0BePtjmhw3PWrD7WUJNUlOaJ1kbuA7l+YGTwPl+UDIgAB6mO8/oQGh5o3puewH8IAYzh27nC2e EmaKJ9hHRM/+VVbWD+zAATqHxSYwaA+HPFOOze9FyrtC62NYxi/J/YAWw9nfM1UGd62QXZsmSrEj ZA8zFkNAnAUjr70GioYPA6soDsUHHADl44+AsnGHQenBB6moFoGEptQqkUULMuL3SRxZCIzRY8bC 0RMmwfEnToHDDj8aNnyyFnbs2AqWFfJH1TOsGIaZSYYx1bewSHmTfTTk2X6vQhovfr8pWoNWzoUo XTbx53eyRYcnoR6FIKetpFW2hFjKOtAq7ri55OPsg//NiDoqAm9oczjE55Cv6fcdjPYW/mwpuyiU Ses4NsTjxQo0Lr67YRi1DAqH362SPcUVrPw+zIDrzx0/nxVYu4N+9h2M9zHrwO4wTD9uMMk2/+J8 tqtyJFguLOEsYasAUKjzaTmz8sPHweBLLkJ2GanEELHH7hbBP+YVRlZqqK+D3z54N6xZtQLCyFCW ZeWKYBPaUnKyCrU8BVyn1RYpPS33BINEX0UZ1B99OIRr66F08Qc6wd0027UH/bLIZZUtahBZeaO7 rhKjNOPCMEwCQJA92sQ/nuPYaajabwhcc90PoaGhDh79/X2KXQNM6t/WBOiKIz1v+Q7W/2MR+znW 2WB3GCbBnsn3WZd5I3d0+OrdCM9Q1hMF4ZqNzHy4DFCIIYpHj4KRV1+p9JJQWZlapxfkp0yN4ym7 NPJisTgcfsQEJZpampugqalBfWboTkVcujhIPenrO9Rx9D2PttJD+1jCFxoFxNXKV/zzyAZNxUSw 9CmDdf/9bdh2/mlQO+lYcCrKoWzhEjBsB4TUP4RqEPOlkVlcB54MtUATLS3rOop31X3wvg6CoKi4 BE6YeDKcPfVi2ImM2ECrduF5dlrPVyfgpNMpGDJ0JFx4ydfh9LMvhP4DB8HAqsEwYuQoeH/xO9DY 2LYcHwIOvybp5aRmYFuBjQSiYXT6y3fl7GQsZ9b9W8HB2QWGARZJV7AcPjEQsc0b7SLbbY3pwYfI NjuFhw3hQQkySdXZZ0DFUUeCEQopVqmtq4fqrdVZ686JDhw7/uf5JqsFj4Xw+uFwFGpqtsOTj/8W Vq/evEv4e4Y1UwltqWYkJxZ+6XKo+fwEsOoaFZAIMMMefARGL1mQ+WV1h7ek7N02sBQS0TBs37RT ZdcHy5XXXAnjx08Ax5OwfctG2LptixKnM2a8lnXebT/5CbLLUEjgACDlnkoJgu29RQvg0Uce6zDs 8qVLzodVK5ci69YoFuug0PL6v2IF/YicCPduAQbYF/FnVhYFu9bzO9dYJFEbbXNS8NFVl0DszFPB wlHu0cqZOALq6hsUWPLZh7KA7dgRUPLtE3AikRjUoTL80AN3Q2l5OZx/4degqKgI0gjYHTu2Qb++ A6CsvI/6UjKZgDSyRKy8TLGSQOYofn8lDH7yeai++FyoOf4osJqy00bcaBwidbXgWSa4qJyrpfXx vtQGJSKk2sH20Cio2QFxZD8XWcQ0LYig+GxNabeIZVj4rCiWUO+ixQiaWxpgy6aNyCaDoKikFJkm 3e4dYyhuzVAEUukk1NfshH9PfxpKS/so1rLtFPQbMAgqysrBRLZ/6P471P1RPPtZIEGRdRhLjeJA mAb2BGAOYa37GxzQeqOzULv60QgEyNrbb4Adx40Hs6lFHSSwbN3azilJ4o7yvWcWcjLIjsFViccu kjqmkuWgsgg44QjrBGnVKTTdIYRU7dguOCRO1FQHU/+Sl6fpgOaIe5EwyHgMREsrmK0ptTgoT5K4 ktwOeM9NnqG1FCHdguKVQOHR53gP+skYrwMxbOC5FgLIo2fzHH9tRZc793MQTBfFZwyhnkb6Gt3b B5dLP/WM7zWoaj+Y/tzj8NaC10lcm8wkH7En/1B2QA5gRZnM8/Ud9emurMu3nGMP5/FNfsfu/9c6 ig84OOIq/z4d6saOBg8Zpr62LsMsOaxxMf69TmjAGFLPRikIEplpLhVMJimQkNoScALXViMKdQbP te3gtcI4xsjt5wWe1aIVjgK/CxcSqBOYyZQHyVSGOmWbRUFpEQ1quX0vc0vVsfnYkEFoqEWHs3+i MVdBDXkeqrltMuw7vP0/jpinsppESsvWJZd5leJSV1vnjT96Iry/ZCHpNa5pmof4nulAWcvMsr4z EOzqQo73MkJf5Ajwr1hkzytokyP1lixdAZUz58GHJx8P21lnycNG1JKThTYRh+F2ntRi74vsrn6M W/lyIincf1PoBGgVaxE61fJ0qZXz23mtmCo2NWdI7QCrhLYsuShHeFey/6QvW4APs0NuOI+6u6F9 +qLF8aT7mWkGsMm+PwUbpdbxkjkWSAkHDOPsyDueR/g09qgexpFpl8+5j1ngyzwItvDzHMY6xlns VLTZCPkZzYXHe98jdaoJPf/w1lRiWmlZ5VMnTTkDZvz7WRSH5p0M9nL+Hnmhn4UuLmi9qz8cvYHt 8++xbf/f7BSa0qEjB+myz4O/hKbZC0ASxQeYIsAacaFjF7dI3eE3sHNqDASy6aWm5H5CBxUrpPae /gu3w6XuBCrnCR00pY77H37eSt5P8fGXOA3gGE5zuJr1tEMYDNdzoDFZQLenX0Ux2Sl3GoOHxPUJ geChX85md/83uIPv5Kj5nwIe6IfZV3Idhwge4Wddx3r4MwywQxl4/8vf+Sbr5L9kVvkqT0K9jvXM HzU3t8SOOGoSjDxgNCQSLXM48v5dlhSPwi6sfr47vzT+Z5ajB7NDjG5KCz5fXFA0oUJItDHi3t9o xRCyk8MDnbAlECkn1jhe6DlzQY9jnEXQ41KnJZALncRXCUAm5kerPjzEWj85wDbi8SFCg2OL0KxF 7PM2R88XQVvW3VLusAcDuns+wPj3KWIHWzV7jt/idIlcp5if4rmJQy41HArYxh7WpoBu8gLfdzgD 7GM/SCr0PU4CzbDv8vGnhXZIDmL/ySOcbz+P2NiTTrS1NQkTP38WDB4ynECTL4zSbYBJszy9hQmi nkfwIUy9eS1js2gYIqwJ+r34KrjFRe30EqGz2PoHvjKC6X2AL7dZ6I8UWl+hYzS/hjLDLmV9Jc1T vV3uEDro//pdM9P9LKnDHX9ixknyyJeBuM0PGTgPd+A9EH4AH7KXGamA9hPekgH9IBYY0QP4Ookc 9aCE79HM1ktLYLAkGUTBWcB9pZ79Q5p9Ne7v8NdLkvraLSiaoKJyAFz3vdvg9DMvUBYk+Xl6AjBU FnJI/NsBEN3GL/Izjj3l3ElAJDQQjnxpjvaOhqxcC4gagBQvmsvzQxYpM4VOp6Tjp5CYktqJWMu0 fxR31oHcyA7rJhHfuSjb/t6M+y8JLTpO5NSB0ex3OJUZYggz55n89wj2dN8K2YncUQYKvUJcZOeZ 9IfsRCUaHWUB0VYccHyW83UW8XfuYUvlXg5J+CEN0lf2CzDXv/k5rxFanJJq8BepGSg4+cLXU6je gswyor6+ES760hVw/c13wdBh+0NQWe5K6Yqnt1B5lxW+zQFRsogb8Vvc4NXZosmCYvJzoHm9cdzB +req26ixjvWKk7lhbmb2WsTiZgIHDp8UnD4qdG4JUfx93FDrmL4bmSH4N1DVtSmD8HUe4SdwByzk DjyPR/Qd/PlUFlmkSK5nEbw4YKEYLH6W8ehfEmCBVj63JeCyT/A5vl/vg4Dr/WMWwTMYBCQ2l+F9 f84MRhbMeP8+Qr/jWn6XSczsT7OOE+L+WBlQzrdzDIt0n+UIkKYUWn3DR4yEkfuPgYVvzVFxudyQ xJ7ww+QrB3IuyDche7n2oSyelrOr2Q668Sl4t27MSJh/BeqWhgVGqjXLFM/n+ZV5nHcd/V3gV0sK +ot6at7+7tyrO55vJAKG/EZ3//RGFWIwTbNbRRIElNMnWOvOtaZu4uvfyZZOxnPioqU0cvka+Pyd v4bQzhpwiuLtGkfkAUuhcEG+v/N5haFA+EF+is7f1XPlbnxXdsOzVVdvAZsyAHYxjvdpRFIQNGOZ St/Kec/FTJFfZ/3gQ0XLlKIQDkFZYzNUzZ4Dmw49CJKDBoJBv21dwLsr8gAnd7+jv/fVIvbwtdqW TBbQhMyybMnbSvntQoByjwEGWEE7i5W73MAVyfpZDKpL2UJQk6IINEWoZQycNx92VpRDywHD6ce6 1C+45aPkQp7fnmjs/yRQKZc0iqCa2hp4dca/IBaL9jhggP0ZV7AFky88vJSVvQtYUftI+THQvIsL C4a9NweKpk+H5r6DIDHmAPCiaNiYqN9ku/R3uaHEXjCye5pdRBcBk0gkYNasuVCENl8oHO5xwJDp Rm75a6FtGkluIefUXNZtprCpuYMSkMxQKVTYDTBg6XsQ/edMiK/ZANGNW6Bx3CEKNGIPNZrYxzp3 T4sjn6VNBswbc+dCY4sDlRXxHgeMD4i17Ah7HwovIbGZPx/GpmA96TUGPouVrke55kDVzi2w38dr ILVmK9Qdf6RKTtoVEIh9jE16GmxBwFCpr2uFPl0AjdEN77Ga3eDfguzlJXKLza75TcF3D6GZ70+/ o4cbsvpdAP6ZKgmFV+mEAmZ4Z4ASXRyZnVlaewuAcp9XdPFdyeGTTCY/E8AAswdFQClkUNHJue2W hQkjaAjrfuKtEF6XR5fsgu8mCLLOlGhZ4Fz5GTOGKOBWkDnvvSvPvGFLy2cGGCoUOqBpGld2ATTt CoEmlvH1ybyN0lEnF/J7yA4YSn5GrLA7IJRd/HxXnX4frav5zADjW0aUO/PV3QJNqApK4oPzuq1F Jw23K049+AxFjuwGZuqKKC5UiMsTicILf/bEL+FSgk6KzennIGeJ985KdNyhMGbsWJ1LK3sX3t1T hZTepqqBMO7QodDU1JgVGti2rQY2bU19Jgzjl7XMNDQDsW+XR1/IgvjHG6HvzLnghUPgFsXUlI/e 0r1lwIDKHjOrOzO5KVWBZh3UQhcWDSJwmK1JqJj7NhSt26BM69SgAeCWFKu5QL1l9wt5dikkMH/u zLyhgbKSMNQ1pD4TkRQslK5A+aSU65KAzlegVrMKqZa99R6Uz18ITeMOgbrjjoTayRO0N9jrFVPd UWjGaHkxdliOOvP/BBgAcMs4lyhIS8wAAAAASUVORK5CYII= --_004_1051EFB4D3A1704680C38CCAAC5836D292F1577AWPTXMAIL2ptxaxw_--

3 3

Hosted Engine use SPICE not VNC
by Pat Riehecky 08 Mar '16

08 Mar '16

Is there a way to configure the hosted engine to only use SPICE and not VNC? /usr/libexec/qemu-kvm -name HostedEngine -S -machine rhel6.5.0,accel=kvm,usb=off -cpu qemu64,-svm -m 4096 -realtime <snip> -device virtserialport,bus=virtio-serial0.0,nr=3,chardev=charchannel2,id=channel2,name=org.ovirt.hosted-engine-setup.0 -vnc 0:0,password -device cirrus-vga,id=video0,bus=pci.0,addr=0x2 -msg timestamp=on ]# cat /etc/ovirt-hosted-engine/hosted-engine.conf conf=/var/run/ovirt-hosted-engine-ha/vm.conf host_id=1 console=qxl domainType=nfs3 ca_cert=/etc/pki/vdsm/libvirt-spice/ca-cert.pem ca_subject="C=EN, L=Test, O=Test, CN=Test" vdsm_use_ssl=true bridge=ovirtmgmt # netstat -an Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State tcp 0 0 0.0.0.0:5900 0.0.0.0:* LISTEN Pat -- Pat Riehecky Scientific Linux developer Fermi National Accelerator Laboratory www.fnal.gov www.scientificlinux.org

2 1

my notes while installing hosted-engine-appliance-3.6.3
by Dan Kenigsberg 08 Mar '16

08 Mar '16

0. The longest part of the installation was setting up DNS-DHCP-MAC for the future hosted engine VM. One should have it ready prior to the actual installation. Luckily, Roy Golan told me of that ahead of time. 1. The release notes http://www.ovirt.org/develop/release-management/releases/3.6/ refer to the Quick Start Guide, but the latter is not updated with 3.6 content. 2. I've started with a fully-updated Fedora 23 host, and installed http://plain.resources.ovirt.org/pub/yum-repo/ovirt-release36.rpm on it. 3. It's a bad bad practice (don't try this at home), but I've modified /etc/yum.repos.d/ovirt-3.6.repo to look for fc22 packages, as fc23 is not supported of ovirt-3.6. 4. The release notes ask to modify KexAlgorithms in sshd_config. This is a bit dishearting, and it would much better to explain WHY this is needed. 5. http://www.ovirt.org/develop/release-management/features/heapplianceflow/ has two broken links to jobs that create the hosted engine appliance. I found my appliance image in http://jenkins.ovirt.org/job/ovirt-appliance_ovirt-3.6_build-artifacts-el7-… 6. While running `hosted-engine --deploy` I was greeted with [WARNING] OVF does not contain a valid image description, using default. which suggest that there's a little problem in the appliance, right? 7. After the installation, I've lost connection to my host: it appears that prior to the installation, dhclient on the host used something other than because /var/lib/dhclient/dhclient--eno1.lease to store the DUID. Thus, I've experienced https://bugzilla.redhat.com/1219429 where ovirtmgmt was given a fresh IP address. We may need to extract DUID right from the running dhclient, Ondra. 8. After resolving this, and adding storage to the default datacenter, Engine has imported its own VM, and presented it clearly. 9. Despite the several hurdles and hacks, installation was quick and uneventful. Kudos to the hosted-engine, appliance, and sla teams!

3 2

Tracking asynchronous tasks results in Python SDK
by James Michels 08 Mar '16

08 Mar '16

Greetings How can I track asynchronous tasks with python sdk? For instance, I want to copy a disk so I use: dcdisk = api.disks.get(id='...') act = params.Action(storage_domain=api.storagedomains.get(name='...')) action = dcdisk.copy(act) I get a params.Action object. Now how can I know which ID has the new copied disk? Thank you James

3 3

Re: [ovirt-users] Storage migration: Preallocation forced on destination
by Nicolás 07 Mar '16

07 Mar '16

----_com.android.email_3413880022141120 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 SWYgaW5zdGVhZCBvZiBjb3B5aW5nIG9uIHN0ZXAgMSB0aGUgZGlzayBoYXMgYmVlbiBtb3ZlZCwg YW55IGNoYW5jZSB0byBhZGFwdCB0aGlzIHdvcmthcm91bmQgc28gdGhlIGRpc2sgaXMgdGhpbiBw cm92aXNpb25lZCBvbiB0aGUgdGFyZ2V0PyBXZSBtb3ZlZCBzb21lIG1hY2hpbmVzIGJlZm9yZSBr bm93aW5nIHRoaXMgYW5kIHVuZm9ydHVuYXRlbHkgb25jZSBtb3ZlZCB0byBpU0NTSSB0aGUgZGlz ayBpcyBwcmVhbGxvY2F0ZWQsIHNvIG1vdmluZyBpdCBiYWNrIHdvbid0IGRvIHRoZSB0cmljay4K Ck90aGVyd2lzZSB0aGUgd29ya2Fyb3VuZCB3b3JrcyBwZXJmZWN0bHkuCgpUaGFua3MuCgotLS0t LS0tLSBNZW5zYWplIG9yaWdpbmFsIC0tLS0tLS0tCkRlOiBOaXIgU29mZmVyIDxuc29mZmVyQHJl ZGhhdC5jb20+IApGZWNoYTowNC8wMy8yMDE2ICAyMzoyMyAgKEdNVCswMDowMCkgClBhcmE6IFBh dmVsIEdhc2hldiA8UGF4QGFjcm9uaXMuY29tPiAKQ2M6IE5pY29sw6FzIDxuaWNvbGFzQGRldmVs cy5lcz4sYW11cmVpbmkgPGFtdXJlaW5pQHJlZGhhdC5jb20+LHVzZXJzQG92aXJ0Lm9yZyAKQXN1 bnRvOiBSZTogW292aXJ0LXVzZXJzXSBTdG9yYWdlIG1pZ3JhdGlvbjogUHJlYWxsb2NhdGlvbiBm b3JjZWQgb24gZGVzdGluYXRpb24gCgpPbiBTYXQsIE1hciA1LCAyMDE2IGF0IDEyOjE5IEFNLCBQ YXZlbCBHYXNoZXYgPFBheEBhY3JvbmlzLmNvbT4gd3JvdGU6Cj4gSSB0aGluayBpdCdzIGhhcmQg dG8gY2FsY3VsYXRlIHRoZSBhZGRpdGlvbmFsIHNwYWNlIGZvciBjb3cgZm9ybWF0IHdpdGhvdXQg YW5hbHlzaW5nIHJhdyBpbWFnZS4gSXQncyBiZXR0ZXIgdG8gYWxsb2NhdGUgZW5vdWdoIHNwYWNl LCBhbmQgdGhlbiBkZWNyZWFzZSBpdCBhZnRlciBxZW11LWltZyBjb252ZXJ0LgoKV2UgdXNlIDEw JSBhcyBhIHJvdWdoIGVzdGltYXRlIGZvciBhZGRpdGlvbmFsIHNwYWNlIHdoZW4gY29udmVydGlu Zwpmcm9tIHJhdyB0byBxY293IGZvcm1hdC4gU3VyZSBpdCB3aWxsIHdhc3RlIHNvbWUgc3BhY2Us IGJ1dCBpdCBpcyBnb29kCmVub3VnaC4KCkhvdyB0byB5b3UgcGxhbiB0byBjaGVjayB0aGUgdXNl ZCBzaXplIG9uIHRoZSBkZXN0aW5hdGlvbiBsdj8KCj4gUGxlYXNlIG5vdGUgdGhhdCB3aGlsZSBk aXNrIG1vdmluZyBrZWVwcyBkaXNrIGZvcm1hdCwgZGlzayBjb3B5aW5nIGNoYW5nZXMgZm9ybWF0 LiBTbyB3aGVuIHlvdSBjb3B5IGEgdGhpbiBwcm92aXNpb25lZCBkaXNrIHRvIGlTQ1NJIHN0b3Jh Z2UgaXQncyBiZWluZyBjb252ZXJ0ZWQgdG8gY293LiBUaGUgaXNzdWUgaXMgdGhhdCBzaXplIG9m IGNvbnZlcnRlZCBsdiBzdGlsbCBsb29rcyBsaWtlIHByZWFsbG9jYXRlZC4gWW91IGNhbiBkZWNy ZWFzZSBpdCBtYW51YWxseSB2aWEgbHZjaGFuZ2UsIG9yIHlvdSBjYW4gbW92ZSBpdCB0byBhIGZp bGUgYmFzZWQgc3RvcmFnZSBhbmQgYmFjay4gTW92aW5nIGRpc2tzIGtlZXBzIGRpc2sgZm9ybWF0 LCBidXQgZml4ZXMgaXRzIHNpemUuCgpZZXMsIHRoaXMgc2VlbXMgdG8gYmUgdGhlIHdheSB0byB3 b3JrIGFyb3VuZCB0aGlzIGlzc3VlIGN1cnJlbnRseToKMS4gQ29weSB0byB0aGUgZGlzayB0byBi bG9jayBzdG9yYWdlIC0gd2lsbCBjb252ZXJ0IGl0IHRvIHFjb3cgZm9ybWF0Cm9uIHByZWFsbG9j YXRlZCBsdgoyLiBNb3ZlIGRpc2sgZnJvbSBibG9jayBzdG9yYWdlIHRvIGZpbGUgc3RvcmFnZQoz LiBNb3ZlIGRpc2sgYmFjayB0byBibG9jayBzdG9yYWdlCgo+IEFsc28gcGxlYXNlIGNvbnNpZGVy IHFjb3cgY29tcGF0PTEuMSBhcyBkZWZhdWx0IGRpc2sgZm9ybWF0IGJvdGggZm9yIGZpbGUgYW5k IGJsb2NrIHN0b3JhZ2VzLgoKVGhpcyB3aWxsIG1ha2UgeW91ciBkaXNrIGluY29tcGF0aWJsZSB3 aXRoIG9sZCBvdmlydCB2ZXJzaW9ucyBvbiBlbDYuCkluIHN0b3JhZ2UgZG9tYWluIGZvcm1hdCB2 Mwp3ZSBhcmUgdXNpbmcgY29tYXB0PTAuMTAuCgpXZSBwbGFuIHRvIG1vdmUgdG8gY29tcGF0PTEu MSBpbiA0LjAuCgo+Cj4KPgo+IE9uIDA0LzAzLzE2IDIzOjIzLCAidXNlcnMtYm91bmNlc0Bvdmly dC5vcmcgb24gYmVoYWxmIG9mIE5pciBTb2ZmZXIiIDx1c2Vycy1ib3VuY2VzQG92aXJ0Lm9yZyBv biBiZWhhbGYgb2YgbnNvZmZlckByZWRoYXQuY29tPiB3cm90ZToKPgo+Pk9uIEZyaSwgTWFyIDQs IDIwMTYgYXQgNzowNyBQTSwgTmljb2zDoXMgPG5pY29sYXNAZGV2ZWxzLmVzPiB3cm90ZToKPj4+ IEhpLAo+Pj4KPj4+IFdlJ3JlIG1pZ3JhdGluZyBhbiBleGlzdGluZyBzdG9yYWdlIChnbHVzdGVy ZnMpIHRvIGEgbmV3IG9uZSAoaVNDU0kpLiBBbGwKPj4+IGRpc2tzIG9uIGdsdXN0ZXJmcyBhcmUg dGhpbiBwcm92aXNpb25lZCwgYnV0IHdoZW4gbWlncmF0aW5nIHRvIGlTQ1NJIHRoZQo+Pj4gZm9s bG93aW5nIHdhcm5pbmcgaXMgc2hvd246Cj4+Pgo+Pj7CoMKgwqDCoCBUaGUgZm9sbG93aW5nIGRp c2tzIHdpbGwgYmVjb21lIHByZWFsbG9jYXRlZCwgYW5kIG1heSBjb25zdW1lCj4+PiBjb25zaWRl cmFibHkgbW9yZSBzcGFjZSBvbiB0aGUgdGFyZ2V0OiBsb2NhbC1kaXNrCj4+Pgo+Pj4gV2h5IGlz IHRoYXQ/IElzIHRoZXJlIGEgd2F5IHRvIG1pZ3JhdGUgZGlza3Mgc28gdGhleSBhcmUgdGhpbiBw cm92aXNpb25lZCBvbgo+Pj4gaVNDU0kgYXMgd2VsbD8KPj4KPj5UaGUgaXNzdWUgaXMgdGhhdCB3 ZSB1c2UgcmF3IHNwYXJzZSBmb3JtYXQgZm9yIHRoaW4gcHJvdmlzaW9uZWQgZGlza3MKPj5vbiBm aWxlIGJhc2VkCj4+c3RvcmFnZS4gVGhlIGZpbGUgc3lzdGVtIHByb3ZpZGVzIHRoZSB0aGluIHBy b3Zpc2lvbmluZywgbWFpbnRhaW5pbmcgaG9sZXMgaW4KPj50aGUgZmlsZXMuCj4+Cj4+V2hlbiB3 ZSBjcmVhdGUgdGhlIGRlc3RpbmF0aW9uIGx2LCB3ZSB1c2UgdGhlIGRpc2sgdmlydHVhbCBzaXpl LCBzbyB5b3UgZ2V0Cj4+cHJhY3RpY2FsbHkgYSBwcmVhbGxvY2F0ZWQgdm9sdW1lLgo+Pgo+Pkkg dGhpbmsgd2UgY2FuIGRvIGJldHRlciAtIGJlZm9yZSBjb3B5aW5nIHRoZSBkaXNrLCB3ZSBjYW4g Y2hlY2sgdGhlIGFjdHVhbCB1c2VkCj4+c3BhY2UgKGUuZy4gd2hhdCBxZW11LWltZyBpbmZvIG9y IHN0YXQgcmVwb3J0KSwgYW5kIGNyZWF0ZSB0aGUKPj5kZXN0aW5hdGlvbiBsdiB1c2luZwo+PnRo ZSB1c2VkIHNpemUgKHBsdXMgYWRkaXRpb25hbCBzcGFjZSBmb3IgcWNvdyBmb3JtYXQpLgo+Pgo+ PkkgdGVzdGVkIHRoaXMgYnkgZXh0ZW5kaW5nIHRoZSBkZXN0aW5hdGlvbiBsdiBtYW51YWxseSBh bmQgdGhlbgo+PmNvcHlpbmcgZGF0YSBtYW51YWxseQo+PnVzaW5nIHFlbXUtaW1nIGNvbnZlcnQs IGFuZCBpdCB3b3Jrcy4KPj4KPj5DYW4geW91IGZpbGUgYSBidWcgZm9yIHRoaXMsIGFuZCBleHBs YWluIHRoZSB1c2UgY2FzZT8KPj4KPj5OaXIKPj5fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXwo+PlVzZXJzIG1haWxpbmcgbGlzdAo+PlVzZXJzQG92aXJ0Lm9y Zwo+Pmh0dHA6Ly9saXN0cy5vdmlydC5vcmcvbWFpbG1hbi9saXN0aW5mby91c2Vycwo= ----_com.android.email_3413880022141120 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keSA+SWYgaW5zdGVhZCBvZiBjb3B5aW5n IG9uIHN0ZXAgMSB0aGUgZGlzayBoYXMgYmVlbiBtb3ZlZCwgYW55IGNoYW5jZSB0byBhZGFwdCB0 aGlzIHdvcmthcm91bmQgc28gdGhlIGRpc2sgaXMgdGhpbiBwcm92aXNpb25lZCBvbiB0aGUgdGFy Z2V0PyBXZSBtb3ZlZCBzb21lIG1hY2hpbmVzIGJlZm9yZSBrbm93aW5nIHRoaXMgYW5kIHVuZm9y dHVuYXRlbHkgb25jZSBtb3ZlZCB0byBpU0NTSSB0aGUgZGlzayBpcyBwcmVhbGxvY2F0ZWQsIHNv IG1vdmluZyBpdCBiYWNrIHdvbid0IGRvIHRoZSB0cmljay48ZGl2Pjxicj48L2Rpdj48ZGl2Pk90 aGVyd2lzZSB0aGUgd29ya2Fyb3VuZCB3b3JrcyBwZXJmZWN0bHkuPC9kaXY+PGRpdj48YnI+PC9k aXY+PGRpdj5UaGFua3MuPC9kaXY+PGJyPjxicj4tLS0tLS0tLSBNZW5zYWplIG9yaWdpbmFsIC0t LS0tLS0tPGJyPkRlOiBOaXIgU29mZmVyIDxuc29mZmVyQHJlZGhhdC5jb20+IDxicj5GZWNoYTow NC8wMy8yMDE2ICAyMzoyMyAgKEdNVCswMDowMCkgPGJyPlBhcmE6IFBhdmVsIEdhc2hldiA8UGF4 QGFjcm9uaXMuY29tPiA8YnI+Q2M6IE5pY29sw6FzIDxuaWNvbGFzQGRldmVscy5lcz4sYW11cmVp bmkgPGFtdXJlaW5pQHJlZGhhdC5jb20+LHVzZXJzQG92aXJ0Lm9yZyA8YnI+QXN1bnRvOiBSZTog W292aXJ0LXVzZXJzXSBTdG9yYWdlIG1pZ3JhdGlvbjogUHJlYWxsb2NhdGlvbiBmb3JjZWQgb24g ZGVzdGluYXRpb24gPGJyPjxicj5PbiBTYXQsIE1hciA1LCAyMDE2IGF0IDEyOjE5IEFNLCBQYXZl bCBHYXNoZXYgJmx0O1BheEBhY3JvbmlzLmNvbSZndDsgd3JvdGU6PGJyPiZndDsgSSB0aGluayBp dCdzIGhhcmQgdG8gY2FsY3VsYXRlIHRoZSBhZGRpdGlvbmFsIHNwYWNlIGZvciBjb3cgZm9ybWF0 IHdpdGhvdXQgYW5hbHlzaW5nIHJhdyBpbWFnZS4gSXQncyBiZXR0ZXIgdG8gYWxsb2NhdGUgZW5v dWdoIHNwYWNlLCBhbmQgdGhlbiBkZWNyZWFzZSBpdCBhZnRlciBxZW11LWltZyBjb252ZXJ0Ljxi cj48YnI+V2UgdXNlIDEwJSBhcyBhIHJvdWdoIGVzdGltYXRlIGZvciBhZGRpdGlvbmFsIHNwYWNl IHdoZW4gY29udmVydGluZzxicj5mcm9tIHJhdyB0byBxY293IGZvcm1hdC4gU3VyZSBpdCB3aWxs IHdhc3RlIHNvbWUgc3BhY2UsIGJ1dCBpdCBpcyBnb29kPGJyPmVub3VnaC48YnI+PGJyPkhvdyB0 byB5b3UgcGxhbiB0byBjaGVjayB0aGUgdXNlZCBzaXplIG9uIHRoZSBkZXN0aW5hdGlvbiBsdj88 YnI+PGJyPiZndDsgUGxlYXNlIG5vdGUgdGhhdCB3aGlsZSBkaXNrIG1vdmluZyBrZWVwcyBkaXNr IGZvcm1hdCwgZGlzayBjb3B5aW5nIGNoYW5nZXMgZm9ybWF0LiBTbyB3aGVuIHlvdSBjb3B5IGEg dGhpbiBwcm92aXNpb25lZCBkaXNrIHRvIGlTQ1NJIHN0b3JhZ2UgaXQncyBiZWluZyBjb252ZXJ0 ZWQgdG8gY293LiBUaGUgaXNzdWUgaXMgdGhhdCBzaXplIG9mIGNvbnZlcnRlZCBsdiBzdGlsbCBs b29rcyBsaWtlIHByZWFsbG9jYXRlZC4gWW91IGNhbiBkZWNyZWFzZSBpdCBtYW51YWxseSB2aWEg bHZjaGFuZ2UsIG9yIHlvdSBjYW4gbW92ZSBpdCB0byBhIGZpbGUgYmFzZWQgc3RvcmFnZSBhbmQg YmFjay4gTW92aW5nIGRpc2tzIGtlZXBzIGRpc2sgZm9ybWF0LCBidXQgZml4ZXMgaXRzIHNpemUu PGJyPjxicj5ZZXMsIHRoaXMgc2VlbXMgdG8gYmUgdGhlIHdheSB0byB3b3JrIGFyb3VuZCB0aGlz IGlzc3VlIGN1cnJlbnRseTo8YnI+MS4gQ29weSB0byB0aGUgZGlzayB0byBibG9jayBzdG9yYWdl IC0gd2lsbCBjb252ZXJ0IGl0IHRvIHFjb3cgZm9ybWF0PGJyPm9uIHByZWFsbG9jYXRlZCBsdjxi cj4yLiBNb3ZlIGRpc2sgZnJvbSBibG9jayBzdG9yYWdlIHRvIGZpbGUgc3RvcmFnZTxicj4zLiBN b3ZlIGRpc2sgYmFjayB0byBibG9jayBzdG9yYWdlPGJyPjxicj4mZ3Q7IEFsc28gcGxlYXNlIGNv bnNpZGVyIHFjb3cgY29tcGF0PTEuMSBhcyBkZWZhdWx0IGRpc2sgZm9ybWF0IGJvdGggZm9yIGZp bGUgYW5kIGJsb2NrIHN0b3JhZ2VzLjxicj48YnI+VGhpcyB3aWxsIG1ha2UgeW91ciBkaXNrIGlu Y29tcGF0aWJsZSB3aXRoIG9sZCBvdmlydCB2ZXJzaW9ucyBvbiBlbDYuPGJyPkluIHN0b3JhZ2Ug ZG9tYWluIGZvcm1hdCB2Mzxicj53ZSBhcmUgdXNpbmcgY29tYXB0PTAuMTAuPGJyPjxicj5XZSBw bGFuIHRvIG1vdmUgdG8gY29tcGF0PTEuMSBpbiA0LjAuPGJyPjxicj4mZ3Q7PGJyPiZndDs8YnI+ Jmd0Ozxicj4mZ3Q7IE9uIDA0LzAzLzE2IDIzOjIzLCAidXNlcnMtYm91bmNlc0BvdmlydC5vcmcg b24gYmVoYWxmIG9mIE5pciBTb2ZmZXIiICZsdDt1c2Vycy1ib3VuY2VzQG92aXJ0Lm9yZyBvbiBi ZWhhbGYgb2YgbnNvZmZlckByZWRoYXQuY29tJmd0OyB3cm90ZTo8YnI+Jmd0Ozxicj4mZ3Q7Jmd0 O09uIEZyaSwgTWFyIDQsIDIwMTYgYXQgNzowNyBQTSwgTmljb2zDoXMgJmx0O25pY29sYXNAZGV2 ZWxzLmVzJmd0OyB3cm90ZTo8YnI+Jmd0OyZndDsmZ3Q7IEhpLDxicj4mZ3Q7Jmd0OyZndDs8YnI+ Jmd0OyZndDsmZ3Q7IFdlJ3JlIG1pZ3JhdGluZyBhbiBleGlzdGluZyBzdG9yYWdlIChnbHVzdGVy ZnMpIHRvIGEgbmV3IG9uZSAoaVNDU0kpLiBBbGw8YnI+Jmd0OyZndDsmZ3Q7IGRpc2tzIG9uIGds dXN0ZXJmcyBhcmUgdGhpbiBwcm92aXNpb25lZCwgYnV0IHdoZW4gbWlncmF0aW5nIHRvIGlTQ1NJ IHRoZTxicj4mZ3Q7Jmd0OyZndDsgZm9sbG93aW5nIHdhcm5pbmcgaXMgc2hvd246PGJyPiZndDsm Z3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVGhlIGZvbGxv d2luZyBkaXNrcyB3aWxsIGJlY29tZSBwcmVhbGxvY2F0ZWQsIGFuZCBtYXkgY29uc3VtZTxicj4m Z3Q7Jmd0OyZndDsgY29uc2lkZXJhYmx5IG1vcmUgc3BhY2Ugb24gdGhlIHRhcmdldDogbG9jYWwt ZGlzazxicj4mZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZndDsmZ3Q7IFdoeSBpcyB0aGF0PyBJcyB0aGVy ZSBhIHdheSB0byBtaWdyYXRlIGRpc2tzIHNvIHRoZXkgYXJlIHRoaW4gcHJvdmlzaW9uZWQgb248 YnI+Jmd0OyZndDsmZ3Q7IGlTQ1NJIGFzIHdlbGw/PGJyPiZndDsmZ3Q7PGJyPiZndDsmZ3Q7VGhl IGlzc3VlIGlzIHRoYXQgd2UgdXNlIHJhdyBzcGFyc2UgZm9ybWF0IGZvciB0aGluIHByb3Zpc2lv bmVkIGRpc2tzPGJyPiZndDsmZ3Q7b24gZmlsZSBiYXNlZDxicj4mZ3Q7Jmd0O3N0b3JhZ2UuIFRo ZSBmaWxlIHN5c3RlbSBwcm92aWRlcyB0aGUgdGhpbiBwcm92aXNpb25pbmcsIG1haW50YWluaW5n IGhvbGVzIGluPGJyPiZndDsmZ3Q7dGhlIGZpbGVzLjxicj4mZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0O1do ZW4gd2UgY3JlYXRlIHRoZSBkZXN0aW5hdGlvbiBsdiwgd2UgdXNlIHRoZSBkaXNrIHZpcnR1YWwg c2l6ZSwgc28geW91IGdldDxicj4mZ3Q7Jmd0O3ByYWN0aWNhbGx5IGEgcHJlYWxsb2NhdGVkIHZv bHVtZS48YnI+Jmd0OyZndDs8YnI+Jmd0OyZndDtJIHRoaW5rIHdlIGNhbiBkbyBiZXR0ZXIgLSBi ZWZvcmUgY29weWluZyB0aGUgZGlzaywgd2UgY2FuIGNoZWNrIHRoZSBhY3R1YWwgdXNlZDxicj4m Z3Q7Jmd0O3NwYWNlIChlLmcuIHdoYXQgcWVtdS1pbWcgaW5mbyBvciBzdGF0IHJlcG9ydCksIGFu ZCBjcmVhdGUgdGhlPGJyPiZndDsmZ3Q7ZGVzdGluYXRpb24gbHYgdXNpbmc8YnI+Jmd0OyZndDt0 aGUgdXNlZCBzaXplIChwbHVzIGFkZGl0aW9uYWwgc3BhY2UgZm9yIHFjb3cgZm9ybWF0KS48YnI+ Jmd0OyZndDs8YnI+Jmd0OyZndDtJIHRlc3RlZCB0aGlzIGJ5IGV4dGVuZGluZyB0aGUgZGVzdGlu YXRpb24gbHYgbWFudWFsbHkgYW5kIHRoZW48YnI+Jmd0OyZndDtjb3B5aW5nIGRhdGEgbWFudWFs bHk8YnI+Jmd0OyZndDt1c2luZyBxZW11LWltZyBjb252ZXJ0LCBhbmQgaXQgd29ya3MuPGJyPiZn dDsmZ3Q7PGJyPiZndDsmZ3Q7Q2FuIHlvdSBmaWxlIGEgYnVnIGZvciB0aGlzLCBhbmQgZXhwbGFp biB0aGUgdXNlIGNhc2U/PGJyPiZndDsmZ3Q7PGJyPiZndDsmZ3Q7TmlyPGJyPiZndDsmZ3Q7X19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+Jmd0OyZndDtV c2VycyBtYWlsaW5nIGxpc3Q8YnI+Jmd0OyZndDtVc2Vyc0BvdmlydC5vcmc8YnI+Jmd0OyZndDto dHRwOi8vbGlzdHMub3ZpcnQub3JnL21haWxtYW4vbGlzdGluZm8vdXNlcnM8YnI+PC9ib2R5Pg== ----_com.android.email_3413880022141120--

1 0

Re: [ovirt-users] Users Digest, Vol 54, Issue 45 VM migration by using the Python SDK
by Jean-Pierre Ribeauville 07 Mar '16

07 Mar '16

Hi, Thx a lot. Regards, J.P. -----Original Message----- From: users-bounces(a)ovirt.org [mailto:users-bounces@ovirt.org] On Behalf Of users-request(a)ovirt.org Sent: lundi 7 mars 2016 20:00 To: users(a)ovirt.org Subject: Users Digest, Vol 54, Issue 45 Send Users mailing list submissions to users(a)ovirt.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.ovirt.org/mailman/listinfo/users or, via email, send a message with subject or body 'help' to users-request(a)ovirt.org You can reach the person managing the list at users-owner(a)ovirt.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Users digest..." Today's Topics: 1. Re: restore-nets failing (was: Fresh install failing (Hosted Engine)) (Jonathan Sherman) 2. Re: regenerate libvirt-spice keys after libvirtd restart? (Bill James) 3. Re: VM migration by using the Python SDK (Yaniv Kaul) ---------------------------------------------------------------------- Message: 1 Date: Mon, 7 Mar 2016 12:49:56 -0500 From: Jonathan Sherman <haviland(a)gmail.com> To: Dan Kenigsberg <danken(a)redhat.com> Cc: Martin Polednik <mpolednik(a)redhat.com>, users <users(a)ovirt.org> Subject: Re: [ovirt-users] restore-nets failing (was: Fresh install failing (Hosted Engine)) Message-ID: <CAG7LhDtBRxQUC1Qnzqg6gY_tXQz8MSS3HUJfPO3F789=cVndUg(a)mail.gmail.com> Content-Type: text/plain; charset="utf-8" Bug 1315435 Submitted. Let me know if there's anything else I can do to help. On Mon, Mar 7, 2016 at 12:04 PM, Dan Kenigsberg <danken(a)redhat.com> wrote: > On Mon, Mar 07, 2016 at 11:45:27AM -0500, Jonathan Sherman wrote: > > The SMBIOS settings were indeed indeed the issue that was blocking > > me. I investigated how to configure the SMBIOS settings and now > > restore-nets works, and I'm getting past where I was failing on the > > hosted-engine --deploy. > > > > FYI, I had to download the "Intel Integrator Toolkit" (which is now > > EOL) and create a custom BIOS to add those settings in for my > > system, which is an Intel NUC DN2820FYKH. > > > > I am happy to back this out and test any changes if you'd like, but > > this has gotten me to where I can continue oVirt testing for now. > > I'll likely be reinstalling a few times along the way to polish my > > documentation, so let me know if you want me to revert my BIOS and test anything. > > > > Thanks all! > > -js > > > > On Mon, Mar 7, 2016 at 11:22 AM, Martin Polednik > > <mpolednik(a)redhat.com> > > wrote: > > > > > On 07/03/16 11:09 -0500, Jonathan Sherman wrote: > > > > > >> Thanks for your time on this Dan! > > >> > > >> The output from the hostdev looks like it may be unparseable, so > > >> I'm hoping this is the issue (and that it can be easily > > >> remedied). > > >> > > >> I've also create a log of the other items you asked for, available at: > > >> https://www.dropbox.com/s/qh0yw1ptpivpatm/typescript?dl=0 > > >> > > >> [root@ovirt01 vdsm]# vdsm-tool restore-nets <device> > > >> <name>computer</name> <capability type='system'> > > >> <product>?????????????????????????????????</product> > > >> <hardware> > > >> <vendor>?????????????????????????????????</vendor> > > >> <version>?????????????????????????????????</version> > > >> <serial>?????????????????????????????????</serial> > > >> <uuid>d6a3e3c1-c5cb-42e9-a54c-ff8d0df91722</uuid> > > >> </hardware> > > >> <firmware> > > >> <vendor>Intel Corp.</vendor> > > >> <version>FYBYT10H.86A.0052.2015.0923.1845</version> > > >> <release_date>09/23/2015</release_date> > > >> </firmware> > > >> </capability> > > >> </device> > > >> > > > > > > That seems to be the issue. Even bigger issue is that we can not > > > skip this device easily, as it is the root of device tree and must > > > be present in database. > > > > > > I can think of logging the exception but letting the call go > > > through and create a hook to fake a (minimal) device tree. Dan, > > > what do you > think? > > > But why isn't this a valid xml, Martin? I suspect that we need to > utf-8-decode nodedev-xml before using them in Vdsm, similar to what we > do with domain-xml? (consider Klingon characters in the <vendor> > element). > > In any case, this issue merits a bug - could you open it, Jonathan, > and attach relevant data to it? > > Regards, > Dan. >

1 0

Re: [ovirt-users] restore-nets failing (was: Fresh install failing (Hosted Engine))
by Yedidyah Bar David 07 Mar '16

07 Mar '16

On Mon, Mar 7, 2016 at 3:01 PM, Jonathan Sherman <haviland(a)gmail.com> wrote: > Didi - > > The vdsmd service error is what led me to the vdsm-tool restore-nets > concern. See the chain of errors below (along with the other details you > requested.) Thanks. Changing subject and adding Dan. > > Thanks! > -js > > -- > > [jsherman@ovirt01 vdsm]$ ls -la /var/log/vdsm > total 48 > drwxr-xr-x. 3 vdsm kvm 4096 Mar 5 18:50 . > drwxr-xr-x. 13 root root 4096 Mar 6 03:08 .. > drwxr-xr-x. 2 vdsm kvm 6 Mar 1 09:18 backup > -rw-r--r--. 1 vdsm kvm 0 Mar 5 17:53 connectivity.log > -rw-r--r--. 1 vdsm kvm 0 Mar 5 17:53 mom.log > -rw-r--r--. 1 root root 34437 Mar 6 22:18 supervdsm.log > -rw-r--r--. 1 root root 1875 Mar 5 17:59 upgrade.log > -rw-r--r--. 1 vdsm kvm 0 Mar 5 17:53 vdsm.log > > -- > > [root@ovirt01 log]# sestatus > SELinux status: enabled > SELinuxfs mount: /sys/fs/selinux > SELinux root directory: /etc/selinux > Loaded policy name: targeted > Current mode: permissive > Mode from config file: enforcing > Policy MLS status: enabled > Policy deny_unknown status: allowed > Max kernel policy version: 28 > > -- > > [root@ovirt01 audit]# tail -20 audit.log > type=USER_AUTH msg=audit(1457355177.617:519): pid=20733 uid=1000 auid=1000 > ses=19 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 > msg='op=PAM:authentication grantors=pam_unix acct="jsherman" > exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/0 res=success' > type=USER_ACCT msg=audit(1457355177.623:520): pid=20733 uid=1000 auid=1000 > ses=19 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 > msg='op=PAM:accounting grantors=pam_unix,pam_localuser acct="jsherman" > exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/0 res=success' > type=USER_CMD msg=audit(1457355177.625:521): pid=20733 uid=1000 auid=1000 > ses=19 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 > msg='cwd="/var/log/vdsm" cmd=73797374656D63746C207374617274207664736D64 > terminal=pts/0 res=success' > type=CRED_ACQ msg=audit(1457355177.626:522): pid=20733 uid=0 auid=1000 > ses=19 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 > msg='op=PAM:setcred grantors=pam_unix acct="root" exe="/usr/bin/sudo" > hostname=? addr=? terminal=/dev/pts/0 res=success' > type=USER_START msg=audit(1457355177.628:523): pid=20733 uid=0 auid=1000 > ses=19 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 > msg='op=PAM:session_open grantors=pam_keyinit,pam_limits acct="root" > exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/0 res=success' > type=USER_END msg=audit(1457355179.095:524): pid=20733 uid=0 auid=1000 > ses=19 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 > msg='op=PAM:session_close grantors=pam_keyinit,pam_limits acct="root" > exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/0 res=success' > type=CRED_DISP msg=audit(1457355179.095:525): pid=20733 uid=0 auid=1000 > ses=19 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 > msg='op=PAM:setcred grantors=pam_unix acct="root" exe="/usr/bin/sudo" > hostname=? addr=? terminal=/dev/pts/0 res=success' > type=SERVICE_START msg=audit(1457355179.099:526): pid=1 uid=0 > auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 > msg='unit=vdsm-network comm="systemd" exe="/usr/lib/systemd/systemd" > hostname=? addr=? terminal=? res=failed' > type=USER_CMD msg=audit(1457355237.531:527): pid=20768 uid=1000 auid=1000 > ses=19 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 > msg='cwd="/var/log" cmd=6C73202D616C206175646974 terminal=pts/0 res=success' > type=CRED_ACQ msg=audit(1457355237.533:528): pid=20768 uid=0 auid=1000 > ses=19 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 > msg='op=PAM:setcred grantors=pam_env,pam_unix acct="root" > exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/0 res=success' > type=USER_START msg=audit(1457355237.535:529): pid=20768 uid=0 auid=1000 > ses=19 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 > msg='op=PAM:session_open grantors=pam_keyinit,pam_limits acct="root" > exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/0 res=success' > type=USER_END msg=audit(1457355237.554:530): pid=20768 uid=0 auid=1000 > ses=19 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 > msg='op=PAM:session_close grantors=pam_keyinit,pam_limits acct="root" > exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/0 res=success' > type=CRED_DISP msg=audit(1457355237.555:531): pid=20768 uid=0 auid=1000 > ses=19 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 > msg='op=PAM:setcred grantors=pam_env,pam_unix acct="root" > exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/0 res=success' > type=USER_CMD msg=audit(1457355242.882:532): pid=20770 uid=1000 auid=1000 > ses=19 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 > msg='cwd="/var/log" cmd=7375202D terminal=pts/0 res=success' > type=CRED_ACQ msg=audit(1457355242.885:533): pid=20770 uid=0 auid=1000 > ses=19 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 > msg='op=PAM:setcred grantors=pam_env,pam_unix acct="root" > exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/0 res=success' > type=USER_START msg=audit(1457355242.887:534): pid=20770 uid=0 auid=1000 > ses=19 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 > msg='op=PAM:session_open grantors=pam_keyinit,pam_limits acct="root" > exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/0 res=success' > type=USER_AUTH msg=audit(1457355242.925:535): pid=20771 uid=0 auid=1000 > ses=19 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 > msg='op=PAM:authentication grantors=pam_rootok acct="root" exe="/usr/bin/su" > hostname=? addr=? terminal=pts/0 res=success' > type=USER_ACCT msg=audit(1457355242.925:536): pid=20771 uid=0 auid=1000 > ses=19 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 > msg='op=PAM:accounting grantors=pam_succeed_if acct="root" exe="/usr/bin/su" > hostname=? addr=? terminal=pts/0 res=success' > type=CRED_ACQ msg=audit(1457355242.928:537): pid=20771 uid=0 auid=1000 > ses=19 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 > msg='op=PAM:setcred grantors=pam_rootok acct="root" exe="/usr/bin/su" > hostname=? addr=? terminal=pts/0 res=success' > type=USER_START msg=audit(1457355242.954:538): pid=20771 uid=0 auid=1000 > ses=19 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 > msg='op=PAM:session_open > grantors=pam_keyinit,pam_keyinit,pam_limits,pam_systemd,pam_unix,pam_xauth > acct="root" exe="/usr/bin/su" hostname=? addr=? terminal=pts/0 res=success' > > -- > > [jsherman@ovirt01 vdsm]$ journalctl -xe > -- Unit vdsm-network.service has failed. > -- > -- The result is failed. > Mar 07 07:52:59 ovirt01 systemd[1]: Dependency failed for 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 dependency. > Mar 07 07:52:59 ovirt01 polkitd[2395]: Unregistered Authentication Agent for > unix-process:20737:13641695 (system bus name :1 > Mar 07 07:52:59 ovirt01 systemd[1]: Dependency failed for MOM instance > configured for VDSM purposes. > -- Subject: Unit mom-vdsm.service has failed > -- Defined-By: systemd > -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel > -- > -- Unit mom-vdsm.service has failed. > -- > -- The result is dependency. > Mar 07 07:52:59 ovirt01 systemd[1]: Job mom-vdsm.service/start failed with > result 'dependency'. > Mar 07 07:52:59 ovirt01 systemd[1]: Job vdsmd.service/start failed with > result 'dependency'. > Mar 07 07:52:59 ovirt01 systemd[1]: Unit vdsm-network.service entered failed > state. > Mar 07 07:52:59 ovirt01 systemd[1]: vdsm-network.service failed. > > -- > > [root@ovirt01 log]# systemctl start mom-vdsm > A dependency job for mom-vdsm.service failed. See 'journalctl -xe' for > details. > [root@ovirt01 log]# journalctl -xe > -- Unit vdsm-network.service has failed. > -- > -- The result is failed. > Mar 07 07:57:34 ovirt01 systemd[1]: Dependency failed for 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 dependency. > Mar 07 07:57:34 ovirt01 systemd[1]: Dependency failed for MOM instance > configured for VDSM purposes. > -- Subject: Unit mom-vdsm.service has failed > -- Defined-By: systemd > -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel > -- > -- Unit mom-vdsm.service has failed. > -- > -- The result is dependency. > Mar 07 07:57:34 ovirt01 systemd[1]: Job mom-vdsm.service/start failed with > result 'dependency'. > Mar 07 07:57:34 ovirt01 systemd[1]: Job vdsmd.service/start failed with > result 'dependency'. > Mar 07 07:57:34 ovirt01 systemd[1]: Unit vdsm-network.service entered failed > state. > Mar 07 07:57:34 ovirt01 systemd[1]: vdsm-network.service failed. > Mar 07 07:57:34 ovirt01 polkitd[2395]: Unregistered Authentication Agent for > unix-process:20832:13669245 (system bus name :1 > > -- > > [root@ovirt01 log]# systemctl start vdsm-network > Job for vdsm-network.service failed because the control process exited with > error code. See "systemctl status vdsm-network.service" and "journalctl -xe" > for details. > [root@ovirt01 log]# journalctl -xe > Mar 07 07:58:32 ovirt01 vdsm-tool[20871]: self._raiseerror(v) > Mar 07 07:58:32 ovirt01 vdsm-tool[20871]: File > "/usr/lib64/python2.7/xml/etree/ElementTree.py", line 1506, in _raiseerror > Mar 07 07:58:32 ovirt01 vdsm-tool[20871]: raise err > Mar 07 07:58:32 ovirt01 vdsm-tool[20871]: xml.etree.ElementTree.ParseError: > not well-formed (invalid token): line 4, column 13 > Mar 07 07:58:32 ovirt01 vdsm-tool[20871]: Traceback (most recent call last): > Mar 07 07:58:32 ovirt01 vdsm-tool[20871]: File "/usr/bin/vdsm-tool", line > 219, in main > Mar 07 07:58:32 ovirt01 vdsm-tool[20871]: return > tool_command[cmd]["command"](*args) > Mar 07 07:58:32 ovirt01 vdsm-tool[20871]: File > "/usr/lib/python2.7/site-packages/vdsm/tool/restore_nets.py", line 41, in > restore_com > Mar 07 07:58:32 ovirt01 vdsm-tool[20871]: exec_restore(cmd) > Mar 07 07:58:32 ovirt01 vdsm-tool[20871]: File > "/usr/lib/python2.7/site-packages/vdsm/tool/restore_nets.py", line 54, in > exec_restor > Mar 07 07:58:32 ovirt01 vdsm-tool[20871]: raise EnvironmentError('Failed to > restore the persisted networks') > Mar 07 07:58:32 ovirt01 vdsm-tool[20871]: EnvironmentError: Failed to > restore the persisted networks > Mar 07 07:58:32 ovirt01 systemd[1]: vdsm-network.service: main process > exited, code=exited, status=1/FAILURE > Mar 07 07:58:32 ovirt01 systemd[1]: Failed to start Virtual Desktop Server > Manager network restoration. > -- Subject: Unit vdsm-network.service has failed > -- Defined-By: systemd > -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel > -- > -- Unit vdsm-network.service has failed. > -- > -- The result is failed. > Mar 07 07:58:32 ovirt01 systemd[1]: Unit vdsm-network.service entered failed > state. > Mar 07 07:58:32 ovirt01 systemd[1]: vdsm-network.service failed. > Mar 07 07:58:32 ovirt01 polkitd[2395]: Unregistered Authentication Agent for > unix-process:20860:13674993 (system bus name :1.115, o > > -- > > [root@ovirt01 log]# vdsm-tool restore-nets > Traceback (most recent call last): > File "/usr/share/vdsm/vdsm-restore-net-config", line 429, in <module> > restore(args) > File "/usr/share/vdsm/vdsm-restore-net-config", line 387, in restore > _restore_sriov_numvfs() > File "/usr/share/vdsm/vdsm-restore-net-config", line 82, in > _restore_sriov_numvfs > sriov_devices = _get_sriov_devices() > File "/usr/share/vdsm/vdsm-restore-net-config", line 54, in > _get_sriov_devices > devices = hostdev.list_by_caps() > File "/usr/share/vdsm/hostdev.py", line 175, in list_by_caps > libvirt_devices = _get_devices_from_libvirt() > File "/usr/share/vdsm/hostdev.py", line 160, in _get_devices_from_libvirt > for device in libvirtconnection.get().listAllDevices(0)) > File "/usr/share/vdsm/hostdev.py", line 160, in <genexpr> > for device in libvirtconnection.get().listAllDevices(0)) > File "/usr/share/vdsm/hostdev.py", line 107, in _parse_device_params > devXML = etree.fromstring(device_xml) > File "/usr/lib64/python2.7/xml/etree/ElementTree.py", line 1300, in XML > parser.feed(text) > File "/usr/lib64/python2.7/xml/etree/ElementTree.py", line 1642, in feed > self._raiseerror(v) > File "/usr/lib64/python2.7/xml/etree/ElementTree.py", line 1506, in > _raiseerror > raise err > xml.etree.ElementTree.ParseError: not well-formed (invalid token): line 4, > column 13 > Traceback (most recent call last): > File "/bin/vdsm-tool", line 219, in main > return tool_command[cmd]["command"](*args) > File "/usr/lib/python2.7/site-packages/vdsm/tool/restore_nets.py", line > 41, in restore_command > exec_restore(cmd) > File "/usr/lib/python2.7/site-packages/vdsm/tool/restore_nets.py", line > 54, in exec_restore > raise EnvironmentError('Failed to restore the persisted networks') > EnvironmentError: Failed to restore the persisted networks > > > On Mon, Mar 7, 2016 at 2:56 AM, Yedidyah Bar David <didi(a)redhat.com> wrote: >> >> On Sun, Mar 6, 2016 at 7:21 PM, Jonathan Sherman <haviland(a)gmail.com> >> wrote: >> > Didi, >> > >> > NetworkManager is off, via "systemctl disable NetworkManager && >> > systemctl >> > stop NetworkManager" (and rebooted after), and network allowing remote >> > ssh >> > access and yum commands functional. >> > >> > Log files with sizes >0 from /var/log/vdsm: >> > https://www.dropbox.com/s/iobee7toeyc2jda/supervdsm.log?dl=0 >> > https://www.dropbox.com/s/rdxi4ujwqhmekgh/upgrade.log?dl=0 >> >> So this means you also have an empty (size 0) vdsm.log? Can you please >> 'ls -la /var/log/vdsm'? >> >> Can you check selinux/audit logs? >> >> > >> > Most recent log file from /var/log/ovirt-hosted-engine-setup: >> > >> > https://www.dropbox.com/s/brbbujmqhhbsx4o/ovirt-hosted-engine-setup-2016030… >> >> This has: >> >> 2016-03-06 10:41:43 DEBUG otopi.plugins.otopi.services.systemd >> plugin.execute:941 execute-output: ('/bin/systemctl', 'start', >> 'vdsmd.service') stderr: >> A dependency job for vdsmd.service failed. See 'journalctl -xe' for >> details. >> >> Can you please check/post output of 'journalctl -xe'? >> >> Thanks, >> >> > >> > Thank you for your time! >> > -js >> > >> > >> > On Sun, Mar 6, 2016 at 5:23 AM, Yedidyah Bar David <didi(a)redhat.com> >> > wrote: >> >> >> >> On Sun, Mar 6, 2016 at 2:50 AM, Jonathan Sherman <haviland(a)gmail.com> >> >> wrote: >> >> > I want to extend my lab and am trying an install using the hosted >> >> > engine, >> >> > but the install is failing for me: >> >> > >> >> > References used for install: >> >> > https://glennsnead.wordpress.com/2016/02/28/ovirt-3-6-installation/ >> >> > >> >> > http://community.redhat.com/blog/2014/10/up-and-running-with-ovirt-3-5/ >> >> > >> >> > Setup: >> >> > Minimal install of CentOS Linux release 7.2.1511 (Core) >> >> > Using DHCP with static address (tried without DHCP with same issue) >> >> > yum upgrade >> >> > >> >> > Installed packages: >> >> > yum localinstall -y >> >> > http://resources.ovirt.org/pub/yum-repo/ovirt-release36.rpm >> >> > yum install -y ovirt-hosted-engine-setup screen glusterfs-server >> >> > nfs-utils >> >> > vdsm-gluster system-storage-manager mailx >> >> > >> >> > rebooted >> >> > >> >> > Tried hosted-engine --deploy, but it errors out. I followed various >> >> > logs >> >> > and I _think_ it's failing related to vdsm-tool restore-nets. I >> >> > could >> >> > use >> >> > some guidance on this to help track down what's happening and how to >> >> > fix. >> >> > >> >> > (Note: I'd very much prefer using the hosted engine vs. another >> >> > option >> >> > for >> >> > my lab, so I'm willing to put in the time to figure this out. Thanks >> >> > for >> >> > any assistance!) >> >> > >> >> > Install error: >> >> > [root@ovirt01 network-scripts]# hosted-engine --deploy >> >> > [ INFO ] Stage: Initializing >> >> > [ INFO ] Generating a temporary VNC password. >> >> > [ INFO ] Stage: Environment setup >> >> > Continuing will configure this host for serving as >> >> > hypervisor >> >> > and >> >> > create a VM where you have to install the engine afterwards. >> >> > Are you sure you want to continue? (Yes, No)[Yes]: >> >> > Configuration files: [] >> >> > Log file: >> >> > >> >> > >> >> > /var/log/ovirt-hosted-engine-setup/ovirt-hosted-engine-setup-20160305194655-o29y86.log >> >> > Version: otopi-1.4.1 (otopi-1.4.1-1.el7.centos) >> >> > [ INFO ] Hardware supports virtualization >> >> > [ INFO ] Stage: Environment packages setup >> >> > [ INFO ] Stage: Programs detection >> >> > [ INFO ] Stage: Environment setup >> >> > [ ERROR ] Failed to execute stage 'Environment setup': Failed to >> >> > start >> >> > service 'vdsmd' >> >> > [ INFO ] Stage: Clean up >> >> > [ INFO ] Generating answer file >> >> > >> >> > '/var/lib/ovirt-hosted-engine-setup/answers/answers-20160305194703.conf' >> >> > [ INFO ] Stage: Pre-termination >> >> > [ INFO ] Stage: Termination >> >> > [ ERROR ] Hosted Engine deployment failed: this system is not >> >> > reliable, >> >> > please check the issue, fix and redeploy >> >> > Log file is located at >> >> > >> >> > >> >> > /var/log/ovirt-hosted-engine-setup/ovirt-hosted-engine-setup-20160305194655-o29y86.log >> >> > >> >> > -- >> >> > vdsm-tool restore-nets output: >> >> > >> >> > [root@ovirt01 etc]# /usr/bin/vdsm-tool restore-nets >> >> > Traceback (most recent call last): >> >> > File "/usr/share/vdsm/vdsm-restore-net-config", line 429, in >> >> > <module> >> >> > restore(args) >> >> > File "/usr/share/vdsm/vdsm-restore-net-config", line 387, in >> >> > restore >> >> > _restore_sriov_numvfs() >> >> > File "/usr/share/vdsm/vdsm-restore-net-config", line 82, in >> >> > _restore_sriov_numvfs >> >> > sriov_devices = _get_sriov_devices() >> >> > File "/usr/share/vdsm/vdsm-restore-net-config", line 54, in >> >> > _get_sriov_devices >> >> > devices = hostdev.list_by_caps() >> >> > File "/usr/share/vdsm/hostdev.py", line 175, in list_by_caps >> >> > libvirt_devices = _get_devices_from_libvirt() >> >> > File "/usr/share/vdsm/hostdev.py", line 160, in >> >> > _get_devices_from_libvirt >> >> > for device in libvirtconnection.get().listAllDevices(0)) >> >> > File "/usr/share/vdsm/hostdev.py", line 160, in <genexpr> >> >> > for device in libvirtconnection.get().listAllDevices(0)) >> >> > File "/usr/share/vdsm/hostdev.py", line 107, in >> >> > _parse_device_params >> >> > devXML = etree.fromstring(device_xml) >> >> > File "/usr/lib64/python2.7/xml/etree/ElementTree.py", line 1300, in >> >> > XML >> >> > parser.feed(text) >> >> > File "/usr/lib64/python2.7/xml/etree/ElementTree.py", line 1642, in >> >> > feed >> >> > self._raiseerror(v) >> >> > File "/usr/lib64/python2.7/xml/etree/ElementTree.py", line 1506, in >> >> > _raiseerror >> >> > raise err >> >> > xml.etree.ElementTree.ParseError: not well-formed (invalid token): >> >> > line >> >> > 4, >> >> > column 13 >> >> > Traceback (most recent call last): >> >> > File "/usr/bin/vdsm-tool", line 219, in main >> >> > return tool_command[cmd]["command"](*args) >> >> > File "/usr/lib/python2.7/site-packages/vdsm/tool/restore_nets.py", >> >> > line >> >> > 41, in restore_command >> >> > exec_restore(cmd) >> >> > File "/usr/lib/python2.7/site-packages/vdsm/tool/restore_nets.py", >> >> > line >> >> > 54, in exec_restore >> >> > raise EnvironmentError('Failed to restore the persisted >> >> > networks') >> >> > EnvironmentError: Failed to restore the persisted networks >> >> >> >> Please check/post full ovirt-hosted-engine-setup logs, vdsm logs. >> >> >> >> Do you have NetworkManager? >> >> >> >> Thanks for the report! >> >> >> >> Best, >> >> -- >> >> Didi >> > >> > >> >> >> >> -- >> Didi > > -- Didi

4 6