- Users - oVirt List Archives

Re: [ovirt-users] Posix FS as alternative to local storage?
by Eduardo Mayoral 30 Apr '18

30 Apr '18

This is a multi-part message in MIME format. --------------5BAADD88E5767C79F227304D Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit First, sorry that my previous answer went directly to you and not to the list. My mistake. Well, detaching and attaching shared storage domains is not the solution I was hoping for, but at least it gives me an option to migrate VMs between hosts. It is either that or gluster (thanks, Tony), depending on the performance impact. Thanks for your help! Eduardo Mayoral Jimeno (emayoral(a)arsys.es) Administrador de sistemas. Departamento de Plataformas. Arsys internet. +34 941 620 145 ext. 5153 On 30/04/18 14:48, Maor Lipchuk wrote: > Will it help if you will have 2 local data centers? > and use the 'trick' with the detach/attach of the shared storage domain? > > Basically the architecture of oVirt does not relate clusters to > storage domains. > Storage domains are part of a data center while hosts are part of a > cluster which is part of a data center. I guess that is the reason why > it will be more problematic to declare cluster as local. > > Regards, > Maor > > On Mon, Apr 30, 2018 at 3:23 PM, Eduardo Mayoral <emayoral(a)arsys.es > <mailto:emayoral@arsys.es>> wrote: > > On 30/04/18 14:05, Maor Lipchuk wrote: >> >> >> On Mon, Apr 30, 2018 at 2:01 PM, Eduardo Mayoral >> <emayoral(a)arsys.es <mailto:emayoral@arsys.es>> wrote: >> >> On 30/04/18 12:51, Tony Brian Albers wrote: >> > On 30/04/18 11:43, Eduardo Mayoral wrote: >> >> Hi, >> >> >> >> I would like to set up a new oVirt deployment with >> hosts that have >> >> the VMs running on local attached storage. I understand >> this has the >> >> requirement of having each host in its own cluster (and >> own datacenter, >> >> it seems, I understand the need for the dedicated cluster, >> not so much >> >> for the dedicated datacenter). >> >> >> >> At the same time, I would like to have some shared >> storage domains >> >> so I can use it to export VMs or migrate them around hosts >> (probably in >> >> three stages, first migrate VM storage from local to the >> shared storage >> >> domain, second migrate the host (probably not possible to >> do a "hot" >> >> migration, but at least "cold"), third migrate the VM >> storage from the >> >> shared storage domain to the local storage domain of the >> new host). >> >> >> >> So I thought maybe I can deploy a datacenter in >> shared storage mode, >> >> with one cluster per host. Use one or two shared storage >> domains for >> >> master and as an stage area for planned VM migrations as >> explained >> >> before, and then configure several storage domains, one >> per host, as >> >> posix FS . I would then deploy the VMs on the local posix >> FS storage >> >> domains and set affinity rules for the VMs to their hosts >> as needed. >> >> >> >> Would this work? Is there a better way of achieving >> local storage >> >> and retaining the ability to share storage among hosts and >> migrate VMs? >> >> >> >> >> > Have you thought about using glusterfs? If hosts are >> physically close, >> > that would probably be the best solution. >> > >> >> Actually, yes, I also had glusterfs in mind. However one of >> the main >> reasons to use local storage is performance, and I am >> concerned about >> the write latencies of gluster (If using gluster, I would >> handle things >> so the VM runs on one of the gluster nodes hosting the VM >> data, so I >> assume the read latency will be close to the one I would get >> with local >> storage, but the gluster replica(s) will be on other hosts, >> so write >> latency may be significantly worse). >> >> Thanks a lot for the suggestion, it is a good one, however, >> the original >> question stands: Would this work? Is there a better way of >> achieving >> local storage and retaining the ability to share storage >> among hosts and >> migrate VMs? >> >> >> Hi Eduardo, >> We support shared storage domains in a local data center >> since oVirt 4.1. >> Will this help you by any chance? > > Hi, Moar, > > Thanks for your fast reply! This helps partly, but does not > quite solve my needs. If I understood correctly, I can have a > shared storage attached to a local storage Data Center. However I > cannot share a shared storage among datacenters. I can detach the > shared storage domain from one datacenter and attach it to another > one, but I cannot "Share" the shared storage as in: both hosts see > it at the same time, as I would expect it to be the case with a > shared storage domain in a regular shared data center. > > Root of the problem for me actually is: I can totally > understand that host with local storage must "live" in a dedicated > cluster. But, why does it also need a dedicated data center entity? > > Thanks for your help! > > -- > Eduardo Mayoral. > > --------------5BAADD88E5767C79F227304D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> </head> <body text="#000000" bgcolor="#FFFFFF"> <p>First, sorry that my previous answer went directly to you and not to the list. My mistake.</p> <p>Well, detaching and attaching shared storage domains is not the solution I was hoping for, but at least it gives me an option to migrate VMs between hosts. It is either that or gluster (thanks, Tony), depending on the performance impact.</p> <p>Thanks for your help!<br> </p> <p><br> </p> <pre class="moz-signature" cols="72">Eduardo Mayoral Jimeno (<a class="moz-txt-link-abbreviated" href="mailto:emayoral@arsys.es">emayoral(a)arsys.es</a>) Administrador de sistemas. Departamento de Plataformas. Arsys internet. +34 941 620 145 ext. 5153</pre> <div class="moz-cite-prefix">On 30/04/18 14:48, Maor Lipchuk wrote:<br> </div> <blockquote type="cite" cite="mid:CAJ1JNOf_KjTnOUCxTUbDsBGpc0e1sVJE2PaoqqvPV_OEWPXk1A@mail.gmail.com"> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> <div dir="ltr"> <div>Will it help if you will have 2 local data centers?<br> </div> <div>and use the 'trick' with the detach/attach of the shared storage domain?</div> <div><br> </div> <div>Basically the architecture of oVirt does not relate clusters to storage domains.</div> <div>Storage domains are part of a data center while hosts are part of a cluster which is part of a data center. I guess that is the reason why it will be more problematic to declare cluster as local.<br> </div> <div><br> </div> <div>Regards,</div> <div>Maor</div> </div> <div class="gmail_extra"><br> <div class="gmail_quote">On Mon, Apr 30, 2018 at 3:23 PM, Eduardo Mayoral <span dir="ltr"><<a href="mailto:emayoral@arsys.es" target="_blank" moz-do-not-send="true">emayoral(a)arsys.es</a>></span> wrote:<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div text="#000000" bgcolor="#FFFFFF"> <div> <div class="h5"> On 30/04/18 14:05, Maor Lipchuk wrote:<br> <blockquote type="cite"> <div dir="ltr"><br> <div class="gmail_extra"><br> <div class="gmail_quote">On Mon, Apr 30, 2018 at 2:01 PM, Eduardo Mayoral <span dir="ltr"><<a href="mailto:emayoral@arsys.es" target="_blank" moz-do-not-send="true">emayoral(a)arsys.es</a>></span> wrote:<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On 30/04/18 12:51, Tony Brian Albers wrote:<br> > On 30/04/18 11:43, Eduardo Mayoral wrote:<br> >> Hi,<br> >><br> >> I would like to set up a new oVirt deployment with hosts that have<br> >> the VMs running on local attached storage. I understand this has the<br> >> requirement of having each host in its own cluster (and own datacenter,<br> >> it seems, I understand the need for the dedicated cluster, not so much<br> >> for the dedicated datacenter).<br> >><br> >> At the same time, I would like to have some shared storage domains<br> >> so I can use it to export VMs or migrate them around hosts (probably in<br> >> three stages, first migrate VM storage from local to the shared storage<br> >> domain, second migrate the host (probably not possible to do a "hot"<br> >> migration, but at least "cold"), third migrate the VM storage from the<br> >> shared storage domain to the local storage domain of the new host).<br> >><br> >> So I thought maybe I can deploy a datacenter in shared storage mode,<br> >> with one cluster per host. Use one or two shared storage domains for<br> >> master and as an stage area for planned VM migrations as explained<br> >> before, and then configure several storage domains, one per host, as<br> >> posix FS . I would then deploy the VMs on the local posix FS storage<br> >> domains and set affinity rules for the VMs to their hosts as needed.<br> >><br> >> Would this work? Is there a better way of achieving local storage<br> >> and retaining the ability to share storage among hosts and migrate VMs?<br> >><br> >><br> > Have you thought about using glusterfs? If hosts are physically close, <br> > that would probably be the best solution.<br> ><br> <br> </span>Actually, yes, I also had glusterfs in mind. However one of the main<br> reasons to use local storage is performance, and I am concerned about<br> the write latencies of gluster (If using gluster, I would handle things<br> so the VM runs on one of the gluster nodes hosting the VM data, so I<br> assume the read latency will be close to the one I would get with local<br> storage, but the gluster replica(s) will be on other hosts, so write<br> latency may be significantly worse).<br> <br> Thanks a lot for the suggestion, it is a good one, however, the original<br> question stands: Would this work? Is there a better way of achieving<br> <span>local storage and retaining the ability to share storage among hosts and<br> migrate VMs?<br> </span></blockquote> <div><br> </div> <div>Hi Eduardo,</div> <div>We support <span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">shared storage domains in a local data center since </span>oVirt 4.1.</div> <div>Will this help you by any chance?</div> </div> </div> </div> </blockquote> <br> </div> </div> Hi, Moar,<br> <br> Thanks for your fast reply! This helps partly, but does not quite solve my needs. If I understood correctly, I can have a shared storage attached to a local storage Data Center. However I cannot share a shared storage among datacenters. I can detach the shared storage domain from one datacenter and attach it to another one, but I cannot "Share" the shared storage as in: both hosts see it at the same time, as I would expect it to be the case with a shared storage domain in a regular shared data center.<br> <br> Root of the problem for me actually is: I can totally understand that host with local storage must "live" in a dedicated cluster. But, why does it also need a dedicated data center entity?<br> <br> Thanks for your help!<br> <br> --<br> Eduardo Mayoral.<br> <br> </div> </blockquote> </div> <br> </div> </blockquote> <br> </body> </html> --------------5BAADD88E5767C79F227304D--

1 0

