Missing CPU features
by Bloemen, Jurriën
--_000_D180F3484A93jurrienbloemendmcamcnetworkscom_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
Hi all,
I try to add a new host to a new cluster but I get this message:
Host <hostname> moved to Non-Operational state as host does not meet the cl=
uster's minimum CPU level. Missing CPU features : model_Haswell
The engine.log shows:
2015-05-19 13:54:09,843 INFO [org.ovirt.engine.core.bll.ActivateVdsCommand=
] (ajp--127.0.0.1-8702-2) [a4e6c90] Lock Acquired to object EngineLock [exc=
lusiveLocks=3D key: 1ac98a04-41ed-40b7-8f02-e1b9cbbc5480 value: VDS
, sharedLocks=3D ]
2015-05-19 13:54:09,868 INFO [org.ovirt.engine.core.bll.ActivateVdsCommand=
] (org.ovirt.thread.pool-8-thread-14) [a4e6c90] Running command: ActivateVd=
sCommand internal: false. Entities affected : ID: 1ac98a04-41ed-40b7-8f02-=
e1b9cbbc5480 Type: VDSAction group MANIPULATE_HOST with role type ADMIN
2015-05-19 13:54:09,869 INFO [org.ovirt.engine.core.bll.ActivateVdsCommand=
] (org.ovirt.thread.pool-8-thread-14) [a4e6c90] Before acquiring lock in or=
der to prevent monitoring for host <hostname> from data-center DMC
2015-05-19 13:54:09,870 INFO [org.ovirt.engine.core.bll.ActivateVdsCommand=
] (org.ovirt.thread.pool-8-thread-14) [a4e6c90] Lock acquired, from now a m=
onitoring of host will be skipped for host <hostname> from data-center DMC
2015-05-19 13:54:09,885 INFO [org.ovirt.engine.core.vdsbroker.SetVdsStatus=
VDSCommand] (org.ovirt.thread.pool-8-thread-14) [a4e6c90] START, SetVdsStat=
usVDSCommand(HostName =3D <hostname>, HostId =3D 1ac98a04-41ed-40b7-8f02-e1=
b9cbbc5480, status=3DUnassigned, nonOperationalReason=3DNONE, stopSpmFailur=
eLogged=3Dfalse), log id: 3ec2e03a
2015-05-19 13:54:09,890 INFO [org.ovirt.engine.core.vdsbroker.SetVdsStatus=
VDSCommand] (org.ovirt.thread.pool-8-thread-14) [a4e6c90] FINISH, SetVdsSta=
tusVDSCommand, log id: 3ec2e03a
2015-05-19 13:54:09,920 INFO [org.ovirt.engine.core.bll.ActivateVdsCommand=
] (org.ovirt.thread.pool-8-thread-14) [a4e6c90] Activate finished. Lock rel=
eased. Monitoring can run now for host <hostname> from data-center DMC
2015-05-19 13:54:09,923 INFO [org.ovirt.engine.core.dal.dbbroker.auditlogh=
andling.AuditLogDirector] (org.ovirt.thread.pool-8-thread-14) [a4e6c90] Cor=
relation ID: a4e6c90, Job ID: 2bb9b203-0d51-4532-9b83-d261d805a19d, Call St=
ack: null, Custom Event ID: -1, Message: Host <hostname> was activated by a=
dmin@internal.
2015-05-19 13:54:09,926 INFO [org.ovirt.engine.core.bll.ActivateVdsCommand=
] (org.ovirt.thread.pool-8-thread-14) [a4e6c90] Lock freed to object Engine=
Lock [exclusiveLocks=3D key: 1ac98a04-41ed-40b7-8f02-e1b9cbbc5480 value: VD=
S
, sharedLocks=3D ]
2015-05-19 13:54:11,706 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.Ge=
tHardwareInfoVDSCommand] (DefaultQuartzScheduler_Worker-94) [3f613a08] STAR=
T, GetHardwareInfoVDSCommand(HostName =3D <hostname>, HostId =3D 1ac98a04-4=
1ed-40b7-8f02-e1b9cbbc5480, vds=3DHost[<hostname>,1ac98a04-41ed-40b7-8f02-e=
1b9cbbc5480]), log id: 32ca13a8
2015-05-19 13:54:11,712 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.Ge=
tHardwareInfoVDSCommand] (DefaultQuartzScheduler_Worker-94) [3f613a08] FINI=
SH, GetHardwareInfoVDSCommand, log id: 32ca13a8
2015-05-19 13:54:11,726 WARN [org.ovirt.engine.core.vdsbroker.VdsManager] =
(DefaultQuartzScheduler_Worker-94) [3f613a08] Host <hostname> is running wi=
th disabled SELinux.
2015-05-19 13:54:11,748 INFO [org.ovirt.engine.core.bll.HandleVdsCpuFlagsO=
rClusterChangedCommand] (DefaultQuartzScheduler_Worker-94) [1f024fdb] Runni=
ng command: HandleVdsCpuFlagsOrClusterChangedCommand internal: true. Entiti=
es affected : ID: 1ac98a04-41ed-40b7-8f02-e1b9cbbc5480 Type: VDS
2015-05-19 13:54:11,772 INFO [org.ovirt.engine.core.bll.SetNonOperationalV=
dsCommand] (DefaultQuartzScheduler_Worker-94) [3ccdb219] Running command: S=
etNonOperationalVdsCommand internal: true. Entities affected : ID: 1ac98a0=
4-41ed-40b7-8f02-e1b9cbbc5480 Type: VDS
2015-05-19 13:54:11,786 INFO [org.ovirt.engine.core.vdsbroker.SetVdsStatus=
VDSCommand] (DefaultQuartzScheduler_Worker-94) [3ccdb219] START, SetVdsStat=
usVDSCommand(HostName =3D <hostname> HostId =3D 1ac98a04-41ed-40b7-8f02-e1=
b9cbbc5480, status=3DNonOperational, nonOperationalReason=3DCPU_TYPE_INCOMP=
ATIBLE_WITH_CLUSTER, stopSpmFailureLogged=3Dfalse), log id: 24054dd4
2015-05-19 13:54:11,789 INFO [org.ovirt.engine.core.vdsbroker.SetVdsStatus=
VDSCommand] (DefaultQuartzScheduler_Worker-94) [3ccdb219] FINISH, SetVdsSta=
tusVDSCommand, log id: 24054dd4
2015-05-19 13:54:11,796 WARN [org.ovirt.engine.core.dal.dbbroker.auditlogh=
andling.AuditLogDirector] (DefaultQuartzScheduler_Worker-94) [3ccdb219] Cor=
relation ID: 1f024fdb, Call Stack: null, Custom Event ID: -1, Message: Host=
<hostname> moved to Non-Operational state as host does not meet the cluste=
r's minimum CPU level. Missing CPU features : model_Haswell
2015-05-19 13:54:11,813 INFO [org.ovirt.engine.core.dal.dbbroker.auditlogh=
andling.AuditLogDirector] (DefaultQuartzScheduler_Worker-94) [3ccdb219] Cor=
relation ID: null, Call Stack: null, Custom Event ID: -1, Message: Status o=
f host <hostname> was set to NonOperational.
2015-05-19 13:54:11,839 INFO [org.ovirt.engine.core.bll.HandleVdsVersionCo=
mmand] (DefaultQuartzScheduler_Worker-94) [4bb0a00] Running command: Handle=
VdsVersionCommand internal: true. Entities affected : ID: 1ac98a04-41ed-40=
b7-8f02-e1b9cbbc5480 Type: VDS
2015-05-19 13:54:11,841 INFO [org.ovirt.engine.core.vdsbroker.VdsUpdateRun=
TimeInfo] (DefaultQuartzScheduler_Worker-94) [4bb0a00] Host 1ac98a04-41ed-4=
0b7-8f02-e1b9cbbc5480 : <hostname> is already in NonOperational status for =
reason CPU_TYPE_INCOMPATIBLE_WITH_CLUSTER. SetNonOperationalVds command is =
skipped.
It says that the host has not meet the minimum CPU level. =93lscpu" has the=
following output:
# lscpu
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
CPU(s): 56
On-line CPU(s) list: 0-55
Thread(s) per core: 2
Core(s) per socket: 14
Socket(s): 2
NUMA node(s): 2
Vendor ID: GenuineIntel
CPU family: 6
Model: 63
Model name: Intel(R) Xeon(R) CPU E5-2697 v3 @ 2.60GHz
Stepping: 2
CPU MHz: 1957.007
BogoMIPS: 5206.30
Virtualization: VT-x
L1d cache: 32K
L1i cache: 32K
L2 cache: 256K
L3 cache: 35840K
NUMA node0 CPU(s): 0-13,28-41
NUMA node1 CPU(s): 14-27,42-55
This model is a haswell: http://ark.intel.com/products/81059/Intel-Xeon-Pro=
cessor-E5-2697-v3-35M-Cache-2_60-Ghz<http://ark.intel.com/products/81059/In=
tel-Xeon-Processor-E5-2697-v3-35M-Cache-2_60-GHz> and http://ark.intel.com/=
products/codename/42174/Haswell#@All
Is this a bug? Should I make a bug report at bugzilla for this? Or am I mis=
sing something?
Kind regards,
Jurri=EBn Bloemen
This message (including any attachments) may contain information that is pr=
ivileged or confidential. If you are not the intended recipient, please not=
ify the sender and delete this email immediately from your systems and dest=
roy all copies of it. You may not, directly or indirectly, use, disclose, d=
istribute, print or copy this email or any part of it if you are not the in=
tended recipient
--_000_D180F3484A93jurrienbloemendmcamcnetworkscom_
Content-Type: text/html; charset="Windows-1252"
Content-ID: <42B749253886BC48BF746A5ED0F34094(a)chellomedia.com>
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DWindows-1=
252">
</head>
<body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-lin=
e-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-fami=
ly: Calibri, sans-serif;">
<div>Hi all,</div>
<div><br>
</div>
<div>I try to add a new host to a new cluster but I get this message:</div>
<div><br>
</div>
<div>Host <hostname> moved to Non-Operational state as host does not =
meet the cluster's minimum CPU level. Missing CPU features : model_Haswell<=
/div>
<div><br>
</div>
<div>The engine.log shows:</div>
<div><br>
</div>
<div>
<p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color=
: rgb(245, 245, 245); background-color: rgb(0, 0, 0);">
2015-05-19 13:54:09,843 INFO [org.ovirt.engine.core.bll.ActivateVdsCo=
mmand] (ajp--127.0.0.1-8702-2) [a4e6c90] Lock Acquired to object EngineLock=
[exclusiveLocks=3D key: 1ac98a04-41ed-40b7-8f02-e1b9cbbc5480 value: VDS</p=
>
<p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color=
: rgb(245, 245, 245); background-color: rgb(0, 0, 0);">
, sharedLocks=3D ]</p>
<p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color=
: rgb(245, 245, 245); background-color: rgb(0, 0, 0);">
2015-05-19 13:54:09,868 INFO [org.ovirt.engine.core.bll.ActivateVdsCo=
mmand] (org.ovirt.thread.pool-8-thread-14) [a4e6c90] Running command: Activ=
ateVdsCommand internal: false. Entities affected : ID: 1ac98a04-41ed-=
40b7-8f02-e1b9cbbc5480 Type: VDSAction group
MANIPULATE_HOST with role type ADMIN</p>
<p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color=
: rgb(245, 245, 245); background-color: rgb(0, 0, 0);">
2015-05-19 13:54:09,869 INFO [org.ovirt.engine.core.bll.ActivateVdsCo=
mmand] (org.ovirt.thread.pool-8-thread-14) [a4e6c90] Before acquiring lock =
in order to prevent monitoring for host <hostname> from data-center D=
MC</p>
<p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color=
: rgb(245, 245, 245); background-color: rgb(0, 0, 0);">
2015-05-19 13:54:09,870 INFO [org.ovirt.engine.core.bll.ActivateVdsCo=
mmand] (org.ovirt.thread.pool-8-thread-14) [a4e6c90] Lock acquired, from no=
w a monitoring of host will be skipped for host <hostname> =
from data-center DMC</p>
<p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color=
: rgb(245, 245, 245); background-color: rgb(0, 0, 0);">
2015-05-19 13:54:09,885 INFO [org.ovirt.engine.core.vdsbroker.SetVdsS=
tatusVDSCommand] (org.ovirt.thread.pool-8-thread-14) [a4e6c90] START, SetVd=
sStatusVDSCommand(HostName =3D <hostname>, HostId =3D 1ac98a04-41ed-4=
0b7-8f02-e1b9cbbc5480, status=3DUnassigned, nonOperationalReason=3DNONE,
stopSpmFailureLogged=3Dfalse), log id: 3ec2e03a</p>
<p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color=
: rgb(245, 245, 245); background-color: rgb(0, 0, 0);">
2015-05-19 13:54:09,890 INFO [org.ovirt.engine.core.vdsbroker.SetVdsS=
tatusVDSCommand] (org.ovirt.thread.pool-8-thread-14) [a4e6c90] FINISH, SetV=
dsStatusVDSCommand, log id: 3ec2e03a</p>
<p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color=
: rgb(245, 245, 245); background-color: rgb(0, 0, 0);">
2015-05-19 13:54:09,920 INFO [org.ovirt.engine.core.bll.ActivateVdsCo=
mmand] (org.ovirt.thread.pool-8-thread-14) [a4e6c90] Activate finished. Loc=
k released. Monitoring can run now for host <hostname> from data-cent=
er DMC</p>
<p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color=
: rgb(245, 245, 245); background-color: rgb(0, 0, 0);">
2015-05-19 13:54:09,923 INFO [org.ovirt.engine.core.dal.dbbroker.audi=
tloghandling.AuditLogDirector] (org.ovirt.thread.pool-8-thread-14) [a4e6c90=
] Correlation ID: a4e6c90, Job ID: 2bb9b203-0d51-4532-9b83-d261d805a19d, Ca=
ll Stack: null, Custom Event ID: -1,
Message: Host <hostname> was activated by admin@internal.</p>
<p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color=
: rgb(245, 245, 245); background-color: rgb(0, 0, 0);">
2015-05-19 13:54:09,926 INFO [org.ovirt.engine.core.bll.ActivateVdsCo=
mmand] (org.ovirt.thread.pool-8-thread-14) [a4e6c90] Lock freed to object E=
ngineLock [exclusiveLocks=3D key: 1ac98a04-41ed-40b7-8f02-e1b9cbbc5480 valu=
e: VDS</p>
<p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color=
: rgb(245, 245, 245); background-color: rgb(0, 0, 0);">
, sharedLocks=3D ]</p>
<p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color=
: rgb(245, 245, 245); background-color: rgb(0, 0, 0);">
2015-05-19 13:54:11,706 INFO [org.ovirt.engine.core.vdsbroker.vdsbrok=
er.GetHardwareInfoVDSCommand] (DefaultQuartzScheduler_Worker-94) [3f613a08]=
START, GetHardwareInfoVDSCommand(HostName =3D <hostname>, HostI=
d =3D 1ac98a04-41ed-40b7-8f02-e1b9cbbc5480, vds=3DHost[<hostname>,1ac=
98a04-41ed-40b7-8f02-e1b9cbbc5480]),
log id: 32ca13a8</p>
<p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color=
: rgb(245, 245, 245); background-color: rgb(0, 0, 0);">
2015-05-19 13:54:11,712 INFO [org.ovirt.engine.core.vdsbroker.vdsbrok=
er.GetHardwareInfoVDSCommand] (DefaultQuartzScheduler_Worker-94) [3f613a08]=
FINISH, GetHardwareInfoVDSCommand, log id: 32ca13a8</p>
<p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color=
: rgb(245, 245, 245); background-color: rgb(0, 0, 0);">
2015-05-19 13:54:11,726 WARN [org.ovirt.engine.core.vdsbroker.VdsMana=
ger] (DefaultQuartzScheduler_Worker-94) [3f613a08] Host <hostname> is=
running with disabled SELinux.</p>
<p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color=
: rgb(245, 245, 245); background-color: rgb(0, 0, 0);">
2015-05-19 13:54:11,748 INFO [org.ovirt.engine.core.bll.HandleVdsCpuF=
lagsOrClusterChangedCommand] (DefaultQuartzScheduler_Worker-94) [1f024fdb] =
Running command: HandleVdsCpuFlagsOrClusterChangedCommand internal: true. E=
ntities affected : ID: 1ac98a04-41ed-40b7-8f02-e1b9cbbc5480
Type: VDS</p>
<p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color=
: rgb(245, 245, 245); background-color: rgb(0, 0, 0);">
2015-05-19 13:54:11,772 INFO [org.ovirt.engine.core.bll.SetNonOperati=
onalVdsCommand] (DefaultQuartzScheduler_Worker-94) [3ccdb219] Running comma=
nd: SetNonOperationalVdsCommand internal: true. Entities affected : I=
D: 1ac98a04-41ed-40b7-8f02-e1b9cbbc5480 Type:
VDS</p>
<p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color=
: rgb(245, 245, 245); background-color: rgb(0, 0, 0);">
2015-05-19 13:54:11,786 INFO [org.ovirt.engine.core.vdsbroker.SetVdsS=
tatusVDSCommand] (DefaultQuartzScheduler_Worker-94) [3ccdb219] START, SetVd=
sStatusVDSCommand(HostName =3D <hostname> HostId =3D 1ac98=
a04-41ed-40b7-8f02-e1b9cbbc5480, status=3DNonOperational, nonOperationalRea=
son=3DCPU_TYPE_INCOMPATIBLE_WITH_CLUSTER,
stopSpmFailureLogged=3Dfalse), log id: 24054dd4</p>
<p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color=
: rgb(245, 245, 245); background-color: rgb(0, 0, 0);">
2015-05-19 13:54:11,789 INFO [org.ovirt.engine.core.vdsbroker.SetVdsS=
tatusVDSCommand] (DefaultQuartzScheduler_Worker-94) [3ccdb219] FINISH, SetV=
dsStatusVDSCommand, log id: 24054dd4</p>
<p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color=
: rgb(245, 245, 245); background-color: rgb(0, 0, 0);">
2015-05-19 13:54:11,796 WARN [org.ovirt.engine.core.dal.dbbroker.audi=
tloghandling.AuditLogDirector] (DefaultQuartzScheduler_Worker-94) [3ccdb219=
] Correlation ID: 1f024fdb, Call Stack: null, Custom Event ID: -1, Message:=
Host <hostname> moved to Non-Operational
state as host does not meet the cluster's minimum CPU level. Missing CPU f=
eatures : model_Haswell</p>
<p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color=
: rgb(245, 245, 245); background-color: rgb(0, 0, 0);">
2015-05-19 13:54:11,813 INFO [org.ovirt.engine.core.dal.dbbroker.audi=
tloghandling.AuditLogDirector] (DefaultQuartzScheduler_Worker-94) [3ccdb219=
] Correlation ID: null, Call Stack: null, Custom Event ID: -1, Message: Sta=
tus of host <hostname> was set to NonOperational.</p>
<p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color=
: rgb(245, 245, 245); background-color: rgb(0, 0, 0);">
2015-05-19 13:54:11,839 INFO [org.ovirt.engine.core.bll.HandleVdsVers=
ionCommand] (DefaultQuartzScheduler_Worker-94) [4bb0a00] Running command: H=
andleVdsVersionCommand internal: true. Entities affected : ID: 1ac98a=
04-41ed-40b7-8f02-e1b9cbbc5480 Type: VDS</p>
<p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color=
: rgb(245, 245, 245); background-color: rgb(0, 0, 0);">
2015-05-19 13:54:11,841 INFO [org.ovirt.engine.core.vdsbroker.VdsUpda=
teRunTimeInfo] (DefaultQuartzScheduler_Worker-94) [4bb0a00] Host 1ac98a04-4=
1ed-40b7-8f02-e1b9cbbc5480 : <hostname> is already in NonOp=
erational status for reason CPU_TYPE_INCOMPATIBLE_WITH_CLUSTER.
SetNonOperationalVds command is skipped.</p>
</div>
<div><br>
</div>
<div>It says that the host has not meet the minimum CPU level. =93lscpu&quo=
t; has the following output:</div>
<div><br>
</div>
<div>
<p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color=
: rgb(245, 245, 245); background-color: rgb(0, 0, 0);">
# lscpu</p>
<p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color=
: rgb(245, 245, 245); background-color: rgb(0, 0, 0);">
Architecture: x86_64</p>
<p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color=
: rgb(245, 245, 245); background-color: rgb(0, 0, 0);">
CPU op-mode(s): 32-bit, 64-bit</p>
<p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color=
: rgb(245, 245, 245); background-color: rgb(0, 0, 0);">
Byte Order: Little Endian</p>
<p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color=
: rgb(245, 245, 245); background-color: rgb(0, 0, 0);">
CPU(s): 56</p>
<p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color=
: rgb(245, 245, 245); background-color: rgb(0, 0, 0);">
On-line CPU(s) list: 0-55</p>
<p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color=
: rgb(245, 245, 245); background-color: rgb(0, 0, 0);">
Thread(s) per core: 2</p>
<p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color=
: rgb(245, 245, 245); background-color: rgb(0, 0, 0);">
Core(s) per socket: 14</p>
<p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color=
: rgb(245, 245, 245); background-color: rgb(0, 0, 0);">
Socket(s): 2</p>
<p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color=
: rgb(245, 245, 245); background-color: rgb(0, 0, 0);">
NUMA node(s): 2</p>
<p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color=
: rgb(245, 245, 245); background-color: rgb(0, 0, 0);">
Vendor ID: GenuineIntel</p>
<p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color=
: rgb(245, 245, 245); background-color: rgb(0, 0, 0);">
CPU family: 6</p>
<p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color=
: rgb(245, 245, 245); background-color: rgb(0, 0, 0);">
Model: 63</p>
<p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color=
: rgb(245, 245, 245); background-color: rgb(0, 0, 0);">
Model name: Intel(R) Xeon(R) CPU E=
5-2697 v3 @ 2.60GHz</p>
<p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color=
: rgb(245, 245, 245); background-color: rgb(0, 0, 0);">
Stepping: 2</p>
<p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color=
: rgb(245, 245, 245); background-color: rgb(0, 0, 0);">
CPU MHz: 1957.007</p>
<p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color=
: rgb(245, 245, 245); background-color: rgb(0, 0, 0);">
BogoMIPS: 5206.30</p>
<p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color=
: rgb(245, 245, 245); background-color: rgb(0, 0, 0);">
Virtualization: VT-x</p>
<p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color=
: rgb(245, 245, 245); background-color: rgb(0, 0, 0);">
L1d cache: 32K</p>
<p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color=
: rgb(245, 245, 245); background-color: rgb(0, 0, 0);">
L1i cache: 32K</p>
<p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color=
: rgb(245, 245, 245); background-color: rgb(0, 0, 0);">
L2 cache: 256K</p>
<p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color=
: rgb(245, 245, 245); background-color: rgb(0, 0, 0);">
L3 cache: 35840K</p>
<p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color=
: rgb(245, 245, 245); background-color: rgb(0, 0, 0);">
NUMA node0 CPU(s): 0-13,28-41</p>
<p style=3D"margin: 0px; font-size: 12px; font-family: 'Courier New'; color=
: rgb(245, 245, 245); background-color: rgb(0, 0, 0);">
NUMA node1 CPU(s): 14-27,42-55</p>
</div>
<div><br>
</div>
<div>This model is a haswell: <a href=3D"http://ark.intel.com/products=
/81059/Intel-Xeon-Processor-E5-2697-v3-35M-Cache-2_60-GHz">http://ark.intel=
.com/products/81059/Intel-Xeon-Processor-E5-2697-v3-35M-Cache-2_60-Ghz</a>&=
nbsp;and <a href=3D"http://ark.intel.com/products/codename/42174/Haswe=
ll#@All">http://ark.intel.com/products/codename/42174/Haswell#@All</a></div=
>
<div><br>
</div>
<div>Is this a bug? Should I make a bug report at bugzilla for this? Or am =
I missing something?</div>
<div><br>
</div>
<div>Kind regards,</div>
<div><br>
</div>
<div>Jurri=EBn Bloemen</div>
This message (including any attachments) may contain information that is pr=
ivileged or confidential. If you are not the intended recipient, please not=
ify the sender and delete this email immediately from your systems and dest=
roy all copies of it. You may not,
directly or indirectly, use, disclose, distribute, print or copy this emai=
l or any part of it if you are not the intended recipient
</body>
</html>
--_000_D180F3484A93jurrienbloemendmcamcnetworkscom_--
10 years, 1 month
- 2
- 2
Re: [ovirt-users] missing disk after storage domain expansion [SOLVED]
by Andrea Ghelardi
Thanks for all your information.
I created a linux script as per details below.
Attached to this email (some info purged)
Gentlemen, we have a disk now!
I'm marking the post as solved ... even though we do not know where the disk
gone in these weeks yet.
Probably unexpected vacation @Cuba? This disk won't reclaim expenses though
I will create a test VM and perform some tests in the future with the
expansion feature
Thank you for all your support
More cats: https://www.youtube.com/watch?v=cWKmorjUzF0
AG
-----Original Message-----
From: Juan Hernández [mailto:jhernand@redhat.com]
Sent: Wednesday, May 20, 2015 10:37 AM
To: Maor Lipchuk; Andrea Ghelardi
Cc: users(a)ovirt.org
Subject: Re: [ovirt-users] missing disk after storage domain expansion
On 05/19/2015 06:23 PM, Maor Lipchuk wrote:
> Hi Andrea,
>
> I'm using "postman" chrome-extension to execute my REST requests.
>
> For firefox the rest-client add-on you can use is
> https://addons.mozilla.org/de/firefox/addon/restclient/
>
> Juan, do we have a wiki for step by step instructions of REST
>
> Regards,
> Maor
>
I'd suggest to try a command line client, as it is easier to share the
results and check what is going wrong. You can use the "curl" command, for
example. Assuming that you already know the identifiers of the storage
domain and of the disk to register it should be something like this:
---8<---
#!/bin/sh -ex
url="https://yourengine/ovirt-engine/api"
user="your user"
password="your password"
storage_domain_id="the storage domain id"
disk_id="the disk id"
curl \
--verbose \
--insecure \
--user "${user}:${password}" \
--request POST \
--header "Content-Type: application/xml" \ --header "Accept:
application/xml" \ --data "
<disk id=\"${disk_id}\"/>
" \
"${url}/storagedomains/${storage_domain_id}/disks;unregistered"
--->8---
>
> ----- Original Message -----
>> From: "Andrea Ghelardi" <a.ghelardi(a)iontrading.com>
>> To: "Maor Lipchuk" <mlipchuk(a)redhat.com>
>> Cc: users(a)ovirt.org
>> Sent: Tuesday, May 19, 2015 4:46:09 PM
>> Subject: RE: [ovirt-users] missing disk after storage domain
>> expansion
>>
>> I got an error but I'm not 100% sure I did everything correctly Error
>> below:
>> <html><head><title>JBoss Web/7.0.13.Final - Error
>> report</title><style><!--H1
>> {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#52
>> 5D76;font-size:22px;}
>> H2
>> {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#52
>> 5D76;font-size:16px;}
>> H3
>> {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#52
>> 5D76;font-size:14px;}
>> BODY
>> {font-family:Tahoma,Arial,sans-serif;color:black;background-color:whi
>> te;} B
>> {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#52
>> 5D76;}
>> P
>> {font-family:Tahoma,Arial,sans-serif;background:white;color:black;fon
>> t-size:12px;}A {color : black;}A.name {color : black;}HR {color :
>> #525D76;}--></style> </head><body><h1>HTTP Status 415 - Cannot
>> consume content type</h1><HR size="1"
>> noshade="noshade"><p><b>type</b> Status report</p><p><b>message</b>
>> <u>Cannot consume content type</u></p><p><b>description</b> <u>The
>> server refused this request because the request entity is in a format
>> not supported by the requested resource for the requested method
>> (Cannot consume content type).</u></p><HR size="1"
>> noshade="noshade"><h3>JBoss Web/7.0.13.Final</h3></body></html>
>>
>> Actions:
>> Used RESTclient 2.3.0 for Firefox to POST this body <disk
>> id='16736ce0-a9df-410f-9f29-3a28364cdd41'></disk>
>>
>> I think I need a step by step guide about how to use the REST client
>> to POST commands to ovirt service remotely
>>
>> Cheers
>> AG
>>
>> -----Original Message-----
>> From: Maor Lipchuk [mailto:mlipchuk@redhat.com]
>> Sent: Monday, May 18, 2015 4:50 PM
>> To: Andrea Ghelardi
>> Subject: Re: [ovirt-users] missing disk after storage domain
>> expansion
>>
>> I've went through the logs, though I didn't noticed any special
>> information.
>> Please let me know how the registration of the disk went.
>>
>> Regards,
>> Maor
>>
>>
>>
>> ----- Original Message -----
>>> From: "Andrea Ghelardi" <a.ghelardi(a)iontrading.com>
>>> To: "Maor Lipchuk" <mlipchuk(a)redhat.com>
>>> Sent: Monday, May 18, 2015 4:35:30 PM
>>> Subject: RE: [ovirt-users] missing disk after storage domain
>>> expansion
>>>
>>> Here the full set of logs as promised.
>>>
>>> Unfortunately, I do not think I have vdsm logs pointing to that date
>>> (logs rotated already).
>>> I tried to search for
>>> xzgrep 16736ce0-a9df-410f-9f29-3a28364cdd41 /var/log/vdsm/* but
>>> nothing found
>>>
>>> cheers
>>> AG
>>>
>>> -----Original Message-----
>>> From: Andrea Ghelardi [mailto:a.ghelardi@iontrading.com]
>>> Sent: Monday, May 18, 2015 3:30 PM
>>> To: 'Maor Lipchuk'
>>> Cc: 'users(a)ovirt.org'
>>> Subject: RE: [ovirt-users] missing disk after storage domain
>>> expansion
>>>
>>> Hi Maor,
>>>
>>> 1) disk creation: ok
>>> 2) no free space at the moment of creation: this is very strange!
>>> Are you sure? I assure you the disk was working, exported to VM
>>> which formatted and wrote data on it
>>> 3) no disk removal mention: this is the very issue I'm facing. In
>>> fact disk disappeared with no notification, no logs, nothing. I'm
>>> forwarding you full set of engine.log separately. If you need
>>> vdsm.logs just tell me from which server you need it as I have
>>> several cluster.
>>> 4) I have not yet tried to register using the procedure you provided
>>> me earlier. I'll try tomorrow.
>>>
>>> Thanks
>>> AG
>>>
>>>
>>> -----Original Message-----
>>> From: Maor Lipchuk [mailto:mlipchuk@redhat.com]
>>> Sent: Monday, May 18, 2015 1:15 PM
>>> To: Andrea Ghelardi
>>> Cc: users(a)ovirt.org
>>> Subject: Re: [ovirt-users] missing disk after storage domain
>>> expansion
>>>
>>> Hi Andrea,
>>>
>>> I guessed I missed those logs, I found it now, thanks.
>>>
>>> I do see the disk creation in the log from 20150501, I can also see
>>> that the Storage Domain hertz-dstore2 has 0 GB of free space at the
>>> moment of
>>> creation:
>>> 2015-05-01 03:30:05,801 ERROR
>>> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirecto
>>> r]
>>> (DefaultQuartzScheduler_Worker-92) Correlation ID: null, Call Stack:
>>> null, Custom Event ID: -1, Message: Critical, Low disk space.
>>> hertz-dstore2 domain has 0 GB of free space
>>>
>>> though, I don't see any indication of the removed disks from the engine.
>>> I have also noticed a gap from the first log which finished at
>>> 2015-05-01
>>> 03:30:05 and the other log which starts at 2015-05-04 03:22:19,879.
>>>
>>> Did you try to register the disk as described in the wiki?
>>>
>>> Regards,
>>> Maor
>>>
>>>
>>>
>>>
>>> ----- Original Message -----
>>>> From: "Andrea Ghelardi" <a.ghelardi(a)iontrading.com>
>>>> To: "Maor Lipchuk" <mlipchuk(a)redhat.com>
>>>> Cc: users(a)ovirt.org
>>>> Sent: Monday, May 18, 2015 12:10:55 PM
>>>> Subject: RE: [ovirt-users] missing disk after storage domain
>>>> expansion
>>>>
>>>> Hi Maor,
>>>> I already added logs in my previous email, did you received them?
>>>> I'm sending them again, but only privately to you not to burden the
>>>> mailing list (or let me know if you prefer otherwise).
>>>>
>>>> Cheers
>>>> AG
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Maor Lipchuk [mailto:mlipchuk@redhat.com]
>>>> Sent: Saturday, May 16, 2015 10:03 AM
>>>> To: Andrea Ghelardi
>>>> Cc: users(a)ovirt.org
>>>> Subject: Re: [ovirt-users] missing disk after storage domain
>>>> expansion
>>>>
>>>> Hi Andrea,
>>>>
>>>> The OVF_STORE disks are disks which mainly being used internally in
>>>> the engine to store VMs' and Templates' OVFs, you can disregard
>>>> them for now.
>>>>
>>>> The behavior you mentioned, that suddenly the disk has disappeared
>>>> from the setup, sounds very weird and I would like to investigate
>>>> this a bit more.
>>>> if you can please add the engine and vdsm logs, I can know what
>>>> made the disk get removed from the setup, at the first place.
>>>> Could it be that some one accessed the data base by any chance?
>>>>
>>>> Regarding the disk registration, basically it should not create any
>>>> problems unless, if your disk was deleted manually form the DB, and
>>>> there are still leftovers related to the disk in some of the tables.
>>>> Once the disk is registered to the setup, you can try to attach it
>>>> to the VM, and try to run it.
>>>>
>>>>
>>>> Regards,
>>>> Maor
>>>>
>>>>
>>>>
>>>> ----- Original Message -----
>>>>> From: "Andrea Ghelardi" <a.ghelardi(a)iontrading.com>
>>>>> To: "Maor Lipchuk" <mlipchuk(a)redhat.com>
>>>>> Cc: users(a)ovirt.org
>>>>> Sent: Friday, May 15, 2015 4:54:25 PM
>>>>> Subject: RE: [ovirt-users] missing disk after storage domain
>>>>> expansion
>>>>>
>>>>> After querying the hosted engine with the suggested command
>>>>> https://pisa-ion-ovirtm-01/ovirt-engine/api/storagedomains/7a48fe4
>>>>> 6-
>>>>> 21 12-40a4-814f-24d74c760b2d/disks;unregistered
>>>>>
>>>>> Indeed shows a (unregistered?) disk
>>>>>
>>>>> <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <disks>
>>>>> <disk
>>>>> href="/ovirt-engine/api/storagedomains/7a48fe46-2112-40a4-814f-24d74c760b2d/disks/16736ce0-a9df-410f-9f29-3a28364cdd41"
>>>>> id="16736ce0-a9df-410f-9f29-3a28364cdd41">
>>>>> <actions>
>>>>> <link
>>>>> href="/ovirt-engine/api/storagedomains/7a48fe46-2112-40a4-814f-24d74c760b2d/disks/16736ce0-a9df-410f-9f29-3a28364cdd41/export"
>>>>> rel="export"/>
>>>>> </actions>
>>>>> <name>hertz_disk5</name>
>>>>> <description>disk for SYBASE installation, on SAN shared
>>>>> storage</description> <link
>>>>> href="/ovirt-engine/api/storagedomains/7a48fe46-2112-40a4-814f-24d74c760b2d/disks/16736ce0-a9df-410f-9f29-3a28364cdd41/permissions"
>>>>> rel="permissions"/>
>>>>> <link
>>>>> href="/ovirt-engine/api/storagedomains/7a48fe46-2112-40a4-814f-24d74c760b2d/disks/16736ce0-a9df-410f-9f29-3a28364cdd41/statistics"
>>>>> rel="statistics"/>
>>>>> <alias>hertz_disk5</alias>
>>>>> <image_id>4ab070c0-fb16-452d-8521-4ff0b004aef3</image_id>
>>>>> <storage_domain
>>>>> href="/ovirt-engine/api/storagedomains/7a48fe46-2112-40a4-814f-24d74c760b2d"
>>>>> id="7a48fe46-2112-40a4-814f-24d74c760b2d"/>
>>>>> <storage_domains>
>>>>> <storage_domain id="7a48fe46-2112-40a4-814f-24d74c760b2d"/>
>>>>> </storage_domains>
>>>>> <size>225485783040</size>
>>>>> <provisioned_size>225485783040</provisioned_size>
>>>>> <actual_size>225485783040</actual_size>
>>>>> <status>
>>>>> <state>ok</state>
>>>>> </status>
>>>>> <interface>ide</interface>
>>>>> <format>raw</format>
>>>>> <sparse>false</sparse>
>>>>> <bootable>false</bootable>
>>>>> <shareable>false</shareable>
>>>>> <wipe_after_delete>false</wipe_after_delete>
>>>>> <propagate_errors>false</propagate_errors>
>>>>> </disk>
>>>>> </disks>
>>>>>
>>>>> I'm waiting for any comments on the two OVF disk or any advice
>>>>> before proceeding with the registering command (test in production
>>>>> environment hmmmmm)
>>>>>
>>>>> Cheers
>>>>> AG
>>>>>
>>>>> -----Original Message-----
>>>>> From: Andrea Ghelardi [mailto:a.ghelardi@iontrading.com]
>>>>> Sent: Friday, May 15, 2015 12:30 PM
>>>>> To: Maor Lipchuk
>>>>> Cc: users(a)ovirt.org
>>>>> Subject: RE: [ovirt-users] missing disk after storage domain
>>>>> expansion
>>>>>
>>>>> Thank you for your reply!
>>>>> I'm unsure if the disk contained any snapshots. I do not think so.
>>>>> Is the register action a safe one to do in production system? I
>>>>> wouldn't mess any of my existing running servers.
>>>>>
>>>>> Here the relevant logs from the date
>>>>> ./engine.log-20150501.gz:2015-04-29 16:10:40,868 : disk creation
>>>>> ("hertz_disk5" newImageId = 4ab070c0-fb16-452d-8521-4ff0b004aef3)
>>>>> ./engine.log-20150512.gz:2015-05-04 17:22:42,691 : last
>>>>> occurrence of the imageid
>>>>>
>>>>> Please note from
>>>>> ./engine.log-20150512.gz 2015-05-11 12:07:16,719 : creation of
>>>>> two disk OVF store (??) on the same storage domain
>>>>> 7a48fe46-2112-40a4-814f-24d74c760b2d
>>>>> right after the volume expansion
>>>>>
>>>>> In the instructions.txt what I did to enlarge the volume (and
>>>>> lose the
>>>>> disk) (the guides is informational only, I followed the steps on a
>>>>> different
>>>>> server)
>>>>>
>>>>> Here some cats to thank you in advance
>>>>> https://www.youtube.com/watch?v=nfTY41-zC7Y
>>>>
>>>>
>>>> lol :)
>>>> Nice cats
>>>>
>>>>> AG
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: Maor Lipchuk [mailto:mlipchuk@redhat.com]
>>>>> Sent: Wednesday, May 13, 2015 11:02 PM
>>>>> To: Andrea Ghelardi
>>>>> Cc: users(a)ovirt.org
>>>>> Subject: Re: [ovirt-users] missing disk after storage domain
>>>>> expansion
>>>>>
>>>>> Hi Andrea,
>>>>>
>>>>> First of all, the issue sounds quite severe, can u please attach
>>>>> the engine logs so we can try to figure out how that happened.
>>>>> second, does this disk contained any snapshots?
>>>>> If not, can you try to register it back (see
>>>>> http://www.ovirt.org/Features/ImportStorageDomain#Register_an_unre
>>>>> gi
>>>>> st
>>>>> ered_disk)
>>>>>
>>>>>
>>>>> Regards,
>>>>> Maor
>>>>>
>>>>>
>>>>>
>>>>> ----- Original Message -----
>>>>>> From: "Andrea Ghelardi" <a.ghelardi(a)iontrading.com>
>>>>>> To: users(a)ovirt.org
>>>>>> Sent: Monday, May 11, 2015 12:01:17 AM
>>>>>> Subject: Re: [ovirt-users] missing disk after storage domain
>>>>>> expansion
>>>>>>
>>>>>>
>>>>>>
>>>>>> Ok, so,
>>>>>>
>>>>>> After _ a lot _ of unsuccessful approach, I finally connected to
>>>>>> postegre DB directly.
>>>>>>
>>>>>> Browsing the tables I found “unregistered_ovf_of_entities” where
>>>>>> there is a reference of the missing disk
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> @ovf:diskId:4ab070c0-fb16-452d-8521-4ff0b004aef3
>>>>>>
>>>>>> @ovf:size:210
>>>>>>
>>>>>> @ovf:actual_size:210
>>>>>>
>>>>>> @ovf:vm_snapshot_id:2e24b255-bb84-4284-8785-e2a042045882
>>>>>>
>>>>>> @ovf:fileRef:16736ce0-a9df-410f-9f29-3a28364cdd41/4ab070c0-fb16-
>>>>>> 45
>>>>>> 2d
>>>>>> -8
>>>>>> 521-4ff0b004aef3
>>>>>>
>>>>>> @ovf:format:
>>>>>> http://www.vmware.com/specifications/vmdk.html#sparse
>>>>>>
>>>>>> @ovf:volume-format:RAW
>>>>>>
>>>>>> @ovf:volume-type:Preallocated
>>>>>>
>>>>>> @ovf:disk-interface:VirtIO
>>>>>>
>>>>>> @ovf:boot:false
>>>>>>
>>>>>> @ovf:disk-alias:hertz_disk5
>>>>>>
>>>>>> @ovf:disk-description:disk for SYBASE installation, on SAN shared
>>>>>> storage
>>>>>>
>>>>>> @ovf:wipe-after-delete:false
>>>>>>
>>>>>>
>>>>>>
>>>>>> However, I’ve been unable to find any other helpful details.
>>>>>>
>>>>>> I guess the disk is not recoverable at this point?
>>>>>>
>>>>>> Any guru who has a good ovirt DB kwnoledge willing to give me
>>>>>> some advice?
>>>>>>
>>>>>>
>>>>>>
>>>>>> Thanks as usual
>>>>>>
>>>>>> AG
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> From: Andrea Ghelardi [mailto: a.ghelardi(a)iontrading.com ]
>>>>>> Sent: Thursday, May 07, 2015 6:08 PM
>>>>>> To: ' users(a)ovirt.org '
>>>>>> Subject: missing disk after storage domain expansion
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Hi gentlemen,
>>>>>>
>>>>>>
>>>>>>
>>>>>> I recently found an error on 1 of my storages: it was complaining
>>>>>> about no free space but the VM was running and disk operational.
>>>>>>
>>>>>> Since I needed to perform some maintenance on the VM, I shut it
>>>>>> down and at restart VM couldn’t boot up properly.
>>>>>>
>>>>>> Checked VM via console and a disk was missing. Edited fstab
>>>>>> (luckily this disk was not root but heck! It had a Sybase DB on
>>>>>> it!) and restarted VM this time ok.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Since the disk resides on the dstore with no space, I expanded
>>>>>> the iSCSI LUN, then refreshed multipath on hosts, then resized
>>>>>> PVs and now ovirt is showing the correct size (logs do not
>>>>>> complain anymore on no free space).
>>>>>>
>>>>>>
>>>>>>
>>>>>> BUUUT
>>>>>>
>>>>>>
>>>>>>
>>>>>> Now disk is missing. It is not shown anymore on Disks tab nor
>>>>>> anywhere else.
>>>>>>
>>>>>> Problem is that storage shows 214GB occupancy (size of the
>>>>>> missing
>>>>>> disk) so data is there but cannot find it anymore.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Logs show original disk creation, errors from the lack of space,
>>>>>> refresh of the storage size and then.... no more references on
>>>>>> the disk.
>>>>>>
>>>>>>
>>>>>>
>>>>>> What can I do to find those missing ~210GBs?
>>>>>>
>>>>>>
>>>>>>
>>>>>> Cheers
>>>>>>
>>>>>> Andrea Ghelardi
>>>>>>
--
Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta 3ºD,
28016 Madrid, Spain Inscrita en el Reg. Mercantil de Madrid – C.I.F.
B82657941 - Red Hat S.L.
10 years, 1 month
- 1
- 0
Huge, unrotated /var/log/glusterfs/cli.log
by Ernest Beinrohr
This is a multi-part message in MIME format.
--------------050503090908010601040603
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Does anyone else has these on their HVs?
I just dropped a new logrotate config, but I think ovirt need to lower
the loglevel for gluster.
--
Ernest Beinrohr, AXON PRO
Ing <http://www.beinrohr.sk/ing.php>, RHCE
<http://www.beinrohr.sk/rhce.php>, RHCVA
<http://www.beinrohr.sk/rhce.php>, LPIC
<http://www.beinrohr.sk/lpic.php>, VCA <http://www.beinrohr.sk/vca.php>,
+421-2-62410360 +421-903-482603
--------------050503090908010601040603
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Does anyone else has these on their HVs?<br>
<br>
I just dropped a new logrotate config, but I think ovirt need to
lower the loglevel for gluster.<br>
<br>
<br>
<div class="moz-signature">-- <br>
<div id="oernii_footer" style="color: gray;">
<span style="font-family: Lucida Console, Luxi Mono, Courier,
monospace; font-size: 90%;">
Ernest Beinrohr, AXON PRO<br>
<a style="text-decoration: none; color: gray;"
href="http://www.beinrohr.sk/ing.php">Ing</a>, <a
style="text-decoration: none; color: gray;"
href="http://www.beinrohr.sk/rhce.php">RHCE</a>, <a
style="text-decoration: none; color: gray;"
href="http://www.beinrohr.sk/rhce.php">RHCVA</a>, <a
style="text-decoration: none; color: gray;"
href="http://www.beinrohr.sk/lpic.php">LPIC</a>, <a
style="text-decoration: none; color: gray;"
href="http://www.beinrohr.sk/vca.php">VCA</a>, <br>
+421-2-62410360 +421-903-482603
<br>
</span> </div>
<img
src="http://nojsstats.appspot.com/UA-44497096-1/email.beinrohr.sk"
moz-do-not-send="true" border="0" width="1" height="1">
</div>
</body>
</html>
--------------050503090908010601040603--
10 years, 1 month
- 2
- 1
Re: [ovirt-users] missing disk after storage domain expansion
by Andrea Ghelardi
I got an error but I'm not 100% sure I did everything correctly
Error below:
<html><head><title>JBoss Web/7.0.13.Final - Error
report</title><style><!--H1
{font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:22px;}
H2
{font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:16px;}
H3
{font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:14px;}
BODY
{font-family:Tahoma,Arial,sans-serif;color:black;background-color:white;} B
{font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;}
P
{font-family:Tahoma,Arial,sans-serif;background:white;color:black;font-size:12px;}A
{color : black;}A.name {color : black;}HR {color : #525D76;}--></style>
</head><body><h1>HTTP Status 415 - Cannot consume content type</h1><HR
size="1" noshade="noshade"><p><b>type</b> Status report</p><p><b>message</b>
<u>Cannot consume content type</u></p><p><b>description</b> <u>The server
refused this request because the request entity is in a format not supported
by the requested resource for the requested method (Cannot consume content
type).</u></p><HR size="1" noshade="noshade"><h3>JBoss
Web/7.0.13.Final</h3></body></html>
Actions:
Used RESTclient 2.3.0 for Firefox to POST this body
<disk id='16736ce0-a9df-410f-9f29-3a28364cdd41'></disk>
I think I need a step by step guide about how to use the REST client to POST
commands to ovirt service remotely
Cheers
AG
-----Original Message-----
From: Maor Lipchuk [mailto:mlipchuk@redhat.com]
Sent: Monday, May 18, 2015 4:50 PM
To: Andrea Ghelardi
Subject: Re: [ovirt-users] missing disk after storage domain expansion
I've went through the logs, though I didn't noticed any special information.
Please let me know how the registration of the disk went.
Regards,
Maor
----- Original Message -----
> From: "Andrea Ghelardi" <a.ghelardi(a)iontrading.com>
> To: "Maor Lipchuk" <mlipchuk(a)redhat.com>
> Sent: Monday, May 18, 2015 4:35:30 PM
> Subject: RE: [ovirt-users] missing disk after storage domain expansion
>
> Here the full set of logs as promised.
>
> Unfortunately, I do not think I have vdsm logs pointing to that date
> (logs rotated already).
> I tried to search for
> xzgrep 16736ce0-a9df-410f-9f29-3a28364cdd41 /var/log/vdsm/* but
> nothing found
>
> cheers
> AG
>
> -----Original Message-----
> From: Andrea Ghelardi [mailto:a.ghelardi@iontrading.com]
> Sent: Monday, May 18, 2015 3:30 PM
> To: 'Maor Lipchuk'
> Cc: 'users(a)ovirt.org'
> Subject: RE: [ovirt-users] missing disk after storage domain expansion
>
> Hi Maor,
>
> 1) disk creation: ok
> 2) no free space at the moment of creation: this is very strange! Are
> you sure? I assure you the disk was working, exported to VM which
> formatted and wrote data on it
> 3) no disk removal mention: this is the very issue I'm facing. In fact
> disk disappeared with no notification, no logs, nothing. I'm
> forwarding you full set of engine.log separately. If you need
> vdsm.logs just tell me from which server you need it as I have several
> cluster.
> 4) I have not yet tried to register using the procedure you provided
> me earlier. I'll try tomorrow.
>
> Thanks
> AG
>
>
> -----Original Message-----
> From: Maor Lipchuk [mailto:mlipchuk@redhat.com]
> Sent: Monday, May 18, 2015 1:15 PM
> To: Andrea Ghelardi
> Cc: users(a)ovirt.org
> Subject: Re: [ovirt-users] missing disk after storage domain expansion
>
> Hi Andrea,
>
> I guessed I missed those logs, I found it now, thanks.
>
> I do see the disk creation in the log from 20150501, I can also see
> that the Storage Domain hertz-dstore2 has 0 GB of free space at the
> moment of
> creation:
> 2015-05-01 03:30:05,801 ERROR
> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
> (DefaultQuartzScheduler_Worker-92) Correlation ID: null, Call Stack:
> null, Custom Event ID: -1, Message: Critical, Low disk space.
> hertz-dstore2 domain has 0 GB of free space
>
> though, I don't see any indication of the removed disks from the engine.
> I have also noticed a gap from the first log which finished at
> 2015-05-01
> 03:30:05 and the other log which starts at 2015-05-04 03:22:19,879.
>
> Did you try to register the disk as described in the wiki?
>
> Regards,
> Maor
>
>
>
>
> ----- Original Message -----
> > From: "Andrea Ghelardi" <a.ghelardi(a)iontrading.com>
> > To: "Maor Lipchuk" <mlipchuk(a)redhat.com>
> > Cc: users(a)ovirt.org
> > Sent: Monday, May 18, 2015 12:10:55 PM
> > Subject: RE: [ovirt-users] missing disk after storage domain
> > expansion
> >
> > Hi Maor,
> > I already added logs in my previous email, did you received them?
> > I'm sending them again, but only privately to you not to burden the
> > mailing list (or let me know if you prefer otherwise).
> >
> > Cheers
> > AG
> >
> >
> > -----Original Message-----
> > From: Maor Lipchuk [mailto:mlipchuk@redhat.com]
> > Sent: Saturday, May 16, 2015 10:03 AM
> > To: Andrea Ghelardi
> > Cc: users(a)ovirt.org
> > Subject: Re: [ovirt-users] missing disk after storage domain
> > expansion
> >
> > Hi Andrea,
> >
> > The OVF_STORE disks are disks which mainly being used internally in
> > the engine to store VMs' and Templates' OVFs, you can disregard them
> > for now.
> >
> > The behavior you mentioned, that suddenly the disk has disappeared
> > from the setup, sounds very weird and I would like to investigate
> > this a bit more.
> > if you can please add the engine and vdsm logs, I can know what made
> > the disk get removed from the setup, at the first place.
> > Could it be that some one accessed the data base by any chance?
> >
> > Regarding the disk registration, basically it should not create any
> > problems unless, if your disk was deleted manually form the DB, and
> > there are still leftovers related to the disk in some of the tables.
> > Once the disk is registered to the setup, you can try to attach it
> > to the VM, and try to run it.
> >
> >
> > Regards,
> > Maor
> >
> >
> >
> > ----- Original Message -----
> > > From: "Andrea Ghelardi" <a.ghelardi(a)iontrading.com>
> > > To: "Maor Lipchuk" <mlipchuk(a)redhat.com>
> > > Cc: users(a)ovirt.org
> > > Sent: Friday, May 15, 2015 4:54:25 PM
> > > Subject: RE: [ovirt-users] missing disk after storage domain
> > > expansion
> > >
> > > After querying the hosted engine with the suggested command
> > > https://pisa-ion-ovirtm-01/ovirt-engine/api/storagedomains/7a48fe4
> > > 6-
> > > 21 12-40a4-814f-24d74c760b2d/disks;unregistered
> > >
> > > Indeed shows a (unregistered?) disk
> > >
> > > <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <disks>
> > > <disk
> > > href="/ovirt-engine/api/storagedomains/7a48fe46-2112-40a4-814f-24d74c760b2d/disks/16736ce0-a9df-410f-9f29-3a28364cdd41"
> > > id="16736ce0-a9df-410f-9f29-3a28364cdd41">
> > > <actions>
> > > <link
> > > href="/ovirt-engine/api/storagedomains/7a48fe46-2112-40a4-814f-24d74c760b2d/disks/16736ce0-a9df-410f-9f29-3a28364cdd41/export"
> > > rel="export"/>
> > > </actions>
> > > <name>hertz_disk5</name>
> > > <description>disk for SYBASE installation, on SAN shared
> > > storage</description> <link
> > > href="/ovirt-engine/api/storagedomains/7a48fe46-2112-40a4-814f-24d74c760b2d/disks/16736ce0-a9df-410f-9f29-3a28364cdd41/permissions"
> > > rel="permissions"/>
> > > <link
> > > href="/ovirt-engine/api/storagedomains/7a48fe46-2112-40a4-814f-24d74c760b2d/disks/16736ce0-a9df-410f-9f29-3a28364cdd41/statistics"
> > > rel="statistics"/>
> > > <alias>hertz_disk5</alias>
> > > <image_id>4ab070c0-fb16-452d-8521-4ff0b004aef3</image_id>
> > > <storage_domain
> > > href="/ovirt-engine/api/storagedomains/7a48fe46-2112-40a4-814f-24d74c760b2d"
> > > id="7a48fe46-2112-40a4-814f-24d74c760b2d"/>
> > > <storage_domains>
> > > <storage_domain id="7a48fe46-2112-40a4-814f-24d74c760b2d"/>
> > > </storage_domains>
> > > <size>225485783040</size>
> > > <provisioned_size>225485783040</provisioned_size>
> > > <actual_size>225485783040</actual_size>
> > > <status>
> > > <state>ok</state>
> > > </status>
> > > <interface>ide</interface>
> > > <format>raw</format>
> > > <sparse>false</sparse>
> > > <bootable>false</bootable>
> > > <shareable>false</shareable>
> > > <wipe_after_delete>false</wipe_after_delete>
> > > <propagate_errors>false</propagate_errors>
> > > </disk>
> > > </disks>
> > >
> > > I'm waiting for any comments on the two OVF disk or any advice
> > > before proceeding with the registering command (test in production
> > > environment hmmmmm)
> > >
> > > Cheers
> > > AG
> > >
> > > -----Original Message-----
> > > From: Andrea Ghelardi [mailto:a.ghelardi@iontrading.com]
> > > Sent: Friday, May 15, 2015 12:30 PM
> > > To: Maor Lipchuk
> > > Cc: users(a)ovirt.org
> > > Subject: RE: [ovirt-users] missing disk after storage domain
> > > expansion
> > >
> > > Thank you for your reply!
> > > I'm unsure if the disk contained any snapshots. I do not think so.
> > > Is the register action a safe one to do in production system? I
> > > wouldn't mess any of my existing running servers.
> > >
> > > Here the relevant logs from the date
> > > ./engine.log-20150501.gz:2015-04-29 16:10:40,868 : disk creation
> > > ("hertz_disk5" newImageId = 4ab070c0-fb16-452d-8521-4ff0b004aef3)
> > > ./engine.log-20150512.gz:2015-05-04 17:22:42,691 : last
> > > occurrence of the imageid
> > >
> > > Please note from
> > > ./engine.log-20150512.gz 2015-05-11 12:07:16,719 : creation of
> > > two disk OVF store (??) on the same storage domain
> > > 7a48fe46-2112-40a4-814f-24d74c760b2d
> > > right after the volume expansion
> > >
> > > In the instructions.txt what I did to enlarge the volume (and
> > > lose the
> > > disk) (the guides is informational only, I followed the steps on a
> > > different
> > > server)
> > >
> > > Here some cats to thank you in advance
> > > https://www.youtube.com/watch?v=nfTY41-zC7Y
> >
> >
> > lol :)
> > Nice cats
> >
> > > AG
> > >
> > >
> > > -----Original Message-----
> > > From: Maor Lipchuk [mailto:mlipchuk@redhat.com]
> > > Sent: Wednesday, May 13, 2015 11:02 PM
> > > To: Andrea Ghelardi
> > > Cc: users(a)ovirt.org
> > > Subject: Re: [ovirt-users] missing disk after storage domain
> > > expansion
> > >
> > > Hi Andrea,
> > >
> > > First of all, the issue sounds quite severe, can u please attach
> > > the engine logs so we can try to figure out how that happened.
> > > second, does this disk contained any snapshots?
> > > If not, can you try to register it back (see
> > > http://www.ovirt.org/Features/ImportStorageDomain#Register_an_unre
> > > gi
> > > st
> > > ered_disk)
> > >
> > >
> > > Regards,
> > > Maor
> > >
> > >
> > >
> > > ----- Original Message -----
> > > > From: "Andrea Ghelardi" <a.ghelardi(a)iontrading.com>
> > > > To: users(a)ovirt.org
> > > > Sent: Monday, May 11, 2015 12:01:17 AM
> > > > Subject: Re: [ovirt-users] missing disk after storage domain
> > > > expansion
> > > >
> > > >
> > > >
> > > > Ok, so,
> > > >
> > > > After _ a lot _ of unsuccessful approach, I finally connected to
> > > > postegre DB directly.
> > > >
> > > > Browsing the tables I found “unregistered_ovf_of_entities” where
> > > > there is a reference of the missing disk
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > @ovf:diskId:4ab070c0-fb16-452d-8521-4ff0b004aef3
> > > >
> > > > @ovf:size:210
> > > >
> > > > @ovf:actual_size:210
> > > >
> > > > @ovf:vm_snapshot_id:2e24b255-bb84-4284-8785-e2a042045882
> > > >
> > > > @ovf:fileRef:16736ce0-a9df-410f-9f29-3a28364cdd41/4ab070c0-fb16-
> > > > 45
> > > > 2d
> > > > -8
> > > > 521-4ff0b004aef3
> > > >
> > > > @ovf:format:
> > > > http://www.vmware.com/specifications/vmdk.html#sparse
> > > >
> > > > @ovf:volume-format:RAW
> > > >
> > > > @ovf:volume-type:Preallocated
> > > >
> > > > @ovf:disk-interface:VirtIO
> > > >
> > > > @ovf:boot:false
> > > >
> > > > @ovf:disk-alias:hertz_disk5
> > > >
> > > > @ovf:disk-description:disk for SYBASE installation, on SAN
> > > > shared storage
> > > >
> > > > @ovf:wipe-after-delete:false
> > > >
> > > >
> > > >
> > > > However, I’ve been unable to find any other helpful details.
> > > >
> > > > I guess the disk is not recoverable at this point?
> > > >
> > > > Any guru who has a good ovirt DB kwnoledge willing to give me
> > > > some advice?
> > > >
> > > >
> > > >
> > > > Thanks as usual
> > > >
> > > > AG
> > > >
> > > >
> > > >
> > > >
> > > > From: Andrea Ghelardi [mailto: a.ghelardi(a)iontrading.com ]
> > > > Sent: Thursday, May 07, 2015 6:08 PM
> > > > To: ' users(a)ovirt.org '
> > > > Subject: missing disk after storage domain expansion
> > > >
> > > >
> > > >
> > > >
> > > > Hi gentlemen,
> > > >
> > > >
> > > >
> > > > I recently found an error on 1 of my storages: it was
> > > > complaining about no free space but the VM was running and disk
> > > > operational.
> > > >
> > > > Since I needed to perform some maintenance on the VM, I shut it
> > > > down and at restart VM couldn’t boot up properly.
> > > >
> > > > Checked VM via console and a disk was missing. Edited fstab
> > > > (luckily this disk was not root but heck! It had a Sybase DB on
> > > > it!) and restarted VM this time ok.
> > > >
> > > >
> > > >
> > > > Since the disk resides on the dstore with no space, I expanded
> > > > the iSCSI LUN, then refreshed multipath on hosts, then resized
> > > > PVs and now ovirt is showing the correct size (logs do not
> > > > complain anymore on no free space).
> > > >
> > > >
> > > >
> > > > BUUUT
> > > >
> > > >
> > > >
> > > > Now disk is missing. It is not shown anymore on Disks tab nor
> > > > anywhere else.
> > > >
> > > > Problem is that storage shows 214GB occupancy (size of the
> > > > missing
> > > > disk) so data is there but cannot find it anymore.
> > > >
> > > >
> > > >
> > > > Logs show original disk creation, errors from the lack of space,
> > > > refresh of the storage size and then.... no more references on
> > > > the disk.
> > > >
> > > >
> > > >
> > > > What can I do to find those missing ~210GBs?
> > > >
> > > >
> > > >
> > > > Cheers
> > > >
> > > > Andrea Ghelardi
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > Users mailing list
> > > > Users(a)ovirt.org
> > > > http://lists.ovirt.org/mailman/listinfo/users
> > > >
> > >
> >
>
10 years, 1 month
- 3
- 2
Gluster and Export Storage
by ml＠ohnewald.net
Hello List,
i have a GlusterFS Data (Master) Storage and a NFS Export Storage.
Now my NFS Export Storage is broken. Does this also put my GlusterFS
Data Storage into Unknown status?
I think my GlusterFS Storage is totally fine, but it wont come up. :-(
° No Split Brain
° Peers are there
° everything is online
Its related to this:
http://lists.ovirt.org/pipermail/users/2015-May/032889.html
It would be cool to get my GlusterFS Up and Running again in order to
migrate the vms onto one host and then reboot my empty one.
Here is some more gluster info: http://fpaste.org/223283/03230114/
Any ideas? Does the NFS Export Problem really block my GlusterData Domain?!
Thanks,
Mario
10 years, 1 month
- 2
- 1
Half Upgraded ovirt packages - to 3.5.2.1
by Soeren Malchow
--_000_826AB8E6591441BFAAE82DEB951200D3mconnet_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
RGVhciBhbGwsDQoNCkkgZ290IGEgcGFydGlhbGx5IHVwZ3JhZGVkIGhvc3RlZCBlbmdpbmUsIHNv
bWUgb2YgdGhlIHBhY2thZ2VzIGFyZSB1cGdyYWRlZCB0byAzLjUuMi4xIGFuZCBzb21lIGFyZSBu
b3QsIGkgY2FuIG5vdCBldmVuIHVwZ3JhZGUgYWZ0ZXJ3YXJkcw0KDQpQYWNrYWdlIGxpc3Q6DQoN
Cm92aXJ0LWVuZ2luZS1zZGstcHl0aG9uLTMuNS4yLjEtMS5lbDYubm9hcmNoDQpvdmlydC1lbmdp
bmUtbGliLTMuNS4yLjEtMS5lbDYubm9hcmNoDQpvdmlydC1lbmdpbmUtc2V0dXAtcGx1Z2luLW92
aXJ0LWVuZ2luZS0zLjUuMi4xLTEuZWw2Lm5vYXJjaA0Kb3ZpcnQtZW5naW5lLXdlYnNvY2tldC1w
cm94eS0zLjUuMi4xLTEuZWw2Lm5vYXJjaA0Kb3ZpcnQtaW1hZ2UtdXBsb2FkZXItMy41LjEtMS5l
bDYubm9hcmNoDQpvdmlydC1lbmdpbmUtamJvc3MtYXMtNy4xLjEtMS5lbDYueDg2XzY0DQpvdmly
dC1ob3N0LWRlcGxveS1qYXZhLTEuMy4xLTEuZWw2Lm5vYXJjaA0Kb3ZpcnQtZW5naW5lLTMuNS4x
LjEtMS5lbDYubm9hcmNoDQpvdmlydC1lbmdpbmUtZHdoLTMuNS4xLTEuZWw2Lm5vYXJjaA0Kb3Zp
cnQtaG9zdC1kZXBsb3ktMS4zLjEtMS5lbDYubm9hcmNoDQpvdmlydC1lbmdpbmUtc2V0dXAtYmFz
ZS0zLjUuMi4xLTEuZWw2Lm5vYXJjaA0Kb3ZpcnQtZW5naW5lLXNldHVwLXBsdWdpbi13ZWJzb2Nr
ZXQtcHJveHktMy41LjIuMS0xLmVsNi5ub2FyY2gNCm92aXJ0LXJlbGVhc2UzNS0wMDQtMS5ub2Fy
Y2gNCm92aXJ0LWVuZ2luZS1jbGktMy41LjAuNS0xLmVsNi5ub2FyY2gNCm92aXJ0LWVuZ2luZS1i
YWNrZW5kLTMuNS4xLjEtMS5lbDYubm9hcmNoDQpvdmlydC1lbmdpbmUtdXNlcnBvcnRhbC0zLjUu
MS4xLTEuZWw2Lm5vYXJjaA0Kb3ZpcnQtZW5naW5lLWRic2NyaXB0cy0zLjUuMS4xLTEuZWw2Lm5v
YXJjaA0Kb3ZpcnQtZW5naW5lLXRvb2xzLTMuNS4xLjEtMS5lbDYubm9hcmNoDQpvdmlydC1pc28t
dXBsb2FkZXItMy41LjItMS5lbDYubm9hcmNoDQpvdmlydC1lbmdpbmUtcmVwb3J0cy1zZXR1cC0z
LjUuMi0wLjMuZWw2Lm5vYXJjaA0Kb3ZpcnQtZW5naW5lLWR3aC1zZXR1cC0zLjUuMi0wLjEuZWw2
Lm5vYXJjaA0Kb3ZpcnQtZW5naW5lLXNldHVwLTMuNS4yLjEtMS5lbDYubm9hcmNoDQpvdmlydC1l
bmdpbmUtZXh0ZW5zaW9ucy1hcGktaW1wbC0zLjUuMi4xLTEuZWw2Lm5vYXJjaA0Kb3ZpcnQtZW5n
aW5lLXJlcG9ydHMtMy41LjEtMS5lbDYubm9hcmNoDQpvdmlydC1ndWVzdC10b29scy0zLjUuMC0w
LjUubWFzdGVyLm5vYXJjaA0Kb3ZpcnQtZW5naW5lLWV4dGVuc2lvbi1hYWEtbGRhcC0xLjAuMi0x
LmVsNi5ub2FyY2gNCm92aXJ0LWVuZ2luZS1zZXR1cC1wbHVnaW4tb3ZpcnQtZW5naW5lLWNvbW1v
bi0zLjUuMi4xLTEuZWw2Lm5vYXJjaA0Kb3ZpcnQtZW5naW5lLXdlYmFkbWluLXBvcnRhbC0zLjUu
MS4xLTEuZWw2Lm5vYXJjaA0Kb3ZpcnQtZW5naW5lLXJlc3RhcGktMy41LjEuMS0xLmVsNi5ub2Fy
Y2gNCm92aXJ0LWd1ZXN0LWFnZW50LTEuMC4xMC4yLTEuZWw2Lm5vYXJjaA0KDQpJZiBpIHF1ZXJ5
IHRoZSByZXBvIHdpdGggInJlcG9xdWVyeSAtLXNob3ctZHVwZXMgb3ZpcnQtZW5naW5l4oCdIGkg
Z2V0IGEgY29tcGxldGUgbGlzdCBpbmNsdWRpbmcgdGhlIDMuNS4yLjEgcGFja2FnZXMgYnV0IHdp
dGggeXVtIGkgZ2V0IG5vdGhpbmcNCg0Kb3ZpcnQtZW5naW5lLTA6My41LjAuMS0xLmVsNi5ub2Fy
Y2gNCm92aXJ0LWVuZ2luZS0wOjMuNS4xLTEuZWw2Lm5vYXJjaA0Kb3ZpcnQtZW5naW5lLTA6My41
LjEuMS0xLmVsNi5ub2FyY2gNCm92aXJ0LWVuZ2luZS0wOjMuNS4yLTEuZWw2Lm5vYXJjaA0Kb3Zp
cnQtZW5naW5lLTA6My41LjIuMS0xLmVsNi5ub2FyY2gNCg0KVW5mb3J0dW5hdGVseSBpIGhhdmUg
bmV2ZXIgc2VlbiBzdWNoIGEgYmVoYXZpb3VyIGJlZm9yZSBhbmQgaSBhbSBsaXN0Lg0KDQpEb2Vz
IGFueWJvZHkgaGF2ZSBhbiBpZGVhID8NCg0KUmVnYXJkcw0KU29lcmVuDQoNCg==
--_000_826AB8E6591441BFAAE82DEB951200D3mconnet_
Content-Type: text/html; charset="utf-8"
Content-ID: <AFA5AB1434BE0E4F8A5E360150369FCE(a)liquidcampaign.com>
Content-Transfer-Encoding: base64
PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy
YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy
ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx
NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXY+DQo8
ZGl2PkRlYXIgYWxsLDwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+SSBnb3QgYSBwYXJ0
aWFsbHkgdXBncmFkZWQgaG9zdGVkIGVuZ2luZSwgc29tZSBvZiB0aGUgcGFja2FnZXMgYXJlIHVw
Z3JhZGVkIHRvIDMuNS4yLjEgYW5kIHNvbWUgYXJlIG5vdCwgaSBjYW4gbm90IGV2ZW4gdXBncmFk
ZSBhZnRlcndhcmRzPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5QYWNrYWdlIGxpc3Q6
PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+b3ZpcnQtZW5naW5lLXNkay1w
eXRob24tMy41LjIuMS0xLmVsNi5ub2FyY2g8L2Rpdj4NCjxkaXY+b3ZpcnQtZW5naW5lLWxpYi0z
LjUuMi4xLTEuZWw2Lm5vYXJjaDwvZGl2Pg0KPGRpdj5vdmlydC1lbmdpbmUtc2V0dXAtcGx1Z2lu
LW92aXJ0LWVuZ2luZS0zLjUuMi4xLTEuZWw2Lm5vYXJjaDwvZGl2Pg0KPGRpdj5vdmlydC1lbmdp
bmUtd2Vic29ja2V0LXByb3h5LTMuNS4yLjEtMS5lbDYubm9hcmNoPC9kaXY+DQo8ZGl2Pm92aXJ0
LWltYWdlLXVwbG9hZGVyLTMuNS4xLTEuZWw2Lm5vYXJjaDwvZGl2Pg0KPGRpdj5vdmlydC1lbmdp
bmUtamJvc3MtYXMtNy4xLjEtMS5lbDYueDg2XzY0PC9kaXY+DQo8ZGl2Pm92aXJ0LWhvc3QtZGVw
bG95LWphdmEtMS4zLjEtMS5lbDYubm9hcmNoPC9kaXY+DQo8ZGl2Pm92aXJ0LWVuZ2luZS0zLjUu
MS4xLTEuZWw2Lm5vYXJjaDwvZGl2Pg0KPGRpdj5vdmlydC1lbmdpbmUtZHdoLTMuNS4xLTEuZWw2
Lm5vYXJjaDwvZGl2Pg0KPGRpdj5vdmlydC1ob3N0LWRlcGxveS0xLjMuMS0xLmVsNi5ub2FyY2g8
L2Rpdj4NCjxkaXY+b3ZpcnQtZW5naW5lLXNldHVwLWJhc2UtMy41LjIuMS0xLmVsNi5ub2FyY2g8
L2Rpdj4NCjxkaXY+b3ZpcnQtZW5naW5lLXNldHVwLXBsdWdpbi13ZWJzb2NrZXQtcHJveHktMy41
LjIuMS0xLmVsNi5ub2FyY2g8L2Rpdj4NCjxkaXY+b3ZpcnQtcmVsZWFzZTM1LTAwNC0xLm5vYXJj
aDwvZGl2Pg0KPGRpdj5vdmlydC1lbmdpbmUtY2xpLTMuNS4wLjUtMS5lbDYubm9hcmNoPC9kaXY+
DQo8ZGl2Pm92aXJ0LWVuZ2luZS1iYWNrZW5kLTMuNS4xLjEtMS5lbDYubm9hcmNoPC9kaXY+DQo8
ZGl2Pm92aXJ0LWVuZ2luZS11c2VycG9ydGFsLTMuNS4xLjEtMS5lbDYubm9hcmNoPC9kaXY+DQo8
ZGl2Pm92aXJ0LWVuZ2luZS1kYnNjcmlwdHMtMy41LjEuMS0xLmVsNi5ub2FyY2g8L2Rpdj4NCjxk
aXY+b3ZpcnQtZW5naW5lLXRvb2xzLTMuNS4xLjEtMS5lbDYubm9hcmNoPC9kaXY+DQo8ZGl2Pm92
aXJ0LWlzby11cGxvYWRlci0zLjUuMi0xLmVsNi5ub2FyY2g8L2Rpdj4NCjxkaXY+b3ZpcnQtZW5n
aW5lLXJlcG9ydHMtc2V0dXAtMy41LjItMC4zLmVsNi5ub2FyY2g8L2Rpdj4NCjxkaXY+b3ZpcnQt
ZW5naW5lLWR3aC1zZXR1cC0zLjUuMi0wLjEuZWw2Lm5vYXJjaDwvZGl2Pg0KPGRpdj5vdmlydC1l
bmdpbmUtc2V0dXAtMy41LjIuMS0xLmVsNi5ub2FyY2g8L2Rpdj4NCjxkaXY+b3ZpcnQtZW5naW5l
LWV4dGVuc2lvbnMtYXBpLWltcGwtMy41LjIuMS0xLmVsNi5ub2FyY2g8L2Rpdj4NCjxkaXY+b3Zp
cnQtZW5naW5lLXJlcG9ydHMtMy41LjEtMS5lbDYubm9hcmNoPC9kaXY+DQo8ZGl2Pm92aXJ0LWd1
ZXN0LXRvb2xzLTMuNS4wLTAuNS5tYXN0ZXIubm9hcmNoPC9kaXY+DQo8ZGl2Pm92aXJ0LWVuZ2lu
ZS1leHRlbnNpb24tYWFhLWxkYXAtMS4wLjItMS5lbDYubm9hcmNoPC9kaXY+DQo8ZGl2Pm92aXJ0
LWVuZ2luZS1zZXR1cC1wbHVnaW4tb3ZpcnQtZW5naW5lLWNvbW1vbi0zLjUuMi4xLTEuZWw2Lm5v
YXJjaDwvZGl2Pg0KPGRpdj5vdmlydC1lbmdpbmUtd2ViYWRtaW4tcG9ydGFsLTMuNS4xLjEtMS5l
bDYubm9hcmNoPC9kaXY+DQo8ZGl2Pm92aXJ0LWVuZ2luZS1yZXN0YXBpLTMuNS4xLjEtMS5lbDYu
bm9hcmNoPC9kaXY+DQo8ZGl2Pm92aXJ0LWd1ZXN0LWFnZW50LTEuMC4xMC4yLTEuZWw2Lm5vYXJj
aDwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5JZiBpIHF1ZXJ5IHRoZSBy
ZXBvIHdpdGggJnF1b3Q7cmVwb3F1ZXJ5IC0tc2hvdy1kdXBlcyBvdmlydC1lbmdpbmXigJ0gaSBn
ZXQgYSBjb21wbGV0ZSBsaXN0IGluY2x1ZGluZyB0aGUgMy41LjIuMSBwYWNrYWdlcyBidXQgd2l0
aCB5dW0gaSBnZXQgbm90aGluZzwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2
Pm92aXJ0LWVuZ2luZS0wOjMuNS4wLjEtMS5lbDYubm9hcmNoPC9kaXY+DQo8ZGl2Pm92aXJ0LWVu
Z2luZS0wOjMuNS4xLTEuZWw2Lm5vYXJjaDwvZGl2Pg0KPGRpdj5vdmlydC1lbmdpbmUtMDozLjUu
MS4xLTEuZWw2Lm5vYXJjaDwvZGl2Pg0KPGRpdj5vdmlydC1lbmdpbmUtMDozLjUuMi0xLmVsNi5u
b2FyY2g8L2Rpdj4NCjxkaXY+b3ZpcnQtZW5naW5lLTA6My41LjIuMS0xLmVsNi5ub2FyY2g8L2Rp
dj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+VW5mb3J0dW5hdGVseSBpIGhhdmUg
bmV2ZXIgc2VlbiBzdWNoIGEgYmVoYXZpb3VyIGJlZm9yZSBhbmQgaSBhbSBsaXN0LiZuYnNwOzwv
ZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+RG9lcyBhbnlib2R5IGhhdmUgYW4gaWRlYSA/
PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5SZWdhcmRzPC9kaXY+DQo8ZGl2PlNvZXJl
biZuYnNwOzwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IGlkPSJNQUNfT1VU
TE9PS19TSUdOQVRVUkUiPjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0K
PC9odG1sPg0K
--_000_826AB8E6591441BFAAE82DEB951200D3mconnet_--
10 years, 1 month
- 3
- 3
Re: [ovirt-users] Backup through export and clone
by Soeren Malchow
--_000_A13FAAA7E886416B80CF7ECF7FB53B4Amconnet_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
T25lIHNtYWxsIGFkZGl0aW9uOiBpZiBzb21lb25lIGhhcyBhbiBpZGVhIGhvdyB0byBrZWVwIHRo
ZSBsb2FkIGRvd24gZXZlbiB3aGVuIGNsb25lIHdpdGhpbiB0aGUgZ2x1c3RlciBzdG9yYWdlIGRv
bWFpbiwgYW55IHN1Z2dlc3Rpb25zIGFyZSB3ZWxjb21lIGFuZCB3ZSB3b3VsZCB0ZXN0IHRoYXQN
Cg0KRnJvbTogPHVzZXJzLWJvdW5jZXNAb3ZpcnQub3JnPG1haWx0bzp1c2Vycy1ib3VuY2VzQG92
aXJ0Lm9yZz4+IG9uIGJlaGFsZiBvZiBTb2VyZW4gTWFsY2hvdw0KRGF0ZTogV2VkbmVzZGF5IDIw
IE1heSAyMDE1IDAwOjE5DQpUbzogInVzZXJzQG92aXJ0Lm9yZzxtYWlsdG86dXNlcnNAb3ZpcnQu
b3JnPiINClN1YmplY3Q6IFtvdmlydC11c2Vyc10gQmFja3VwIHRocm91Z2ggZXhwb3J0IGFuZCBj
bG9uZQ0KDQpEZWFyIGFsbCwNCg0KSSBhbSBubyBweXRob24gZGV2ZWxvcGVyIChiYXNpY2FsbHkg
bm8gZGV2ZWxvcGVyIGF0IGFsbCkgYnV0IGkgc3RydWdnbGVkIHdpdGggdGhlIGJhY2t1cCBmb3Ig
YSB3aGlsZSBidXQgZmluYWxseSBpIGhhdmUgYSBzY3JpcHQgYWxtb3N0IE9LIGZvciB0aGUgYmFj
a3VwLg0KDQpEdWUgdG8gdGhlIGZhY3QgdGhhdCB0aGUg4oCcc25hcHNob3QgLT4gZXhwb3J04oCd
IGZlYXR1cmUgaXMgY29taW5nIGFzIGl0IHNlZW1zIGluIDMuNiB3ZSBzdGlsbCBuZWVkIHRvIGNs
b25lIGFuZCB0aGVuIGV4cG9ydC4NCg0KVGhpcyBzY3JpcHQgaXMgdGhyZWFkZWQgdG8gZG8gYmFj
a3VwcyBvZiAzIFZtcyBjb25jdXJyZW50bHksIGhvd2V2ZXIsIGluIG91ciBzZXR1cCAoIGNvbXB1
dGUgc2VydmVyIHdpdGggMyBzZXBhcmF0ZSBnbHVzdGVyIG1hY2hpbmVzKSBwYXJhbGxlbCBiYWNr
dXBzIG9mIDMgVk1TIGNyZWF0ZSB2ZXJ5IGhlYXZ5IGxvYWQgb24gdGhlIGdsdXN0ZXIgc3RvcmFn
ZSBzZXJ2ZXJzLCBhbmQgaSB3b3VsZCBsaWtlIHRvIGRvIHRoZSDigJxjbG9uZSBzbmFwc2hvdOKA
nSB0byBhIHNlcGFyYXRlIGludGVybWVkaWF0ZSBzdG9yYWdlIGFscmVhZHksIGNhbiBhbnlib2R5
IGhlbHAgbWUgd2l0aCB0aGF0ID8gKHNvbWV3aGVyZSBhcm91bmQgbGluZSA3MCkNClRoZSBjbG9u
aW5nIGNhbiBob3BlZnVsbHkgZ28gYXdheSBpbiBTZXB0ZW1iZXIgd2l0aCAzLjYgYnV0IHVudGls
IHRoZW4gd2Ugc3RpbGwgbmVlZCB0aGF0Lg0KDQpBbnkgb3RoZXIgaW1wcm92ZW1lbnRzIGFyZSBt
b3JlIHRoYW4gd2VsY29tZSDigJMgcGxlYXNlIGtlZXAgaW4gbWluZCBpIGFtIG5vdCBhIGRldmVs
b3BlciBhbmQgSSBvbmx5IHRyaWVkIG15IHZlcnkgYmVzdCB0byB3cml0ZSBhIGRlY2VudCBzY3Jp
cHQuDQoNCkFsc286IGRvIHdlIGhhdmUgYSBwbGFjZSAoZ2l0IHJlcG8gb3Igc28pIHdoZXJlIHdl
IGNhbiBwdXQgdGhpcyBzY3JpcHQgZm9yIGV2ZXJ5Ym9keSA/DQoNCkkgYW0gcHJldHR5IHN1cmUg
dGhlcmUgaXMgbW9yZSB0aGFuIG9uZSBwZXJzb24gb3V0IHRoZXJlIGxvb2tpbmcgZm9yIHNvbWV0
aGluZyBsaWtlIHRoYXQgKGF0IGxlYXN0IGkgaG9wZSA6LSkgKQ0KDQpSZWdhcmRzDQpTb2VyZW4N
Cg0K
--_000_A13FAAA7E886416B80CF7ECF7FB53B4Amconnet_
Content-Type: text/html; charset="utf-8"
Content-ID: <FD072BC5D8B01A458711015AE4BE1137(a)liquidcampaign.com>
Content-Transfer-Encoding: base64
PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy
YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy
ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx
NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXY+T25l
IHNtYWxsIGFkZGl0aW9uOiBpZiBzb21lb25lIGhhcyBhbiBpZGVhIGhvdyB0byBrZWVwIHRoZSBs
b2FkIGRvd24gZXZlbiB3aGVuIGNsb25lIHdpdGhpbiB0aGUgZ2x1c3RlciBzdG9yYWdlIGRvbWFp
biwgYW55IHN1Z2dlc3Rpb25zIGFyZSB3ZWxjb21lIGFuZCB3ZSB3b3VsZCB0ZXN0IHRoYXQmbmJz
cDs8L2Rpdj4NCjxkaXY+DQo8ZGl2IGlkPSJNQUNfT1VUTE9PS19TSUdOQVRVUkUiPjwvZGl2Pg0K
PC9kaXY+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZ
X1NFQ1RJT04iPg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTsgZm9udC1zaXplOjEy
cHQ7IHRleHQtYWxpZ246bGVmdDsgY29sb3I6YmxhY2s7IEJPUkRFUi1CT1RUT006IG1lZGl1bSBu
b25lOyBCT1JERVItTEVGVDogbWVkaXVtIG5vbmU7IFBBRERJTkctQk9UVE9NOiAwaW47IFBBRERJ
TkctTEVGVDogMGluOyBQQURESU5HLVJJR0hUOiAwaW47IEJPUkRFUi1UT1A6ICNiNWM0ZGYgMXB0
IHNvbGlkOyBCT1JERVItUklHSFQ6IG1lZGl1bSBub25lOyBQQURESU5HLVRPUDogM3B0Ij4NCjxz
cGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5Gcm9tOiA8L3NwYW4+Jmx0OzxhIGhyZWY9Im1h
aWx0bzp1c2Vycy1ib3VuY2VzQG92aXJ0Lm9yZyI+dXNlcnMtYm91bmNlc0BvdmlydC5vcmc8L2E+
Jmd0OyBvbiBiZWhhbGYgb2YgU29lcmVuIE1hbGNob3c8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13
ZWlnaHQ6Ym9sZCI+RGF0ZTogPC9zcGFuPldlZG5lc2RheSAyMCBNYXkgMjAxNSAwMDoxOTxicj4N
CjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5UbzogPC9zcGFuPiZxdW90OzxhIGhyZWY9
Im1haWx0bzp1c2Vyc0BvdmlydC5vcmciPnVzZXJzQG92aXJ0Lm9yZzwvYT4mcXVvdDs8YnI+DQo8
c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+U3ViamVjdDogPC9zcGFuPltvdmlydC11c2Vy
c10gQmFja3VwIHRocm91Z2ggZXhwb3J0IGFuZCBjbG9uZTxicj4NCjwvZGl2Pg0KPGRpdj48YnI+
DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJr
aXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFj
ZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAxNHB4OyBmb250LWZhbWlseTogQ2Fs
aWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj5EZWFyIGFsbCw8L2Rpdj4NCjxkaXY+PGJyPg0KPC9k
aXY+DQo8ZGl2PkkgYW0gbm8gcHl0aG9uIGRldmVsb3BlciAoYmFzaWNhbGx5IG5vIGRldmVsb3Bl
ciBhdCBhbGwpIGJ1dCBpIHN0cnVnZ2xlZCB3aXRoIHRoZSBiYWNrdXAgZm9yIGEgd2hpbGUgYnV0
IGZpbmFsbHkgaSBoYXZlIGEgc2NyaXB0IGFsbW9zdCBPSyBmb3IgdGhlIGJhY2t1cC48L2Rpdj4N
CjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkR1ZSB0byB0aGUgZmFjdCB0aGF0IHRoZSDigJxzbmFw
c2hvdCAtJmd0OyBleHBvcnTigJ0gZmVhdHVyZSBpcyBjb21pbmcgYXMgaXQgc2VlbXMgaW4gMy42
IHdlIHN0aWxsIG5lZWQgdG8gY2xvbmUgYW5kIHRoZW4gZXhwb3J0LjwvZGl2Pg0KPGRpdj48YnI+
DQo8L2Rpdj4NCjxkaXY+VGhpcyBzY3JpcHQgaXMgdGhyZWFkZWQgdG8gZG8gYmFja3VwcyBvZiAz
IFZtcyBjb25jdXJyZW50bHksIGhvd2V2ZXIsIGluIG91ciBzZXR1cCAoIGNvbXB1dGUgc2VydmVy
IHdpdGggMyBzZXBhcmF0ZSBnbHVzdGVyIG1hY2hpbmVzKSBwYXJhbGxlbCBiYWNrdXBzIG9mIDMg
Vk1TIGNyZWF0ZSB2ZXJ5IGhlYXZ5IGxvYWQgb24gdGhlIGdsdXN0ZXIgc3RvcmFnZSBzZXJ2ZXJz
LCBhbmQgaSB3b3VsZCBsaWtlIHRvIGRvIHRoZSDigJxjbG9uZSBzbmFwc2hvdOKAnQ0KIHRvIGEg
c2VwYXJhdGUgaW50ZXJtZWRpYXRlIHN0b3JhZ2UgYWxyZWFkeSwgY2FuIGFueWJvZHkgaGVscCBt
ZSB3aXRoIHRoYXQgPyAoc29tZXdoZXJlIGFyb3VuZCBsaW5lIDcwKTwvZGl2Pg0KPGRpdj5UaGUg
Y2xvbmluZyBjYW4gaG9wZWZ1bGx5IGdvIGF3YXkgaW4gU2VwdGVtYmVyIHdpdGggMy42IGJ1dCB1
bnRpbCB0aGVuIHdlIHN0aWxsIG5lZWQgdGhhdC48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8
ZGl2PkFueSBvdGhlciBpbXByb3ZlbWVudHMgYXJlIG1vcmUgdGhhbiB3ZWxjb21lIOKAkyBwbGVh
c2Uga2VlcCBpbiBtaW5kIGkgYW0gbm90IGEgZGV2ZWxvcGVyIGFuZCBJIG9ubHkgdHJpZWQgbXkg
dmVyeSBiZXN0IHRvIHdyaXRlIGEgZGVjZW50IHNjcmlwdC48L2Rpdj4NCjxkaXY+PGJyPg0KPC9k
aXY+DQo8ZGl2PkFsc286IGRvIHdlIGhhdmUgYSBwbGFjZSAoZ2l0IHJlcG8gb3Igc28pIHdoZXJl
IHdlIGNhbiBwdXQgdGhpcyBzY3JpcHQgZm9yIGV2ZXJ5Ym9keSA/PC9kaXY+DQo8ZGl2Pjxicj4N
CjwvZGl2Pg0KPGRpdj5JIGFtIHByZXR0eSBzdXJlIHRoZXJlIGlzIG1vcmUgdGhhbiBvbmUgcGVy
c29uIG91dCB0aGVyZSBsb29raW5nIGZvciBzb21ldGhpbmcgbGlrZSB0aGF0IChhdCBsZWFzdCBp
IGhvcGUgOi0pICk8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlJlZ2FyZHM8L2Rpdj4N
CjxkaXY+U29lcmVuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgaWQ9IiI+
PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L3NwYW4+DQo8L2JvZHk+DQo8L2h0bWw+
DQo=
--_000_A13FAAA7E886416B80CF7ECF7FB53B4Amconnet_--
10 years, 1 month
- 1
- 0
Backup through export and clone
by Soeren Malchow
--_004_2BD21C61C0C14E8DACCCC9752B029867mconnet_
Content-Type: multipart/alternative;
boundary="_000_2BD21C61C0C14E8DACCCC9752B029867mconnet_"
--_000_2BD21C61C0C14E8DACCCC9752B029867mconnet_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
RGVhciBhbGwsDQoNCkkgYW0gbm8gcHl0aG9uIGRldmVsb3BlciAoYmFzaWNhbGx5IG5vIGRldmVs
b3BlciBhdCBhbGwpIGJ1dCBpIHN0cnVnZ2xlZCB3aXRoIHRoZSBiYWNrdXAgZm9yIGEgd2hpbGUg
YnV0IGZpbmFsbHkgaSBoYXZlIGEgc2NyaXB0IGFsbW9zdCBPSyBmb3IgdGhlIGJhY2t1cC4NCg0K
RHVlIHRvIHRoZSBmYWN0IHRoYXQgdGhlIOKAnHNuYXBzaG90IC0+IGV4cG9ydOKAnSBmZWF0dXJl
IGlzIGNvbWluZyBhcyBpdCBzZWVtcyBpbiAzLjYgd2Ugc3RpbGwgbmVlZCB0byBjbG9uZSBhbmQg
dGhlbiBleHBvcnQuDQoNClRoaXMgc2NyaXB0IGlzIHRocmVhZGVkIHRvIGRvIGJhY2t1cHMgb2Yg
MyBWbXMgY29uY3VycmVudGx5LCBob3dldmVyLCBpbiBvdXIgc2V0dXAgKCBjb21wdXRlIHNlcnZl
ciB3aXRoIDMgc2VwYXJhdGUgZ2x1c3RlciBtYWNoaW5lcykgcGFyYWxsZWwgYmFja3VwcyBvZiAz
IFZNUyBjcmVhdGUgdmVyeSBoZWF2eSBsb2FkIG9uIHRoZSBnbHVzdGVyIHN0b3JhZ2Ugc2VydmVy
cywgYW5kIGkgd291bGQgbGlrZSB0byBkbyB0aGUg4oCcY2xvbmUgc25hcHNob3TigJ0gdG8gYSBz
ZXBhcmF0ZSBpbnRlcm1lZGlhdGUgc3RvcmFnZSBhbHJlYWR5LCBjYW4gYW55Ym9keSBoZWxwIG1l
IHdpdGggdGhhdCA/IChzb21ld2hlcmUgYXJvdW5kIGxpbmUgNzApDQpUaGUgY2xvbmluZyBjYW4g
aG9wZWZ1bGx5IGdvIGF3YXkgaW4gU2VwdGVtYmVyIHdpdGggMy42IGJ1dCB1bnRpbCB0aGVuIHdl
IHN0aWxsIG5lZWQgdGhhdC4NCg0KQW55IG90aGVyIGltcHJvdmVtZW50cyBhcmUgbW9yZSB0aGFu
IHdlbGNvbWUg4oCTIHBsZWFzZSBrZWVwIGluIG1pbmQgaSBhbSBub3QgYSBkZXZlbG9wZXIgYW5k
IEkgb25seSB0cmllZCBteSB2ZXJ5IGJlc3QgdG8gd3JpdGUgYSBkZWNlbnQgc2NyaXB0Lg0KDQpB
bHNvOiBkbyB3ZSBoYXZlIGEgcGxhY2UgKGdpdCByZXBvIG9yIHNvKSB3aGVyZSB3ZSBjYW4gcHV0
IHRoaXMgc2NyaXB0IGZvciBldmVyeWJvZHkgPw0KDQpJIGFtIHByZXR0eSBzdXJlIHRoZXJlIGlz
IG1vcmUgdGhhbiBvbmUgcGVyc29uIG91dCB0aGVyZSBsb29raW5nIGZvciBzb21ldGhpbmcgbGlr
ZSB0aGF0IChhdCBsZWFzdCBpIGhvcGUgOi0pICkNCg0KUmVnYXJkcw0KU29lcmVuDQoNCg==
--_000_2BD21C61C0C14E8DACCCC9752B029867mconnet_
Content-Type: text/html; charset="utf-8"
Content-ID: <B23104407061FD47B920E44171210E96(a)liquidcampaign.com>
Content-Transfer-Encoding: base64
PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy
YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy
ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx
NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj5EZWFyIGFsbCw8
L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkkgYW0gbm8gcHl0aG9uIGRldmVsb3BlciAo
YmFzaWNhbGx5IG5vIGRldmVsb3BlciBhdCBhbGwpIGJ1dCBpIHN0cnVnZ2xlZCB3aXRoIHRoZSBi
YWNrdXAgZm9yIGEgd2hpbGUgYnV0IGZpbmFsbHkgaSBoYXZlIGEgc2NyaXB0IGFsbW9zdCBPSyBm
b3IgdGhlIGJhY2t1cC48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkR1ZSB0byB0aGUg
ZmFjdCB0aGF0IHRoZSDigJxzbmFwc2hvdCAtJmd0OyBleHBvcnTigJ0gZmVhdHVyZSBpcyBjb21p
bmcgYXMgaXQgc2VlbXMgaW4gMy42IHdlIHN0aWxsIG5lZWQgdG8gY2xvbmUgYW5kIHRoZW4gZXhw
b3J0LjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+VGhpcyBzY3JpcHQgaXMgdGhyZWFk
ZWQgdG8gZG8gYmFja3VwcyBvZiAzIFZtcyBjb25jdXJyZW50bHksIGhvd2V2ZXIsIGluIG91ciBz
ZXR1cCAoIGNvbXB1dGUgc2VydmVyIHdpdGggMyBzZXBhcmF0ZSBnbHVzdGVyIG1hY2hpbmVzKSBw
YXJhbGxlbCBiYWNrdXBzIG9mIDMgVk1TIGNyZWF0ZSB2ZXJ5IGhlYXZ5IGxvYWQgb24gdGhlIGds
dXN0ZXIgc3RvcmFnZSBzZXJ2ZXJzLCBhbmQgaSB3b3VsZCBsaWtlIHRvIGRvIHRoZSDigJxjbG9u
ZSBzbmFwc2hvdOKAnQ0KIHRvIGEgc2VwYXJhdGUgaW50ZXJtZWRpYXRlIHN0b3JhZ2UgYWxyZWFk
eSwgY2FuIGFueWJvZHkgaGVscCBtZSB3aXRoIHRoYXQgPyAoc29tZXdoZXJlIGFyb3VuZCBsaW5l
IDcwKTwvZGl2Pg0KPGRpdj5UaGUgY2xvbmluZyBjYW4gaG9wZWZ1bGx5IGdvIGF3YXkgaW4gU2Vw
dGVtYmVyIHdpdGggMy42IGJ1dCB1bnRpbCB0aGVuIHdlIHN0aWxsIG5lZWQgdGhhdC48L2Rpdj4N
CjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkFueSBvdGhlciBpbXByb3ZlbWVudHMgYXJlIG1vcmUg
dGhhbiB3ZWxjb21lIOKAkyBwbGVhc2Uga2VlcCBpbiBtaW5kIGkgYW0gbm90IGEgZGV2ZWxvcGVy
IGFuZCBJIG9ubHkgdHJpZWQgbXkgdmVyeSBiZXN0IHRvIHdyaXRlIGEgZGVjZW50IHNjcmlwdC48
L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkFsc286IGRvIHdlIGhhdmUgYSBwbGFjZSAo
Z2l0IHJlcG8gb3Igc28pIHdoZXJlIHdlIGNhbiBwdXQgdGhpcyBzY3JpcHQgZm9yIGV2ZXJ5Ym9k
eSA/PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5JIGFtIHByZXR0eSBzdXJlIHRoZXJl
IGlzIG1vcmUgdGhhbiBvbmUgcGVyc29uIG91dCB0aGVyZSBsb29raW5nIGZvciBzb21ldGhpbmcg
bGlrZSB0aGF0IChhdCBsZWFzdCBpIGhvcGUgOi0pICk8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+
DQo8ZGl2PlJlZ2FyZHM8L2Rpdj4NCjxkaXY+U29lcmVuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2
Pg0KPGRpdj4NCjxkaXYgaWQ9Ik1BQ19PVVRMT09LX1NJR05BVFVSRSI+PC9kaXY+DQo8L2Rpdj4N
CjwvYm9keT4NCjwvaHRtbD4NCg==
--_000_2BD21C61C0C14E8DACCCC9752B029867mconnet_--
--_004_2BD21C61C0C14E8DACCCC9752B029867mconnet_
Content-Type: text/x-python-script; name="backup-queue.py"
Content-Description: backup-queue.py
Content-Disposition: attachment; filename="backup-queue.py"; size=5249;
creation-date="Tue, 19 May 2015 22:19:10 GMT";
modification-date="Tue, 19 May 2015 22:19:10 GMT"
Content-ID: <786F63264519A449B193A37F1DC80C77(a)liquidcampaign.com>
Content-Transfer-Encoding: base64
IyEvdXNyL2Jpbi9weXRob24KCmltcG9ydCBRdWV1ZQppbXBvcnQgdGhyZWFkaW5nCmltcG9ydCB0
aW1lCmZyb20gb3ZpcnRzZGsuYXBpIGltcG9ydCBBUEkKZnJvbSBvdmlydHNkay54bWwgaW1wb3J0
IHBhcmFtcwppbXBvcnQgc3lzCmltcG9ydCBkYXRldGltZQppbXBvcnQgc210cGxpYgpmcm9tIGVt
YWlsLm1pbWUudGV4dCBpbXBvcnQgTUlNRVRleHQKCgpnbG9iYWwgU05BUFNIT1RfTkFNRQoKVkVS
U0lPTiAgICAgICAgICAgICA9IHBhcmFtcy5WZXJzaW9uKG1ham9yPSczJywgbWlub3I9JzAnKQpF
TkdJTkVfU0VSVkVSICAgICAgID0gJycKRU5HSU5FX1VTRVIgICAgICAgICA9ICdhZG1pbkBpbnRl
cm5hbCcKRU5HSU5FX1BBU1NXT1JEICAgICA9ICcnCkVOR0lORV9DRVJUICAgICAgICAgPSAnJwpO
T1cgICAgICAgICAgICAgICAgID0gZGF0ZXRpbWUuZGF0ZXRpbWUubm93KCkKU05BUFNIT1RfTkFN
RSAgICAgICA9ICdCQUNLVVBfJyArIE5PVy5zdHJmdGltZSgiJVktJW0tJWQtJUglTSIpCkRBWV9P
Rl9XRUVLICAgICAgICAgPSBOT1cuc3RyZnRpbWUoIiV3IikKQkFDS1VQICAgICAgICAgICAgICA9
ICJGVUxMIgoKZXhpdEZsYWcgPSAwCgpjbGFzcyBteVRocmVhZCAodGhyZWFkaW5nLlRocmVhZCk6
CiAgICBkZWYgX19pbml0X18oc2VsZiwgdGhyZWFkSUQsIG5hbWUsIHEpOgogICAgICAgIHRocmVh
ZGluZy5UaHJlYWQuX19pbml0X18oc2VsZikKICAgICAgICBzZWxmLnRocmVhZElEID0gdGhyZWFk
SUQKICAgICAgICBzZWxmLm5hbWUgPSBuYW1lCiAgICAgICAgc2VsZi5xID0gcQogICAgICAgIHNl
bGYuYXBpID0gYXBpCiAgICAgICAgZ2xvYmFsIG1lc3NhZ2UKICAgIGRlZiBydW4oc2VsZik6CiAg
ICAgICAgcHJpbnQgIlN0YXJ0aW5nICIgKyBzZWxmLm5hbWUKICAgICAgICBwcm9jZXNzX2RhdGEo
c2VsZi5uYW1lLCBzZWxmLnEpCiAgICAgICAgcHJpbnQgIkV4aXRpbmcgIiArIHNlbGYubmFtZQoK
ZGVmIHByb2Nlc3NfZGF0YSh0aHJlYWROYW1lLCBxKToKICAgIHdoaWxlIG5vdCBleGl0RmxhZzoK
ICAgICAgICBxdWV1ZUxvY2suYWNxdWlyZSgpCiAgICAgICAgaWYgbm90IHdvcmtRdWV1ZS5lbXB0
eSgpOgogICAgICAgICAgICBkYXRhID0gcS5nZXQoKQogICAgICAgICAgICBxdWV1ZUxvY2sucmVs
ZWFzZSgpCiAgICAgICAgICAgIHByaW50ICIlcyBwcm9jZXNzaW5nICVzIiAlICh0aHJlYWROYW1l
LCBkYXRhLm5hbWUpCiAgICAgICAgICAgIHZtID0gYXBpLnZtcy5nZXQobmFtZT1kYXRhLm5hbWUp
CiAgICAgICAgICAgIHZtbmFtZSA9IGRhdGEubmFtZSArIl8iCiAgICAgICAgICAgIG5ld3ZtbmFt
ZSA9IHZtbmFtZSArIFNOQVBTSE9UX05BTUUKICAgICAgICAgICAgY2x1c3RlciA9IGFwaS5jbHVz
dGVycy5nZXQoaWQ9dm0uY2x1c3Rlci5pZCkKICAgICAgICAgICAgZGMgPSBhcGkuZGF0YWNlbnRl
cnMuZ2V0KGlkPWNsdXN0ZXIuZGF0YV9jZW50ZXIuaWQpCiAgICAgICAgICAgIGV4cG9ydCA9IE5v
bmUKICAgICAgICAgICAgZm9yIHNkIGluIGRjLnN0b3JhZ2Vkb21haW5zLmxpc3QoKToKICAgICAg
ICAgICAgICAgIGlmIHNkLnR5cGVfID09ICJleHBvcnQiOgogICAgICAgICAgICAgICAgICAgIGV4
cG9ydCA9IHNkCiAgICAgICAgICAgIGlmIG5vdCBleHBvcnQ6CiAgICAgICAgICAgICAgICBwcmlu
dCgiRXhwb3J0IGRvbWFpbiByZXF1aXJlZCwgYW5kIG5vbmUgZm91bmQsIGV4aXR0aW5nLi4uXG4i
KQogICAgICAgICAgICAgICAgc3lzLmV4aXQoMSkKCiAgICAgICAgICAgIGlmIHZtLm5hbWUgIT0g
Ikhvc3RlZEVuZ2luZSI6CiAgICAgICAgICAgICAgICB2bS5zbmFwc2hvdHMuYWRkKHBhcmFtcy5T
bmFwc2hvdChkZXNjcmlwdGlvbj1TTkFQU0hPVF9OQU1FLCB2bT12bSApKQogICAgICAgICAgICAg
ICAgc25hcCA9IHZtLnNuYXBzaG90cy5saXN0KGRlc2NyaXB0aW9uPVNOQVBTSE9UX05BTUUpWzBd
CiAgICAgICAgICAgICAgICB3aGlsZSB2bS5zbmFwc2hvdHMuZ2V0KGlkPXNuYXAuaWQpLnNuYXBz
aG90X3N0YXR1cyA9PSAibG9ja2VkIjoKICAgICAgICAgICAgICAgICAgICBwcmludCgiJXMgV2Fp
dGluZyBmb3Igc25hcHNob3Qgb2YgJXMgdG8gZmluaXNoIikgJSAodGhyZWFkTmFtZSwgdm0ubmFt
ZSkKICAgICAgICAgICAgICAgICAgICB0aW1lLnNsZWVwKDEwKQogICAgICAgICAgICAgICAgcHJp
bnQoIiVzIFNuYXBzaG90dGluZyAlcyBpcyBkb25lIikgJSAodGhyZWFkTmFtZSx2bS5uYW1lKQog
ICAgICAgICAgICAgICAgdHJ5OgogICAgICAgICAgICAgICAgICAgIHNuYXBzaG90cyA9IHBhcmFt
cy5TbmFwc2hvdHMoc25hcHNob3Q9W3BhcmFtcy5TbmFwc2hvdChpZD1zbmFwLmlkKV0pCiAgICAg
ICAgICAgICAgICAgICAgYXBpLnZtcy5hZGQocGFyYW1zLlZNKG5hbWU9bmV3dm1uYW1lLCBzbmFw
c2hvdHM9c25hcHNob3RzLCBjbHVzdGVyPWNsdXN0ZXIsIHRlbXBsYXRlPWFwaS50ZW1wbGF0ZXMu
Z2V0KG5hbWU9IkJsYW5rIikpKQogICAgICAgICAgICAgICAgICAgIHdoaWxlIGFwaS52bXMuZ2V0
KG5hbWU9bmV3dm1uYW1lKS5zdGF0dXMuc3RhdGUgPT0gImltYWdlX2xvY2tlZCI6CiAgICAgICAg
ICAgICAgICAgICAgICAgIHByaW50KCIlcyBXYWl0aW5nIGZvciBjbG9uZSBvZiAlcyB0byBmaW5p
c2giKSAlICh0aHJlYWROYW1lLCB2bS5uYW1lKQogICAgICAgICAgICAgICAgICAgICAgICB0aW1l
LnNsZWVwKDYwKQogICAgICAgICAgICAgICAgICAgIHByaW50KCIlcyBDbG9uaW5nIG9mICVzICBk
b25lIikgJSAodGhyZWFkTmFtZSwgdm0ubmFtZSkKICAgICAgICAgICAgICAgICAgICBhcGkudm1z
LmdldChuYW1lPW5ld3ZtbmFtZSkuZXhwb3J0KHBhcmFtcy5BY3Rpb24oc3RvcmFnZV9kb21haW49
ZXhwb3J0KSkKICAgICAgICAgICAgICAgICAgICB3aGlsZSBhcGkudm1zLmdldChuYW1lPW5ld3Zt
bmFtZSkuc3RhdHVzLnN0YXRlID09ICJpbWFnZV9sb2NrZWQiOgogICAgICAgICAgICAgICAgICAg
ICAgICBwcmludCgiJXMgV2FpdGluZyBmb3IgZXhwb3J0IG9mICVzIGZpbmlzaCIpICUgKHRocmVh
ZE5hbWUsIHZtLm5hbWUpCiAgICAgICAgICAgICAgICAgICAgICAgIHRpbWUuc2xlZXAoNjApCiAg
ICAgICAgICAgICAgICAgICAgcHJpbnQoIiVzIEV4cG9ydGluZyAlcyBkb25lIikgJSAodGhyZWFk
TmFtZSwgdm0ubmFtZSkKICAgICAgICAgICAgICAgICAgICBhcGkudm1zLmdldChuYW1lPW5ld3Zt
bmFtZSkuZGVsZXRlKCkKICAgICAgICAgICAgICAgIGV4Y2VwdCBFeGNlcHRpb24gYXMgZToKICAg
ICAgICAgICAgICAgICAgICBwcmludCAoIlNvbWV0aGluZyB3ZW50IHdyb25nIHdpdGggdGhlIGNv
bGluZyBvciBleHBvcnRpbmdcbiVzIikgJSBzdHIoZSkKICAgICAgICAgICAgICAgIHNuYXBzaG90
bGlzdCA9IHZtLnNuYXBzaG90cy5saXN0KCkKICAgICAgICAgICAgICAgIGZvciBzbmFwc2hvdCBp
biBzbmFwc2hvdGxpc3Q6CiAgICAgICAgICAgICAgICAgICAgaWYgc25hcHNob3QuZGVzY3JpcHRp
b24gIT0gIkFjdGl2ZSBWTSI6CiAgICAgICAgICAgICAgICAgICAgICAgIHNuYXBzaG90LmRlbGV0
ZSgpCiAgICAgICAgICAgICAgICAgICAgICAgIHRpbWUuc2xlZXAoMykKICAgICAgICAgICAgICAg
ICAgICAgICAgdHJ5OgogICAgICAgICAgICAgICAgICAgICAgICAgICAgd2hpbGUgYXBpLnZtcy5n
ZXQobmFtZT12bS5uYW1lKS5zbmFwc2hvdHMuZ2V0KGlkPXNuYXBzaG90LmlkKS5zbmFwc2hvdF9z
dGF0dXMgPT0gImxvY2tlZCI6CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgcHJpbnQo
IiVzIFdhaXRpbmcgZm9yIHNuYXBzaG90ICVzIG9uICVzIGRlbGV0aW9uIHRvIGZpbmlzaCIpICUg
KHRocmVhZE5hbWUsIHNuYXBzaG90Lm5hbWUsIHZtLm5hbWUpCiAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgdGltZS5zbGVlcCgxMCkKICAgICAgICAgICAgICAgICAgICAgICAgZXhjZXB0
IEV4Y2VwdGlvbiBhcyBlOgogICAgICAgICAgICAgICAgICAgICAgICAgICAgcHJpbnQgKCIlcyBT
bmFwc2hvdCBzdGF0dXMgcmVxdWVzdCBtaWdodCBoYXZlIGZhaWxlZCwgdGhpcyB1c3VhbGx5IG1l
YW5zIHRoYXQgdGhlIHNucGFzaG90IHdhcyBkZWxldGVkIHByb3Blcmx5IikgJSB0aHJlYWROYW1l
CiAgICAgICAgICAgICAgICAgICAgICAgIHByaW50KCIlcyBEZWxldGluZyBzbmFwc2hvdCAlcyBv
biAlcyBkb25lIikgJSAodGhyZWFkTmFtZSwgc25hcHNob3QubmFtZSwgdm0ubmFtZSkKCiAgICAg
ICAgZWxzZToKICAgICAgICAgICAgcXVldWVMb2NrLnJlbGVhc2UoKQogICAgICAgIHRpbWUuc2xl
ZXAoMSkKCnRocmVhZExpc3QgPSBbIkJhY2t1cC1UaHJlYWQtMSIsICJCYWNrdXAtVGhyZWFkLTIi
LCAiQmFja3VwLVRocmVhZC0zIl0KCmRlZiBDb25uZWN0KCk6CiAgICBnbG9iYWwgYXBpCiAgICBh
cGkgPSBBUEkodXJsPUVOR0lORV9TRVJWRVIsIHVzZXJuYW1lPUVOR0lORV9VU0VSLCBwYXNzd29y
ZD1FTkdJTkVfUEFTU1dPUkQsIGNhX2ZpbGU9RU5HSU5FX0NFUlQpCgpkZWYgRGlzY29ubmVjdChl
eGl0Y29kZSk6CiAgICBhcGkuZGlzY29ubmVjdCgpCiAgICBzeXMuZXhpdChleGl0Y29kZSkKCnRy
eToKICAgIENvbm5lY3QoKQogICAgdm1zID0gYXBpLnZtcy5saXN0KCkKCmV4Y2VwdCBFeGNlcHRp
b24gYXMgZToKICAgIHByaW50ICdGYWlsZWQ6XG4lcycgJSBzdHIoZSkKCm5hbWVMaXN0ID0gdm1z
IApxdWV1ZUxvY2sgPSB0aHJlYWRpbmcuTG9jaygpCndvcmtRdWV1ZSA9IFF1ZXVlLlF1ZXVlKDAp
CnRocmVhZHMgPSBbXQp0aHJlYWRJRCA9IDEKCiMgQ3JlYXRlIG5ldyB0aHJlYWRzCmZvciB0TmFt
ZSBpbiB0aHJlYWRMaXN0OgogICAgdGhyZWFkID0gbXlUaHJlYWQodGhyZWFkSUQsIHROYW1lLCB3
b3JrUXVldWUpCiAgICB0aHJlYWQuc3RhcnQoKQogICAgdGhyZWFkcy5hcHBlbmQodGhyZWFkKQog
ICAgdGhyZWFkSUQgKz0gMQoKIyBGaWxsIHRoZSBxdWV1ZQpxdWV1ZUxvY2suYWNxdWlyZSgpCmZv
ciB3b3JkIGluIG5hbWVMaXN0OgogICAgd29ya1F1ZXVlLnB1dCh3b3JkKQpxdWV1ZUxvY2sucmVs
ZWFzZSgpCgojIFdhaXQgZm9yIHF1ZXVlIHRvIGVtcHR5CndoaWxlIG5vdCB3b3JrUXVldWUuZW1w
dHkoKToKICAgIHBhc3MKCiMgTm90aWZ5IHRocmVhZHMgaXQncyB0aW1lIHRvIGV4aXQKZXhpdEZs
YWcgPSAxCgojIFdhaXQgZm9yIGFsbCB0aHJlYWRzIHRvIGNvbXBsZXRlCmZvciB0IGluIHRocmVh
ZHM6CiAgICB0LmpvaW4oKQpwcmludCAiRXhpdGluZyBNYWluIFRocmVhZCIKYXBpLmRpc2Nvbm5l
Y3QoKQo=
--_004_2BD21C61C0C14E8DACCCC9752B029867mconnet_--
10 years, 1 month
- 1
- 0
ReferenceError: WebUtil is not defined => novnc console broken after yum update (on centos 6.6?)
by ml＠ohnewald.net
Hello,
i think i ran into this bug:
https://bugzilla.redhat.com/show_bug.cgi?format=multiple&id=1202356
I can not use my novnc console anymore.
Does anyone have a fix for this (on centos 6.6?)
Thanks,
Mario
10 years, 1 month
- 3
- 2
Postponing oVirt 3.6.0 alpha to tomorrow
by Sandro Bonazzola
Hi,
due to outage on the copr repository not providing patternfly rpms, we need to postpone the alpha to tomorrow
in order to properly test it before releasing.
Thanks,
--
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com
10 years, 1 month
- 1
- 0