[ovirt-users] Error while executing action New SAN Storage Domain: Cannot zero out volume
Every time I try to create a Data / iSCSI Storage Domain, I receive an "Error while executing action New SAN Storage Domain: Cannot zero out volume" error. iscsid does login to the node, and the volumes appear to have been created. However, I cannot use it to create or import a Data / iSCSI storage domain. [root@lnx84 ~]# iscsiadm -m node #.#.#.#:3260,1 iqn.2015-10.N.N.N.lnx88:lnx88.target1 [root@lnx84 ~]# iscsiadm -m session tcp: [1] #.#.#.#:3260,1 iqn.2015-10.N.N.N.lnx88:lnx88.target1 (non-flash) [root@lnx84 ~]# pvscan PV /dev/mapper/1IET_00010001 VG f73c8720-77c3-42a6-8a29-9677db54bac6 lvm2 [547.62 GiB / 543.75 GiB free] ... [root@lnx84 ~]# lvscan inactive '/dev/f73c8720-77c3-42a6-8a29-9677db54bac6/metadata' [512.00 MiB] inherit inactive '/dev/f73c8720-77c3-42a6-8a29-9677db54bac6/outbox' [128.00 MiB] inherit inactive '/dev/f73c8720-77c3-42a6-8a29-9677db54bac6/leases' [2.00 GiB] inherit inactive '/dev/f73c8720-77c3-42a6-8a29-9677db54bac6/ids' [128.00 MiB] inherit inactive '/dev/f73c8720-77c3-42a6-8a29-9677db54bac6/inbox' [128.00 MiB] inherit inactive '/dev/f73c8720-77c3-42a6-8a29-9677db54bac6/master' [1.00 GiB] inherit ... Any help would be greatly appreciated. Many thanks, Devin Here are the relevant lines from engine.log: -- 2015-10-23 16:04:56,925 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.GetDeviceListVDSCommand] (ajp--127.0.0.1-8702-8) START, GetDeviceListVDSCommand(HostName = lnx84, HostId = a650e161-75f6-4916-bc18-96044bf3fc26, storageType=ISCSI), log id: 44a64578 2015-10-23 16:04:57,681 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.GetDeviceListVDSCommand] (ajp--127.0.0.1-8702-8) FINISH, GetDeviceListVDSCommand, return: [LUNs [id=1IET_00010001, physicalVolumeId=wpmBIM-tgc1-yKtH-XSwc-40wZ-Kn49-btwBFn, volumeGroupId=8gZEwa-3x5m-TiqA-uEPX-gC04-wkzx-PlaQDu, serial=SIET_VIRTUAL-DISK, lunMapping=1, vendorId=IET, productId=VIRTUAL-DISK, _lunConnections=[{ id: null, connection: #.#.#.#, iqn: iqn.2015-10.N.N.N.lnx88:lnx88.target1, vfsType: null, mountOptions: null, nfsVersion: null, nfsRetrans: null, nfsTimeo: null };], deviceSize=547, vendorName=IET, pathsDictionary={sdi=true}, lunType=ISCSI, status=Used, diskId=null, diskAlias=null, storageDomainId=null, storageDomainName=null]], log id: 44a64578 2015-10-23 16:05:06,474 INFO [org.ovirt.engine.core.bll.storage.AddSANStorageDomainCommand] (ajp--127.0.0.1-8702-8) [53dd8c98] Running command: AddSANStorageDomainCommand internal: false. Entities affected : ID: aaa0----123456789aaa Type: SystemAction group CREATE_STORAGE_DOMAIN with role type ADMIN 2015-10-23 16:05:06,488 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.CreateVGVDSCommand] (ajp--127.0.0.1-8702-8) [53dd8c98] START, CreateVGVDSCommand(HostName = lnx84, HostId = a650e161-75f6-4916-bc18-96044bf3fc26, storageDomainId=cb5b0e2e-d68d-462a-b8fa-8894a6e0ed19, deviceList=[1IET_00010001], force=true), log id: 12acc23b 2015-10-23 16:05:07,379 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.CreateVGVDSCommand] (ajp--127.0.0.1-8702-8) [53dd8c98] FINISH, CreateVGVDSCommand, return: dDaCCO-PLDu-S2nz-yOjM-qpOW-PGaa-ecpJ8P, log id: 12acc23b 2015-10-23 16:05:07,384 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.CreateStorageDomainVDSCommand] (ajp--127.0.0.1-8702-8) [53dd8c98] START, CreateStorageDomainVDSCommand(HostName = lnx84, HostId = a650e161-75f6-4916-bc18-96044bf3fc26, storageDomain=StorageDomainStatic[lnx88, cb5b0e2e-d68d-462a-b8fa-8894a6e0ed19], args=dDaCCO-PLDu-S2nz-yOjM-qpOW-PGaa-ecpJ8P), log id: cc93ec6 2015-10-23 16:05:10,356 ERROR [org.ovirt.engine.core.vdsbroker.vdsbroker.CreateStorageDomainVDSCommand] (ajp--127.0.0.1-8702-8) [53dd8c98] Failed in CreateStorageDomainVDS method 2015-10-23 16:05:10,360 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.CreateStorageDomainVDSCommand] (ajp--127.0.0.1-8702-8) [53dd8c98] Command org.ovirt.engine.core.vdsbroker.vdsbroker.CreateStorageDomainVDSCommand return value StatusOnlyReturnForXmlRpc [mStatus=StatusForXmlRpc [mCode=374, mMessage=Cannot zero out volume: ('/dev/cb5b0e2e-d68d-462a-b8fa-8894a6e0ed19/metadata',)]] 2015-10-23 16:05:10,367 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.CreateStorageDomainVDSCommand] (ajp--127.0.0.1-8702-8) [53dd8c98] HostName = lnx84 2015-10-23 16:05:10,370 ERROR [org.ovirt.engine.core.vdsbroker.vdsbroker.CreateStorageDomainVDSCommand] (ajp--127.0.0.1-8702-8) [53dd8c98] Command CreateStorageDomainVDSCommand(HostName = lnx84, HostId = a650e161-75f6-4916-bc18-96044bf3fc26, storageDomain=StorageDomainStatic[lnx88, cb5b0e2e-d68d-462a-b8fa-8894a6e0ed19], args=dDaCCO-PLDu-S2nz-yOjM-qpOW-PGaa-ecpJ8P) execution failed. Exception: VDSErrorException: VDSGenericException: VDSErrorException: Failed to CreateStorageDomainVDS, error = Cannot zero out volume: ('/dev/cb5b0e2e-d68d-462a-b8fa-8894a6e0ed19/metadata',), code = 374 2015-10-23 16:05:10,381 INFO [org.ovirt.e
Re: [ovirt-users] Testing self hosted engine in 3.6: hostname not resolved error
On Fri, Oct 23, 2015 at 6:10 PM, Simone Tiraboschi wrote: > > >> >> Probably inside the [unit] section I should add >> After=nfs-server.service >> >> > Ok, I understood. > You are right: the broker was failing cause the NFS storage was not ready > cause it was served in loopback and there isn't any explicit service > dependency on that. > > We are not imposing it cause generally an NFS shared domain is generally > thought to be served from and external system while a loopback NFS is just > a degenerate case. > Simply fix it manually. > > OK, understod. Done and the fix works as expected. > it should be: > remote-viewer --spice-ca-file=/etc/pki/vdsm/libvirt-spice/ca-cert.pem > spice://ovc71.localdomain.local?tls-port=5900 --spice-host-subject="C=US, > O=localdomain.local, CN=ovc71.localdomain.local" > > > same error... [root@ovc71 ~]# remote-viewer --spice-ca-file=/etc/pki/vdsm/libvirt-spice/ca-cert.pem spice://ovc71.localdomain.local?tls-port=5900 --spice-host-subject="C=US, O=localdomain.local, CN=ovc71.localdomain.local" ** (remote-viewer:4788): WARNING **: Couldn't connect to accessibility bus: Failed to connect to socket /tmp/dbus-Gb5xXSKiKK: Connection refused GLib-GIO-Message: Using the 'memory' GSettings backend. Your settings will not be saved or shared with other applications. (/usr/bin/remote-viewer:4788): Spice-Warning **: ssl_verify.c:492:openssl_verify: ssl: subject 'C=US, O=localdomain.local, CN=ovc71.localdomain.local' verification failed (/usr/bin/remote-viewer:4788): Spice-Warning **: ssl_verify.c:494:openssl_verify: ssl: verification failed (remote-viewer:4788): GSpice-WARNING **: main-1:0: SSL_connect: error:0001:lib(0):func(0):reason(1) even if I copy the /etc/pki/vdsm/libvirt-spice/ca-cert.pem from hypervisor to my pc in /tmp and run: [g.cecchi@ope46 ~]$ remote-viewer --spice-ca-file=/tmp/ca-cert.pem spice://ovc71.localdomain.local?tls-port=5900 --spice-host-subject="C=US, O=localdomain.local, CN=ovc71.localdomain.local"(/usr/bin/remote-viewer:8915): Spice-Warning **: ssl_verify.c:493:openssl_verify: ssl: subject 'C=US, O=localdomain.local, CN=ovc71.localdomain.local' verification failed (/usr/bin/remote-viewer:8915): Spice-Warning **: ssl_verify.c:495:openssl_verify: ssl: verification failed (remote-viewer:8915): GSpice-WARNING **: main-1:0: SSL_connect: error:0001:lib(0):func(0):reason(1) ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [ovirt-users] Testing self hosted engine in 3.6: hostname not resolved error
On Fri, Oct 23, 2015 at 5:55 PM, Gianluca Cecchi wrote: > On Fri, Oct 23, 2015 at 5:05 PM, Simone Tiraboschi > wrote: > >> >>> >> OK, can you please try again the whole reboot procedure just to ensure >> that it was just a temporary NFS glitch? >> > > > It seems reproducible. > > This time I was able to shutdown the hypervisor without manual power off. > Only strange thing is that I ran > > shutdown -h now > > and actually the VM at some point (I was able to see that the watchdog > stopped...) booted ? > > Related lines in messages: > Oct 23 17:33:32 ovc71 systemd: Unmounting RPC Pipe File System... > Oct 23 17:33:32 ovc71 systemd: Stopping Session 11 of user root. > Oct 23 17:33:33 ovc71 systemd: Stopped Session 11 of user root. > Oct 23 17:33:33 ovc71 systemd: Stopping user-0.slice. > Oct 23 17:33:33 ovc71 systemd: Removed slice user-0.slice. > Oct 23 17:33:33 ovc71 systemd: Stopping vdsm-dhclient.slice. > Oct 23 17:33:33 ovc71 systemd: Removed slice vdsm-dhclient.slice. > Oct 23 17:33:33 ovc71 systemd: Stopping vdsm.slice. > Oct 23 17:33:33 ovc71 systemd: Removed slice vdsm.slice. > Oct 23 17:33:33 ovc71 systemd: Stopping Sound Card. > Oct 23 17:33:33 ovc71 systemd: Stopped target Sound Card. > Oct 23 17:33:33 ovc71 systemd: Stopping LVM2 PV scan on device 8:2... > Oct 23 17:33:33 ovc71 systemd: Stopping LVM2 PV scan on device 8:16... > Oct 23 17:33:33 ovc71 systemd: Stopping Dump dmesg to /var/log/dmesg... > Oct 23 17:33:33 ovc71 systemd: Stopped Dump dmesg to /var/log/dmesg. > Oct 23 17:33:33 ovc71 systemd: Stopping Watchdog Multiplexing Daemon... > Oct 23 17:33:33 ovc71 systemd: Stopping Multi-User System. > Oct 23 17:33:33 ovc71 systemd: Stopped target Multi-User System. > Oct 23 17:33:33 ovc71 systemd: Stopping ABRT kernel log watcher... > Oct 23 17:33:33 ovc71 systemd: Stopping Command Scheduler... > Oct 23 17:33:33 ovc71 rsyslogd: [origin software="rsyslogd" > swVersion="7.4.7" x-pid="690" x-info="http://www.rsyslog.com";] exiting on > signal 15. > Oct 23 17:36:24 ovc71 rsyslogd: [origin software="rsyslogd" > swVersion="7.4.7" x-pid="697" x-info="http://www.rsyslog.com";] start > Oct 23 17:36:21 ovc71 journal: Runtime journal is using 8.0M (max 500.0M, > leaving 750.0M of free 4.8G, current limit 500.0M). > Oct 23 17:36:21 ovc71 kernel: Initializing cgroup subsys cpuset > > > Coming back with the ovrt processes I see: > > [root@ovc71 ~]# systemctl status ovirt-ha-broker > ovirt-ha-broker.service - oVirt Hosted Engine High Availability > Communications Broker >Loaded: loaded (/usr/lib/systemd/system/ovirt-ha-broker.service; > enabled) >Active: inactive (dead) since Fri 2015-10-23 17:36:25 CEST; 31s ago > Process: 849 ExecStop=/usr/lib/systemd/systemd-ovirt-ha-broker stop > (code=exited, status=0/SUCCESS) > Process: 723 ExecStart=/usr/lib/systemd/systemd-ovirt-ha-broker start > (code=exited, status=0/SUCCESS) > Main PID: 844 (code=exited, status=0/SUCCESS) >CGroup: /system.slice/ovirt-ha-broker.service > > Oct 23 17:36:24 ovc71.localdomain.local systemd-ovirt-ha-broker[723]: > Starting ovirt-ha-broker: [... > Oct 23 17:36:24 ovc71.localdomain.local systemd[1]: Started oVirt Hosted > Engine High Availabili...r. > Oct 23 17:36:25 ovc71.localdomain.local systemd-ovirt-ha-broker[849]: > Stopping ovirt-ha-broker: [... > Hint: Some lines were ellipsized, use -l to show in full. > > ANd > [root@ovc71 ~]# systemctl status nfs-server > nfs-server.service - NFS server and services >Loaded: loaded (/usr/lib/systemd/system/nfs-server.service; enabled) >Active: active (exited) since Fri 2015-10-23 17:36:27 CEST; 1min 9s ago > Process: 1123 ExecStart=/usr/sbin/rpc.nfsd $RPCNFSDARGS (code=exited, > status=0/SUCCESS) > Process: 1113 ExecStartPre=/usr/sbin/exportfs -r (code=exited, > status=0/SUCCESS) > Main PID: 1123 (code=exited, status=0/SUCCESS) >CGroup: /system.slice/nfs-server.service > > Oct 23 17:36:27 ovc71.localdomain.local systemd[1]: Starting NFS server > and services... > Oct 23 17:36:27 ovc71.localdomain.local systemd[1]: Started NFS server and > services. > > So it seems that the broker tries to start and fails (17:36:25) before NFS > server start phase completes (17:36:27)...? > > Again if I then manually start ha-broker and ha-agent, they start ok and > I'm able to become operational again with the sh engine up > > systemd file for broker is this > > [Unit] > Description=oVirt Hosted Engine High Availability Communications Broker > > [Service] > Type=forking > EnvironmentFile=-/etc/sysconfig/ovirt-ha-broker > ExecStart=/usr/lib/systemd/systemd-ovirt-ha-broker start > ExecStop=/usr/lib/systemd/systemd-ovirt-ha-broker stop > > [Install] > WantedBy=multi-user.target > > Probably inside the [unit] section I should add > After=nfs-server.service > > Ok, I understood. You are right: the broker was failing cause the NFS storage was not ready cause it was served in loopback and there isn't any explicit service dependency on that. We are not imposing it cause genera
Re: [ovirt-users] Testing self hosted engine in 3.6: hostname not resolved error
On Fri, Oct 23, 2015 at 5:05 PM, Simone Tiraboschi wrote: > >> > OK, can you please try again the whole reboot procedure just to ensure > that it was just a temporary NFS glitch? > It seems reproducible. This time I was able to shutdown the hypervisor without manual power off. Only strange thing is that I ran shutdown -h now and actually the VM at some point (I was able to see that the watchdog stopped...) booted ? Related lines in messages: Oct 23 17:33:32 ovc71 systemd: Unmounting RPC Pipe File System... Oct 23 17:33:32 ovc71 systemd: Stopping Session 11 of user root. Oct 23 17:33:33 ovc71 systemd: Stopped Session 11 of user root. Oct 23 17:33:33 ovc71 systemd: Stopping user-0.slice. Oct 23 17:33:33 ovc71 systemd: Removed slice user-0.slice. Oct 23 17:33:33 ovc71 systemd: Stopping vdsm-dhclient.slice. Oct 23 17:33:33 ovc71 systemd: Removed slice vdsm-dhclient.slice. Oct 23 17:33:33 ovc71 systemd: Stopping vdsm.slice. Oct 23 17:33:33 ovc71 systemd: Removed slice vdsm.slice. Oct 23 17:33:33 ovc71 systemd: Stopping Sound Card. Oct 23 17:33:33 ovc71 systemd: Stopped target Sound Card. Oct 23 17:33:33 ovc71 systemd: Stopping LVM2 PV scan on device 8:2... Oct 23 17:33:33 ovc71 systemd: Stopping LVM2 PV scan on device 8:16... Oct 23 17:33:33 ovc71 systemd: Stopping Dump dmesg to /var/log/dmesg... Oct 23 17:33:33 ovc71 systemd: Stopped Dump dmesg to /var/log/dmesg. Oct 23 17:33:33 ovc71 systemd: Stopping Watchdog Multiplexing Daemon... Oct 23 17:33:33 ovc71 systemd: Stopping Multi-User System. Oct 23 17:33:33 ovc71 systemd: Stopped target Multi-User System. Oct 23 17:33:33 ovc71 systemd: Stopping ABRT kernel log watcher... Oct 23 17:33:33 ovc71 systemd: Stopping Command Scheduler... Oct 23 17:33:33 ovc71 rsyslogd: [origin software="rsyslogd" swVersion="7.4.7" x-pid="690" x-info="http://www.rsyslog.com";] exiting on signal 15. Oct 23 17:36:24 ovc71 rsyslogd: [origin software="rsyslogd" swVersion="7.4.7" x-pid="697" x-info="http://www.rsyslog.com";] start Oct 23 17:36:21 ovc71 journal: Runtime journal is using 8.0M (max 500.0M, leaving 750.0M of free 4.8G, current limit 500.0M). Oct 23 17:36:21 ovc71 kernel: Initializing cgroup subsys cpuset Coming back with the ovrt processes I see: [root@ovc71 ~]# systemctl status ovirt-ha-broker ovirt-ha-broker.service - oVirt Hosted Engine High Availability Communications Broker Loaded: loaded (/usr/lib/systemd/system/ovirt-ha-broker.service; enabled) Active: inactive (dead) since Fri 2015-10-23 17:36:25 CEST; 31s ago Process: 849 ExecStop=/usr/lib/systemd/systemd-ovirt-ha-broker stop (code=exited, status=0/SUCCESS) Process: 723 ExecStart=/usr/lib/systemd/systemd-ovirt-ha-broker start (code=exited, status=0/SUCCESS) Main PID: 844 (code=exited, status=0/SUCCESS) CGroup: /system.slice/ovirt-ha-broker.service Oct 23 17:36:24 ovc71.localdomain.local systemd-ovirt-ha-broker[723]: Starting ovirt-ha-broker: [... Oct 23 17:36:24 ovc71.localdomain.local systemd[1]: Started oVirt Hosted Engine High Availabili...r. Oct 23 17:36:25 ovc71.localdomain.local systemd-ovirt-ha-broker[849]: Stopping ovirt-ha-broker: [... Hint: Some lines were ellipsized, use -l to show in full. ANd [root@ovc71 ~]# systemctl status nfs-server nfs-server.service - NFS server and services Loaded: loaded (/usr/lib/systemd/system/nfs-server.service; enabled) Active: active (exited) since Fri 2015-10-23 17:36:27 CEST; 1min 9s ago Process: 1123 ExecStart=/usr/sbin/rpc.nfsd $RPCNFSDARGS (code=exited, status=0/SUCCESS) Process: 1113 ExecStartPre=/usr/sbin/exportfs -r (code=exited, status=0/SUCCESS) Main PID: 1123 (code=exited, status=0/SUCCESS) CGroup: /system.slice/nfs-server.service Oct 23 17:36:27 ovc71.localdomain.local systemd[1]: Starting NFS server and services... Oct 23 17:36:27 ovc71.localdomain.local systemd[1]: Started NFS server and services. So it seems that the broker tries to start and fails (17:36:25) before NFS server start phase completes (17:36:27)...? Again if I then manually start ha-broker and ha-agent, they start ok and I'm able to become operational again with the sh engine up systemd file for broker is this [Unit] Description=oVirt Hosted Engine High Availability Communications Broker [Service] Type=forking EnvironmentFile=-/etc/sysconfig/ovirt-ha-broker ExecStart=/usr/lib/systemd/systemd-ovirt-ha-broker start ExecStop=/usr/lib/systemd/systemd-ovirt-ha-broker stop [Install] WantedBy=multi-user.target Probably inside the [unit] section I should add After=nfs-server.service but this should be true only for sh engine configured with NFS so to be done at install/setup time? If you want I can set this change for my environment and verify... > > The issue was here: --spice-host-subject="C=EN, L=Test, O=Test, CN=Test" > This one was just the temporary subject used by hosted-engine-setup during > the bootstrap sequence when your engine was still to come. > At the end that cert got replace by the engine CA signed ones and so you > have to sub
Re: [ovirt-users] Testing self hosted engine in 3.6: hostname not resolved error
On Fri, Oct 23, 2015 at 4:56 PM, Gianluca Cecchi wrote: > On Fri, Oct 23, 2015 at 4:42 PM, Simone Tiraboschi > wrote: > >> >> >> >> Are ovirt-ha-agent and ovirt-ha-broker up and running? >> Can you please try to restart them via systemd? >> >> >> In the mean time I found inside the logs they failed to start. > > I found in broker log the message > Thread-1730::ERROR::2015-10-22 > 17:31:47,016::listener::192::ovirt_hosted_engine_ha.broker.listener.ConnectionHandler::(handle) > Error handling request, data: 'set-storage-domain FilesystemBackend > dom_type=nfs3 sd_uuid=f53854cd-8767-4011-9564-36dc36e0a5d1' > Traceback (most recent call last): > ... > BackendFailureException: path to storage domain > f53854cd-8767-4011-9564-36dc36e0a5d1 not found in /rhev/data-center/mnt > > so probably the NFS part was not in lace yet when the broker attempted to > start? > I saw that actually I had now > > [root@ovc71 ovirt-hosted-engine-ha]# ll > /rhev/data-center/mnt/ovc71.localdomain.local:_NFS__DOMAIN > total 0 > -rwxr-xr-x. 1 vdsm kvm 0 Oct 23 16:46 __DIRECT_IO_TEST__ > drwxr-xr-x. 5 vdsm kvm 47 Oct 22 15:49 f53854cd-8767-4011-9564-36dc36e0a5d1 > > and I was able to run > > systemctl start ovirt-ha-broker.service > and verify it correctly started. > and the same for > systemctl start ovirt-ha-agent > > after a couple of minutes the sh engine VM was powered on and I was able > to access web admin portal. > > OK, can you please try again the whole reboot procedure just to ensure that it was just a temporary NFS glitch? > But if I try to connect to its console with > > [root@ovc71 ovirt-hosted-engine-ha]# hosted-engine --add-console-password > Enter password: > code = 0 > message = 'Done' > > and then > # remote-viewer --spice-ca-file=/etc/pki/vdsm/libvirt-spice/ca-cert.pem > spice://localhost?tls-port=5900 --spice-host-subject="C=EN, L=Test, O=Test, > CN=Test" > > ** (remote-viewer:7173): WARNING **: Couldn't connect to accessibility > bus: Failed to connect to socket /tmp/dbus-Gb5xXSKiKK: Connection refused > GLib-GIO-Message: Using the 'memory' GSettings backend. Your settings > will not be saved or shared with other applications. > (/usr/bin/remote-viewer:7173): Spice-Warning **: > ssl_verify.c:492:openssl_verify: ssl: subject 'C=EN, L=Test, O=Test, > CN=Test' verification failed > (/usr/bin/remote-viewer:7173): Spice-Warning **: > ssl_verify.c:494:openssl_verify: ssl: verification failed > > The issue was here: --spice-host-subject="C=EN, L=Test, O=Test, CN=Test" This one was just the temporary subject used by hosted-engine-setup during the bootstrap sequence when your engine was still to come. At the end that cert got replace by the engine CA signed ones and so you have to substitute that subject to match the one you used during your setup. > (remote-viewer:7173): GSpice-WARNING **: main-1:0: SSL_connect: > error:0001:lib(0):func(0):reason(1) > > I get an error window with > Unable to connect to the graphic server spice://localhost?tls-port=5900 > > [root@ovc71 ovirt-hosted-engine-ha]# netstat -tan | grep 5900 > tcp0 0 0.0.0.0:59000.0.0.0:* LISTEN > > > the qemu command line of the sh engine is: > qemu 4489 1 23 16:41 ?00:02:35 /usr/libexec/qemu-kvm > -name HostedEngine -S -machine pc-i440fx-rhel7.2.0,accel=kvm,usb=off -cpu > Nehalem -m 8192 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 > -uuid 9e654c4a-925c-48ba-9818-6908b7714d3a -smbios > type=1,manufacturer=oVirt,product=oVirt > Node,version=7-1.1503.el7.centos.2.8,serial=97F39B57-FA7D-2A47-9E0E-304705DE227D,uuid=9e654c4a-925c-48ba-9818-6908b7714d3a > -no-user-config -nodefaults -chardev > socket,id=charmonitor,path=/var/lib/libvirt/qemu/HostedEngine.monitor,server,nowait > -mon chardev=charmonitor,id=monitor,mode=control -rtc > base=2015-10-23T14:41:23,driftfix=slew -global > kvm-pit.lost_tick_policy=discard -no-hpet -no-reboot -boot strict=on > -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device > virtio-scsi-pci,id=scsi0,bus=pci.0,addr=0x4 -device > virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 -drive > if=none,id=drive-ide0-1-0,readonly=on,format=raw,serial= -device > ide-cd,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -drive > file=/var/run/vdsm/storage/f53854cd-8767-4011-9564-36dc36e0a5d1/45ae3a4a-2190-4494-9419-b7c2af8a7aef/52b97c5b-96ae-4efc-b2e0-f56cde243384,if=none,id=drive-virtio-disk0,format=raw,serial=45ae3a4a-2190-4494-9419-b7c2af8a7aef,cache=none,werror=stop,rerror=stop,aio=threads > -device > virtio-blk-pci,scsi=off,bus=pci.0,addr=0x6,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 > -netdev tap,fd=26,id=hostnet0,vhost=on,vhostfd=27 -device > virtio-net-pci,netdev=hostnet0,id=net0,mac=00:16:3e:16:6a:b6,bus=pci.0,addr=0x3 > -chardev > socket,id=charchannel0,path=/var/lib/libvirt/qemu/channels/9e654c4a-925c-48ba-9818-6908b7714d3a.com.redhat.rhevm.vdsm,server,nowait > -device > virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=chan
Re: [ovirt-users] Testing self hosted engine in 3.6: hostname not resolved error
On Fri, Oct 23, 2015 at 4:42 PM, Simone Tiraboschi wrote: > > > > Are ovirt-ha-agent and ovirt-ha-broker up and running? > Can you please try to restart them via systemd? > > > In the mean time I found inside the logs they failed to start. I found in broker log the message Thread-1730::ERROR::2015-10-22 17:31:47,016::listener::192::ovirt_hosted_engine_ha.broker.listener.ConnectionHandler::(handle) Error handling request, data: 'set-storage-domain FilesystemBackend dom_type=nfs3 sd_uuid=f53854cd-8767-4011-9564-36dc36e0a5d1' Traceback (most recent call last): ... BackendFailureException: path to storage domain f53854cd-8767-4011-9564-36dc36e0a5d1 not found in /rhev/data-center/mnt so probably the NFS part was not in lace yet when the broker attempted to start? I saw that actually I had now [root@ovc71 ovirt-hosted-engine-ha]# ll /rhev/data-center/mnt/ovc71.localdomain.local:_NFS__DOMAIN total 0 -rwxr-xr-x. 1 vdsm kvm 0 Oct 23 16:46 __DIRECT_IO_TEST__ drwxr-xr-x. 5 vdsm kvm 47 Oct 22 15:49 f53854cd-8767-4011-9564-36dc36e0a5d1 and I was able to run systemctl start ovirt-ha-broker.service and verify it correctly started. and the same for systemctl start ovirt-ha-agent after a couple of minutes the sh engine VM was powered on and I was able to access web admin portal. But if I try to connect to its console with [root@ovc71 ovirt-hosted-engine-ha]# hosted-engine --add-console-password Enter password: code = 0 message = 'Done' and then # remote-viewer --spice-ca-file=/etc/pki/vdsm/libvirt-spice/ca-cert.pem spice://localhost?tls-port=5900 --spice-host-subject="C=EN, L=Test, O=Test, CN=Test" ** (remote-viewer:7173): WARNING **: Couldn't connect to accessibility bus: Failed to connect to socket /tmp/dbus-Gb5xXSKiKK: Connection refused GLib-GIO-Message: Using the 'memory' GSettings backend. Your settings will not be saved or shared with other applications. (/usr/bin/remote-viewer:7173): Spice-Warning **: ssl_verify.c:492:openssl_verify: ssl: subject 'C=EN, L=Test, O=Test, CN=Test' verification failed (/usr/bin/remote-viewer:7173): Spice-Warning **: ssl_verify.c:494:openssl_verify: ssl: verification failed (remote-viewer:7173): GSpice-WARNING **: main-1:0: SSL_connect: error:0001:lib(0):func(0):reason(1) I get an error window with Unable to connect to the graphic server spice://localhost?tls-port=5900 [root@ovc71 ovirt-hosted-engine-ha]# netstat -tan | grep 5900 tcp0 0 0.0.0.0:59000.0.0.0:* LISTEN the qemu command line of the sh engine is: qemu 4489 1 23 16:41 ?00:02:35 /usr/libexec/qemu-kvm -name HostedEngine -S -machine pc-i440fx-rhel7.2.0,accel=kvm,usb=off -cpu Nehalem -m 8192 -realtime mlock=off -smp 1,sockets=1,cores=1,threads=1 -uuid 9e654c4a-925c-48ba-9818-6908b7714d3a -smbios type=1,manufacturer=oVirt,product=oVirt Node,version=7-1.1503.el7.centos.2.8,serial=97F39B57-FA7D-2A47-9E0E-304705DE227D,uuid=9e654c4a-925c-48ba-9818-6908b7714d3a -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/HostedEngine.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=2015-10-23T14:41:23,driftfix=slew -global kvm-pit.lost_tick_policy=discard -no-hpet -no-reboot -boot strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device virtio-scsi-pci,id=scsi0,bus=pci.0,addr=0x4 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 -drive if=none,id=drive-ide0-1-0,readonly=on,format=raw,serial= -device ide-cd,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -drive file=/var/run/vdsm/storage/f53854cd-8767-4011-9564-36dc36e0a5d1/45ae3a4a-2190-4494-9419-b7c2af8a7aef/52b97c5b-96ae-4efc-b2e0-f56cde243384,if=none,id=drive-virtio-disk0,format=raw,serial=45ae3a4a-2190-4494-9419-b7c2af8a7aef,cache=none,werror=stop,rerror=stop,aio=threads -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x6,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -netdev tap,fd=26,id=hostnet0,vhost=on,vhostfd=27 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=00:16:3e:16:6a:b6,bus=pci.0,addr=0x3 -chardev socket,id=charchannel0,path=/var/lib/libvirt/qemu/channels/9e654c4a-925c-48ba-9818-6908b7714d3a.com.redhat.rhevm.vdsm,server,nowait -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.rhevm.vdsm -chardev socket,id=charchannel1,path=/var/lib/libvirt/qemu/channels/9e654c4a-925c-48ba-9818-6908b7714d3a.org.qemu.guest_agent.0,server,nowait -device virtserialport,bus=virtio-serial0.0,nr=2,chardev=charchannel1,id=channel1,name=org.qemu.guest_agent.0 -chardev spicevmc,id=charchannel2,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=3,chardev=charchannel2,id=channel2,name=com.redhat.spice.0 -chardev socket,id=charchannel3,path=/var/lib/libvirt/qemu/channels/9e654c4a-925c-48ba-9818-6908b7714d3a.org.ovirt.hosted-engine-setup.0,server,nowait -device virtserialport,bus=virtio-serial0.0,nr=4,chardev=charchannel3,id=channel3,name=org.ovirt.hosted-engine-setup.0 -char
Re: [ovirt-users] Issue with kernel 2.6.32-573.3.1.el6.x86_64?
Not an option unfortunately. The system is a production one and we don't have spare equipment to test that on. On Fri, Oct 23, 2015, 12:47 AM Giorgio Bersano wrote: > Hi Michael, > if you have the possibility to test with > kernel-2.6.32-504.16.2.el6.x86_64 and > kernel-2.6.32-504.23.4.el6.x86_64 please do it. > > I'm expecting that 2.6.32-504.16.2.el6 is the latest correctly working > kernel. Please tell us if this is your case. > There are clear signs of misbehaviours due to changes in the VLAN code > between the two kernels above. > > Also take a look at https://bugs.centos.org/view.php?id=9467 and > https://bugzilla.redhat.com/show_bug.cgi?id=1263561 . > > Best regards, > Giorgio. > > P.S. sorry for top posting. I tried to revert this thread but I > couldn't do it in an effective way :( > > > > 2015-10-21 23:05 GMT+02:00 Michael Kleinpaste > : > > VMs are on different VLANs and use a central Vyos VM as the firewall and > > default gateway. The only indication I had that the packets were getting > > dropped or being sent out of order was by tshark'ing the traffic. Tons > and > > tons of resends. > > > > The problem was definitely resolved after I dropped back to the prior > kernel > > (2.6.32-504.12.2.el6.x86_64). > > > > > > On Tue, Oct 20, 2015 at 11:51 PM Ido Barkan wrote: > >> > >> Hi Michael, > >> Can you describe your network architecture for this vm (inside the > host). > >> Do you know where are the packets get dropped? > >> Ido > >> > >> On Tue, Sep 22, 2015 at 1:19 AM, Michael Kleinpaste > >> wrote: > >> > Nobody's seen this? > >> > > >> > On Wed, Sep 16, 2015 at 9:08 AM Michael Kleinpaste > >> > wrote: > >> >> > >> >> So I patched my vhosts and updated the kernel to > >> >> 2.6.32-573.3.1.el6.x86_64. Afterwards the networking became unstable > >> >> for my > >> >> vyatta firewall vm. Lots of packet loss and out of order packets > >> >> (based on > >> >> my tshark at the time). > >> >> > >> >> Has anybody else experienced this? > >> >> -- > >> >> Michael Kleinpaste > -- *Michael Kleinpaste* Senior Systems Administrator SharperLending, LLC. www.SharperLending.com michael.kleinpa...@sharperlending.com (509) 324-1230 Fax: (509) 324-1234 ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [ovirt-users] schedule a VM backup in ovirt 3.5
Using ovirt-node EL7 we’ve been able to live merge since 3.5.3 without any issues. -Patrick > On Oct 23, 2015, at 12:24 AM, Christopher Cox wrote: > > On 10/22/2015 10:46 PM, Indunil Jayasooriya wrote: > ... >> >> Hmm, >> >> *How to list the sanphot? >> * >> *how to backup the VM with snapshot? >> * >> *finally , how to remove this snapshot? >> * >> >> >> Then. I think it will be OVER. Yesterday, I tried a lot. but, NO success. >> >> Hope to hear from you. > > Not exactly "help" but AFAIK, even with 3.5, there is no live merging of > snapshots so they can't be deleted unless the VM is down. I know for large > snapshots that have been around for awhile removing them can take some time > too. > > Others feel free to chime in... > > > ___ > Users mailing list > Users@ovirt.org > http://lists.ovirt.org/mailman/listinfo/users ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [ovirt-users] Testing self hosted engine in 3.6: hostname not resolved error
On Fri, Oct 23, 2015 at 3:57 PM, Gianluca Cecchi wrote: > On Thu, Oct 22, 2015 at 5:38 PM, Simone Tiraboschi > wrote: > >> >> >>> In case I want to setup a single host with self hosted engine, could I >>> configure on hypervisor >>> a) one NFS share for sh engine >>> b) one NFS share for ISO DOMAIN >>> c) a local filesystem to be used to create then a local POSIX complant >>> FS storage domain >>> and work this way as a replacement of all-in-one? >>> >> >> Yes but c is just a workaround, using another external NFS share would >> help a lot if in the future you plan to add o to migrate to a new server. >> > > Why do you see this as a workaround, if I plan to have this for example as > a devel personal infra without no other hypervisors? > I think about better performance directly going local instead of adding > overhead of NFS with itself > Just cause you are using as a shared storage something that is not really shared. > Put the host in global maintenance (otherwise the engine VM will be restarted) Shutdown the engine VM Shutdown the host >>> > Please note that at some point I had to power off the hypervisor in the > previous step, because it was stalled trying to stop two processes: > "Watchdog Multiplexing Daemon" > and > "Shared Storage Lease Manager" > > https://drive.google.com/file/d/0BwoPbcrMv8mvTVoyNzhRNGpqN1U/view?usp=sharing > > It was apparently able to stop the "Watchdog Multiplexing Daemon" after > some minutes > > https://drive.google.com/file/d/0BwoPbcrMv8mvZExNNkw5LVBiXzA/view?usp=sharing > > But no way for the Shared Storage Lease Manager and the screen above is > when I forced a power off yesterday, after global maintenance and correct > shutdown of sh engine and shutdown of hypervisor stalled. > > > > > >> > >>> Ok. And for starting all again, is this correct: >>> >>> a) power on hypevisor >>> b) hosted-engine --set-maintenance --mode=none >>> >>> other steps required? >>> >>> >> No, that's correct >> > > > Today after powering on hypervisor and waiting about 6 minutes I then ran: > > [root@ovc71 ~]# ps -ef|grep qemu > root 2104 1985 0 15:41 pts/000:00:00 grep --color=auto qemu > > --> as expected no VM in execution > > [root@ovc71 ~]# systemctl status vdsmd > vdsmd.service - Virtual Desktop Server Manager >Loaded: loaded (/usr/lib/systemd/system/vdsmd.service; enabled) >Active: active (running) since Fri 2015-10-23 15:34:46 CEST; 3min 25s > ago > Process: 1666 ExecStartPre=/usr/libexec/vdsm/vdsmd_init_common.sh > --pre-start (code=exited, status=0/SUCCESS) > Main PID: 1745 (vdsm) >CGroup: /system.slice/vdsmd.service >├─1745 /usr/bin/python /usr/share/vdsm/vdsm >└─1900 /usr/libexec/ioprocess --read-pipe-fd 56 --write-pipe-fd > 55 --max-threads 10 --... > > Oct 23 15:34:46 ovc71.localdomain.local python[1745]: DIGEST-MD5 client > step 1 > Oct 23 15:34:46 ovc71.localdomain.local python[1745]: DIGEST-MD5 > ask_user_info() > Oct 23 15:34:46 ovc71.localdomain.local python[1745]: DIGEST-MD5 client > step 1 > Oct 23 15:34:46 ovc71.localdomain.local python[1745]: DIGEST-MD5 > ask_user_info() > Oct 23 15:34:46 ovc71.localdomain.local python[1745]: DIGEST-MD5 > make_client_response() > Oct 23 15:34:46 ovc71.localdomain.local python[1745]: DIGEST-MD5 client > step 2 > Oct 23 15:34:46 ovc71.localdomain.local python[1745]: DIGEST-MD5 > parse_server_challenge() > Oct 23 15:34:46 ovc71.localdomain.local python[1745]: DIGEST-MD5 > ask_user_info() > Oct 23 15:34:46 ovc71.localdomain.local python[1745]: DIGEST-MD5 > make_client_response() > Oct 23 15:34:46 ovc71.localdomain.local python[1745]: DIGEST-MD5 client > step 3 > > --> I think it is expected that vdsmd starts anyway, even in global > maintenance, is it correct? > > But then: > > [root@ovc71 ~]# hosted-engine --set-maintenance --mode=none > Traceback (most recent call last): > File "/usr/lib64/python2.7/runpy.py", line 162, in _run_module_as_main > "__main__", fname, loader, pkg_name) > File "/usr/lib64/python2.7/runpy.py", line 72, in _run_code > exec code in run_globals > File > "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_setup/set_maintenance.py", > line 73, in > if not maintenance.set_mode(sys.argv[1]): > File > "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_setup/set_maintenance.py", > line 61, in set_mode > value=m_global, > File > "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/client/client.py", > line 259, in set_maintenance_mode > str(value)) > File > "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/client/client.py", > line 201, in set_global_md_flag > with broker.connection(self._retries, self._wait): > File "/usr/lib64/python2.7/contextlib.py", line 17, in __enter__ > return self.gen.next() > File > "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/lib/brokerlink.py", > line 99, in connection > self.connect(retries, wait) > File > "/usr/lib/python2.7
Re: [ovirt-users] Testing self hosted engine in 3.6: hostname not resolved error
On Thu, Oct 22, 2015 at 5:38 PM, Simone Tiraboschi wrote: > > >> In case I want to setup a single host with self hosted engine, could I >> configure on hypervisor >> a) one NFS share for sh engine >> b) one NFS share for ISO DOMAIN >> c) a local filesystem to be used to create then a local POSIX complant FS >> storage domain >> and work this way as a replacement of all-in-one? >> > > Yes but c is just a workaround, using another external NFS share would > help a lot if in the future you plan to add o to migrate to a new server. > Why do you see this as a workaround, if I plan to have this for example as a devel personal infra without no other hypervisors? I think about better performance directly going local instead of adding overhead of NFS with itself >> >>> Put the host in global maintenance (otherwise the engine VM will be >>> restarted) >>> Shutdown the engine VM >>> Shutdown the host >>> >>> >> Please note that at some point I had to power off the hypervisor in the previous step, because it was stalled trying to stop two processes: "Watchdog Multiplexing Daemon" and "Shared Storage Lease Manager" https://drive.google.com/file/d/0BwoPbcrMv8mvTVoyNzhRNGpqN1U/view?usp=sharing It was apparently able to stop the "Watchdog Multiplexing Daemon" after some minutes https://drive.google.com/file/d/0BwoPbcrMv8mvZExNNkw5LVBiXzA/view?usp=sharing But no way for the Shared Storage Lease Manager and the screen above is when I forced a power off yesterday, after global maintenance and correct shutdown of sh engine and shutdown of hypervisor stalled. > >> Ok. And for starting all again, is this correct: >> >> a) power on hypevisor >> b) hosted-engine --set-maintenance --mode=none >> >> other steps required? >> >> > No, that's correct > Today after powering on hypervisor and waiting about 6 minutes I then ran: [root@ovc71 ~]# ps -ef|grep qemu root 2104 1985 0 15:41 pts/000:00:00 grep --color=auto qemu --> as expected no VM in execution [root@ovc71 ~]# systemctl status vdsmd vdsmd.service - Virtual Desktop Server Manager Loaded: loaded (/usr/lib/systemd/system/vdsmd.service; enabled) Active: active (running) since Fri 2015-10-23 15:34:46 CEST; 3min 25s ago Process: 1666 ExecStartPre=/usr/libexec/vdsm/vdsmd_init_common.sh --pre-start (code=exited, status=0/SUCCESS) Main PID: 1745 (vdsm) CGroup: /system.slice/vdsmd.service ├─1745 /usr/bin/python /usr/share/vdsm/vdsm └─1900 /usr/libexec/ioprocess --read-pipe-fd 56 --write-pipe-fd 55 --max-threads 10 --... Oct 23 15:34:46 ovc71.localdomain.local python[1745]: DIGEST-MD5 client step 1 Oct 23 15:34:46 ovc71.localdomain.local python[1745]: DIGEST-MD5 ask_user_info() Oct 23 15:34:46 ovc71.localdomain.local python[1745]: DIGEST-MD5 client step 1 Oct 23 15:34:46 ovc71.localdomain.local python[1745]: DIGEST-MD5 ask_user_info() Oct 23 15:34:46 ovc71.localdomain.local python[1745]: DIGEST-MD5 make_client_response() Oct 23 15:34:46 ovc71.localdomain.local python[1745]: DIGEST-MD5 client step 2 Oct 23 15:34:46 ovc71.localdomain.local python[1745]: DIGEST-MD5 parse_server_challenge() Oct 23 15:34:46 ovc71.localdomain.local python[1745]: DIGEST-MD5 ask_user_info() Oct 23 15:34:46 ovc71.localdomain.local python[1745]: DIGEST-MD5 make_client_response() Oct 23 15:34:46 ovc71.localdomain.local python[1745]: DIGEST-MD5 client step 3 --> I think it is expected that vdsmd starts anyway, even in global maintenance, is it correct? But then: [root@ovc71 ~]# hosted-engine --set-maintenance --mode=none Traceback (most recent call last): File "/usr/lib64/python2.7/runpy.py", line 162, in _run_module_as_main "__main__", fname, loader, pkg_name) File "/usr/lib64/python2.7/runpy.py", line 72, in _run_code exec code in run_globals File "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_setup/set_maintenance.py", line 73, in if not maintenance.set_mode(sys.argv[1]): File "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_setup/set_maintenance.py", line 61, in set_mode value=m_global, File "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/client/client.py", line 259, in set_maintenance_mode str(value)) File "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/client/client.py", line 201, in set_global_md_flag with broker.connection(self._retries, self._wait): File "/usr/lib64/python2.7/contextlib.py", line 17, in __enter__ return self.gen.next() File "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/lib/brokerlink.py", line 99, in connection self.connect(retries, wait) File "/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/lib/brokerlink.py", line 78, in connect raise BrokerConnectionError(error_msg) ovirt_hosted_engine_ha.lib.exceptions.BrokerConnectionError: Failed to connect to broker, the number of errors has exceeded the limit (1) What to do next? ___ Users mailing list Users@ovirt.org http:
Re: [ovirt-users] oVirt monitoring with libirt-snmp
Hi Dan, I want to monitor my oVirt infrastructure with Zabbix. I found a zabbix template , but it needs to modifiy libirtd.conf to enable libvirt-snmp to access VM informations (https://github.com/jensdepuydt/zabbix-ovirt). Kevin - Mail original - > De: "Dan Kenigsberg" > À: "Roman Mohr" > Cc: "Kevin COUSIN" , "users" > Envoyé: Jeudi 22 Octobre 2015 09:39:49 > Objet: Re: [ovirt-users] oVirt monitoring with libirt-snmp > On Wed, Oct 21, 2015 at 05:48:17PM +0200, Roman Mohr wrote: >> Hi Kevin, >> >> >> you should not change auth_unix_rw=sasl. I never used libvirt-snmp but it >> is save to create another user like this: >> >> > saslpasswd2 -a libvirt >> >> I did that several times on my hosts. >> >> >> On Mon, Oct 19, 2015 at 4:43 PM, Kevin COUSIN >> wrote: >> >> > Hi list, >> > >> > Is it safe to edit /etc/libvirt/libvirtd.conf? I need to change >> > auth_unix_rw="sasl" because I want to allow libvirt-snmp to acess to VM >> > informations. Perhaps I need to create a user in sasl instead ? > > Would you share your use case for libvirt-snmp? > > The supposed danger is that whatever uses snmp may modify VM state under > the feet of oVirt and surprise it. ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [ovirt-users] Issue with kernel 2.6.32-573.3.1.el6.x86_64?
Hi Michael, if you have the possibility to test with kernel-2.6.32-504.16.2.el6.x86_64 and kernel-2.6.32-504.23.4.el6.x86_64 please do it. I'm expecting that 2.6.32-504.16.2.el6 is the latest correctly working kernel. Please tell us if this is your case. There are clear signs of misbehaviours due to changes in the VLAN code between the two kernels above. Also take a look at https://bugs.centos.org/view.php?id=9467 and https://bugzilla.redhat.com/show_bug.cgi?id=1263561 . Best regards, Giorgio. P.S. sorry for top posting. I tried to revert this thread but I couldn't do it in an effective way :( 2015-10-21 23:05 GMT+02:00 Michael Kleinpaste : > VMs are on different VLANs and use a central Vyos VM as the firewall and > default gateway. The only indication I had that the packets were getting > dropped or being sent out of order was by tshark'ing the traffic. Tons and > tons of resends. > > The problem was definitely resolved after I dropped back to the prior kernel > (2.6.32-504.12.2.el6.x86_64). > > > On Tue, Oct 20, 2015 at 11:51 PM Ido Barkan wrote: >> >> Hi Michael, >> Can you describe your network architecture for this vm (inside the host). >> Do you know where are the packets get dropped? >> Ido >> >> On Tue, Sep 22, 2015 at 1:19 AM, Michael Kleinpaste >> wrote: >> > Nobody's seen this? >> > >> > On Wed, Sep 16, 2015 at 9:08 AM Michael Kleinpaste >> > wrote: >> >> >> >> So I patched my vhosts and updated the kernel to >> >> 2.6.32-573.3.1.el6.x86_64. Afterwards the networking became unstable >> >> for my >> >> vyatta firewall vm. Lots of packet loss and out of order packets >> >> (based on >> >> my tshark at the time). >> >> >> >> Has anybody else experienced this? >> >> -- >> >> Michael Kleinpaste ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users