Virtual Machine Storage Size
by Hari Prasanth Loganathan 30 Apr '18

30 Apr '18

Hi Team, How to get the total and used storage size of a VM? When I run statistics Rest URL I get the following response, Which is the Total and Used storage in it? { "next_run_configuration_exists": "false", "numa_tune_mode": "interleave", "status": "down", "stop_time": 1524728637295, "original_template": { "href": "/ovirt-engine/api/templates/00000000-0000-0000-0000-000000000000", "id": "00000000-0000-0000-0000-000000000000" }, "statistics": { "statistic": [ { "kind": "gauge", "type": "integer", "unit": "bytes", "values": { "value": [ { "datum": 1073741824 } ] }, "vm": { "href": "/ovirt-engine/api/vms/b89deb8c-882c-47a4-9911-b4978cddcded", "id": "b89deb8c-882c-47a4-9911-b4978cddcded" }, "name": "memory.installed", "description": "Total memory configured", "href": "/ovirt-engine/api/vms/b89deb8c-882c-47a4-9911-b4978cddcded/statistics/5a89a1d2-32be-33f7-a0d1-f8b5bc974ff6", "id": "5a89a1d2-32be-33f7-a0d1-f8b5bc974ff6" }, { "kind": "gauge", "type": "integer", "unit": "bytes", "values": { "value": [ { "datum": 0 } ] }, "vm": { "href": "/ovirt-engine/api/vms/b89deb8c-882c-47a4-9911-b4978cddcded", "id": "b89deb8c-882c-47a4-9911-b4978cddcded" }, "name": "memory.used", "description": "Memory used (agent)", "href": "/ovirt-engine/api/vms/b89deb8c-882c-47a4-9911-b4978cddcded/statistics/b7499508-c1c3-32f0-8174-c1783e57bb08", "id": "b7499508-c1c3-32f0-8174-c1783e57bb08" }, { "kind": "gauge", "type": "decimal", "unit": "percent", "values": { "value": [ { "datum": 0 } ] }, "vm": { "href": "/ovirt-engine/api/vms/b89deb8c-882c-47a4-9911-b4978cddcded", "id": "b89deb8c-882c-47a4-9911-b4978cddcded" }, "name": "cpu.current.guest", "description": "CPU used by guest", "href": "/ovirt-engine/api/vms/b89deb8c-882c-47a4-9911-b4978cddcded/statistics/ef802239-b74a-329f-9955-be8fea6b50a4", "id": "ef802239-b74a-329f-9955-be8fea6b50a4" }, { "kind": "gauge", "type": "decimal", "unit": "percent", "values": { "value": [ { "datum": 0 } ] }, "vm": { "href": "/ovirt-engine/api/vms/b89deb8c-882c-47a4-9911-b4978cddcded", "id": "b89deb8c-882c-47a4-9911-b4978cddcded" }, "name": "cpu.current.hypervisor", "description": "CPU overhead", "href": "/ovirt-engine/api/vms/b89deb8c-882c-47a4-9911-b4978cddcded/statistics/d849a55f-0049-36f8-ae65-face541473ac", "id": "d849a55f-0049-36f8-ae65-face541473ac" }, { "kind": "gauge", "type": "decimal", "unit": "percent", "values": { "value": [ { "datum": 0 } ] }, "vm": { "href": "/ovirt-engine/api/vms/b89deb8c-882c-47a4-9911-b4978cddcded", "id": "b89deb8c-882c-47a4-9911-b4978cddcded" }, "name": "cpu.current.total", "description": "Total CPU used", "href": "/ovirt-engine/api/vms/b89deb8c-882c-47a4-9911-b4978cddcded/statistics/2ec286fe-4bec-32f5-8d63-dba7bed58763", "id": "2ec286fe-4bec-32f5-8d63-dba7bed58763" }, { "kind": "gauge", "type": "decimal", "unit": "percent", "values": { "value": [ { "datum": 0 } ] }, "vm": { "href": "/ovirt-engine/api/vms/b89deb8c-882c-47a4-9911-b4978cddcded", "id": "b89deb8c-882c-47a4-9911-b4978cddcded" }, "name": "migration.progress", "description": "Migration Progress", "href": "/ovirt-engine/api/vms/b89deb8c-882c-47a4-9911-b4978cddcded/statistics/892b69a7-41ca-36b1-9a2e-ae5177ef21bb", "id": "892b69a7-41ca-36b1-9a2e-ae5177ef21bb" }, { "kind": "gauge", "type": "integer", "unit": "bytes", "values": { "value": [ { "datum": 0 } ] }, "vm": { "href": "/ovirt-engine/api/vms/b89deb8c-882c-47a4-9911-b4978cddcded", "id": "b89deb8c-882c-47a4-9911-b4978cddcded" }, "name": "memory.buffered", "description": "Memory buffered (agent)", "href": "/ovirt-engine/api/vms/b89deb8c-882c-47a4-9911-b4978cddcded/statistics/09e07489-64fd-32ab-8e4e-a2b61eed8d60", "id": "09e07489-64fd-32ab-8e4e-a2b61eed8d60" }, { "kind": "gauge", "type": "integer", "unit": "bytes", "values": { "value": [ { "datum": 0 } ] }, "vm": { "href": "/ovirt-engine/api/vms/b89deb8c-882c-47a4-9911-b4978cddcded", "id": "b89deb8c-882c-47a4-9911-b4978cddcded" }, "name": "memory.cached", "description": "Memory cached (agent)", "href": "/ovirt-engine/api/vms/b89deb8c-882c-47a4-9911-b4978cddcded/statistics/1b6244ee-8dbd-365d-8762-482ddc05ee11", "id": "1b6244ee-8dbd-365d-8762-482ddc05ee11" }, { "kind": "gauge", "type": "integer", "unit": "bytes", "values": { "value": [ { "datum": 0 } ] }, "vm": { "href": "/ovirt-engine/api/vms/b89deb8c-882c-47a4-9911-b4978cddcded", "id": "b89deb8c-882c-47a4-9911-b4978cddcded" }, "name": "memory.free", "description": "Memory free (agent)", "href": "/ovirt-engine/api/vms/b89deb8c-882c-47a4-9911-b4978cddcded/statistics/5a0fba9d-33d7-3cbf-addd-ba462040c946", "id": "5a0fba9d-33d7-3cbf-addd-ba462040c946" } ] }, "template": { "href": "/ovirt-engine/api/templates/00000000-0000-0000-0000-000000000000", "id": "00000000-0000-0000-0000-000000000000" }, "actions": { "link": [ { "href": "/ovirt-engine/api/vms/b89deb8c-882c-47a4-9911-b4978cddcded/detach", "rel": "detach" }, { "href": "/ovirt-engine/api/vms/b89deb8c-882c-47a4-9911-b4978cddcded/export", "rel": "export" }, { "href": "/ovirt-engine/api/vms/b89deb8c-882c-47a4-9911-b4978cddcded/ticket", "rel": "ticket" }, { "href": "/ovirt-engine/api/vms/b89deb8c-882c-47a4-9911-b4978cddcded/reboot", "rel": "reboot" }, { "href": "/ovirt-engine/api/vms/b89deb8c-882c-47a4-9911-b4978cddcded/migrate", "rel": "migrate" }, { "href": "/ovirt-engine/api/vms/b89deb8c-882c-47a4-9911-b4978cddcded/commitsnapshot", "rel": "commitsnapshot" }, { "href": "/ovirt-engine/api/vms/b89deb8c-882c-47a4-9911-b4978cddcded/cancelmigration", "rel": "cancelmigration" }, { "href": "/ovirt-engine/api/vms/b89deb8c-882c-47a4-9911-b4978cddcded/clone", "rel": "clone" }, { "href": "/ovirt-engine/api/vms/b89deb8c-882c-47a4-9911-b4978cddcded/freezefilesystems", "rel": "freezefilesystems" }, { "href": "/ovirt-engine/api/vms/b89deb8c-882c-47a4-9911-b4978cddcded/logon", "rel": "logon" }, { "href": "/ovirt-engine/api/vms/b89deb8c-882c-47a4-9911-b4978cddcded/maintenance", "rel": "maintenance" }, { "href": "/ovirt-engine/api/vms/b89deb8c-882c-47a4-9911-b4978cddcded/previewsnapshot", "rel": "previewsnapshot" }, { "href": "/ovirt-engine/api/vms/b89deb8c-882c-47a4-9911-b4978cddcded/reordermacaddresses", "rel": "reordermacaddresses" }, { "href": "/ovirt-engine/api/vms/b89deb8c-882c-47a4-9911-b4978cddcded/thawfilesystems", "rel": "thawfilesystems" }, { "href": "/ovirt-engine/api/vms/b89deb8c-882c-47a4-9911-b4978cddcded/undosnapshot", "rel": "undosnapshot" }, { "href": "/ovirt-engine/api/vms/b89deb8c-882c-47a4-9911-b4978cddcded/shutdown", "rel": "shutdown" }, { "href": "/ovirt-engine/api/vms/b89deb8c-882c-47a4-9911-b4978cddcded/start", "rel": "start" }, { "href": "/ovirt-engine/api/vms/b89deb8c-882c-47a4-9911-b4978cddcded/stop", "rel": "stop" }, { "href": "/ovirt-engine/api/vms/b89deb8c-882c-47a4-9911-b4978cddcded/suspend", "rel": "suspend" } ] }, "name": "memory", "href": "/ovirt-engine/api/vms/b89deb8c-882c-47a4-9911-b4978cddcded", "id": "b89deb8c-882c-47a4-9911-b4978cddcded", "bios": { "boot_menu": { "enabled": "false" } }, "cpu": { "architecture": "x86_64", "topology": { "cores": "1", "sockets": "1", "threads": "1" } }, "display": { "allow_override": "false", "copy_paste_enabled": "true", "disconnect_action": "LOCK_SCREEN", "file_transfer_enabled": "true", "monitors": "1", "single_qxl_pci": "false", "smartcard_enabled": "false", "type": "spice" }, "io": { "threads": "0" }, * "memory": 1073741824,* "migration": { "auto_converge": "inherit", "compressed": "inherit" }, "origin": "ovirt", "os": { "boot": { "devices": { "device": [ "hd" ] } }, "type": "other" }, "sso": { "methods": { "method": [ { "id": "guest_agent" } ] } }, "stateless": "false", "type": "desktop", "usb": { "enabled": "false" }, "cluster": { "href": "/ovirt-engine/api/clusters/8111b6c0-c60d-416d-bcdb-ea926f8035fc", "id": "8111b6c0-c60d-416d-bcdb-ea926f8035fc" }, "quota": { "id": "96e54503-092a-467e-be8e-12ac203b9991" }, "link": [ { "href": "/ovirt-engine/api/vms/b89deb8c-882c-47a4-9911-b4978cddcded/cdroms", "rel": "cdroms" }, { "href": "/ovirt-engine/api/vms/b89deb8c-882c-47a4-9911-b4978cddcded/watchdogs", "rel": "watchdogs" }, { "href": "/ovirt-engine/api/vms/b89deb8c-882c-47a4-9911-b4978cddcded/katelloerrata", "rel": "katelloerrata" }, { "href": "/ovirt-engine/api/vms/b89deb8c-882c-47a4-9911-b4978cddcded/permissions", "rel": "permissions" }, { "href": "/ovirt-engine/api/vms/b89deb8c-882c-47a4-9911-b4978cddcded/tags", "rel": "tags" }, { "href": "/ovirt-engine/api/vms/b89deb8c-882c-47a4-9911-b4978cddcded/diskattachments", "rel": "diskattachments" }, { "href": "/ovirt-engine/api/vms/b89deb8c-882c-47a4-9911-b4978cddcded/snapshots", "rel": "snapshots" }, { "href": "/ovirt-engine/api/vms/b89deb8c-882c-47a4-9911-b4978cddcded/applications", "rel": "applications" }, { "href": "/ovirt-engine/api/vms/b89deb8c-882c-47a4-9911-b4978cddcded/affinitylabels", "rel": "affinitylabels" }, { "href": "/ovirt-engine/api/vms/b89deb8c-882c-47a4-9911-b4978cddcded/hostdevices", "rel": "hostdevices" }, { "href": "/ovirt-engine/api/vms/b89deb8c-882c-47a4-9911-b4978cddcded/numanodes", "rel": "numanodes" }, { "href": "/ovirt-engine/api/vms/b89deb8c-882c-47a4-9911-b4978cddcded/reporteddevices", "rel": "reporteddevices" }, { "href": "/ovirt-engine/api/vms/b89deb8c-882c-47a4-9911-b4978cddcded/sessions", "rel": "sessions" }, { "href": "/ovirt-engine/api/vms/b89deb8c-882c-47a4-9911-b4978cddcded/graphicsconsoles", "rel": "graphicsconsoles" }, { "href": "/ovirt-engine/api/vms/b89deb8c-882c-47a4-9911-b4978cddcded/nics", "rel": "nics" }, { "href": "/ovirt-engine/api/vms/b89deb8c-882c-47a4-9911-b4978cddcded/statistics", "rel": "statistics" } ], "cpu_shares": "0", "creation_time": 1524728637178, "delete_protected": "false", "high_availability": { "enabled": "false", "priority": "0" }, "large_icon": { "href": "/ovirt-engine/api/icons/ae1951e6-d1c8-50a9-4dc3-59a0967afd21", "id": "ae1951e6-d1c8-50a9-4dc3-59a0967afd21" }, "memory_policy": { "guaranteed": 1073741824, "max": 4294967296 }, "migration_downtime": "-1", "placement_policy": { "affinity": "migratable" }, "small_icon": { "href": "/ovirt-engine/api/icons/07a3e3fc-a384-e5cc-d496-942f8047eea8", "id": "07a3e3fc-a384-e5cc-d496-942f8047eea8" }, "start_paused": "false", "storage_error_resume_behaviour": "auto_resume", "time_zone": { "name": "Etc/GMT" }, "cpu_profile": { "href": "/ovirt-engine/api/cpuprofiles/ab2e9ead-2464-41f9-94f4-1e68c648a8a1", "id": "ab2e9ead-2464-41f9-94f4-1e68c648a8a1" } }

2 1

Posix FS as alternative to local storage?
by Eduardo Mayoral 30 Apr '18

30 Apr '18

Hi, I would like to set up a new oVirt deployment with hosts that have the VMs running on local attached storage. I understand this has the requirement of having each host in its own cluster (and own datacenter, it seems, I understand the need for the dedicated cluster, not so much for the dedicated datacenter). At the same time, I would like to have some shared storage domains so I can use it to export VMs or migrate them around hosts (probably in three stages, first migrate VM storage from local to the shared storage domain, second migrate the host (probably not possible to do a "hot" migration, but at least "cold"), third migrate the VM storage from the shared storage domain to the local storage domain of the new host). So I thought maybe I can deploy a datacenter in shared storage mode, with one cluster per host. Use one or two shared storage domains for master and as an stage area for planned VM migrations as explained before, and then configure several storage domains, one per host, as posix FS . I would then deploy the VMs on the local posix FS storage domains and set affinity rules for the VMs to their hosts as needed. Would this work? Is there a better way of achieving local storage and retaining the ability to share storage among hosts and migrate VMs? -- Eduardo Mayoral Jimeno (emayoral(a)arsys.es) Administrador de sistemas. Departamento de Plataformas. Arsys internet. +34 941 620 145 ext. 5153

3 3

General SSLEngine problem
by gsswzt＠pku.edu.cn 30 Apr '18

30 Apr '18

This is a multi-part message in MIME format. ------=_001_NextPart885427541416_=---- Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: base64 SGksDQoNCkkgZ290IHRoaXMgZXJyIGxvZyB3aGVuIEkgc3RhcnQgbXkgZW5naW5lIHNlcnZpY2Uu DQoNCjIwMTgtMDQtMjUgMTg6NDA6MjEsMDEyKzA4IElORk8gIFtvcmcub3ZpcnQudmRzbS5qc29u cnBjLmNsaWVudC5yZWFjdG9ycy5SZWFjdG9yQ2xpZW50XSAoU1NMIFN0b21wIFJlYWN0b3IpIFtd IENvbm5lY3RpbmcgdG8gLzE5Mi4xNjguMTIyLjE4Nw0KMjAxOC0wNC0yNSAxODo0MDoyMSwwMTkr MDggRVJST1IgW29yZy5vdmlydC52ZHNtLmpzb25ycGMuY2xpZW50LnJlYWN0b3JzLlJlYWN0b3Jd IChTU0wgU3RvbXAgUmVhY3RvcikgW10gVW5hYmxlIHRvIHByb2Nlc3MgbWVzc2FnZXMgR2VuZXJh bCBTU0xFbmdpbmUgcHJvYmxlbQ0KDQoNCkFuZCBsb2dnaW4gbXkgZW5naW5lIEdVSSwgZ290IHRo aXMgZXJyDQoNCk1pc3NpbmcgcGFyYW1ldGVyOiAnY2xpZW50X3NlY3JldCcgDQo= ------=_001_NextPart885427541416_=---- Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html><head><meta http-equiv=3D"content-type" content=3D"text/html; charse= t=3Dus-ascii"><style>body { line-height: 1.5; }body { font-size: 10.5pt; f= ont-family: ????; color: rgb(0, 0, 0); line-height: 1.5; }</style></head><= body>=0A<div><span></span><div>Hi,</div><div><br></div><div>I got this err= log when I start my engine service.</div><div><br></div><div>2018-04-25 1= 8:40:21,012+08 INFO  [org.ovirt.vdsm.jsonrpc.client.reactors.ReactorC= lient] (SSL Stomp Reactor) [] Connecting to /192.168.122.187</div><div>201= 8-04-25 18:40:21,019+08 ERROR [org.ovirt.vdsm.jsonrpc.client.reactors.Reac= tor] (SSL Stomp Reactor) [] Unable to process messages General SSLEngine p= roblem</div></div><div><br></div><div><br></div><div>And loggin my engine = GUI, got this err</div><div><br></div><div>Missing parameter: 'client_secr= et' </div>=0A</body></html> ------=_001_NextPart885427541416_=------

2 1

engine setup error
by dhy336＠sina.com 30 Apr '18

30 Apr '18

--=-sinamail_mix_c101082a388e342a957d987294109e01 Content-Type: multipart/alternative; boundary="=-sinamail_alt_b07360d2a984dc30f8d3dd33c45e1d37" --=-sinamail_alt_b07360d2a984dc30f8d3dd33c45e1d37 Content-Type: text/plain; charset=GBK Content-Transfer-Encoding: base64 Content-Disposition: inline SGkgSSBlbmdpbmUgc2V0dXAgZmFjZXMgc29tZSBlcnJvci4KIEkgdHJ5IHRvIHNvbHV0ZSBpdCBh bmQgIGl0IGlzIHdvcmsuIGhlcmUgaXMgbXkgcGF0Y2guIEJ1dCAgbm90IHN1cmUgaXQgaXMgcmln aHQ/CgogJEhPTUUvb3ZpcnQtZW5naW5lL2Jpbi9lbmdpbmUtc2V0dXBbIElORk8gIF0gU3RhZ2U6 IEluaXRpYWxpemluZwogICAgICAgICAgU2V0dXAgd2FzIHJ1biB1bmRlciB1bnByaXZpbGVnZWQg dXNlciB0aGlzIHdpbGwgcHJvZHVjZSBkZXZlbG9wbWVudCBpbnN0YWxsYXRpb24gZG8geW91IHdp c2ggdG8gcHJvY2VlZD8gKFllcywgTm8pIFtOb106IHllcwpbIElORk8gIF0gU3RhZ2U6IEVudmly b25tZW50IHNldHVwCiAgICAgICAgICBDb25maWd1cmF0aW9uIGZpbGVzOiBbXQogICAgICAgICAg TG9nIGZpbGU6IC9ob21lL2d1b3NzNC9vdmlydC1lbmdpbmUvdmFyL2xvZy9vdmlydC1lbmdpbmUv c2V0dXAvb3ZpcnQtZW5naW5lLXNldHVwLTIwMTgwNDI3MDAxNTI4LTZoN3NucC5sb2cKICAgICAg ICAgIFZlcnNpb246IG90b3BpLTEuOC4wX21hc3RlciAob3RvcGktMS44LjAtMC4wLm1hc3Rlci4y MDE4MDMxMzA4NDExNC5naXQ0ZTc4OGY5LmVsNy5jZW50b3MpClsgRVJST1IgXSAiYmVmb3JlIiBw YXJhbWV0ZXIgb2YgbWV0aG9kIG90b3BpLnBsdWdpbnMub3ZpcnRfZW5naW5lX3NldHVwLm92aXJ0 X2VuZ2luZS5uZXR3b3JrLm92aXJ0cHJvdmlkZXJvdm4uUGx1Z2luLl9taXNjX2NvbmZpZ3VyZV9v dm5fcGtpIGlzIGEgc3RyaW5nLCBzaG91bGQgcHJvYmFibHkgYmUgYSB0dXBsZS4gUGVyaGFwcyBh IG1pc3NpbmcgY29tbWE/CiAgICAgICAgICBtZXRob2RpbmZvOiB7J3ByaW9yaXR5JzogNTAwMCwg J25hbWUnOiBOb25lLCAnYmVmb3JlJzogJ29zZXR1cC5vdm4ucHJvdmlkZXIuc2VydmljZS5yZXN0 YXJ0JywgJ2FmdGVyJzogKCdvc2V0dXAucGtpLmNhLmF2YWlsYWJsZScsICdvc2V0dXAub3ZuLnNl cnZpY2VzLnJlc3RhcnQnKSwgJ21ldGhvZCc6IDxib3VuZCBtZXRob2QgPy5fbWlzY19jb25maWd1 cmVfb3ZuX3BraSBvZiA8b3RvcGkucGx1Z2lucy5vdmlydF9lbmdpbmVfc2V0dXAub3ZpcnRfZW5n aW5lLm5ldHdvcmsub3ZpcnRwcm92aWRlcm92bi5QbHVnaW4gb2JqZWN0IGF0IDB4MzAwODdkMD4+ LCAnY29uZGl0aW9uJzogPGJvdW5kIG1ldGhvZCA/LjxsYW1iZGE+IG9mIDxvdG9waS5wbHVnaW5z Lm92aXJ0X2VuZ2luZV9zZXR1cC5vdmlydF9lbmdpbmUubmV0d29yay5vdmlydHByb3ZpZGVyb3Zu LlBsdWdpbiBvYmplY3QgYXQgMHgzMDA4N2QwPj4sICdzdGFnZSc6IDExfQpbIEVSUk9SIF0gImJl Zm9yZSIgcGFyYW1ldGVyIG9mIG1ldGhvZCBvdG9waS5wbHVnaW5zLm92aXJ0X2VuZ2luZV9zZXR1 cC5vdmlydF9lbmdpbmUubmV0d29yay5vdmlydHByb3ZpZGVyb3ZuLlBsdWdpbi5fbWlzY19jb25m aWd1cmVfcHJvdmlkZXIgaXMgYSBzdHJpbmcsIHNob3VsZCBwcm9iYWJseSBiZSBhIHR1cGxlLiBQ ZXJoYXBzIGEgbWlzc2luZyBjb21tYT8KICAgICAgICAgIG1ldGhvZGluZm86IHsncHJpb3JpdHkn OiA1MDAwLCAnbmFtZSc6IE5vbmUsICdiZWZvcmUnOiAnb3NldHVwLm92bi5wcm92aWRlci5zZXJ2 aWNlLnJlc3RhcnQnLCAnYWZ0ZXInOiAoJ29zZXR1cC5wa2kuY2EuYXZhaWxhYmxlJywgJ29zZXR1 cC5vdm4uc2VydmljZXMucmVzdGFydCcpLCAnbWV0aG9kJzogPGJvdW5kIG1ldGhvZCA/Ll9taXNj X2NvbmZpZ3VyZV9wcm92aWRlciBvZiA8b3RvcGkucGx1Z2lucy5vdmlydF9lbmdpbmVfc2V0dXAu b3ZpcnRfZW5naW5lLm5ldHdvcmsub3ZpcnRwcm92aWRlcm92bi5QbHVnaW4gb2JqZWN0IGF0IDB4 MzAwODdkMD4+LCAnY29uZGl0aW9uJzogPGJvdW5kIG1ldGhvZCA/LjxsYW1iZGE+IG9mIDxvdG9w aS5wbHVnaW5zLm92aXJ0X2VuZ2luZV9zZXR1cC5vdmlydF9lbmdpbmUubmV0d29yay5vdmlydHBy b3ZpZGVyb3ZuLlBsdWdpbiBvYmplY3QgYXQgMHgzMDA4N2QwPj4sICdzdGFnZSc6IDExfQpbIEVS Uk9SIF0gRmFpbGVkIHRvIGV4ZWN1dGUgc3RhZ2UgJ0Vudmlyb25tZW50IHNldHVwJzogRm91bmQg YmFkICJiZWZvcmUiIG9yICJhZnRlciIgcGFyYW1ldGVycwpbIElORk8gIF0gU3RhZ2U6IENsZWFu IHVwCiAgICAgICAgICBMb2cgZmlsZSBpcyBsb2NhdGVkIGF0IC9ob21lL2d1b3NzNC9vdmlydC1l bmdpbmUvdmFyL2xvZy9vdmlydC1lbmdpbmUvc2V0dXAvb3ZpcnQtZW5naW5lLXNldHVwLTIwMTgw NDI3MDAxNTI4LTZoN3NucC5sb2cKWyBFUlJPUiBdIEZhaWxlZCB0byBleGVjdXRlIHN0YWdlICdD bGVhbiB1cCc6ICdOb25lVHlwZScgb2JqZWN0IGhhcyBubyBhdHRyaWJ1dGUgJ2NsZWFudXAnClsg SU5GTyAgXSBHZW5lcmF0aW5nIGFuc3dlciBmaWxlICcvaG9tZS9ndW9zczQvb3ZpcnQtZW5naW5l L3Zhci9saWIvb3ZpcnQtZW5naW5lL3NldHVwL2Fuc3dlcnMvMjAxODA0MjcwMDE1MzEtc2V0dXAu Y29uZicKWyBJTkZPICBdIFN0YWdlOiBQcmUtdGVybWluYXRpb24KWyBJTkZPICBdIFN0YWdlOiBU ZXJtaW5hdGlvbgpbIEVSUk9SIF0gRXhlY3V0aW9uIG9mIHNldHVwIGZhaWxlZAo= --=-sinamail_alt_b07360d2a984dc30f8d3dd33c45e1d37 Content-Type: text/html; charset=GBK Content-Transfer-Encoding: base64 Content-Disposition: inline PGRpdj5IaTwvZGl2PjxkaXY+Jm5ic3A7SSBlbmdpbmUgc2V0dXAgZmFjZXMgc29tZSBlcnJvci48 L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PiZuYnNwO0kgdHJ5IHRvIHNvbHV0ZSBpdCBhbmQmbmJz cDsgaXQgaXMgd29yay4gaGVyZSBpcyBteSBwYXRjaC4gQnV0Jm5ic3A7IG5vdCBzdXJlIGl0IGlz IHJpZ2h0PzwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+Jm5ic3A7JEhP TUUvb3ZpcnQtZW5naW5lL2Jpbi9lbmdpbmUtc2V0dXA8L2Rpdj5bJm5ic3A7SU5GTyZuYnNwOyZu YnNwO10mbmJzcDtTdGFnZTombmJzcDtJbml0aWFsaXppbmc8YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7U2V0dXAmbmJzcDt3YXMm bmJzcDtydW4mbmJzcDt1bmRlciZuYnNwO3VucHJpdmlsZWdlZCZuYnNwO3VzZXImbmJzcDt0aGlz Jm5ic3A7d2lsbCZuYnNwO3Byb2R1Y2UmbmJzcDtkZXZlbG9wbWVudCZuYnNwO2luc3RhbGxhdGlv biZuYnNwO2RvJm5ic3A7eW91Jm5ic3A7d2lzaCZuYnNwO3RvJm5ic3A7cHJvY2VlZD8mbmJzcDso WWVzLCZuYnNwO05vKSZuYnNwO1tOb106Jm5ic3A7eWVzPGJyPlsmbmJzcDtJTkZPJm5ic3A7Jm5i c3A7XSZuYnNwO1N0YWdlOiZuYnNwO0Vudmlyb25tZW50Jm5ic3A7c2V0dXA8YnI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Q29uZmln dXJhdGlvbiZuYnNwO2ZpbGVzOiZuYnNwO1tdPGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO0xvZyZuYnNwO2ZpbGU6Jm5ic3A7L2hv bWUvZ3Vvc3M0L292aXJ0LWVuZ2luZS92YXIvbG9nL292aXJ0LWVuZ2luZS9zZXR1cC9vdmlydC1l bmdpbmUtc2V0dXAtMjAxODA0MjcwMDE1MjgtNmg3c25wLmxvZzxicj4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtWZXJzaW9uOiZuYnNw O290b3BpLTEuOC4wX21hc3RlciZuYnNwOyhvdG9waS0xLjguMC0wLjAubWFzdGVyLjIwMTgwMzEz MDg0MTE0LmdpdDRlNzg4ZjkuZWw3LmNlbnRvcyk8YnI+WyZuYnNwO0VSUk9SJm5ic3A7XSZuYnNw OyJiZWZvcmUiJm5ic3A7cGFyYW1ldGVyJm5ic3A7b2YmbmJzcDttZXRob2QmbmJzcDtvdG9waS5w bHVnaW5zLm92aXJ0X2VuZ2luZV9zZXR1cC5vdmlydF9lbmdpbmUubmV0d29yay5vdmlydHByb3Zp ZGVyb3ZuLlBsdWdpbi5fbWlzY19jb25maWd1cmVfb3ZuX3BraSZuYnNwO2lzJm5ic3A7YSZuYnNw O3N0cmluZywmbmJzcDtzaG91bGQmbmJzcDtwcm9iYWJseSZuYnNwO2JlJm5ic3A7YSZuYnNwO3R1 cGxlLiZuYnNwO1BlcmhhcHMmbmJzcDthJm5ic3A7bWlzc2luZyZuYnNwO2NvbW1hPzxicj4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtt ZXRob2RpbmZvOiZuYnNwO3sncHJpb3JpdHknOiZuYnNwOzUwMDAsJm5ic3A7J25hbWUnOiZuYnNw O05vbmUsJm5ic3A7J2JlZm9yZSc6Jm5ic3A7J29zZXR1cC5vdm4ucHJvdmlkZXIuc2VydmljZS5y ZXN0YXJ0JywmbmJzcDsnYWZ0ZXInOiZuYnNwOygnPGltZyBzcmM9ImZpbGU6Ly8vQzpcVXNlcnNc ZHVoeTJcQXBwRGF0YVxSb2FtaW5nXFRlbmNlbnRcUVFcVGVtcFwlV0BHSiRBQ09GKFRZRFlFQ09L VkRZQi5wbmciPm9zZXR1cC5wa2kuY2EuYXZhaWxhYmxlJywmbmJzcDsnb3NldHVwLm92bi5zZXJ2 aWNlcy5yZXN0YXJ0JyksJm5ic3A7J21ldGhvZCc6Jm5ic3A7Jmx0O2JvdW5kJm5ic3A7bWV0aG9k Jm5ic3A7Py5fbWlzY19jb25maWd1cmVfb3ZuX3BraSZuYnNwO29mJm5ic3A7Jmx0O290b3BpLnBs dWdpbnMub3ZpcnRfZW5naW5lX3NldHVwLm92aXJ0X2VuZ2luZS5uZXR3b3JrLm92aXJ0cHJvdmlk ZXJvdm4uUGx1Z2luJm5ic3A7b2JqZWN0Jm5ic3A7YXQmbmJzcDsweDMwMDg3ZDAmZ3Q7Jmd0Oywm bmJzcDsnY29uZGl0aW9uJzombmJzcDsmbHQ7Ym91bmQmbmJzcDttZXRob2QmbmJzcDs/LiZsdDts YW1iZGEmZ3Q7Jm5ic3A7b2YmbmJzcDsmbHQ7b3RvcGkucGx1Z2lucy5vdmlydF9lbmdpbmVfc2V0 dXAub3ZpcnRfZW5naW5lLm5ldHdvcmsub3ZpcnRwcm92aWRlcm92bi5QbHVnaW4mbmJzcDtvYmpl Y3QmbmJzcDthdCZuYnNwOzB4MzAwODdkMCZndDsmZ3Q7LCZuYnNwOydzdGFnZSc6Jm5ic3A7MTF9 PGJyPlsmbmJzcDtFUlJPUiZuYnNwO10mbmJzcDsiYmVmb3JlIiZuYnNwO3BhcmFtZXRlciZuYnNw O29mJm5ic3A7bWV0aG9kJm5ic3A7b3RvcGkucGx1Z2lucy5vdmlydF9lbmdpbmVfc2V0dXAub3Zp cnRfZW5naW5lLm5ldHdvcmsub3ZpcnRwcm92aWRlcm92bi5QbHVnaW4uX21pc2NfY29uZmlndXJl X3Byb3ZpZGVyJm5ic3A7aXMmbmJzcDthJm5ic3A7c3RyaW5nLCZuYnNwO3Nob3VsZCZuYnNwO3By b2JhYmx5Jm5ic3A7YmUmbmJzcDthJm5ic3A7dHVwbGUuJm5ic3A7UGVyaGFwcyZuYnNwO2EmbmJz cDttaXNzaW5nJm5ic3A7Y29tbWE/PGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO21ldGhvZGluZm86Jm5ic3A7eydwcmlvcml0eSc6 Jm5ic3A7NTAwMCwmbmJzcDsnbmFtZSc6Jm5ic3A7Tm9uZSwmbmJzcDsnYmVmb3JlJzombmJzcDsn b3NldHVwLm92bi5wcm92aWRlci5zZXJ2aWNlLnJlc3RhcnQnLCZuYnNwOydhZnRlcic6Jm5ic3A7 KCc8aW1nIHNyYz0iZmlsZTovLy9DOlxVc2Vyc1xkdWh5MlxBcHBEYXRhXFJvYW1pbmdcVGVuY2Vu dFxRUVxUZW1wXCVXQEdKJEFDT0YoVFlEWUVDT0tWRFlCLnBuZyI+b3NldHVwLnBraS5jYS5hdmFp bGFibGUnLCZuYnNwOydvc2V0dXAub3ZuLnNlcnZpY2VzLnJlc3RhcnQnKSwmbmJzcDsnbWV0aG9k JzombmJzcDsmbHQ7Ym91bmQmbmJzcDttZXRob2QmbmJzcDs/Ll9taXNjX2NvbmZpZ3VyZV9wcm92 aWRlciZuYnNwO29mJm5ic3A7Jmx0O290b3BpLnBsdWdpbnMub3ZpcnRfZW5naW5lX3NldHVwLm92 aXJ0X2VuZ2luZS5uZXR3b3JrLm92aXJ0cHJvdmlkZXJvdm4uUGx1Z2luJm5ic3A7b2JqZWN0Jm5i c3A7YXQmbmJzcDsweDMwMDg3ZDAmZ3Q7Jmd0OywmbmJzcDsnY29uZGl0aW9uJzombmJzcDsmbHQ7 Ym91bmQmbmJzcDttZXRob2QmbmJzcDs/LiZsdDtsYW1iZGEmZ3Q7Jm5ic3A7b2YmbmJzcDsmbHQ7 b3RvcGkucGx1Z2lucy5vdmlydF9lbmdpbmVfc2V0dXAub3ZpcnRfZW5naW5lLm5ldHdvcmsub3Zp cnRwcm92aWRlcm92bi5QbHVnaW4mbmJzcDtvYmplY3QmbmJzcDthdCZuYnNwOzB4MzAwODdkMCZn dDsmZ3Q7LCZuYnNwOydzdGFnZSc6Jm5ic3A7MTF9PGJyPlsmbmJzcDtFUlJPUiZuYnNwO10mbmJz cDtGYWlsZWQmbmJzcDt0byZuYnNwO2V4ZWN1dGUmbmJzcDtzdGFnZSZuYnNwOydFbnZpcm9ubWVu dCZuYnNwO3NldHVwJzombmJzcDtGb3VuZCZuYnNwO2JhZCZuYnNwOyJiZWZvcmUiJm5ic3A7b3Im bmJzcDsiYWZ0ZXIiJm5ic3A7cGFyYW1ldGVyczxicj5bJm5ic3A7SU5GTyZuYnNwOyZuYnNwO10m bmJzcDtTdGFnZTombmJzcDtDbGVhbiZuYnNwO3VwPGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO0xvZyZuYnNwO2ZpbGUmbmJzcDtp cyZuYnNwO2xvY2F0ZWQmbmJzcDthdCZuYnNwOy9ob21lL2d1b3NzNC9vdmlydC1lbmdpbmUvdmFy L2xvZy9vdmlydC1lbmdpbmUvc2V0dXAvb3ZpcnQtZW5naW5lLXNldHVwLTIwMTgwNDI3MDAxNTI4 LTZoN3NucC5sb2c8YnI+WyZuYnNwO0VSUk9SJm5ic3A7XSZuYnNwO0ZhaWxlZCZuYnNwO3RvJm5i c3A7ZXhlY3V0ZSZuYnNwO3N0YWdlJm5ic3A7J0NsZWFuJm5ic3A7dXAnOiZuYnNwOydOb25lVHlw ZScmbmJzcDtvYmplY3QmbmJzcDtoYXMmbmJzcDtubyZuYnNwO2F0dHJpYnV0ZSZuYnNwOydjbGVh bnVwJzxicj5bJm5ic3A7SU5GTyZuYnNwOyZuYnNwO10mbmJzcDtHZW5lcmF0aW5nJm5ic3A7YW5z d2VyJm5ic3A7ZmlsZSZuYnNwOycvaG9tZS9ndW9zczQvb3ZpcnQtZW5naW5lL3Zhci9saWIvb3Zp cnQtZW5naW5lL3NldHVwL2Fuc3dlcnMvMjAxODA0MjcwMDE1MzEtc2V0dXAuY29uZic8YnI+WyZu YnNwO0lORk8mbmJzcDsmbmJzcDtdJm5ic3A7U3RhZ2U6Jm5ic3A7UHJlLXRlcm1pbmF0aW9uPGJy PlsmbmJzcDtJTkZPJm5ic3A7Jm5ic3A7XSZuYnNwO1N0YWdlOiZuYnNwO1Rlcm1pbmF0aW9uPGJy PlsmbmJzcDtFUlJPUiZuYnNwO10mbmJzcDtFeGVjdXRpb24mbmJzcDtvZiZuYnNwO3NldHVwJm5i c3A7ZmFpbGVkPGJyPg== --=-sinamail_alt_b07360d2a984dc30f8d3dd33c45e1d37-- --=-sinamail_mix_c101082a388e342a957d987294109e01 Content-Type: application/octet-stream; name="=?GBK?B?MDAwMS1maXhlZC1lbmdpbmUtc2V0dXAtZXJyb3IucGF0Y2g=?=" Content-Disposition: attachment; filename="=?GBK?B?MDAwMS1maXhlZC1lbmdpbmUtc2V0dXAtZXJyb3IucGF0Y2g=?=" Content-Transfer-Encoding: base64 RnJvbSAyMjQ2M2RkZjQ2MzFkODRiZTMyY2IyY2I1OGUyZTA5M2YzN2E0NjI3IE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBIb25neXUgRHUgPGR1aG9uZ3l1bGludXhAZ21haWwuY29tPgpE YXRlOiBGcmksIDI3IEFwciAyMDE4IDEyOjI0OjI2ICswODAwClN1YmplY3Q6IFtQQVRDSF0gZml4 ZWQgZW5naW5lIHNldHVwIGVycm9yCgpTaWduZWQtb2ZmLWJ5OiBIb25neXUgRHUgPGR1aG9uZ3l1 bGludXhAZ21haWwuY29tPgotLS0KIC4uLi9vdmlydC1lbmdpbmUtc2V0dXAvb3ZpcnQtZW5naW5l L25ldHdvcmsvb3ZpcnRwcm92aWRlcm92bi5weSAgICAgICB8IDQgKystLQogMSBmaWxlIGNoYW5n ZWQsIDIgaW5zZXJ0aW9ucygrKSwgMiBkZWxldGlvbnMoLSkKCmRpZmYgLS1naXQgYS9wYWNrYWdp bmcvc2V0dXAvcGx1Z2lucy9vdmlydC1lbmdpbmUtc2V0dXAvb3ZpcnQtZW5naW5lL25ldHdvcmsv b3ZpcnRwcm92aWRlcm92bi5weSBiL3BhY2thZ2luZy9zZXR1cC9wbHVnaW5zL292aXJ0LWVuZ2lu ZS1zZXR1cC9vdmlydC1lbmdpbmUvbmV0d29yay9vdmlydHByb3ZpZGVyb3ZuLnB5CmluZGV4IDFj NDU3MzcuLmFlYTE0NjQgMTAwNjQ0Ci0tLSBhL3BhY2thZ2luZy9zZXR1cC9wbHVnaW5zL292aXJ0 LWVuZ2luZS1zZXR1cC9vdmlydC1lbmdpbmUvbmV0d29yay9vdmlydHByb3ZpZGVyb3ZuLnB5Cisr KyBiL3BhY2thZ2luZy9zZXR1cC9wbHVnaW5zL292aXJ0LWVuZ2luZS1zZXR1cC9vdmlydC1lbmdp bmUvbmV0d29yay9vdmlydHByb3ZpZGVyb3ZuLnB5CkBAIC03ODEsNyArNzgxLDcgQEAgY2xhc3Mg UGx1Z2luKHBsdWdpbi5QbHVnaW5CYXNlKToKICAgICBAcGx1Z2luLmV2ZW50KAogICAgICAgICBz dGFnZT1wbHVnaW4uU3RhZ2VzLlNUQUdFX01JU0MsCiAgICAgICAgIGJlZm9yZT0oCi0gICAgICAg ICAgICBvZW5naW5lY29ucy5TdGFnZXMuT1ZOX1BST1ZJREVSX1NFUlZJQ0VfUkVTVEFSVAorICAg ICAgICAgICAgb2VuZ2luZWNvbnMuU3RhZ2VzLk9WTl9QUk9WSURFUl9TRVJWSUNFX1JFU1RBUlQs CiAgICAgICAgICksCiAgICAgICAgIGFmdGVyPSgKICAgICAgICAgICAgIG9lbmdpbmVjb25zLlN0 YWdlcy5DQV9BVkFJTEFCTEUsCkBAIC03OTYsNyArNzk2LDcgQEAgY2xhc3MgUGx1Z2luKHBsdWdp bi5QbHVnaW5CYXNlKToKICAgICBAcGx1Z2luLmV2ZW50KAogICAgICAgICBzdGFnZT1wbHVnaW4u U3RhZ2VzLlNUQUdFX01JU0MsCiAgICAgICAgIGJlZm9yZT0oCi0gICAgICAgICAgICBvZW5naW5l Y29ucy5TdGFnZXMuT1ZOX1BST1ZJREVSX1NFUlZJQ0VfUkVTVEFSVAorICAgICAgICAgICAgb2Vu Z2luZWNvbnMuU3RhZ2VzLk9WTl9QUk9WSURFUl9TRVJWSUNFX1JFU1RBUlQsCiAgICAgICAgICks CiAgICAgICAgIGFmdGVyPSgKICAgICAgICAgICAgIG9lbmdpbmVjb25zLlN0YWdlcy5DQV9BVkFJ TEFCTEUsCi0tIAoxLjguMy4xCgo= --=-sinamail_mix_c101082a388e342a957d987294109e01--

2 1

Cannot install ovirt-hosted-engine-setup as package has file conflicts in its dependancies
by Sam McLeod 30 Apr '18

30 Apr '18

--Apple-Mail=_5ADEE8C9-36EA-45DC-B5A8-E5BBE7A7427D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii This started occurring on all new oVirt installs I've attempted to do on = minimal CentOS 7 since 27/4. I logged a bug for this on Bugzilla last week: = https://bugzilla.redhat.com/show_bug.cgi?id=3D1572434 = <https://bugzilla.redhat.com/show_bug.cgi?id=3D1572434> The package ovirt-hosted-engine-setup depends on collectd, collectd-disk = and collectd-write_http. ovirt-hosted-engine-setup depends on the two collectd plugins which are = provided by the ovirt-4.2-centos-opstools repo - but those two packages = seem to provide files that are already included in the standard collectd = package from epel (which the package also depends on). Additionally, this conflict is not picked up until the packages are at = the install phase, resulting in: Transaction check error: file /usr/lib64/collectd/disk.so conflicts between attempted installs = of collectd-disk-5.8.0-3.el7.x86_64 and collectd-5.8.0-3.el7.x86_64 file /usr/lib64/collectd/write_http.so conflicts between attempted = installs of collectd-write_http-5.8.0-3.el7.x86_64 and = collectd-5.8.0-3.el7.x86_64 --- root@s1-b2:~ 1 # yum info collectd-write_http Loaded plugins: fastestmirror, priorities, protectbase, rpm-warm-cache, = versionlock Loading mirror speeds from cached hostfile * ovirt-4.2-epel: fedora.melbourneitmirror.net 0 packages excluded due to repository protections Available Packages Name : collectd-write_http Arch : x86_64 Version : 5.8.0 Release : 3.el7 Size : 33 k Repo : ovirt-4.2-centos-opstools/x86_64 Summary : HTTP output plugin for collectd URL : https://collectd.org/ <https://collectd.org/> License : MIT and GPLv2 Description : This plugin can send data to Redis. root@s1-b2:~ # yum info collectd-disk-5.8.0-3.el7.x86_64 Loaded plugins: fastestmirror, priorities, protectbase, rpm-warm-cache, = versionlock Loading mirror speeds from cached hostfile * ovirt-4.2-epel: fedora.melbourneitmirror.net 0 packages excluded due to repository protections Available Packages Name : collectd-disk Arch : x86_64 Version : 5.8.0 Release : 3.el7 Size : 26 k Repo : ovirt-4.2-centos-opstools/x86_64 Summary : Disk plugin for collectd URL : https://collectd.org/ <https://collectd.org/> License : MIT and GPLv2 Description : This plugin collects statistics of harddisk and, where = supported, partitions. root@s1-b2:~ # yum info collectd-5.8.0-3.el7.x86_64 Loaded plugins: fastestmirror, priorities, protectbase, rpm-warm-cache, = versionlock Loading mirror speeds from cached hostfile * ovirt-4.2-epel: fedora.melbourneitmirror.net 0 packages excluded due to repository protections Available Packages Name : collectd Arch : x86_64 Version : 5.8.0 Release : 3.el7 Size : 711 k Repo : epel Summary : Statistics collection daemon for filling RRD files URL : https://collectd.org/ <https://collectd.org/> License : GPLv2 Description : collectd is a daemon which collects system performance = statistics periodically : and provides mechanisms to store the values in a variety = of ways, : for example in RRD files. -- Sam McLeod Please respond via email when possible. https://smcleod.net https://twitter.com/s_mcleod --Apple-Mail=_5ADEE8C9-36EA-45DC-B5A8-E5BBE7A7427D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii <html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; = charset=3Dus-ascii"></head><body style=3D"word-wrap: break-word; = -webkit-nbsp-mode: space; line-break: after-white-space;" class=3D""><div = class=3D"">This started occurring on all new oVirt installs I've = attempted to do on minimal CentOS 7 since 27/4.</div><div class=3D""><br = class=3D""></div>I logged a bug for this on Bugzilla last week: <a = href=3D"https://bugzilla.redhat.com/show_bug.cgi?id=3D1572434" = class=3D"">https://bugzilla.redhat.com/show_bug.cgi?id=3D1572434</a><div = class=3D""><br class=3D""></div><div class=3D"">The = package ovirt-hosted-engine-setup depends on collectd, = collectd-disk and collectd-write_http.</div><div class=3D""><br = class=3D""></div><div class=3D"">ovirt-hosted-engine-setup depends on = the two collectd plugins which are provided by the = ovirt-4.2-centos-opstools repo - but those two packages seem to provide = files that are already included in the standard collectd package from = epel (which the package also depends on).</div><div class=3D""><br = class=3D""></div><div class=3D"">Additionally, this conflict is not = picked up until the packages are at the install phase, resulting = in:</div><div class=3D""><br class=3D""></div><div class=3D""><pre = class=3D" bz_comment_text bz_wrap_comment_text" id=3D"comment_text_0">Transaction check error: file /usr/lib64/collectd/disk.so conflicts between attempted installs = of collectd-disk-5.8.0-3.el7.x86_64 and collectd-5.8.0-3.el7.x86_64 file /usr/lib64/collectd/write_http.so conflicts between attempted = installs of collectd-write_http-5.8.0-3.el7.x86_64 and = collectd-5.8.0-3.el7.x86_64</pre><pre class=3D" bz_comment_text bz_wrap_comment_text" id=3D"comment_text_0"><br class=3D""></pre><pre = class=3D" bz_comment_text bz_wrap_comment_text" id=3D"comment_text_0">---</pre><pre class=3D" = bz_comment_text bz_wrap_comment_text" id=3D"comment_text_0"><br class=3D""></pre><pre = class=3D" bz_comment_text bz_wrap_comment_text" id=3D"comment_text_0"><pre class=3D" = bz_comment_text bz_wrap_comment_text" id=3D"comment_text_2">root@s1-b2:~ 1 # yum info = collectd-write_http Loaded plugins: fastestmirror, priorities, protectbase, rpm-warm-cache, = versionlock Loading mirror speeds from cached hostfile * ovirt-4.2-epel: <a href=3D"http://fedora.melbourneitmirror.net" = class=3D"">fedora.melbourneitmirror.net</a> 0 packages excluded due to repository protections Available Packages Name : collectd-write_http Arch : x86_64 Version : 5.8.0 Release : 3.el7 Size : 33 k Repo : ovirt-4.2-centos-opstools/x86_64 Summary : HTTP output plugin for collectd URL : <a href=3D"https://collectd.org/" = class=3D"">https://collectd.org/</a> License : MIT and GPLv2 Description : This plugin can send data to Redis. root@s1-b2:~ # yum info collectd-disk-5.8.0-3.el7.x86_64 Loaded plugins: fastestmirror, priorities, protectbase, rpm-warm-cache, = versionlock Loading mirror speeds from cached hostfile * ovirt-4.2-epel: <a href=3D"http://fedora.melbourneitmirror.net" = class=3D"">fedora.melbourneitmirror.net</a> 0 packages excluded due to repository protections Available Packages Name : collectd-disk Arch : x86_64 Version : 5.8.0 Release : 3.el7 Size : 26 k Repo : ovirt-4.2-centos-opstools/x86_64 Summary : Disk plugin for collectd URL : <a href=3D"https://collectd.org/" = class=3D"">https://collectd.org/</a> License : MIT and GPLv2 Description : This plugin collects statistics of harddisk and, where = supported, partitions. root@s1-b2:~ # yum info collectd-5.8.0-3.el7.x86_64 Loaded plugins: fastestmirror, priorities, protectbase, rpm-warm-cache, = versionlock Loading mirror speeds from cached hostfile * ovirt-4.2-epel: <a href=3D"http://fedora.melbourneitmirror.net" = class=3D"">fedora.melbourneitmirror.net</a> 0 packages excluded due to repository protections Available Packages Name : collectd Arch : x86_64 Version : 5.8.0 Release : 3.el7 Size : 711 k Repo : epel Summary : Statistics collection daemon for filling RRD files URL : <a href=3D"https://collectd.org/" = class=3D"">https://collectd.org/</a> License : GPLv2 Description : collectd is a daemon which collects system performance = statistics periodically : and provides mechanisms to store the values in a variety = of ways, : for example in RRD files.</pre><div class=3D""><br = class=3D""></div></pre><div class=3D""> <br class=3D"">--<br class=3D"">Sam McLeod<br class=3D"">Please respond = via email when possible.<br class=3D""><a href=3D"https://smcleod.net" = class=3D"">https://smcleod.net</a><br = class=3D"">https://twitter.com/s_mcleod </div> <br class=3D""></div></body></html>= --Apple-Mail=_5ADEE8C9-36EA-45DC-B5A8-E5BBE7A7427D--

2 4

Remove Host Device Error
by gsswzt＠pku.edu.cn 29 Apr '18

29 Apr '18

This is a multi-part message in MIME format. ------=_001_NextPart321267004745_=---- Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: base64 IEhpLA0KDQpJIGdvdCB0aGlzIGxvZyBpbiAvdmFyL2xvZy9vdmlydC1lbmdpbmUvZW5naW5lLmxv Zywgd2hlbiBJIHJlbW92ZSBhIGhvc3QgcGFzcyB0aHJvdWdoIFNDU0kgZGV2aWNlIGluIFZNLg0K DQoyMDE4LTA0LTI4IDEyOjIzOjE0LDU2OCswOCBFUlJPUiBbb3JnLm92aXJ0LmVuZ2luZS5jb3Jl LmJsbC5ob3N0ZGV2LlJlbW92ZVZtSG9zdERldmljZXNDb21tYW5kXSAoZGVmYXVsdCB0YXNrLTkp IFs3ZDEwZWI0OS0zMjhlLTRjZGUtODliOS0zZjNlN2U5ZDM2NjZdIENvbW1hbmQgJ29yZy5vdmly dC5lbmdpbmUuY29yZS5ibGwuaG9zdGRldi5SZW1vdmVWbUhvc3REZXZpY2VzQ29tbWFuZCcgZmFp bGVkOiBudWxsDQoyMDE4LTA0LTI4IDEyOjIzOjE0LDU2OCswOCBFUlJPUiBbb3JnLm92aXJ0LmVu Z2luZS5jb3JlLmJsbC5ob3N0ZGV2LlJlbW92ZVZtSG9zdERldmljZXNDb21tYW5kXSAoZGVmYXVs dCB0YXNrLTkpIFs3ZDEwZWI0OS0zMjhlLTRjZGUtODliOS0zZjNlN2U5ZDM2NjZdIEV4Y2VwdGlv bjogamF2YS5sYW5nLk51bGxQb2ludGVyRXhjZXB0aW9uDQogICAgICAgIGF0IG9yZy5vdmlydC5l bmdpbmUuY29yZS5ibGwuaG9zdGRldi5SZW1vdmVWbUhvc3REZXZpY2VzQ29tbWFuZC5leGVjdXRl Q29tbWFuZChSZW1vdmVWbUhvc3REZXZpY2VzQ29tbWFuZC5qYXZhOjY0KSBbYmxsLmphcjpdDQog ICAgICAgIGF0IG9yZy5vdmlydC5lbmdpbmUuY29yZS5ibGwuQ29tbWFuZEJhc2UuZXhlY3V0ZVdp dGhvdXRUcmFuc2FjdGlvbihDb21tYW5kQmFzZS5qYXZhOjEyMDUpIFtibGwuamFyOl0NCiAgICAg ICAgYXQgb3JnLm92aXJ0LmVuZ2luZS5jb3JlLmJsbC5Db21tYW5kQmFzZS5leGVjdXRlQWN0aW9u SW5UcmFuc2FjdGlvblNjb3BlKENvbW1hbmRCYXNlLmphdmE6MTM0NSkgW2JsbC5qYXI6XQ0KICAg ICAgICBhdCBvcmcub3ZpcnQuZW5naW5lLmNvcmUuYmxsLkNvbW1hbmRCYXNlLnJ1bkluVHJhbnNh Y3Rpb24oQ29tbWFuZEJhc2UuamF2YToxOTg3KSBbYmxsLmphcjpdDQogICAgICAgIGF0IG9yZy5v dmlydC5lbmdpbmUuY29yZS51dGlscy50cmFuc2FjdGlvbi5UcmFuc2FjdGlvblN1cHBvcnQuZXhl Y3V0ZUluTmV3VHJhbnNhY3Rpb24oVHJhbnNhY3Rpb25TdXBwb3J0LmphdmE6MjAyKSBbdXRpbHMu amFyOl0NCiAgICAgICAgYXQgb3JnLm92aXJ0LmVuZ2luZS5jb3JlLnV0aWxzLnRyYW5zYWN0aW9u LlRyYW5zYWN0aW9uU3VwcG9ydC5leGVjdXRlSW5SZXF1aXJlZChUcmFuc2FjdGlvblN1cHBvcnQu amF2YToxMzcpIFt1dGlscy5qYXI6XQ0KICAgICAgICBhdCBvcmcub3ZpcnQuZW5naW5lLmNvcmUu dXRpbHMudHJhbnNhY3Rpb24uVHJhbnNhY3Rpb25TdXBwb3J0LmV4ZWN1dGVJblNjb3BlKFRyYW5z YWN0aW9uU3VwcG9ydC5qYXZhOjEwNSkgW3V0aWxzLmphcjpdDQogICAgICAgIGF0IG9yZy5vdmly dC5lbmdpbmUuY29yZS5ibGwuQ29tbWFuZEJhc2UuZXhlY3V0ZShDb21tYW5kQmFzZS5qYXZhOjE0 MDUpIFtibGwuamFyOl0NCiAgICAgICAgYXQgb3JnLm92aXJ0LmVuZ2luZS5jb3JlLmJsbC5Db21t YW5kQmFzZS5leGVjdXRlQWN0aW9uKENvbW1hbmRCYXNlLmphdmE6NDEyKSBbYmxsLmphcjpdDQog ICAgICAgIGF0IG9yZy5vdmlydC5lbmdpbmUuY29yZS5ibGwuZXhlY3V0b3IuRGVmYXVsdEJhY2tl bmRBY3Rpb25FeGVjdXRvci5leGVjdXRlKERlZmF1bHRCYWNrZW5kQWN0aW9uRXhlY3V0b3IuamF2 YToxMykgW2JsbC5qYXI6XQ0KICAgICAgICBhdCBvcmcub3ZpcnQuZW5naW5lLmNvcmUuYmxsLkJh Y2tlbmQucnVuQWN0aW9uKEJhY2tlbmQuamF2YTo1MDkpIFtibGwuamFyOl0NCiAgICAgICAgYXQg b3JnLm92aXJ0LmVuZ2luZS5jb3JlLmJsbC5CYWNrZW5kLnJ1bkFjdGlvbkltcGwoQmFja2VuZC5q YXZhOjQ5MSkgW2JsbC5qYXI6XQ0KICAgICAgICBhdCBvcmcub3ZpcnQuZW5naW5lLmNvcmUuYmxs LkJhY2tlbmQucnVuQWN0aW9uKEJhY2tlbmQuamF2YTo0NDQpIFtibGwuamFyOl0NCiAgICAgICAg YXQgc3VuLnJlZmxlY3QuR2VuZXJhdGVkTWV0aG9kQWNjZXNzb3IzNzAuaW52b2tlKFVua25vd24g U291cmNlKSBbOjEuOC4wXzE2MV0NCiAgICAgICAgYXQgc3VuLnJlZmxlY3QuRGVsZWdhdGluZ01l dGhvZEFjY2Vzc29ySW1wbC5pbnZva2UoRGVsZWdhdGluZ01ldGhvZEFjY2Vzc29ySW1wbC5qYXZh OjQzKSBbcnQuamFyOjEuOC4wXzE2MV0NCiAgICAgICAgYXQgamF2YS5sYW5nLnJlZmxlY3QuTWV0 aG9kLmludm9rZShNZXRob2QuamF2YTo0OTgpIFtydC5qYXI6MS44LjBfMTYxXQ0KDQo= ------=_001_NextPart321267004745_=---- Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html><head><meta http-equiv=3D"content-type" content=3D"text/html; charse= t=3Dus-ascii"><style>body { line-height: 1.5; }body { font-size: 10.5pt; f= ont-family: ????; color: rgb(0, 0, 0); line-height: 1.5; }</style></head><= body>=0A<div><span></span><span style=3D"color: rgb(0, 0, 0); background-c= olor: rgba(0, 0, 0, 0);"> Hi,</span></div><div><span style=3D"color: = rgb(0, 0, 0); background-color: rgba(0, 0, 0, 0);"><br></span></div><div><= span style=3D"color: rgb(0, 0, 0); background-color: rgba(0, 0, 0, 0);">I = got this log in /var/log/ovirt-engine/engine.log, when I remove a host pas= s through SCSI device in VM.</span></div><div><span style=3D"color: rgb(0,= 0, 0); background-color: rgba(0, 0, 0, 0);"><br></span></div><div><span s= tyle=3D"background-color: rgba(0, 0, 0, 0);"><div>2018-04-28 12:23:14,568+= 08 ERROR [org.ovirt.engine.core.bll.hostdev.RemoveVmHostDevicesCommand] (d= efault task-9) [7d10eb49-328e-4cde-89b9-3f3e7e9d3666] Command 'org.ovirt.e= ngine.core.bll.hostdev.RemoveVmHostDevicesCommand' failed: null</div><div>= 2018-04-28 12:23:14,568+08 ERROR [org.ovirt.engine.core.bll.hostdev.Remove= VmHostDevicesCommand] (default task-9) [7d10eb49-328e-4cde-89b9-3f3e7e9d36= 66] Exception: java.lang.NullPointerException</div><div>    &nbs= p;   at org.ovirt.engine.core.bll.hostdev.RemoveVmHostDevicesCommand.= executeCommand(RemoveVmHostDevicesCommand.java:64) [bll.jar:]</div><div>&n= bsp;       at org.ovirt.engine.core.bll.CommandBase.execute= WithoutTransaction(CommandBase.java:1205) [bll.jar:]</div><div>  &nbs= p;     at org.ovirt.engine.core.bll.CommandBase.executeActionInT= ransactionScope(CommandBase.java:1345) [bll.jar:]</div><div>    =     at org.ovirt.engine.core.bll.CommandBase.runInTransaction(Co= mmandBase.java:1987) [bll.jar:]</div><div>        at o= rg.ovirt.engine.core.utils.transaction.TransactionSupport.executeInNewTran= saction(TransactionSupport.java:202) [utils.jar:]</div><div>    =     at org.ovirt.engine.core.utils.transaction.TransactionSuppor= t.executeInRequired(TransactionSupport.java:137) [utils.jar:]</div><div>&n= bsp;       at org.ovirt.engine.core.utils.transaction.Trans= actionSupport.executeInScope(TransactionSupport.java:105) [utils.jar:]</di= v><div>        at org.ovirt.engine.core.bll.CommandBas= e.execute(CommandBase.java:1405) [bll.jar:]</div><div>     =   at org.ovirt.engine.core.bll.CommandBase.executeAction(CommandBase= .java:412) [bll.jar:]</div><div>        at org.ovirt.e= ngine.core.bll.executor.DefaultBackendActionExecutor.execute(DefaultBacken= dActionExecutor.java:13) [bll.jar:]</div><div>        = at org.ovirt.engine.core.bll.Backend.runAction(Backend.java:509) [bll.jar:= ]</div><div>        at org.ovirt.engine.core.bll.Backe= nd.runActionImpl(Backend.java:491) [bll.jar:]</div><div>    &nbs= p;   at org.ovirt.engine.core.bll.Backend.runAction(Backend.java:444)= [bll.jar:]</div><div>        at sun.reflect.Generated= MethodAccessor370.invoke(Unknown Source) [:1.8.0_161]</div><div>  &nb= sp;     at sun.reflect.DelegatingMethodAccessorImpl.invoke(Deleg= atingMethodAccessorImpl.java:43) [rt.jar:1.8.0_161]</div><div>  &nbsp= ;     at java.lang.reflect.Method.invoke(Method.java:498) [rt.ja= r:1.8.0_161]</div></span></div><div><span><div style=3D"MARGIN: 10px; FONT= -FAMILY: verdana; FONT-SIZE: 10pt"><br></div></span></div>=0A</body></html= > ------=_001_NextPart321267004745_=------

2 1

Mailing-Lists upgrade
by Marc Dequènes (Duck) 27 Apr '18

27 Apr '18

This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --IfGqXrbgT9wNNdIsvS8kI8WdhEQHlgkiq Content-Type: multipart/mixed; boundary="AUFHCWPQQknM84fF2kF4uGjIv4blC9bMv"; protected-headers="v1" From: =?UTF-8?B?TWFyYyBEZXF1w6huZXMgKER1Y2sp?= <duck(a)redhat.com> To: oVirt Infra <infra(a)ovirt.org>, users <users(a)ovirt.org>, devel <devel(a)ovirt.org> Message-ID: <c5c71fce-0290-e97a-ddd0-eab0e6fccea4(a)redhat.com> Subject: Mailing-Lists upgrade --AUFHCWPQQknM84fF2kF4uGjIv4blC9bMv Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Quack, On behalf of the oVirt infra team, I'd like to announce the current Mailing-Lists system is going to be upgraded to a brand new Mailman 3 installation on Monday during the slot 11:00-12:00 JST. It should not take a full hour to migrate as we already made incremental synchronization with the current system but better keep some margin. The system will then take over delivery of the mails but might be a bit slow at first as it needs to reindex all the archived mails (which might take a few hours). To manage your subscriptions and delivery settings you can do this easily on the much nicer web interface (https://lists.ovirt.org) There is a notion of account so you don't need to login separately for each ML.= You can Sign In using Fedora, GitHub or Google or create a local account if you prefer. Please keep in mind signing in with a different method would create separate accounts (which cannot be merged at the moment). But you can easily link your account to other authentication methods in your settings (click on you name in the up-right corner -> Account -> Account Connections). As for the original mail archives, because the previous system did not have stable URLs, we cannot create mappings to the new pages. We decided to keep the old archives around on the same URL (/pipermail), so the Internet links would still work fine. Hope you'd be happy with the new system. \_o< --AUFHCWPQQknM84fF2kF4uGjIv4blC9bMv-- --IfGqXrbgT9wNNdIsvS8kI8WdhEQHlgkiq Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEcpcqg+UmRT3yiF+BVen596wcRD8FAlmwx0MACgkQVen596wc RD9LTQ/+LtUncsq9K8D/LX8wqUTd6VyPwAD5UnAk5c3H/2tmyVA0u7FIfhEyPsXs Z//LE9FEneTDqDVRi1Dw9I54K0ZwxPBemi71dXfwgBI7Ay0ezkbLWrA168Mt9spE tHAODEuxPt2to2aqaS4ujogrkp/gvEP8ILoxPEqoTPCJ/eDTPAu/I1a2JzjMPK3n 2BBS6D8z0TLAf7w1n72TsgX2QzJW57ig/0HELyjvat2/K8V3HSrkwiKlsdULQDWe zB+aMde7r6UoyVKHqlu4asTl2tU/lGZ+e31Hd9Bnx1/oZOJdzslGOhEo9Qoz6763 AHWU9LKiK4NtxYHj2UQTWhndr8PiTtTmR73eIDmkb0cuRXxzjl9VQbwYJ0Kbrmfp attTqpc2CnEojTNXUUNSmNxotZoYXZiX8ZvjPfSgRVr15TUYujzlOfG+lUynbQMV 9rQ9/m58wgwYUymMpOIsRGaIcAKzjm+WpuuVnO+bS2AfmcBkGMQRoIhfV+3SkS8q kT9cDXgcDZOzVFcnZZB4EjbycMcPgZDcoHxU88VdYH+jFJYvvb21esgswVF/wJ2Z uEI/chp4+ADaQhl8ehZNWMSZq125v6SeirPhBNgLG7zFVZI1S9Tm/6qFmH+ajQY7 nCk1X9HZlB1ubex1X+HibRz9QKOilkMgkADyJ4yMDckwYj93sx0= =l6uN -----END PGP SIGNATURE----- --IfGqXrbgT9wNNdIsvS8kI8WdhEQHlgkiq--

2 4

How to change the interface when the host is being deployed?
by Xirinachs, Diego 27 Apr '18

27 Apr '18

Hi everyone! I am trying to setup ovirt for the first time. I have my ovirt-engine up and running and I am trying to add my first host to it. The problem I am having is that I have 4 interfaces, 2 of them unused. I would like ovirtmgmt bridge to be setup on ens15f1 interface which has a private ip of 10.10.10.9 on it. When I try to add the host to oVirt, I can see it attaches the ovirtmgmt bridge to one of the unused interfaces, this of course will never work, so I need a way of changing that to be ens15f1. I tried going into the "setup networks" part on the host and dragging the box over to the correct interface, but it complains with the following error: Cannot setup Networks. The following Networks' definitions on the Network Interfaces are different than those on the Logical Networks. Please synchronize the Network Interfaces before editing the networks: ovirtmgmt. So I go and try to synchronize networks which seems to finish successfully, but nothing happens ( So what I did was to manually go into the host, edit the interface files myself to make ovirtmgmt point to the correct interface. Is there a way to make the ovirt-engine aware of this? Or push the config from the host to the engine so that it syncs? What other things can I try? It seems really weird that the initial provisioning picks an interface that is down and no clear way to change it. Thanks for the help! Diego Xirinachs Akamai Technologies

1 0

vdsm hook noipspoof on interface level
by Peter Hudec 27 Apr '18

27 Apr '18

Hi, I would like to restrict of usage IP address on VMs. Thos could be achied by usinf clear-filter instead of vdsm-no-mac-spoofing. I have found noipspoof vdsm hook, https://github.com/oVirt/vdsm/tree/master/vdsm_hooks/noipspoof. This hook but set the filtering on all interfaces, the setting is on VM level, not interface level. So if the there are more interfaces on all of them. I would like just restrict the WAN interface on multi homed VMs. Peter -- *Peter Hudec* Infraštruktúrny architekt phudec(a)cnc.sk <mailto:phudec@cnc.sk> *CNC, a.s.* Borská 6, 841 04 Bratislava Recepcia: +421 2 35 000 100 Mobil:+421 905 997 203 *www.cnc.sk* <http:///www.cnc.sk>

2 3