[ovirt-users] Re: OVN networks

[Michael Burman]

Hi Egor,

This feature requires Cluster enabled with Open vSwitch networking. Create
a new Cluster with Switch Type set to OVS (experimental). You need to
create a new cluster, in 'Switch Type' choose OVS.
The upgrade from linux bridge to OVS type is not officially supported.

Cheers)

On Mon, May 28, 2018 at 5:07 PM, Егор Чиж  wrote:

>
>
> Hello,
>
> Could you help with how to change Switch type in ovirt cluster from Linux
> Bridge to OVS.
>
> I mean, using this link https://ovirt.org/develop/release-management/
> features/network/provider-physical-network/
> I read paragraph  Create a cluster with Network Type set to OVS.
>
> Now i have cluster with installing type Linux Bridge, how can i changed it
> to OVS?
>
> Best regards,
> Egor
>
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> oVirt Code of Conduct: https://www.ovirt.org/community/about/community-
> guidelines/
> List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/
> message/XIYRT3TPID5KAAML4UHJCBKUCJPMT2L6/
>
>


-- 

Michael Burman

Senior Quality engineer - rhv network - redhat israel

Red Hat



mbur...@redhat.comM: 0545355725 IM: mburman

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

[ovirt-users] Re: Attaching previously owned storage domain to 4.2 Cluster

[Maton, Brett]

I've not needed to do it with production data.
But when I trash my testlab hosted engine I regularly re-import the
existing vm (not hosted engine) storage domain.
Not had many issues with the process.

That said, I've only done it with all vm's being down and physical hosts
rebooted to ensure that no VM is active on the 'old' storage area.

On 30 May 2018 at 15:59, John Nguyen  wrote:

> Hi Guys,
>
> I'm working through a disaster recovery of a failed cluster.  And I found
> the documentation for attaching the old storage domain as an import domain
> to a new Cluster.  Both clusters are 4.2.
>
> https://ovirt.org/develop/release-management/features/
> storage/importstoragedomain/
>
> The documentation is referencing 3.5 and I would like to know if its still
> applies to the 4.2 release.
>
> When I try to do the import I see warnings below:
>
>
>
> I know that its really hard to say this operation may not be destructive.
> But is the general work flow outlined in the 3.5 documentation still valid?
>
> Thanks,
> John
>
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> oVirt Code of Conduct: https://www.ovirt.org/community/about/community-
> guidelines/
> List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/
> message/GRFF63P6ORZKGGH734EJT5Y53W3PB36P/
>
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/PTETMNEPFLBMTBKN6NWG72QL3UNYLYEQ/

[ovirt-users] logical_name of virtual machine disk not seen in the ovirt engine

[Punaatua PK]

Hello,

i used the vm_backup script as provide here : 
https://github.com/oVirt/ovirt-engine-sdk/blob/master/sdk/examples/vm_backup.py

I understood the process to backup VM. I'm stuck at getting the logical_name of 
the disk when the snapshot disk is attached in a VM.

I checked the flow like this:

- The disk is attached on the VM
- oVirt guest agent detect the new disk and the mapping seen on the LOG (i did 
put those log in DEBUG in /etc/ovirt-guest-agent.conf), i also reduce the 
report_disk_usage to 10 to speed up the process
- VDSM on the host get the info from the ovirt guest agent seen by running the 
following command vdsm-client Host getVMFullList
- On the engine the logical_name is empty seen with the following sql request 
select device,type,device_id, logical_name from vm_device where type='disk' and 
vm_id='XXX';

ovirt-engine-4.2.3.5-1.el7.centos.noarch
vdsm-4.20.27.1-1.el7.centos.x86_64
ovirt-guest-agent-common-1.0.14-1.el7.noarch

Do you have an idea ? Is the information request by the engine to VDSM ? VDSM 
does report to the engine ? What is the flow to get the logical_name populated 
in the engine DB, python SDK ? 

I can provide logs if needed. I juste don't know how to enable debug on VDSM (I 
will take a look for this)
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/XX56LMYRBV73WWGLEEVMBF2KYOAGYQBS/

[ovirt-users] Re: Simple API call to start VM

[Kirin van der Veer]

Many thanks to:
gsswzt, Luca, Andrej, Fred, Karli, Ondra and Bohdan for their replies.

A number of people mentioned the need to specify a CA cert, but curl was
able to find my organizations CA locally - so that was not an issue.
Correcting my url to include ovirt-engine in the path and my username to
admin@internal as suggested by Andrej as per below:
curl --user "admin@internal:SECRETPASSWORD" --request POST --header
"Content-Type: application/xml" --header "Accept: application/xml" --data
''
https://ovirt-engine.localnet:443/ovirt-engine/api/vms/69c47a91-bbv1-4eda-b71d-7bddf82ee8ab/start

Got me a new error message:


For correct usage, see:
https://ovirt-engine.localnet/ovirt-engine/apidoc#services/vm/methods/start

Request syntactically incorrect.


I followed the URL, but it just seemed to repeat the information already
available at
http://ovirt.github.io/ovirt-engine-api-model/4.2/#services/vm/methods/start

Here is the relevant section of engine.log on ovirt-engine.localnet:
2018-05-31 10:48:15,550+10 INFO
[org.ovirt.engine.core.sso.utils.AuthenticationUtils] (default task-25) []
User admin@internal successfully logged in with scopes: ovirt-app-api
ovirt-ext=token-info:authz-search ovirt-ext=token-info:public-authz-search
ovirt-ext=token-info:validate ovirt-ext=token:password-access
2018-05-31 10:48:15,569+10 INFO
[org.ovirt.engine.core.bll.aaa.CreateUserSessionCommand] (default task-29)
[8ffa0f3] Running command: CreateUserSessionCommand internal: false.
2018-05-31 10:48:15,581+10 INFO
[org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
(default task-29) [8ffa0f3] EVENT_ID: USER_VDC_LOGIN(30), User
admin@internal-authz connecting from '192.168.1.0' using session
'JNweIEHoHhw9U+wMt7Z03Ovb5Pc1zR3WyvTcSfRTpdHjd55CHbcspfDcJgToMVshtlgXamzvUSW2rzHB9ApJHA=='
logged in.
2018-05-31 10:48:15,587+10 ERROR
[org.ovirt.engine.api.restapi.resource.validation.IOExceptionMapper]
(default task-29) [] IO exception while processing "POST" request for path
"/vms/69c47a91-bbv1-4eda-b71d-7bddf82ee8ab/start"
2018-05-31 10:48:15,587+10 ERROR
[org.ovirt.engine.api.restapi.resource.validation.IOExceptionMapper]
(default task-29) [] Exception: java.io.IOException:
javax.xml.stream.XMLStreamException: ParseError at [row,col]:[1,2]
Message: The markup in the document preceding the root element must be
well-formed.
at
org.ovirt.engine.api.restapi.xml.JAXBProvider.readFrom(JAXBProvider.java:200)
[restapi-jaxrs.jar:]
at
org.ovirt.engine.api.restapi.xml.JAXBProvider.readFrom(JAXBProvider.java:162)
[restapi-jaxrs.jar:]
at
org.jboss.resteasy.core.interception.AbstractReaderInterceptorContext.readFrom(AbstractReaderInterceptorContext.java:66)
[resteasy-jaxrs-3.0.24.Final.jar:3.0.24.Final]
at
org.jboss.resteasy.core.interception.ServerReaderInterceptorContext.readFrom(ServerReaderInterceptorContext.java:61)
[resteasy-jaxrs-3.0.24.Final.jar:3.0.24.Final]
at
org.jboss.resteasy.core.interception.AbstractReaderInterceptorContext.proceed(AbstractReaderInterceptorContext.java:56)
[resteasy-jaxrs-3.0.24.Final.jar:3.0.24.Final]
at
org.jboss.resteasy.security.doseta.DigitalVerificationInterceptor.aroundReadFrom(DigitalVerificationInterceptor.java:36)
[resteasy-crypto-3.0.24.Final.jar:3.0.24.Final]

at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_171]
Caused by: javax.xml.stream.XMLStreamException: ParseError at
[row,col]:[1,2]
Message: The markup in the document preceding the root element must be
well-formed.
at
com.sun.org.apache.xerces.internal.impl.XMLStreamReaderImpl.next(XMLStreamReaderImpl.java:604)
[rt.jar:1.8.0_171]
at
com.sun.xml.bind.v2.runtime.unmarshaller.StAXStreamConnector.bridge(StAXStreamConnector.java:164)
at
com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal0(UnmarshallerImpl.java:415)
at
com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal(UnmarshallerImpl.java:386)
at
org.ovirt.engine.api.restapi.xml.JAXBProvider.readFrom(JAXBProvider.java:187)
[restapi-jaxrs.jar:]
... 104 more
2018-05-31 10:48:15,593+10 INFO
[org.ovirt.engine.core.bll.aaa.LogoutSessionCommand] (default task-29)
[4531c52a] Running command: LogoutSessionCommand internal: false.
2018-05-31 10:48:15,598+10 INFO
[org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
(default task-29) [4531c52a] EVENT_ID: USER_VDC_LOGOUT(31), User
admin@internal-authz connected from '192.168.1.0' using session
'JNweIEHoHhw9U+wMt7Z03Ovb5Pc1zR3WyvTcSfRTpdHjd55CHbcspfDcJgToMVshtlgXamzvUSW2rzHB9ApJHA=='
logged out.
2018-05-31 10:48:27,542+10 INFO
[org.ovirt.engine.core.sso.servlets.OAuthRevokeServlet] (default task-32)
[] User admin@internal successfully logged out
2018-05-31 10:48:27,550+10 INFO
[org.ovirt.engine.core.bll.aaa.TerminateSessionsForTokenCommand] (default
task-35) [76676851] Running command: TerminateSessionsForTokenCommand
internal: true.


Later I thought that perhaps the problem was that I need to use the VM Name
instead of it's 

[ovirt-users] Re: ovirt 4.2.3 console.vv provide IP addr, not FQHN for host= (spice connection)

[Oliver Riesener]

Hi Luca, 

thanks for reply,

> Am 30.05.2018 um 20:47 schrieb Luca 'remix_tj' Lorenzetto 
> :
> 
> Hello,
> 
> On Wed, May 30, 2018 at 12:19 PM, Oliver Riesener
>  wrote:
>> Hi,
>> 
>> i recently upgraded to ovirt 4.2.3-[78] and noticed that the spice client
>> got and use
>> 
>>  host=IPAddr
>> 
>> from received console.vv file and not
>> 
>>  host=FQHN
>> 
>> of the virtualization host.
>> 
>> I need the FQHN because i access ovirt-webui remote via ssh with port
>> forwarding.
>> I added a "127.0.0.1 FQHN" entry in /etc/hosts on client side to access
>> remote ports.
>> 
>> Please could everyone provide a < 4.2.3 console.vv file ?
> 
> 
> For what i know, in console.vv file, vm.display.address property is
> used, you can see the value with this api call:
> 
> https://engine.fqdn/ovirt-engine/api/vms
> 
> 
> I'm using 4.2.0.2 and the file starts in this way:
> 
> [virt-viewer]
> type=spice
> host=kvm002.fqdn

I have here (console.vv):

[virt-viewer]
type=spice
host=192.168.nnn.nnn

That’s my problem here, with the HOST IPaddress without FQDN.

The ovirt-engine/webadmin and ovirt-engine/web-ui do the same thing here.
Console button call „ActionPanelView_ConsoleConnectCommand“.

> 
> So check with the api call and see which is the value you see there.
> 
The api call list all vms with there FQDN names, no HOST info there.

Oliver 

> Luca
> 
> 
> 
> 
> -- 
> "E' assurdo impiegare gli uomini di intelligenza eccellente per fare
> calcoli che potrebbero essere affidati a chiunque se si usassero delle
> macchine"
> Gottfried Wilhelm von Leibnitz, Filosofo e Matematico (1646-1716)
> 
> "Internet è la più grande biblioteca del mondo.
> Ma il problema è che i libri sono tutti sparsi sul pavimento"
> John Allen Paulos, Matematico (1945-vivente)
> 
> Luca 'remix_tj' Lorenzetto, http://www.remixtj.net , 
> 
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/U5HIEQRHEVEB62WVDLENUA2YCLE4G36W/

[ovirt-users] Re: Hardering oVirt Engine

[Punaatua PK]

Any ideas anyone ? At least, could you please provide your opinion ?

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

[ovirt-users] Re: ovirt 4.2.3 console.vv provide IP addr, not FQHN for host= (spice connection)

[Luca 'remix_tj' Lorenzetto]

Hello,

On Wed, May 30, 2018 at 12:19 PM, Oliver Riesener
 wrote:
> Hi,
>
> i recently upgraded to ovirt 4.2.3-[78] and noticed that the spice client
> got and use
>
>   host=IPAddr
>
> from received console.vv file and not
>
>   host=FQHN
>
> of the virtualization host.
>
> I need the FQHN because i access ovirt-webui remote via ssh with port
> forwarding.
> I added a "127.0.0.1 FQHN" entry in /etc/hosts on client side to access
> remote ports.
>
> Please could everyone provide a < 4.2.3 console.vv file ?


For what i know, in console.vv file, vm.display.address property is
used, you can see the value with this api call:

https://engine.fqdn/ovirt-engine/api/vms


I'm using 4.2.0.2 and the file starts in this way:

[virt-viewer]
type=spice
host=kvm002.fqdn

So check with the api call and see which is the value you see there.

Luca




-- 
"E' assurdo impiegare gli uomini di intelligenza eccellente per fare
calcoli che potrebbero essere affidati a chiunque se si usassero delle
macchine"
Gottfried Wilhelm von Leibnitz, Filosofo e Matematico (1646-1716)

"Internet è la più grande biblioteca del mondo.
Ma il problema è che i libri sono tutti sparsi sul pavimento"
John Allen Paulos, Matematico (1945-vivente)

Luca 'remix_tj' Lorenzetto, http://www.remixtj.net , 
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/Y5IWORWJV5JTRA742EHSAW5O77QITVMW/

[ovirt-users] Re: Fwd: FreeBSD after 10.3 could not boot (Freeze)

[Karli Sjöberg]

Den 30 maj 2018 19:08 skrev "Paul.LKW" :
Hi Karli Sjöberg:
  May be you still using oVirt-4.1 so no problem but I am sorry
  could not agreed with "nothing wrong with oVirt", if nothing is
  wrong why I use FreeBSD 10.3 installation CD could boot and even
  finished the installation but not for FreeBSD 10.4 and 11.Yeah, no, I worded that wrong, of course it is a regression. What I meant was that something most likely has changed in how oVirt is starting the VMs that is causing this. A good start would be for you to compare the VM XML from 3.6 to what you have now, 4.2 was it? So you can file a bug report to give the devs something to look at.My hunch is that unfortunately not at alot of people run AMD clusters which then don't get as much "love" as the other. Hopefully this'll change to at least a 50/50 attention as AMD takes more shares of the market, but it won't do any good for your old Gen 3 Opterons, so don't hold your breath hoping for it to just fix itself, you'll have to really push the devs to do something about it!Good luck with it!/K
  As all my Host is AMD based, so no idea how to test further, May
  be I will try to reinstall oVirt again to see does it work and
  report again.
  Remark: I could even migrate FreeBSD 10.2 and 10.3 to this
  oVirt-4.2 but surely could not install new or migrate 10.4 or 11


Karli Sjöberg 於 30/5/2018 17:31 寫道:


  

  
Den 30 maj 2018 10:26 skrev
  "Paul.LKW" :
  

  
Hi  Karli
  Sjöberg 
It is
  very upset as I am using even more older version
  3.6 also could run higher version of FreeBSD,
  yesterday I just tried install FreeBSD 11 in oVirt
  3.6 is no problem but newer version of oVirt not
  work !!!
  

  

  



Well, I am running 4.1 and can run both 10.4 and
  11, so there's nothing wrong with oVirt itself. Do you have an
  Intel cluster you can test with?


/K



  

  

  

  
  
2018-05-30 12:16 GMT+08:00
  Karli Sjöberg :
  

  Paul, "reply all" next time

  Den 30 maj 2018
05:32 skrev "Paul.LKW" :

  

  Hi 
Karli
  Sjöberg/ 
  Alexandr
Krivulya

  
  

  

  

  
  
  
  So the image says the virtual
hardware is about the same, except for
Cluster type. I've had issues before getting
FreeBSD running in oVirt with Opteron. Since
i then had two clusters: one AMD and one
Intel, I worked around it by only using the
Intel cluster for FreeBSD guests.
  
  
  I also tested booting FreeBSD
ISO on the host metal (old Sun Fire, maybe
X4440, something like that), so it should
just be a oVirt/QEMU thing, but I never
tried fixing it.
  


/K
  
  

  
  
  

  

  



  2018-05-30 2:06 GMT+08:00
  

[ovirt-users] Re: Fwd: FreeBSD after 10.3 could not boot (Freeze)

[Paul.LKW]

Hi Karli Sjöberg:
May be you still using oVirt-4.1 so no problem but I am sorry could not 
agreed with "nothing wrong with oVirt", if nothing is wrong why I use 
FreeBSD 10.3 installation CD could boot and even finished the 
installation but not for FreeBSD 10.4 and 11.
As all my Host is AMD based, so no idea how to test further, May be I 
will try to reinstall oVirt again to see does it work and report again.
Remark: I could even migrate FreeBSD 10.2 and 10.3 to this oVirt-4.2 but 
surely could not install new or migrate 10.4 or 11



Karli Sjöberg 於 30/5/2018 17:31 寫道:



Den 30 maj 2018 10:26 skrev "Paul.LKW" :

Hi Karli Sjöberg
It is very upset as I am using even more older version 3.6 also
could run higher version of FreeBSD, yesterday I just tried
install FreeBSD 11 in oVirt 3.6 is no problem but newer version of
oVirt not work !!!


Well, I am running 4.1 and can run both 10.4 and 11, so there's 
nothing wrong with oVirt itself. Do you have an Intel cluster you can 
test with?


/K



2018-05-30 12:16 GMT+08:00 Karli Sjöberg mailto:ka...@inparadise.se>>:

Paul, "reply all" next time

Den 30 maj 2018 05:32 skrev "Paul.LKW" mailto:paul@gmail.com>>:

Hi Karli Sjöberg/ Alexandr Krivulya


So the image says the virtual hardware is about the same,
except for Cluster type. I've had issues before getting
FreeBSD running in oVirt with Opteron. Since i then had two
clusters: one AMD and one Intel, I worked around it by only
using the Intel cluster for FreeBSD guests.

I also tested booting FreeBSD ISO on the host metal (old Sun
Fire, maybe X4440, something like that), so it should just be
a oVirt/QEMU thing, but I never tried fixing it.

/K



2018-05-30 2:06 GMT+08:00 Karli Sjöberg
mailto:ka...@inparadise.se>>:

On Wed, 2018-05-30 at 01:09 +0800, Paul.LKW wrote:
> Hi Alexandr Krivulya:
> Tried all configuration combination also could not
boot still hang on
> the screen captured !

I just tried it as well, works fine, no problemo. My
VM has:
1       vCPU
1GB     vRAM
8GB     vHDD

In a Nehalem cluster.

Alex, Paul, what´s yours?

/K

>
> Alexandr Krivulya 於 29/5/2018 22:57 寫道:
> > Hi!
> > I procced with default instalation of 10.4-amd64
from ISO and it
> > boots just fine. Can you provide some more info
about VM
> > configuration?
> >
> > 26.05.2018 20:59, Paul.LKW пишет:
> > > HI All:
> > > Any one have tried to boot up FreeBSD 10.4
successful? I tried
> > > 10.3 is all working fine but no lucky in 10.4 at
all even boot
> > > from DVD !!!
> > > Attached is the freezes point.
> > >
> > >
> > >
> > > BR,
> > > Paul.LKW
> > >
> > >
> > > ___
> > > Users mailing list -- users@ovirt.org

> > > To unsubscribe send an email to
users-le...@ovirt.org 
> >
> >
> > ___
> > Users mailing list -- users@ovirt.org

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

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

[ovirt-users] Re: [Qemu-block] Libvirt ERROR cannot access backing file after importing VM from OpenStack

[Kevin Wolf]

Am 30.05.2018 um 18:14 hat Arik Hadas geschrieben:
> On Wed, May 30, 2018 at 6:33 PM, Kevin Wolf  wrote:
> > I think the problem is that we're talking about two different things in
> > one thread. If I understand correctly, what oVirt does today is:
> >
> > 1. qemu-img convert to create a temporary qcow2 image that merges the
> >whole backing chain in a single file
> >
> > 2. tar to create an temporary OVA archive that contains, amongst others,
> >the temporary qcow2 image. This is a second temporary file.
> >
> > 3. Stream this temporary OVA archive over HTTP
> >
> 
> Well, today we suggest users to mount a shared storage to multiple hosts
> that reside in different oVirt/RHV deployments so they could export
> VMs/templates as OVAs to that shared storage and import these OVAs from the
> shared storage to a destination deployment. This process involves only #1
> and #2.
> 
> The technique you proposed earlier for writing disks directly into an OVA,
> assuming that the target size can be retrieved with 'qemu-img measure',
> sounds like a nice approach to accelerate this process. I think we should
> really consider doing that if that's as easy as it sounds.

Writing the image to a given offset in a file is the example that I gave
further down in the mail:

> > You added another host into the mix, which just receives the image
> > content via NBD and then re-exports it as HTTP. Does this host actually
> > exist or is it the same host where the original images are located?
> >
> > Because if you stay local for this step, there is no need to use NBD at
> > all:
> >
> > $ ./qemu-img measure -O qcow2 ~/images/hd.img
> > required size: 67436544
> > fully allocated size: 67436544
> > $ ./qemu-img create -f file /tmp/test.qcow2 67436544
> > Formatting '/tmp/test.qcow2', fmt=file size=67436544
> > $ ./qemu-img convert -n --target-image-opts ~/images/hd.img
> > driver=raw,file.driver=file,file.filename=/tmp/test.qcow2,offset=65536
> >
> > hexdump verifies that this does the expected thing.

> But #3 is definitely something we are interested in because we expect the
> next step to be exporting the OVAs to a remote instance of Glance that
> serves as a shared repository for the different deployments. Being able to
> stream the collapsed form of a volume chain without writing anything to the
> storage device would be fantastic. I think that even at the expense of
> iterating the chain twice - once to map the structure of the jump tables
> (right?) and once to stream the whole data.

If the target is not a stupid web browser, but something actually
virt-related like Glance, I'm sure it can offer a more suitable protocol
than HTTP? If you could talk NBD to Glance, you'd get rid of the
streaming requirement. I think it would make more sense to invest the
effort there.

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

[ovirt-users] Re: Non-responsive vm's due to crashed host and hosted vm liveliness check fails

[clam2718]

Hi,

I am still working to resolve my issue - is there any further detail or 
clarification I can provide that might help?  I really appreciate your time.

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

[ovirt-users] VM status and issue with cloud_init

[03ce007]

Some what new to the VM and Ovirt world here and need some help understanding 
terminologies and get the VM to work as per requirement. 

I have a self-hosted-engine (4.2) running on centos (7.4). The engine is in 
good health and I have deployed a test VM using below playbook successfully. It 
is currently in "up" state.


- name: oVirt Self-Hosted-Engine - Manage VMs
  hosts: hypervisor_ovirt
  gather_facts: false

  vars_files:
# Contains encrypted `engine_password` varibale using ansible-vault
- ovirt-secrets.yml

  vars:
engine_url: https://engine-ovirt.dw/ovirt-engine/api
engine_user: admin@internal
engine_cafile: /etc/pki/ovirt-engine/ca.pem

mytest_vm:
  cluster: Default
  memory: 64GiB
  memory_guaranteed: 1GiB
  cores: 2
  nics:
- name: vnet0
  network: ovirtmgmt
  profile: ovirtmgmt
  interface: virtio
  wait: true
  domain: node.dev.dw
  os_type: rhel_7x64
  ssh_key: ssh-rsa AAA...LGx user01@mytestvm
  root_password: super_password
  disks:
- size: 20GiB
  name: data
  storage_domain: hosted_storage
  interface: virtio
  bootable: true
  nics:
- name: vnet0
  network: ovirtmgmt
  profile: ovirtmgmt
  interface: virtio

vms:
  - name: mytest_vm
tag: mytest_vm
profile: "{{ mytest_vm }}"
cloud_init:
  dns_servers:
- 10.90.x.1
- 10.90.x.1
  nic_boot_protocol: static
  nic_ip_address: 10.90.x.y
  nic_netmask: 255.255.255.0
  nic_gateway: 10.90.x.z
  nic_name: eth0
  nic_on_boot: true
  host_name: mytestvm.test.dw
  custom_script: |
write_files:
 - content: |
 Hello, world!
   path: /tmp/greeting.txt
   permissions: '0644'
  user_name: root
  root_password: super_password
cloud_init_persist: true

  roles:
- oVirt.vm-infra


Above playbook runs fine, but when i see summary using ovirt4.py, i do not see 
ipaddr for this test vm. 

- I do not see the ipaddr for this VM despite specifying it using cloud_init
- does the "up" status mean it has "booted" or I need to do something else to 
boot it with centos 7.4 minimal

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

[ovirt-users] Re: [Qemu-block] Libvirt ERROR cannot access backing file after importing VM from OpenStack

[Arik Hadas]

On Wed, May 30, 2018 at 6:33 PM, Kevin Wolf  wrote:

> Am 30.05.2018 um 17:05 hat Eric Blake geschrieben:
> > If I understood the question, we start with a local:
> >
> > T (any format) <- S (qcow2) <- V (qcow2)
> >
> > and want to create a remote tar file:
> >
> > dest.tar == | header ... | qcow2 image |
> >
> > where we write a single collapsed view of the T<-S<-V chain as a qcow2
> image
> > in the subset of the remote tar file.
>
> I think the problem is that we're talking about two different things in
> one thread. If I understand correctly, what oVirt does today is:
>
> 1. qemu-img convert to create a temporary qcow2 image that merges the
>whole backing chain in a single file
>
> 2. tar to create an temporary OVA archive that contains, amongst others,
>the temporary qcow2 image. This is a second temporary file.
>
> 3. Stream this temporary OVA archive over HTTP
>

Well, today we suggest users to mount a shared storage to multiple hosts
that reside in different oVirt/RHV deployments so they could export
VMs/templates as OVAs to that shared storage and import these OVAs from the
shared storage to a destination deployment. This process involves only #1
and #2.

The technique you proposed earlier for writing disks directly into an OVA,
assuming that the target size can be retrieved with 'qemu-img measure',
sounds like a nice approach to accelerate this process. I think we should
really consider doing that if that's as easy as it sounds.

But #3 is definitely something we are interested in because we expect the
next step to be exporting the OVAs to a remote instance of Glance that
serves as a shared repository for the different deployments. Being able to
stream the collapsed form of a volume chain without writing anything to the
storage device would be fantastic. I think that even at the expense of
iterating the chain twice - once to map the structure of the jump tables
(right?) and once to stream the whole data.


>
> Your proposal is about getting rid of the temporary file from step 1,
> but keeping the temporary file from step 2. I was kind of ignoring
> step 2 and answering how you can avoid a temporary file by creating and
> streaming a qcow2 file in a single step, but if you already have the
> code to create a qcow2 image as a stream, adding a tar header as well
> shouldn't be that hard...
>
> I think Nir was talking about both.
>
> Ideally, we'd somehow get rid of HTTP, which introduces the requirement
> of a non-seekable stream.
>
> > So, first use qemu-img to learn how big to size the collapsed qcow2
> image,
> > and by extension, the overall tar image
> > $ qemu-img measure -f qcow2 -O qcow2 V
> >
> > then pre-create a large enough tar file on the destination
> > $ create header
> > $ truncate --size=XXX dest.qcow2
> > $ tar cf dest.tar header dest.qcow2
> >
> > (note that I explicitly did NOT use tar --sparse; dest.qcow2 is sparse
> and
> > occupies practically no disk space, but dest.tar must NOT be sparse
> because
> > neither tar nor NBD work well with after-the-fact resizing)
> >
> > then set up an NBD server on the destination that can write to the
> subset of
> > the tar file:
> >
> > $ learn the offset of dest.qcow2 within dest.tar (probably a multiple of
> > 10240, given default GNU tar options)
> > $ qemu-nbd --image-opts
> > driver=raw,offset=YYY,size=XXX,file.driver=file,file.filename=dest.tar
> >
> > (I'm not sure if I got the --image-opts syntax exactly correct.  nbdkit
> has
> > more examples of learning offsets within a tar file, and may be a better
> > option as a server than qemu-nbd - but the point remains: serve up the
> > subset of the dest.tar file as raw bytes)
> >
> > finally set up qemu as an NBD client on the source:
> > $ qemu-img convert -f qcow2 V -O qcow2 nbd://remote
> >
> > (now the client collapses the qcow2 chain onto the source, and writes
> that
> > into a qcow2 subset of the tar file on the destination, where the
> > destination was already sized large enough to hold the qcow2 image, and
> > where no other temporary storage was needed other than the sparse
> dest.qcow2
> > used in creating a large enough tar file)
>
> You added another host into the mix, which just receives the image
> content via NBD and then re-exports it as HTTP. Does this host actually
> exist or is it the same host where the original images are located?
>
> Because if you stay local for this step, there is no need to use NBD at
> all:
>
> $ ./qemu-img measure -O qcow2 ~/images/hd.img
> required size: 67436544
> fully allocated size: 67436544
> $ ./qemu-img create -f file /tmp/test.qcow2 67436544
> Formatting '/tmp/test.qcow2', fmt=file size=67436544
> $ ./qemu-img convert -n --target-image-opts ~/images/hd.img
> driver=raw,file.driver=file,file.filename=/tmp/test.qcow2,offset=65536
>
> hexdump verifies that this does the expected thing.
>
> > > Exporting to a stream is possible if we're allowed to make two passes
> > > over the source, but the existing QEMU code is useless for 

[ovirt-users] Re: Unable to login after upgrade

[Michael Watters]

It looks like the issue was caused by a new admin account being created
in the internal-authz domain.  Here is what the engine logs show.

2018-05-30 11:15:21,893-04 INFO 
[org.ovirt.engine.core.sso.utils.AuthenticationUtils] (default task-9)
[] User admin@internal successfully logged in with scopes:
ovirt-app-admin ovirt-app-api ovirt-app-portal
ovirt-ext=auth:sequence-priority=~ ovirt-ext=revoke:revoke-all
ovirt-ext=token-info:authz-search
ovirt-ext=token-info:public-authz-search ovirt-ext=token-info:validate
ovirt-ext=token:password-access

2018-05-30 11:15:22,175-04 INFO 
[org.ovirt.engine.core.bll.aaa.CreateUserSessionCommand] (default
task-11) [77362b19] Running command: CreateUserSessionCommand internal:
false.

2018-05-30 11:15:22,252-04 ERROR
[org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
(default task-11) [77362b19] EVENT_ID: USER_VDC_LOGIN_FAILED(114), User
admin@internal-authz connecting from '10.209.44.27' failed to log
in.

2018-05-30 11:15:22,253-04 ERROR
[org.ovirt.engine.core.aaa.servlet.SsoPostLoginServlet] (default
task-11) [] The user admin@internal is not authorized to perform login

I was able to login after updating the permissions table to use the new
user ID as follows.

update permissions set ad_element_id = (select user_id from users where
domain = 'internal-authz' and username = 'admin') where ad_element_id =
(select user_id from users where domain = 'internal' and username =
'admin') ;

Despite this the ovirt-aaa-jdbc-tool still shows the wrong user ID when
querying the admin account.  For example:

[root@mdct-ovirt-engine-dev ~]# ovirt-aaa-jdbc-tool user show admin
-- User admin(fdfc627c-d875-11e0-90f0-83df133b58cc) --
Namespace: *
Name: admin
ID: fdfc627c-d875-11e0-90f0-83df133b58cc
Display Name:
Email:
First Name: admin
Last Name:
Department:
Title:
Description:
Account Disabled: false
Account Locked: false
Account Unlocked At: 1970-01-01 00:00:00Z
Account Valid From: 2016-11-16 15:27:01Z
Account Valid To: 2216-11-16 15:27:01Z
Account Without Password: false
Last successful Login At: 2018-05-30 16:02:46Z
Last unsuccessful Login At: 2018-05-29 19:25:28Z
Password Valid To: 2216-09-29 15:27:01Z

Is there a way to resolve this conflict?  Where does the
admin@internal-authz account come from?  I tried renaming the account
but it is recreated every time that the engine is restarted.


On 05/29/2018 04:31 PM, Alex K wrote:
> Are you using engine IP to login? Perhaps the sso default file was
> overwritten?
>
> Alex
>
> On Tue, May 29, 2018, 20:32 Michael Watters  > wrote:
>
> I recently upgraded one of our ovirt engines from 4.1 to the 4.2.3
> release and the admin account is no longer able to login.  After
> entering the user name and password I receive a message that
> states "The
> user admin@internal is not authorized to perform login".
>
> Is there a way to resolve this?  Resetting the password did not work.
> ___
> Users mailing list -- users@ovirt.org 
> To unsubscribe send an email to users-le...@ovirt.org
> 
> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> 
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/FT3NKC36NMNDQEIWCVPMYSYSLVZSGJOM/
>

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

[ovirt-users] Re: [Qemu-block] Libvirt ERROR cannot access backing file after importing VM from OpenStack

[Kevin Wolf]

Am 30.05.2018 um 17:05 hat Eric Blake geschrieben:
> If I understood the question, we start with a local:
> 
> T (any format) <- S (qcow2) <- V (qcow2)
> 
> and want to create a remote tar file:
> 
> dest.tar == | header ... | qcow2 image |
> 
> where we write a single collapsed view of the T<-S<-V chain as a qcow2 image
> in the subset of the remote tar file.

I think the problem is that we're talking about two different things in
one thread. If I understand correctly, what oVirt does today is:

1. qemu-img convert to create a temporary qcow2 image that merges the
   whole backing chain in a single file

2. tar to create an temporary OVA archive that contains, amongst others,
   the temporary qcow2 image. This is a second temporary file.

3. Stream this temporary OVA archive over HTTP

Your proposal is about getting rid of the temporary file from step 1,
but keeping the temporary file from step 2. I was kind of ignoring
step 2 and answering how you can avoid a temporary file by creating and
streaming a qcow2 file in a single step, but if you already have the
code to create a qcow2 image as a stream, adding a tar header as well
shouldn't be that hard...

I think Nir was talking about both.

Ideally, we'd somehow get rid of HTTP, which introduces the requirement
of a non-seekable stream.

> So, first use qemu-img to learn how big to size the collapsed qcow2 image,
> and by extension, the overall tar image
> $ qemu-img measure -f qcow2 -O qcow2 V
> 
> then pre-create a large enough tar file on the destination
> $ create header
> $ truncate --size=XXX dest.qcow2
> $ tar cf dest.tar header dest.qcow2
> 
> (note that I explicitly did NOT use tar --sparse; dest.qcow2 is sparse and
> occupies practically no disk space, but dest.tar must NOT be sparse because
> neither tar nor NBD work well with after-the-fact resizing)
> 
> then set up an NBD server on the destination that can write to the subset of
> the tar file:
> 
> $ learn the offset of dest.qcow2 within dest.tar (probably a multiple of
> 10240, given default GNU tar options)
> $ qemu-nbd --image-opts
> driver=raw,offset=YYY,size=XXX,file.driver=file,file.filename=dest.tar
> 
> (I'm not sure if I got the --image-opts syntax exactly correct.  nbdkit has
> more examples of learning offsets within a tar file, and may be a better
> option as a server than qemu-nbd - but the point remains: serve up the
> subset of the dest.tar file as raw bytes)
> 
> finally set up qemu as an NBD client on the source:
> $ qemu-img convert -f qcow2 V -O qcow2 nbd://remote
> 
> (now the client collapses the qcow2 chain onto the source, and writes that
> into a qcow2 subset of the tar file on the destination, where the
> destination was already sized large enough to hold the qcow2 image, and
> where no other temporary storage was needed other than the sparse dest.qcow2
> used in creating a large enough tar file)

You added another host into the mix, which just receives the image
content via NBD and then re-exports it as HTTP. Does this host actually
exist or is it the same host where the original images are located?

Because if you stay local for this step, there is no need to use NBD at
all:

$ ./qemu-img measure -O qcow2 ~/images/hd.img 
required size: 67436544
fully allocated size: 67436544
$ ./qemu-img create -f file /tmp/test.qcow2 67436544
Formatting '/tmp/test.qcow2', fmt=file size=67436544
$ ./qemu-img convert -n --target-image-opts ~/images/hd.img 
driver=raw,file.driver=file,file.filename=/tmp/test.qcow2,offset=65536

hexdump verifies that this does the expected thing.

> > Exporting to a stream is possible if we're allowed to make two passes
> > over the source, but the existing QEMU code is useless for that because
> > it inherently requires seeking. I think if I had to get something like
> > this, I'd probably implement such an exporter as a script external to
> > QEMU.
> 
> Wait. What are we trying to stream?  A qcow2 file, or what the guest would
> see?  If you stream just what the guest sees, then 'qemu-img map' tells you
> which portions of which source files to read in order to reconstruct data in
> the order it would be seen by the guest.

I think the requirement was that the HTTP client downloads a qcow2
image. Did I get this wrong?

> But yeah, an external exporter that takes a raw file, learns its size
> and where the holes are, and then writes a trivial qcow2 header and
> appends L1/L2/refcount tables on the end to convert the raw file into
> a slightly-larger qcow2 file, might be a valid way to create a qcow2
> file from a two-pass read.

Right. It may have to calculate the size of the L1 and refcount table
first so it can write the right offsets into the header, so maybe it's
easiest to precreate the whole metadata. But that's an implementation
detail.

Anyway, I don't think the existing QEMU code helps you with this.

Kevin
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to 

[ovirt-users] Re: [Qemu-block] Libvirt ERROR cannot access backing file after importing VM from OpenStack

[Eric Blake]

On 05/30/2018 09:16 AM, Kevin Wolf wrote:

Am 30.05.2018 um 15:44 hat Eric Blake geschrieben:

On 05/29/2018 04:18 PM, Nir Soffer wrote:

You CAN get a logically collapsed view of storage (that is, what the
guest would see), by using an NBD export of volume V.  Reading from that
volume will then pull sectors from whichever portion of the chain you
need.  You can use either qemu-nbd (if no guest is writing to the
chain), or within a running qemu, you can use nbd-server-start and
nbd-server-add (over QMP) to get such an NBD server running.



NBD expose the guest data, but we want the qcow2 stream - without
creating a new image.


NBD can do both. You choose whether it exposes the guest data or the qcow2
data, by whether the client or the server is interpreting qcow2 data.


But if I understand correctly, it doesn't result in the image Nir wants.
You would only export an existing qcow2 file, i.e. a single layer in the
backing chain, this way. The question was about a collapsed image, i.e.
the disk content as the guest sees it.

The problem is that qcow2 just isn't made to be streamable. Importing a
qcow2 stream without saving it into a temporary file (or a memory buffer
as large as the image file) simply isn't possible in the general case.


If I understood the question, we start with a local:

T (any format) <- S (qcow2) <- V (qcow2)

and want to create a remote tar file:

dest.tar == | header ... | qcow2 image |

where we write a single collapsed view of the T<-S<-V chain as a qcow2 
image in the subset of the remote tar file.


So, first use qemu-img to learn how big to size the collapsed qcow2 
image, and by extension, the overall tar image

$ qemu-img measure -f qcow2 -O qcow2 V

then pre-create a large enough tar file on the destination
$ create header
$ truncate --size=XXX dest.qcow2
$ tar cf dest.tar header dest.qcow2

(note that I explicitly did NOT use tar --sparse; dest.qcow2 is sparse 
and occupies practically no disk space, but dest.tar must NOT be sparse 
because neither tar nor NBD work well with after-the-fact resizing)


then set up an NBD server on the destination that can write to the 
subset of the tar file:


$ learn the offset of dest.qcow2 within dest.tar (probably a multiple of 
10240, given default GNU tar options)
$ qemu-nbd --image-opts 
driver=raw,offset=YYY,size=XXX,file.driver=file,file.filename=dest.tar


(I'm not sure if I got the --image-opts syntax exactly correct.  nbdkit 
has more examples of learning offsets within a tar file, and may be a 
better option as a server than qemu-nbd - but the point remains: serve 
up the subset of the dest.tar file as raw bytes)


finally set up qemu as an NBD client on the source:
$ qemu-img convert -f qcow2 V -O qcow2 nbd://remote

(now the client collapses the qcow2 chain onto the source, and writes 
that into a qcow2 subset of the tar file on the destination, where the 
destination was already sized large enough to hold the qcow2 image, and 
where no other temporary storage was needed other than the sparse 
dest.qcow2 used in creating a large enough tar file)



Exporting to a stream is possible if we're allowed to make two passes
over the source, but the existing QEMU code is useless for that because
it inherently requires seeking. I think if I had to get something like
this, I'd probably implement such an exporter as a script external to
QEMU.


Wait. What are we trying to stream?  A qcow2 file, or what the guest 
would see?  If you stream just what the guest sees, then 'qemu-img map' 
tells you which portions of which source files to read in order to 
reconstruct data in the order it would be seen by the guest.  But yeah, 
an external exporter that takes a raw file, learns its size and where 
the holes are, and then writes a trivial qcow2 header and appends 
L1/L2/refcount tables on the end to convert the raw file into a 
slightly-larger qcow2 file, might be a valid way to create a qcow2 file 
from a two-pass read.


--
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3266
Virtualization:  qemu.org | libvirt.org
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/UTMXG4DZLWRDCIVZ5KPNAYFJUWSSKFIJ/

[ovirt-users] Attaching previously owned storage domain to 4.2 Cluster

[John Nguyen]

Hi Guys,

I'm working through a disaster recovery of a failed cluster.  And I found
the documentation for attaching the old storage domain as an import domain
to a new Cluster.  Both clusters are 4.2.

https://ovirt.org/develop/release-management/features/storage/importstoragedomain/

The documentation is referencing 3.5 and I would like to know if its still
applies to the 4.2 release.

When I try to do the import I see warnings below:



I know that its really hard to say this operation may not be destructive.
But is the general work flow outlined in the 3.5 documentation still valid?

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

[ovirt-users] Re: Debugging ceph access

[Bernhard Dick]

Hi,

I found the reason for my timeout problems: It is the version of librbd1 
(which is 0.94.5) in conjunction with my CEPH test-environment which is 
running the luminous release.
When I install the librbd1 (and librados2) packages from the 
centos-ceph-luminous repository (version 12.2.5) I'm able to start and 
migrate VMs inbetween the hosts.


  Regards
Bernhard

Am 25.05.2018 um 17:08 schrieb Bernhard Dick:

Hi,

as you might already know I try to use ceph with openstack in an oVirt 
test environment. I'm able to create and remove volumes. But if I try to 
run a VM which contains a ceph volume it is in the "Wait for launch" 
state for a very long time. Then it gets into "down" state again. The 
qemu log states


2018-05-25T15:03:41.100401Z qemu-kvm: -drive 
file=rbd:rbd/volume-3bec499e-d0d0-45ef-86ad-2c187cdb2811:id=cinder:auth_supported=cephx\;none:mon_host=[mon0]\:6789\;[mon1]\:6789,file.password-secret=scsi0-0-0-0-secret0,format=raw,if=none,id=drive-scsi0-0-0-0,serial=3bec499e-d0d0-45ef-86ad-2c187cdb2811,cache=none,werror=stop,rerror=stop,aio=threads: 
error connecting: Connection timed out


2018-05-25 15:03:41.109+: shutting down, reason=failed

On the monitor hosts I see traffic with the ceph-mon-port, but not on 
other ports (the osds for example). In the ceph logs however I don't 
really see what happens.

Do you have some tips how to debug this problem?

   Regards
     Bernhard

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

[ovirt-users] Re: oVirt hosted-engine-setup issues with getting host facts

[Mariusz Kozakowski]

On Mon, 2018-05-28 at 14:30 +0200, Mariusz Kozakowski wrote:
On Mon, 2018-05-28 at 12:57 +0200, Simone Tiraboschi wrote:
The issue is on network configuration:
you have to check /var/log/vdsm/vdsm.log and /var/log/vdsm/supervdsm.log to 
understand why it failed.

From same time frame, vdsm.log. Can this be related?

2018-05-28 11:07:34,481+0200 INFO  (jsonrpc/1) [api.host] START getAllVmStats() 
from=::1,45816 (api:46)
2018-05-28 11:07:34,482+0200 INFO  (jsonrpc/1) [api.host] FINISH getAllVmStats 
return={'status': {'message': 'Done', 'code': 0}, 'statsList': (suppressed)} 
from=::1,45816 (api:52)
2018-05-28 11:07:34,483+0200 INFO  (jsonrpc/1) [jsonrpc.JsonRpcServer] RPC call 
Host.getAllVmStats succeeded in 0.01 seconds (__init__:573)
2018-05-28 11:07:34,489+0200 INFO  (jsonrpc/2) [api.host] START 
getAllVmIoTunePolicies() from=::1,45816 (api:46)
2018-05-28 11:07:34,489+0200 INFO  (jsonrpc/2) [api.host] FINISH 
getAllVmIoTunePolicies return={'status': {'message': 'Done', 'code': 0}, 
'io_tune_policies_dict': {'405f8ec0-03f9-43cb-a7e1-343a4c30453f': {'policy': 
[], 'current_values': []}}} from=::1,45816 (api:52)
2018-05-28 11:07:34,490+0200 INFO  (jsonrpc/2) [jsonrpc.JsonRpcServer] RPC call 
Host.getAllVmIoTunePolicies succeeded in 0.00 seconds (__init__:573)
2018-05-28 11:07:35,555+0200 INFO  (vmrecovery) [vdsm.api] START 
getConnectedStoragePoolsList(options=None) from=internal, 
task_id=6f517c47-a9f3-4913-bf9d-661355262c38 (api:46)
2018-05-28 11:07:35,555+0200 INFO  (vmrecovery) [vdsm.api] FINISH 
getConnectedStoragePoolsList return={'poollist': []} from=internal, 
task_id=6f517c47-a9f3-4913-bf9d-661355262c38 (api:52)
2018-05-28 11:07:35,555+0200 INFO  (vmrecovery) [vds] recovery: waiting for 
storage pool to go up (clientIF:707)
2018-05-28 11:07:38,982+0200 WARN  (vdsm.Scheduler) [Executor] Worker blocked: 
 timeout=60, 
duration=180 at 0x2fc3650> task#=1 at 0x3590710>, traceback:
File: "/usr/lib64/python2.7/threading.py", line 785, in __bootstrap
  self.__bootstrap_inner()
File: "/usr/lib64/python2.7/threading.py", line 812, in __bootstrap_inner
  self.run()
File: "/usr/lib64/python2.7/threading.py", line 765, in run
  self.__target(*self.__args, **self.__kwargs)
File: "/usr/lib/python2.7/site-packages/vdsm/common/concurrent.py", line 194, 
in run
  ret = func(*args, **kwargs)
File: "/usr/lib/python2.7/site-packages/vdsm/executor.py", line 301, in _run
  self._execute_task()
File: "/usr/lib/python2.7/site-packages/vdsm/executor.py", line 315, in 
_execute_task
  task()
File: "/usr/lib/python2.7/site-packages/vdsm/executor.py", line 391, in __call__
  self._callable()
File: "/usr/lib/python2.7/site-packages/yajsonrpc/__init__.py", line 523, in 
__call__
  self._handler(self._ctx, self._req)
File: "/usr/lib/python2.7/site-packages/yajsonrpc/__init__.py", line 566, in 
_serveRequest
  response = self._handle_request(req, ctx)
File: "/usr/lib/python2.7/site-packages/yajsonrpc/__init__.py", line 606, in 
_handle_request
  res = method(**params)
File: "/usr/lib/python2.7/site-packages/vdsm/rpc/Bridge.py", line 201, in 
_dynamicMethod
  result = fn(*methodArgs)
File: "", line 2, in getCapabilities
File: "/usr/lib/python2.7/site-packages/vdsm/common/api.py", line 48, in method
  ret = func(*args, **kwargs)
File: "/usr/lib/python2.7/site-packages/vdsm/API.py", line 1339, in 
getCapabilities
  c = caps.get()
File: "/usr/lib/python2.7/site-packages/vdsm/host/caps.py", line 201, in get
  liveSnapSupported = _getLiveSnapshotSupport(cpuarch.effective())
File: "/usr/lib/python2.7/site-packages/vdsm/common/cache.py", line 41, in 
__call__
  value = self.func(*args)
File: "/usr/lib/python2.7/site-packages/vdsm/host/caps.py", line 92, in 
_getLiveSnapshotSupport
  capabilities = _getCapsXMLStr()
File: "/usr/lib/python2.7/site-packages/vdsm/common/cache.py", line 41, in 
__call__
  value = self.func(*args)
File: "/usr/lib/python2.7/site-packages/vdsm/host/caps.py", line 60, in 
_getCapsXMLStr
  return _getFreshCapsXMLStr()
File: "/usr/lib/python2.7/site-packages/vdsm/host/caps.py", line 55, in 
_getFreshCapsXMLStr
  return libvirtconnection.get().getCapabilities()
File: "/usr/lib/python2.7/site-packages/vdsm/common/libvirtconnection.py", line 
130, in wrapper
  ret = f(*args, **kwargs)
File: "/usr/lib/python2.7/site-packages/vdsm/common/function.py", line 92, in 
wrapper
  return func(inst, *args, **kwargs)
File: "/usr/lib64/python2.7/site-packages/libvirt.py", line 3669, in 
getCapabilities
  ret = libvirtmod.virConnectGetCapabilities(self._o) (executor:363)
2018-05-28 11:07:40,561+0200 INFO  (vmrecovery) [vdsm.api] START 
getConnectedStoragePoolsList(options=None) from=internal, 
task_id=2ef7c0a3-4cf9-436e-ad6b-ee04e2a0cf3a (api:46)
2018-05-28 11:07:40,561+0200 INFO  (vmrecovery) [vdsm.api] FINISH 
getConnectedStoragePoolsList return={'poollist': []} from=internal, 
task_id=2ef7c0a3-4cf9-436e-ad6b-ee04e2a0cf3a (api:52)
2018-05-28 11:07:40,561+0200 INFO  (vmrecovery) [vds] recovery: waiting for 
storage pool to go up 

[ovirt-users] Re: oVirt hosted-engine-setup issues with getting host facts

[Mariusz Kozakowski]

On Mon, 2018-05-28 at 12:57 +0200, Simone Tiraboschi wrote:
The issue is on network configuration:
you have to check /var/log/vdsm/vdsm.log and /var/log/vdsm/supervdsm.log to 
understand why it failed.

From same time frame, vdsm.log. Can this be related?

2018-05-28 11:07:34,481+0200 INFO  (jsonrpc/1) [api.host] START getAllVmStats() 
from=::1,45816 (api:46)
2018-05-28 11:07:34,482+0200 INFO  (jsonrpc/1) [api.host] FINISH getAllVmStats 
return={'status': {'message': 'Done', 'code': 0}, 'statsList': (suppressed)} 
from=::1,45816 (api:52)
2018-05-28 11:07:34,483+0200 INFO  (jsonrpc/1) [jsonrpc.JsonRpcServer] RPC call 
Host.getAllVmStats succeeded in 0.01 seconds (__init__:573)
2018-05-28 11:07:34,489+0200 INFO  (jsonrpc/2) [api.host] START 
getAllVmIoTunePolicies() from=::1,45816 (api:46)
2018-05-28 11:07:34,489+0200 INFO  (jsonrpc/2) [api.host] FINISH 
getAllVmIoTunePolicies return={'status': {'message': 'Done', 'code': 0}, 
'io_tune_policies_dict': {'405f8ec0-03f9-43cb-a7e1-343a4c30453f': {'policy': 
[], 'current_values': []}}} from=::1,45816 (api:52)
2018-05-28 11:07:34,490+0200 INFO  (jsonrpc/2) [jsonrpc.JsonRpcServer] RPC call 
Host.getAllVmIoTunePolicies succeeded in 0.00 seconds (__init__:573)
2018-05-28 11:07:35,555+0200 INFO  (vmrecovery) [vdsm.api] START 
getConnectedStoragePoolsList(options=None) from=internal, 
task_id=6f517c47-a9f3-4913-bf9d-661355262c38 (api:46)
2018-05-28 11:07:35,555+0200 INFO  (vmrecovery) [vdsm.api] FINISH 
getConnectedStoragePoolsList return={'poollist': []} from=internal, 
task_id=6f517c47-a9f3-4913-bf9d-661355262c38 (api:52)
2018-05-28 11:07:35,555+0200 INFO  (vmrecovery) [vds] recovery: waiting for 
storage pool to go up (clientIF:707)
2018-05-28 11:07:38,982+0200 WARN  (vdsm.Scheduler) [Executor] Worker blocked: 
 timeout=60, 
duration=180 at 0x2fc3650> task#=1 at 0x3590710>, traceback:
File: "/usr/lib64/python2.7/threading.py", line 785, in __bootstrap
  self.__bootstrap_inner()
File: "/usr/lib64/python2.7/threading.py", line 812, in __bootstrap_inner
  self.run()
File: "/usr/lib64/python2.7/threading.py", line 765, in run
  self.__target(*self.__args, **self.__kwargs)
File: "/usr/lib/python2.7/site-packages/vdsm/common/concurrent.py", line 194, 
in run
  ret = func(*args, **kwargs)
File: "/usr/lib/python2.7/site-packages/vdsm/executor.py", line 301, in _run
  self._execute_task()
File: "/usr/lib/python2.7/site-packages/vdsm/executor.py", line 315, in 
_execute_task
  task()
File: "/usr/lib/python2.7/site-packages/vdsm/executor.py", line 391, in __call__
  self._callable()
File: "/usr/lib/python2.7/site-packages/yajsonrpc/__init__.py", line 523, in 
__call__
  self._handler(self._ctx, self._req)
File: "/usr/lib/python2.7/site-packages/yajsonrpc/__init__.py", line 566, in 
_serveRequest
  response = self._handle_request(req, ctx)
File: "/usr/lib/python2.7/site-packages/yajsonrpc/__init__.py", line 606, in 
_handle_request
  res = method(**params)
File: "/usr/lib/python2.7/site-packages/vdsm/rpc/Bridge.py", line 201, in 
_dynamicMethod
  result = fn(*methodArgs)
File: "", line 2, in getCapabilities
File: "/usr/lib/python2.7/site-packages/vdsm/common/api.py", line 48, in method
  ret = func(*args, **kwargs)
File: "/usr/lib/python2.7/site-packages/vdsm/API.py", line 1339, in 
getCapabilities
  c = caps.get()
File: "/usr/lib/python2.7/site-packages/vdsm/host/caps.py", line 201, in get
  liveSnapSupported = _getLiveSnapshotSupport(cpuarch.effective())
File: "/usr/lib/python2.7/site-packages/vdsm/common/cache.py", line 41, in 
__call__
  value = self.func(*args)
File: "/usr/lib/python2.7/site-packages/vdsm/host/caps.py", line 92, in 
_getLiveSnapshotSupport
  capabilities = _getCapsXMLStr()
File: "/usr/lib/python2.7/site-packages/vdsm/common/cache.py", line 41, in 
__call__
  value = self.func(*args)
File: "/usr/lib/python2.7/site-packages/vdsm/host/caps.py", line 60, in 
_getCapsXMLStr
  return _getFreshCapsXMLStr()
File: "/usr/lib/python2.7/site-packages/vdsm/host/caps.py", line 55, in 
_getFreshCapsXMLStr
  return libvirtconnection.get().getCapabilities()
File: "/usr/lib/python2.7/site-packages/vdsm/common/libvirtconnection.py", line 
130, in wrapper
  ret = f(*args, **kwargs)
File: "/usr/lib/python2.7/site-packages/vdsm/common/function.py", line 92, in 
wrapper
  return func(inst, *args, **kwargs)
File: "/usr/lib64/python2.7/site-packages/libvirt.py", line 3669, in 
getCapabilities
  ret = libvirtmod.virConnectGetCapabilities(self._o) (executor:363)
2018-05-28 11:07:40,561+0200 INFO  (vmrecovery) [vdsm.api] START 
getConnectedStoragePoolsList(options=None) from=internal, 
task_id=2ef7c0a3-4cf9-436e-ad6b-ee04e2a0cf3a (api:46)
2018-05-28 11:07:40,561+0200 INFO  (vmrecovery) [vdsm.api] FINISH 
getConnectedStoragePoolsList return={'poollist': []} from=internal, 
task_id=2ef7c0a3-4cf9-436e-ad6b-ee04e2a0cf3a (api:52)
2018-05-28 11:07:40,561+0200 INFO  (vmrecovery) [vds] recovery: waiting for 
storage pool to go up (clientIF:707)

supervdsm hase nothing at 11:07:39.

[ovirt-users]OVN networks

[Егор Чиж]

Hello, 

Could you help with how to change Switch type in ovirt cluster from Linux 
Bridge to OVS. 

I mean, using this link  
https://ovirt.org/develop/release-management/features/network/provider-physical-network/
  
I read paragraph   Create a cluster with Network Type set to OVS.

Now i have cluster with installing type Linux Bridge, how can i changed it to 
OVS?

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

[ovirt-users] Re: [Qemu-block] Libvirt ERROR cannot access backing file after importing VM from OpenStack

[Kevin Wolf]

Am 30.05.2018 um 15:44 hat Eric Blake geschrieben:
> On 05/29/2018 04:18 PM, Nir Soffer wrote:
> > > You CAN get a logically collapsed view of storage (that is, what the
> > > guest would see), by using an NBD export of volume V.  Reading from that
> > > volume will then pull sectors from whichever portion of the chain you
> > > need.  You can use either qemu-nbd (if no guest is writing to the
> > > chain), or within a running qemu, you can use nbd-server-start and
> > > nbd-server-add (over QMP) to get such an NBD server running.
> > 
> > 
> > NBD expose the guest data, but we want the qcow2 stream - without
> > creating a new image.
> 
> NBD can do both. You choose whether it exposes the guest data or the qcow2
> data, by whether the client or the server is interpreting qcow2 data.

But if I understand correctly, it doesn't result in the image Nir wants.
You would only export an existing qcow2 file, i.e. a single layer in the
backing chain, this way. The question was about a collapsed image, i.e.
the disk content as the guest sees it.

The problem is that qcow2 just isn't made to be streamable. Importing a
qcow2 stream without saving it into a temporary file (or a memory buffer
as large as the image file) simply isn't possible in the general case.

Exporting to a stream is possible if we're allowed to make two passes
over the source, but the existing QEMU code is useless for that because
it inherently requires seeking. I think if I had to get something like
this, I'd probably implement such an exporter as a script external to
QEMU.

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

[ovirt-users] Re: [Qemu-block] Libvirt ERROR cannot access backing file after importing VM from OpenStack

[Eric Blake]

On 05/29/2018 04:18 PM, Nir Soffer wrote:

You CAN get a logically collapsed view of storage (that is, what the
guest would see), by using an NBD export of volume V.  Reading from that
volume will then pull sectors from whichever portion of the chain you
need.  You can use either qemu-nbd (if no guest is writing to the
chain), or within a running qemu, you can use nbd-server-start and
nbd-server-add (over QMP) to get such an NBD server running.



NBD expose the guest data, but we want the qcow2 stream - without
creating a new image.


NBD can do both. You choose whether it exposes the guest data or the 
qcow2 data, by whether the client or the server is interpreting qcow2 
data.  Visually, if everything is local, qemu normally needs only two 
block layer entries:


qcow2 format layer => file protocol layer

But you can also make qemu use four block layer entries, since the raw 
layer is a normally passthrough layer (unless you are also using it for 
it's ability to support an offset within a larger file, such as reading 
from a tar file):


raw format layer => qcow2 format layer => raw format layer => file 
protocol layer


Then when you introduce NBD into the picture, you have the choice of 
WHERE in the four-layer system. The usual choice is:


NBD server using -f qcow2, client using -f raw:
raw format => NBD client protocol => (raw bytes) => NBD server => qcow2 
format => raw format => file protocol

(simplified to
raw format => NBD client protocol => (raw bytes) => NBD server => qcow2 
format => file protocol)


But an alternative choice is:

NBD server using -f raw, client using -f qcow2:
raw format => qcow2 format => NBD client protocol => (qcow2 bytes) => 
NBD server => raw format => file protocol

(simplified to
qcow2 format => NBD client protocol => (qcow2 bytes) => NBD server => 
raw format => file protocol)


--
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3266
Virtualization:  qemu.org | libvirt.org
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/7UGMMAKFC77DWBUAGZWRKOR2NEPGGNRO/

[ovirt-users] Re: Simple API call to start VM

[Bohdan Iakymets]

If VM with that UUID does not exist, then engine will return empty response
with 404 status code. In that case response not empty. Thus problem is,
most likely, in wrong path to engine.

BI

On Wed, May 30, 2018 at 9:36 AM, gss...@pku.edu.cn 
wrote:

> It looks like VM with UUID 60c47a91-bca1-4eda-b71d-7bddf82ee8ab does not
> exist.
>
>
> *From:* Kirin van der Veer 
> *Date:* 2018-05-30 14:07
> *To:* users 
> *Subject:* [ovirt-users] Simple API call to start VM
> Hi oVirt users,
> I have (what I hope) is a simple problem.
> I want to make an https request to start a VM via the oVirt REST API.
> Here is the command that I think should work:
> curl --user "admin:SECRETPASSWORD" --request POST --header "Content-Type:
> application/xml" --header "Accept: application/xml" --data ''
> https://ovirtengine.localnet:443/api/vms/69c47a91-bbv1-
> 4eda-b71d-7bddf82ee8ab/start
>
> However I get a 404 in response (see below):
> 
> 
> 404 Not Found
> 
> Not Found
> The requested URL /api/vms/60c47a91-bca1-4eda-b71d-7bddf82ee8ab/start
> was not found on this server.
> 
>
> Where have I made a mistake here?
>
>
>
> *IMPORTANT NOTE. *If you are NOT AN AUTHORISED RECIPIENT of this e-mail,
> please contact Planet Innovation Pty Ltd by return e-mail or by telephone
> on +613 9945 7510.  In this case, you should not read, print, re-transmit,
> store or act in reliance on this e-mail or any attachments, and should
> destroy all copies of them.  This e-mail and any attachments are
> confidential and may contain legally privileged information and/or
> copyright material of Planet Innovation Pty Ltd or third parties.  You
> should only re-transmit, distribute or commercialise the material if you
> are authorised to do so.  Although we use virus scanning software, we deny
> all liability for viruses or alike in any message or attachment. This
> notice should not be removed.
>
>
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> oVirt Code of Conduct: https://www.ovirt.org/community/about/community-
> guidelines/
> List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/
> message/CNKUCZR2CDSDVIYVUJMGY55W5ORVJMIP/
>
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/E5ZC7FOWQEPP6KGKSZLP7WSEO54QLFXH/

[ovirt-users] Re: [Qemu-block] Libvirt ERROR cannot access backing file after importing VM from OpenStack

[Eric Blake]

On 05/30/2018 07:35 AM, Nir Soffer wrote:


This is not the flow we are looking for. We need a way to read qcow2 data
from a pipe.


Why? The qcow2 format inherently requires seeking (or a HUGE amount of 
free RAM) the moment you want to interpret the data as qcow2.  It can't 
be piped when being produced or consumed for reading guest contents (it 
can be piped as a read-only format if you aren't inspecting guest 
contents, but then again so can raw).


If you are asking how to connect a SEEKABLE network connection, so that 
you don't need temporary storage locally, then NBD is a great format (it 
is network friendly, where the local qemu-img process is using the 
remote server for all storage; no local storage required).  But even 
then, it still requires a seekable input if you are not visiting the 
file in byte order, and qcow2 as an interpreted format cannot be written 
or read in byte order (for example, it inherently requires dereferencing 
through header, L1, L2, and refcount tables, which implies seeking).



But in any case you can just use the nbdkit tar plugin which already
does all of this.



Can it work with a tar stream read from stdin, or it requires a tar file?


nbdkit includes a plugin for creating a seekable layer on top of a pipe, 
at the expense of a huge memory cost (you have to have as much RAM 
available as you would ever have to seek backwards).  It also makes it 
easy to have a plugin for a tar file (reading tar files is easy; writing 
is a bit harder, but should work as long as you don't need resize and 
don't have any compressed sparse regions that need to be rewritten to 
non-sparse data)


--
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3266
Virtualization:  qemu.org | libvirt.org
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/72CIHHKEZZJFCEKTZQAGU2524X27VBR6/

[ovirt-users] Re: Libvirt ERROR cannot access backing file after importing VM from OpenStack

[Richard W.M. Jones]

On Wed, May 30, 2018 at 03:35:11PM +0300, Nir Soffer wrote:
> This is not the flow we are looking for. We need a way to read qcow2 data
> from a pipe.

The flow you asked for:

> > > image in any format -> qemu-img -> [qcow2 byte stream] -> imageio http
> > > server -> http client

is exactly what rhv-upload-plugin.py does, except for "-> http client"
at the end which I don't understand.

Can you describe exactly what you're trying to do again?

[...]
> > But in any case you can just use the nbdkit tar plugin which already
> > does all of this.
> >
> 
> Can it work with a tar stream read from stdin, or it requires a tar file?

As above it may help to describe from the start exactly what you're
trying to do.  This email thread has gone on for days and it's hard to
keep track of everything.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/JILUXYB2FPZMUZ347M5CMHR6LOSGZVK3/

[ovirt-users] Re: Libvirt ERROR cannot access backing file after importing VM from OpenStack

[Nir Soffer]

On Wed, May 30, 2018 at 11:58 AM Richard W.M. Jones 
wrote:

> On Wed, May 30, 2018 at 12:11:21AM +0300, Nir Soffer wrote:
> > Exporting images or ova files:
> >
> > image in any format -> qemu-img -> [qcow2 byte stream] -> imageio http
> > server -> http client
>
> You can do this with nbdkit + plugin, it's exactly what we do today
> for virt-v2v:
>
>
> https://github.com/libguestfs/libguestfs/blob/master/v2v/rhv-upload-plugin.py


This is not the flow we are looking for. We need a way to read qcow2 data
from a pipe.

> Importing images or ova files:
> >
> > http client -> imageio http server -> [qcow2 byte stream] -> qemu-img ->
> > image in any format
>
> Also could be done with nbdkit + plugin, basically the reverse of the
> above.
>
> > > If you can create a tar file that reserves space for the image file
> > > without actually writing it, a possible workaround today would be using
> > > the offset/size runtime options of the raw driver to convert directly
> > > into a region inside the tar archive.
> > >
> >
> > What are the offset/size runtime options? I cannot find anything about
> > them in man qemu-img.
>
> See:
>
> https://github.com/libguestfs/libguestfs/blob/dd162d2cd56a2ecf4bcd40a7f463940eaac875b8/v2v/input_ova.ml#L161
>
> But in any case you can just use the nbdkit tar plugin which already
> does all of this.
>

Can it work with a tar stream read from stdin, or it requires a tar file?

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

[ovirt-users] Re: [Qemu-block] Libvirt ERROR cannot access backing file after importing VM from OpenStack

[Nir Soffer]

On Wed, May 30, 2018 at 12:35 AM Eric Blake  wrote:

> On 05/29/2018 04:11 PM, Nir Soffer wrote:
>
> >> I think real streaming is unlikely to happen because most image formats
> >> that QEMU supports aren't made that way. If there is a compelling
> >> reason, we can consider it, but it would work only with very few target
> >> formats and as such would have to be separate from existing commands.
> >>
> >
> > Real streaming is exactly what we want, and we need it only for qcow2
> > format,
> > because it is our preferred way to pack images in ova.
> >
> > We have 2 possible use cases:
> >
> > Exporting images or ova files:
> >
> > image in any format -> qemu-img -> [qcow2 byte stream] -> imageio http
> > server -> http client
>
> image in any format -> qemu-img measure (to learn how large to size qcow2)
> then create destination qcow2 file that large


Isn't this a temporary qcow2 file we want to avoid?


> and serve it over NBD as
> raw (perhaps using an nbdkit plugin for this part)
> then qemu-img convert to destination format qcow2 as NBD client
>
> So, as long as your NBD server (via nbdkit plugin) can talk to imageio
> http server -> http client, and sized things properly according to
> qemu-img measure, then qemu-img can write qcow2 (rather than it's more
> usual raw) over the NBD connection, and when the process is complete,
> the http client will have a fully-populated qcow2 file with no temporary
> files created in the meantime.
>

Ok, it may work. What I need is:

qemu-img converting image to qcow2 format to a nbd server
nbd server writing qcow2 stream to stdout
imageio running both, sending data from nbd server stdout to client

But this means the nbd server cannot handle flow like:

- zero entire disk
- write data block 1 at offset x
- write data block 2 at offset y

We have seen this in virt-v2v nbdkit plugin on the server side using
raw output format, maybe this is not an issue with qcow2 output format?

qemu-img must know that the transport cannot seek.

When I tried in the past to do something like this it did not work, but
maybe
I was missing some options.

I think this should be implemented as a transport driver, like curl/ driver,
instead of creating these complex pipelines.

>
> > Importing images or ova files:
> >
> > http client -> imageio http server -> [qcow2 byte stream] -> qemu-img ->
> > image in any format
>
> Same sort of thing - as long as the NBD server is serving a qcow2 file
> as raw data, then the NBD client is interpreting that data as qcow2,
> then qemu-img convert should be able to convert that qcow2 stream into
> any format.
>
> Or, put another way, usually you do the conversion from qcow2 to raw at
> the server, then the client sees raw bytes:
>
> qemu-nbd -f qcow2 file.qcow2 # expose only the guest-visible bytes...

qemu-img convert -f raw nbd://host output # and write those bytes


> but in this case, you'd be serving raw bytes at the server, and letting
> the client do qcow2 conversion:
>
> qemu-nbd -f raw file.qcow2 # expose the full qcow2 file...
> qemu-img convert -f qcow2 nbd://host output # and extract the guest view
>
> where using nbdkit instead of qemu-nbd as your point of contact with the
> imageio http server may make more sense.
>
> >
> > If we will have this, we don't need to create temporary storage space
> and we
> > can avoid several image copies in the process.
> >
> > This will also improve the user experience, avoiding the wait until
> > a ova is created before the user can start downloading it.
> >
> > As for OVA files, I think it might be useful to have a tar block driver
> >> instead which would allow you to open a file inside a tar archive (you
> >> could then also directly run an OVA without extracting it first). We
> >> probably wouldn't be able to support resizing images there, but that
> >> should be okay.
> >>
> >> If you can create a tar file that reserves space for the image file
> >> without actually writing it, a possible workaround today would be using
> >> the offset/size runtime options of the raw driver to convert directly
> >> into a region inside the tar archive.
> >>
> >
> > What are the offset/size runtime options? I cannot find anything about
> > them in man qemu-img.
>
> ##
> # @BlockdevOptionsRaw:
> #
> # Driver specific block device options for the raw driver.
> #
> # @offset:  position where the block device starts
> # @size:the assumed size of the device
> #
> # Since: 2.9
> ##
> { 'struct': 'BlockdevOptionsRaw',
>'base': 'BlockdevOptionsGenericFormat',
>'data': { '*offset': 'int', '*size': 'int' } }
>
>
> Yeah, it's a pity that "qemu-img create -o help -f raw" has forgotten to
> document them, the way "qemu-img create -o help -f qcow2" does for its
> options, so we should fix that.
>

Thanks for the hint, but I still don't understand for which command these
options can be used, and how.

Can you show an example of using the options?

Nir
___
Users mailing 

[ovirt-users] Re: Simple API call to start VM

[Bohdan Iakymets]

Hello,

are you sure that URL is correct? Maybe it must be
https://ovirtengine.localnet:443/ovirt-engine/api/vms/69c47a91-bbv1-
4eda-b71d-7bddf82ee8ab/start

 .

BI

On Wed, May 30, 2018 at 8:07 AM, Kirin van der Veer <
kirin.vanderv...@planetinnovation.com.au> wrote:

> Hi oVirt users,
> I have (what I hope) is a simple problem.
> I want to make an https request to start a VM via the oVirt REST API.
> Here is the command that I think should work:
> curl --user "admin:SECRETPASSWORD" --request POST --header "Content-Type:
> application/xml" --header "Accept: application/xml" --data ''
> https://ovirtengine.localnet:443/api/vms/69c47a91-bbv1-
> 4eda-b71d-7bddf82ee8ab/start
>
> However I get a 404 in response (see below):
> 
> 
> 404 Not Found
> 
> Not Found
> The requested URL /api/vms/60c47a91-bca1-4eda-b71d-7bddf82ee8ab/start
> was not found on this server.
> 
>
> Where have I made a mistake here?
>
>
>
> *IMPORTANT NOTE. *If you are NOT AN AUTHORISED RECIPIENT of this e-mail,
> please contact Planet Innovation Pty Ltd by return e-mail or by telephone
> on +613 9945 7510.  In this case, you should not read, print, re-transmit,
> store or act in reliance on this e-mail or any attachments, and should
> destroy all copies of them.  This e-mail and any attachments are
> confidential and may contain legally privileged information and/or
> copyright material of Planet Innovation Pty Ltd or third parties.  You
> should only re-transmit, distribute or commercialise the material if you
> are authorised to do so.  Although we use virus scanning software, we deny
> all liability for viruses or alike in any message or attachment. This
> notice should not be removed.
>
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> oVirt Code of Conduct: https://www.ovirt.org/community/about/community-
> guidelines/
> List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/
> message/5N6N4BHF6ZFJLEARSEALCON7DJIMXRCZ/
>
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/6VO2WNKLHQS6SVD2WHQYUKO2LEDAXIKH/

[ovirt-users] Re: Fwd: FreeBSD after 10.3 could not boot (Freeze)

[Karli Sjöberg]

Den 30 maj 2018 12:51 skrev Alexandr Krivulya :
2        vCPU
  8Gb   vRAM
  10Gb vHDD (virtio-scsi)

Intel SandyBridge Family ClusterThanks! So we have two working for Intel, so right now, AMD seems to be the problem/K

29.05.2018 21:06, Karli Sjöberg пишет:

  I just tried it as well, works fine, no problemo. My VM has:
1	vCPU
1GB	vRAM
8GB	vHDD

In a Nehalem cluster.

Alex, Paul, what´s yours?


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

[ovirt-users] Re: Cannot see ipaddr of new VM

[03ce007]

the vm does come up, but I do not see any ipaddr, fqdn or dns. 
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/NAJRZ62LOPIXGMWKOUM74NLQBIM6F33J/

[ovirt-users] Re: Simple API call to start VM

[Ondra Machacek]

On 05/30/2018 08:07 AM, Kirin van der Veer wrote:

Hi oVirt users,
I have (what I hope) is a simple problem.
I want to make an https request to start a VM via the oVirt REST API.
Here is the command that I think should work:
curl --user "admin:SECRETPASSWORD" --request POST --header 


s/admin/admin@internal

"Content-Type: application/xml" --header "Accept: application/xml" 
--data '' 
https://ovirtengine.localnet:443/api/vms/69c47a91-bbv1-4eda-b71d-7bddf82ee8ab/start


missing ovirt-engine in URL:

https://ovirtengine.localnet:443/ovirt-engine/api/vms/69c47a91-bbv1-4eda-b71d-7bddf82ee8ab/start



However I get a 404 in response (see below):


404 Not Found

Not Found
The requested URL /api/vms/60c47a91-bca1-4eda-b71d-7bddf82ee8ab/start 
was not found on this server.



Where have I made a mistake here?



*IMPORTANT NOTE. *If you are NOT AN AUTHORISED RECIPIENT of this e-mail, 
please contact Planet Innovation Pty Ltd by return e-mail or by 
telephone on +613 9945 7510.  In this case, you should not read, print, 
re-transmit, store or act in reliance on this e-mail or any attachments, 
and should destroy all copies of them.  This e-mail and any attachments 
are confidential and may contain legally privileged information and/or 
copyright material of Planet Innovation Pty Ltd or third parties. You 
should only re-transmit, distribute or commercialise the material if you 
are authorised to do so.  Although we use virus scanning software, we 
deny all liability for viruses or alike in any message or 
attachment. This notice should not be removed.


**


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


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

[ovirt-users] Re: ovirt-node: freshly installed node: network interfaces not visible

[Ales Musil]

On Wed, May 30, 2018 at 10:14 AM, Etienne Charlier <
etienne.charl...@reduspaceservices.eu> wrote:

> Hello, Thanks for the support
>
>
> log are only sent to you , not to the list !!!
>
>
> Kind Regards,
>
> Etienne
>
>
Can you also please send the engine log?

Regards,
Ales


>
> --
> *De :* Ales Musil 
> *Envoyé :* mercredi 30 mai 2018 09:02
> *À :* Etienne Charlier
> *Cc :* users
> *Objet :* Re: [ovirt-users] Re: ovirt-node: freshly installed node:
> network interfaces not visible
>
>
>
> On Tue, May 29, 2018 at 8:40 AM, 
> wrote:
>
>> Hello Ales,
>>
>> Thanks for the answer !
>>
>> I tried multiple time to refresh capabilities... without success
>>
>> For the record, the tab named "Host Devices" is also empty
>>
>> Have  a nice Day
>> Etienne
>>
>
> Can you please send us the vdsm and supervdsm log from the host?
>
>
>
>
>> ___
>> Users mailing list -- users@ovirt.org
>> To unsubscribe send an email to users-le...@ovirt.org
>> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
>> oVirt Code of Conduct: https://www.ovirt.org/communit
>> y/about/community-guidelines/
>> List Archives: https://lists.ovirt.org/archiv
>> es/list/users@ovirt.org/message/ISBFSCIX7J6INUIKJXUSI6J4DWKA326Q/
>>
>
>
>
> --
>
> ALES MUSIL
> INTERN - rhv network
>
> Red Hat EMEA 
>
>
> amu...@redhat.com   IM: amusil
> 
>



-- 

ALES MUSIL
INTERN - rhv network

Red Hat EMEA 


amu...@redhat.com   IM: amusil

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

[ovirt-users] ovirt 4.2.3 console.vv provide IP addr, not FQHN for host= (spice connection)

[Oliver Riesener]

Hi,

i recently upgraded to ovirt 4.2.3-[78] and noticed that the spice 
client got and use


  host=IPAddr

from received console.vv file and not

  host=FQHN

of the virtualization host.

I need the FQHN because i access ovirt-webui remote via ssh with port 
forwarding.
I added a "127.0.0.1 FQHN" entry in /etc/hosts on client side to access 
remote ports.


Please could everyone provide a < 4.2.3 console.vv file ?

How can i change the behavior back to FQHN?

How can i re enable WebSocket Proxy ?  It's permanent False in engine-setup?

Greetings

Oliver



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

[ovirt-users] Error attaching cd iso image from data domain

[Gianluca Cecchi]

Hello,
I'm with oVirt 4.2.3 (upgraded from 4.1 and compatibilities set to 4.2)
I have a CentOS 7 VM.
I correctly uploaded an iSO image to the disks of a data storage domain
(iSCSI).
Now in web admin portal I select the VM, then the 3 dots in top right, then
change cd
I'm proposed with the [Eject] line and into the dropdown I see the two iso
images I have uploaded up to now.
I select an image and then OK

I get a window with title "Operation canceled" and content
Error while executing action Change CD: Drive image file could not be found

Do I have to edit any setting in my VM to be able to connect an ISO image
this way?
Or other things to check?

In engine.log I have:

2018-05-30 11:58:58,772+02 ERROR
[org.ovirt.engine.core.vdsbroker.vdsbroker.ChangeDiskVDSCommand] (d
efault task-9) [d9aae17f-2a49-4d70-a909-6395d61d3ab1] Failed in
'ChangeDiskVDS' method
2018-05-30 11:58:58,775+02 ERROR
[org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
(default task-9) [d9aae17f-2a49-4d70-a909-6395d61d3ab1] EVENT_ID:
VDS_BROKER_COMMAND_FAILURE(10,802), VDSM ov200 command ChangeDiskVDS
failed: Drive image file could not be found
2018-05-30 11:58:58,775+02 INFO
[org.ovirt.engine.core.vdsbroker.vdsbroker.ChangeDiskVDSCommand] (default
task-9) [d9aae17f-2a49-4d70-a909-6395d61d3ab1] Command
'org.ovirt.engine.core.vdsbroker.vdsbroker.ChangeDiskVDSCommand' return
value 'org.ovirt.engine.core.vdsbroker.vdsbroker.OneVmReturn@5e673b59'
2018-05-30 11:58:58,775+02 INFO
[org.ovirt.engine.core.vdsbroker.vdsbroker.ChangeDiskVDSCommand] (default
task-9) [d9aae17f-2a49-4d70-a909-6395d61d3ab1] HostName = ov200
2018-05-30 11:58:58,775+02 ERROR
[org.ovirt.engine.core.vdsbroker.vdsbroker.ChangeDiskVDSCommand] (default
task-9) [d9aae17f-2a49-4d70-a909-6395d61d3ab1] Command
'ChangeDiskVDSCommand(HostName = ov200,
ChangeDiskVDSCommandParameters:{hostId='d16e723c-b44c-4c1c-be76-c67911e47ccd',
vmId='2e571c77-bae1-4c1c-bf98-effaf9fed741', iface='ide', index='2',
diskPath='/rhev/data-center/mnt/blockSD/fa33df49-b09d-4f86-9719-ede649542c21/images/71a84a1c-0c53-4bb9-9474-deb92419e955/5404add1-cac4-4129-b8f5-2e7b2fc0da86'})'
execution failed: VDSGenericException: VDSErrorException: Failed to
ChangeDiskVDS, error = Drive image file could not be found, code = 13
2018-05-30 11:58:58,775+02 INFO
[org.ovirt.engine.core.vdsbroker.vdsbroker.ChangeDiskVDSCommand] (default
task-9) [d9aae17f-2a49-4d70-a909-6395d61d3ab1] FINISH,
ChangeDiskVDSCommand, log id: 740b3c78
2018-05-30 11:58:58,775+02 ERROR
[org.ovirt.engine.core.bll.storage.disk.ChangeDiskCommand] (default task-9)
[d9aae17f-2a49-4d70-a909-6395d61d3ab1] Command
'org.ovirt.engine.core.bll.storage.disk.ChangeDiskCommand' failed:
EngineException:
org.ovirt.engine.core.vdsbroker.vdsbroker.VDSErrorException:
VDSGenericException: VDSErrorException: Failed to ChangeDiskVDS, error =
Drive image file could not be found, code = 13 (Failed with error imageErr
and code 13)
2018-05-30 11:58:58,779+02 ERROR
[org.ovirt.engine.core.bll.storage.disk.ChangeDiskCommand] (default task-9)
[d9aae17f-2a49-4d70-a909-6395d61d3ab1] Transaction rolled-back for command
'org.ovirt.engine.core.bll.storage.disk.ChangeDiskCommand'.
2018-05-30 11:58:58,784+02 ERROR
[org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
(default task-9) [d9aae17f-2a49-4d70-a909-6395d61d3ab1] EVENT_ID:
USER_FAILED_CHANGE_DISK_VM(102), Failed to change disk in VM c7service
(Host: ov200, User: g.cecchi@internal-authz).
2018-05-30 11:59:30,262+02 INFO
[org.ovirt.engine.core.bll.tasks.AsyncTaskManager]
(EE-ManagedThreadFactory-engineScheduled-Thread-33) [] Setting new tasks
map. The map contains now 0 tasks
2018-05-30 11:59:30,262+02 INFO
[org.ovirt.engine.core.bll.tasks.AsyncTaskManager]
(EE-ManagedThreadFactory-engineScheduled-Thread-33) [] Cleared all tasks of
pool 'ef17cad6-7724-4cd8-96e3-9af6e529db51'.


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

[ovirt-users] Re: Use an oVirt-VM as a VDSM server

[Sandro Bonazzola]

Il lun 30 apr 2018, 15:03 James Michels 
ha scritto:

> Greetings.
>
> In terms of teaching our students how to create and configure an oVirt
> infrastructure, we're planning to provide each of them a VM that will act
> as a Manager server, which has no issues so far.
>

If you are teaching about oVirt, I would suggest to join
http://teachingopensource.org/ initiative and share teaching material there
or pushing it to oVirt site at https://github.com/oVirt/ovirt-site so other
universities / schools can re-use the teaching material and contribute to
it.



The problem is that we don't have enough physical machines to use as
> virtualization servers (VDSM), therefore we have been trying to use a
> CentOS7 based oVirt guest to run as a VDSM server.
>
> However, when trying to add it as a host, a (logical) error message shows
> up saying that the VM doesn't allow virtualization.
>
> The question is simple: Is there a way to enable virtualization on an
> oVirt VM, so we can deploy them as VDSM servers?
>
> This is oVirt 4.2.2 FWIW.
>
> Thanks
>
> James
> ___
> Users mailing list
> Users@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/K66QRLMVLP55KUMFMOCNZC4LRFDCKPLM/

[ovirt-users] Re: Fwd: FreeBSD after 10.3 could not boot (Freeze)

[Karli Sjöberg]

Den 30 maj 2018 10:26 skrev "Paul.LKW" :

Hi  Karli Sjöberg It is very upset as I am using even more older version 3.6 also could run higher version of FreeBSD, yesterday I just tried install FreeBSD 11 in oVirt 3.6 is no problem but newer version of oVirt not work !!!
Well, I am running 4.1 and can run both 10.4 and 11, so there's nothing wrong with oVirt itself. Do you have an Intel cluster you can test with?/K
2018-05-30 12:16 GMT+08:00 Karli Sjöberg :Paul, "reply all" next timeDen 30 maj 2018 05:32 skrev "Paul.LKW" :Hi 

Karli Sjöberg/ 

Alexandr Krivulya

So the image says the virtual hardware is about the same, except for Cluster type. I've had issues before getting FreeBSD running in oVirt with Opteron. Since i then had two clusters: one AMD and one Intel, I worked around it by only using the Intel cluster for FreeBSD guests.I also tested booting FreeBSD ISO on the host metal (old Sun Fire, maybe X4440, something like that), so it should just be a oVirt/QEMU thing, but I never tried fixing it./K2018-05-30 2:06 GMT+08:00 Karli Sjöberg :On Wed, 2018-05-30 at 01:09 +0800, Paul.LKW wrote:
> Hi Alexandr Krivulya:
> Tried all configuration combination also could not boot still hang on
> the screen captured !

I just tried it as well, works fine, no problemo. My VM has:
1       vCPU
1GB     vRAM
8GB     vHDD

In a Nehalem cluster.

Alex, Paul, what´s yours?

/K

> 
> Alexandr Krivulya 於 29/5/2018 22:57 寫道:
> > Hi!
> > I procced with default instalation of 10.4-amd64 from ISO and it
> > boots just fine. Can you provide some more info about VM
> > configuration? 
> > 
> > 26.05.2018 20:59, Paul.LKW пишет:
> > > HI All:
> > > Any one have tried to boot up FreeBSD 10.4 successful? I tried
> > > 10.3 is all working fine but no lucky in 10.4 at all even boot
> > > from DVD !!!
> > > Attached is the freezes point.
> > > 
> > > 
> > > 
> > > BR,
> > > Paul.LKW
> > > 
> > > 
> > > ___
> > > Users mailing list -- users@ovirt.org
> > > To unsubscribe send an email to users-le...@ovirt.org
> >  
> > 
> > ___
> > Users mailing list -- users@ovirt.org
> > To unsubscribe send an email to users-le...@ovirt.org
> > Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> > oVirt Code of Conduct: https://www.ovirt.org/community/about/commun
> > ity-guidelines/
> > List Archives: https://lists.ovirt.org/archives/list/us...@ovirt.or
> > g/message/BCXCX5QMXL7SQUVBJMN3HFSQSS56VPJF/
>  
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> oVirt Code of Conduct: https://www.ovirt.org/community/about/communit
> y-guidelines/
> List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/
> message/6ZPGH2ZJ7LL65GV2ATVPRV4FX6SBHM7Z/

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

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

[ovirt-users] Re: Simple API call to start VM

[Karli Sjöberg]

Den 30 maj 2018 09:25 skrev Kirin van der Veer :Hi oVirt users,I have (what I hope) is a simple problem.I want to make an https request to start a VM via the oVirt REST API.Here is the command that I think should work:curl
 --user "admin:SECRETPASSWORD" --request POST --header "Content-Type: 
application/xml" --header "Accept: application/xml" --data 
'' 
https://ovirtengine.localnet:443/api/vms/69c47a91-bbv1-4eda-b71d-7bddf82ee8ab/startHi!It needs to be https://ovirtengine.localnet:443/ovirt-engine/api/.../KHowever I get a 404 in response (see below):404 Not FoundNot FoundThe requested URL /api/vms/60c47a91-bca1-4eda-b71d-7bddf82ee8ab/start was not found on this server.Where have I made a mistake here?




IMPORTANT
NOTE. If you are
NOT AN AUTHORISED RECIPIENT of this e-mail, please contact Planet Innovation Pty
Ltd by return e-mail or by telephone on +613 9945 7510.  In this case, you
should not read, print, re-transmit, store or act in reliance on this e-mail or
any attachments, and should destroy all copies of them.  This e-mail and
any attachments are confidential and may contain legally privileged information
and/or copyright material of Planet Innovation Pty Ltd or third parties. 
You should only re-transmit, distribute or commercialise the material if you
are authorised to do so.  Although we use virus scanning software, we deny
all liability for viruses or alike in any message or attachment. This
notice should not be removed.

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

[ovirt-users] Re: Simple API call to start VM

[Fred Rolland]

HI,

Check here for an example:
http://ovirt.github.io/ovirt-engine-api-model/4.3/#_example_start_the_virtual_machine

>From your example, it may be a few issues:
- missing "ovirt-engine" in the URL
- the user should be admin@internal
- if you use https, you should specify a certificate

Regards,
Fred

On Wed, May 30, 2018 at 9:07 AM, Kirin van der Veer <
kirin.vanderv...@planetinnovation.com.au> wrote:

> Hi oVirt users,
> I have (what I hope) is a simple problem.
> I want to make an https request to start a VM via the oVirt REST API.
> Here is the command that I think should work:
> curl --user "admin:SECRETPASSWORD" --request POST --header "Content-Type:
> application/xml" --header "Accept: application/xml" --data ''
> https://ovirtengine.localnet:443/api/vms/69c47a91-bbv1-
> 4eda-b71d-7bddf82ee8ab/start
>
> However I get a 404 in response (see below):
> 
> 
> 404 Not Found
> 
> Not Found
> The requested URL /api/vms/60c47a91-bca1-4eda-b71d-7bddf82ee8ab/start
> was not found on this server.
> 
>
> Where have I made a mistake here?
>
>
>
> *IMPORTANT NOTE. *If you are NOT AN AUTHORISED RECIPIENT of this e-mail,
> please contact Planet Innovation Pty Ltd by return e-mail or by telephone
> on +613 9945 7510.  In this case, you should not read, print, re-transmit,
> store or act in reliance on this e-mail or any attachments, and should
> destroy all copies of them.  This e-mail and any attachments are
> confidential and may contain legally privileged information and/or
> copyright material of Planet Innovation Pty Ltd or third parties.  You
> should only re-transmit, distribute or commercialise the material if you
> are authorised to do so.  Although we use virus scanning software, we deny
> all liability for viruses or alike in any message or attachment. This
> notice should not be removed.
>
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> oVirt Code of Conduct: https://www.ovirt.org/community/about/community-
> guidelines/
> List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/
> message/5N6N4BHF6ZFJLEARSEALCON7DJIMXRCZ/
>
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/O7X2Z2DGANICGCNNLDH5ZGOGDZCWPCZG/

[ovirt-users] Re: Simple API call to start VM

[Andrej Krejcir]

Hi,

the URL path is missing 'ovirt-engine', it should be:
https://ovirtengine.localnet:443/ovirt-engine/api/vms/dfbba498-e8b6-4fee-a86c-c91ab68eae0d/start

Also, the admin user name is: 'admin@internal'

Here is the API documentation, for more info:
http://ovirt.github.io/ovirt-engine-api-model/4.2/#services/vm/methods/start


Andrej

On 30 May 2018 at 08:07, Kirin van der Veer <
kirin.vanderv...@planetinnovation.com.au> wrote:

> Hi oVirt users,
> I have (what I hope) is a simple problem.
> I want to make an https request to start a VM via the oVirt REST API.
> Here is the command that I think should work:
> curl --user "admin:SECRETPASSWORD" --request POST --header "Content-Type:
> application/xml" --header "Accept: application/xml" --data ''
> https://ovirtengine.localnet:443/api/vms/69c47a91-bbv1-
> 4eda-b71d-7bddf82ee8ab/start
>
> However I get a 404 in response (see below):
> 
> 
> 404 Not Found
> 
> Not Found
> The requested URL /api/vms/60c47a91-bca1-4eda-b71d-7bddf82ee8ab/start
> was not found on this server.
> 
>
> Where have I made a mistake here?
>
>
>
> *IMPORTANT NOTE. *If you are NOT AN AUTHORISED RECIPIENT of this e-mail,
> please contact Planet Innovation Pty Ltd by return e-mail or by telephone
> on +613 9945 7510.  In this case, you should not read, print, re-transmit,
> store or act in reliance on this e-mail or any attachments, and should
> destroy all copies of them.  This e-mail and any attachments are
> confidential and may contain legally privileged information and/or
> copyright material of Planet Innovation Pty Ltd or third parties.  You
> should only re-transmit, distribute or commercialise the material if you
> are authorised to do so.  Although we use virus scanning software, we deny
> all liability for viruses or alike in any message or attachment. This
> notice should not be removed.
>
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> oVirt Code of Conduct: https://www.ovirt.org/community/about/community-
> guidelines/
> List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/
> message/5N6N4BHF6ZFJLEARSEALCON7DJIMXRCZ/
>
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/EXEGUYYIG6AAHZ37HLFIVSASVKMTPLWC/

[ovirt-users] Re: Libvirt ERROR cannot access backing file after importing VM from OpenStack

[Richard W.M. Jones]

On Wed, May 30, 2018 at 12:11:21AM +0300, Nir Soffer wrote:
> Exporting images or ova files:
> 
> image in any format -> qemu-img -> [qcow2 byte stream] -> imageio http
> server -> http client

You can do this with nbdkit + plugin, it's exactly what we do today
for virt-v2v:

https://github.com/libguestfs/libguestfs/blob/master/v2v/rhv-upload-plugin.py

> Importing images or ova files:
> 
> http client -> imageio http server -> [qcow2 byte stream] -> qemu-img ->
> image in any format

Also could be done with nbdkit + plugin, basically the reverse of the
above.

> > If you can create a tar file that reserves space for the image file
> > without actually writing it, a possible workaround today would be using
> > the offset/size runtime options of the raw driver to convert directly
> > into a region inside the tar archive.
> >
> 
> What are the offset/size runtime options? I cannot find anything about
> them in man qemu-img.

See:
https://github.com/libguestfs/libguestfs/blob/dd162d2cd56a2ecf4bcd40a7f463940eaac875b8/v2v/input_ova.ml#L161

But in any case you can just use the nbdkit tar plugin which already
does all of this.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/PXRHKGNW7FTPT27XSGEDFWK7LRPNZMNL/

[ovirt-users] Re: Simple API call to start VM

[gss...@pku.edu.cn]

It looks like VM with UUID 60c47a91-bca1-4eda-b71d-7bddf82ee8ab does not exist.

 
From: Kirin van der Veer
Date: 2018-05-30 14:07
To: users
Subject: [ovirt-users] Simple API call to start VM
Hi oVirt users,
I have (what I hope) is a simple problem.
I want to make an https request to start a VM via the oVirt REST API.
Here is the command that I think should work:
curl --user "admin:SECRETPASSWORD" --request POST --header "Content-Type: 
application/xml" --header "Accept: application/xml" --data '' 
https://ovirtengine.localnet:443/api/vms/69c47a91-bbv1-4eda-b71d-7bddf82ee8ab/start

However I get a 404 in response (see below):


404 Not Found

Not Found
The requested URL /api/vms/60c47a91-bca1-4eda-b71d-7bddf82ee8ab/start was 
not found on this server.


Where have I made a mistake here?



IMPORTANT NOTE. If you are NOT AN AUTHORISED RECIPIENT of this e-mail, please 
contact Planet Innovation Pty Ltd by return e-mail or by telephone on +613 9945 
7510.  In this case, you should not read, print, re-transmit, store or act in 
reliance on this e-mail or any attachments, and should destroy all copies of 
them.  This e-mail and any attachments are confidential and may contain legally 
privileged information and/or copyright material of Planet Innovation Pty Ltd 
or third parties.  You should only re-transmit, distribute or commercialise the 
material if you are authorised to do so.  Although we use virus scanning 
software, we deny all liability for viruses or alike in any message or 
attachment. This notice should not be removed.
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/CNKUCZR2CDSDVIYVUJMGY55W5ORVJMIP/

[ovirt-users] Re: Simple API call to start VM

[Luca 'remix_tj' Lorenzetto]

Hello,

you're using the wrong API address. you have to use

 https://ovirtengine.localnet:443/ovirt-engine/api/

Luca

On Wed, May 30, 2018 at 8:07 AM, Kirin van der Veer
 wrote:
> Hi oVirt users,
> I have (what I hope) is a simple problem.
> I want to make an https request to start a VM via the oVirt REST API.
> Here is the command that I think should work:
> curl --user "admin:SECRETPASSWORD" --request POST --header "Content-Type:
> application/xml" --header "Accept: application/xml" --data ''
> https://ovirtengine.localnet:443/api/vms/69c47a91-bbv1-4eda-b71d-7bddf82ee8ab/start
>
> However I get a 404 in response (see below):
> 
> 
> 404 Not Found
> 
> Not Found
> The requested URL /api/vms/60c47a91-bca1-4eda-b71d-7bddf82ee8ab/start was
> not found on this server.
> 
>
> Where have I made a mistake here?
>
>
>
> IMPORTANT NOTE. If you are NOT AN AUTHORISED RECIPIENT of this e-mail,
> please contact Planet Innovation Pty Ltd by return e-mail or by telephone on
> +613 9945 7510.  In this case, you should not read, print, re-transmit,
> store or act in reliance on this e-mail or any attachments, and should
> destroy all copies of them.  This e-mail and any attachments are
> confidential and may contain legally privileged information and/or copyright
> material of Planet Innovation Pty Ltd or third parties.  You should only
> re-transmit, distribute or commercialise the material if you are authorised
> to do so.  Although we use virus scanning software, we deny all liability
> for viruses or alike in any message or attachment. This notice should not be
> removed.
>
>
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/5N6N4BHF6ZFJLEARSEALCON7DJIMXRCZ/
>



-- 
"E' assurdo impiegare gli uomini di intelligenza eccellente per fare
calcoli che potrebbero essere affidati a chiunque se si usassero delle
macchine"
Gottfried Wilhelm von Leibnitz, Filosofo e Matematico (1646-1716)

"Internet è la più grande biblioteca del mondo.
Ma il problema è che i libri sono tutti sparsi sul pavimento"
John Allen Paulos, Matematico (1945-vivente)

Luca 'remix_tj' Lorenzetto, http://www.remixtj.net , 
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/SCKYAK5O6CKMD37UP2IQ7WP3EFMGVKKO/

[ovirt-users] Re: ovirt-node: freshly installed node: network interfaces not visible

[Ales Musil]

On Tue, May 29, 2018 at 8:40 AM, 
wrote:

> Hello Ales,
>
> Thanks for the answer !
>
> I tried multiple time to refresh capabilities... without success
>
> For the record, the tab named "Host Devices" is also empty
>
> Have  a nice Day
> Etienne
>

Can you please send us the vdsm and supervdsm log from the host?




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



-- 

ALES MUSIL
INTERN - rhv network

Red Hat EMEA 


amu...@redhat.com   IM: amusil

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

[ovirt-users] Re: Fwd: FreeBSD after 10.3 could not boot (Freeze)

[Alexandr Krivulya]

2        vCPU
8Gb   vRAM
10Gb vHDD (virtio-scsi)

Intel SandyBridge Family Cluster

29.05.2018 21:06, Karli Sjöberg пишет:

I just tried it as well, works fine, no problemo. My VM has:
1   vCPU
1GB vRAM
8GB vHDD

In a Nehalem cluster.

Alex, Paul, what´s yours?


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

[ovirt-users] Re: Gluster problems, cluster performance issues

[Johan Bernhardsson]

Is storage working as it should?  Does the gluster mount point respond as 
it should? Can you write files to it?  Does the physical drives say that 
they are ok? Can you write (you shouldn't bypass gluster mount point but 
you need to test the drives) to the physical drives?


For me this sounds like broken or almost broken hardware or broken 
underlying filesystems.


If one of the drives malfunction and timeout, gluster will be slow and 
timeout. It runs write in sync so the slowest node will slow down the whole 
system.


/Johan


On May 30, 2018 08:29:46 Jim Kusznir  wrote:
hosted-engine --deploy failed (would not come up on my existing gluster 
storage).  However, I realized no changes were written to my existing 
storage.  So, I went back to trying to get my old engine running.


hosted-engine --vm-status is now taking a very long time (5+minutes) to 
return, and it returns stail information everywhere.  I thought perhaps the 
lockspace is corrupt, so tried to clean that and metadata, but both are 
failing (--cleam-metadata has hung and I can't even ctrl-c out of it).


How can I reinitialize all the lockspace/metadata safely?  There is no 
engine or VMs running currently


--Jim

On Tue, May 29, 2018 at 9:33 PM, Jim Kusznir  wrote:
Well, things went from bad to very, very bad

It appears that during one of the 2 minute lockups, the fencing agents 
decided that another node in the cluster was down.  As a result, 2 of the 3 
nodes were simultaneously reset with fencing agent reboot.  After the nodes 
came back up, the engine would not start.  All running VMs (including VMs 
on the 3rd node that was not rebooted) crashed.


I've now been working for about 3 hours trying to get the engine to come 
up.  I don't know why it won't start.  hosted-engine --vm-start says its 
starting, but it doesn't start (virsh doesn't show any VMs running).  I'm 
currently running --deploy, as I had run out of options for anything else I 
can come up with.  I hope this will allow me to re-import all my existing 
VMs and allow me to start them back up after everything comes back up.


I do have an unverified geo-rep backup; I don't know if it is a good backup 
(there were several prior messages to this list, but I didn't get replies 
to my questions.  It was running in what I believe to be "strange", and the 
data directories are larger than their source).


I'll see if my --deploy works, and if not, I'll be back with another 
message/help request.


When the dust settles and I'm at least minimally functional again, I really 
want to understand why all these technologies designed to offer redundancy 
conspired to reduce uptime and create failures where there weren't any 
otherwise.  I thought with hosted engine, 3 ovirt servers and glusterfs 
with minimum replica 2+arb or replica 3 should have offered strong 
resilience against server failure or disk failure, and should have 
prevented / recovered from data corruption.  Instead, all of the above 
happened (once I get my cluster back up, I still have to try and recover my 
webserver VM, which won't boot due to XFS corrupt journal issues created 
during the gluster crashes).  I think a lot of these issues were rooted 
from the upgrade from 4.1 to 4.2.


--Jim

On Tue, May 29, 2018 at 6:25 PM, Jim Kusznir  wrote:
I also finally found the following in my system log on one server:

[10679.524491] INFO: task glusterclogro:14933 blocked for more than 120 
seconds.
[10679.525826] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables 
this message.

[10679.527144] glusterclogro   D 97209832bf40 0 14933  1 0x0080
[10679.527150] Call Trace:
[10679.527161]  [] schedule+0x29/0x70
[10679.527218]  [] _xfs_log_force_lsn+0x2e8/0x340 [xfs]
[10679.527225]  [] ? wake_up_state+0x20/0x20
[10679.527254]  [] xfs_file_fsync+0x107/0x1e0 [xfs]
[10679.527260]  [] do_fsync+0x67/0xb0
[10679.527268]  [] ? system_call_after_swapgs+0xbc/0x160
[10679.527271]  [] SyS_fsync+0x10/0x20
[10679.527275]  [] system_call_fastpath+0x1c/0x21
[10679.527279]  [] ? system_call_after_swapgs+0xc8/0x160
[10679.527283] INFO: task glusterposixfsy:14941 blocked for more than 120 
seconds.
[10679.528608] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables 
this message.

[10679.529956] glusterposixfsy D 972495f84f10 0 14941  1 0x0080
[10679.529961] Call Trace:
[10679.529966]  [] schedule+0x29/0x70
[10679.530003]  [] _xfs_log_force_lsn+0x2e8/0x340 [xfs]
[10679.530008]  [] ? wake_up_state+0x20/0x20
[10679.530038]  [] xfs_file_fsync+0x107/0x1e0 [xfs]
[10679.530042]  [] do_fsync+0x67/0xb0
[10679.530046]  [] ? system_call_after_swapgs+0xbc/0x160
[10679.530050]  [] SyS_fdatasync+0x13/0x20
[10679.530054]  [] system_call_fastpath+0x1c/0x21
[10679.530058]  [] ? system_call_after_swapgs+0xc8/0x160
[10679.530062] INFO: task glusteriotwr13:15486 blocked for more than 120 
seconds.
[10679.531805] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables 
this message.

[10679.533732] 

[ovirt-users] Re: Gluster problems, cluster performance issues

[Jim Kusznir]

At the moment, it is responding like I would expect.  I do know I have one
failed drive on one brick (hardware failure, OS removed drive completely;
the underlying /dev/sdb is gone).  I have a new disk on order (overnight),
but that is also one brick of one volume that is replica 3, so I would hope
a complete failure like that would restore the system to operational
capabilities.

Since having the gluster-volume-starting problems, I have performed a test
in the engine volume with writing and removing a file and verifying its
happening from all three hosts; that worked.  The engine volume has all of
its bricks, as well two other volumes; its only one volume that is shy one
brick.

--Jim

On Tue, May 29, 2018 at 11:41 PM, Johan Bernhardsson  wrote:

> Is storage working as it should?  Does the gluster mount point respond as
> it should? Can you write files to it?  Does the physical drives say that
> they are ok? Can you write (you shouldn't bypass gluster mount point but
> you need to test the drives) to the physical drives?
>
> For me this sounds like broken or almost broken hardware or broken
> underlying filesystems.
>
> If one of the drives malfunction and timeout, gluster will be slow and
> timeout. It runs write in sync so the slowest node will slow down the whole
> system.
>
> /Johan
>
>
> On May 30, 2018 08:29:46 Jim Kusznir  wrote:
>
>> hosted-engine --deploy failed (would not come up on my existing gluster
>> storage).  However, I realized no changes were written to my existing
>> storage.  So, I went back to trying to get my old engine running.
>>
>> hosted-engine --vm-status is now taking a very long time (5+minutes) to
>> return, and it returns stail information everywhere.  I thought perhaps the
>> lockspace is corrupt, so tried to clean that and metadata, but both are
>> failing (--cleam-metadata has hung and I can't even ctrl-c out of it).
>>
>> How can I reinitialize all the lockspace/metadata safely?  There is no
>> engine or VMs running currently
>>
>> --Jim
>>
>> On Tue, May 29, 2018 at 9:33 PM, Jim Kusznir  wrote:
>>
>>> Well, things went from bad to very, very bad
>>>
>>> It appears that during one of the 2 minute lockups, the fencing agents
>>> decided that another node in the cluster was down.  As a result, 2 of the 3
>>> nodes were simultaneously reset with fencing agent reboot.  After the nodes
>>> came back up, the engine would not start.  All running VMs (including VMs
>>> on the 3rd node that was not rebooted) crashed.
>>>
>>> I've now been working for about 3 hours trying to get the engine to come
>>> up.  I don't know why it won't start.  hosted-engine --vm-start says its
>>> starting, but it doesn't start (virsh doesn't show any VMs running).  I'm
>>> currently running --deploy, as I had run out of options for anything else I
>>> can come up with.  I hope this will allow me to re-import all my existing
>>> VMs and allow me to start them back up after everything comes back up.
>>>
>>> I do have an unverified geo-rep backup; I don't know if it is a good
>>> backup (there were several prior messages to this list, but I didn't get
>>> replies to my questions.  It was running in what I believe to be "strange",
>>> and the data directories are larger than their source).
>>>
>>> I'll see if my --deploy works, and if not, I'll be back with another
>>> message/help request.
>>>
>>> When the dust settles and I'm at least minimally functional again, I
>>> really want to understand why all these technologies designed to offer
>>> redundancy conspired to reduce uptime and create failures where there
>>> weren't any otherwise.  I thought with hosted engine, 3 ovirt servers and
>>> glusterfs with minimum replica 2+arb or replica 3 should have offered
>>> strong resilience against server failure or disk failure, and should have
>>> prevented / recovered from data corruption.  Instead, all of the above
>>> happened (once I get my cluster back up, I still have to try and recover my
>>> webserver VM, which won't boot due to XFS corrupt journal issues created
>>> during the gluster crashes).  I think a lot of these issues were rooted
>>> from the upgrade from 4.1 to 4.2.
>>>
>>> --Jim
>>>
>>> On Tue, May 29, 2018 at 6:25 PM, Jim Kusznir 
>>> wrote:
>>>
 I also finally found the following in my system log on one server:

 [10679.524491] INFO: task glusterclogro:14933 blocked for more than 120
 seconds.
 [10679.525826] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
 disables this message.
 [10679.527144] glusterclogro   D 97209832bf40 0 14933  1
 0x0080
 [10679.527150] Call Trace:
 [10679.527161]  [] schedule+0x29/0x70
 [10679.527218]  [] _xfs_log_force_lsn+0x2e8/0x340
 [xfs]
 [10679.527225]  [] ? wake_up_state+0x20/0x20
 [10679.527254]  [] xfs_file_fsync+0x107/0x1e0 [xfs]
 [10679.527260]  [] do_fsync+0x67/0xb0
 [10679.527268]  [] ? system_call_after_swapgs+0xbc/
 0x160
 [10679.527271]  [] 

[ovirt-users] Re: Fwd: FreeBSD after 10.3 could not boot (Freeze)

[Paul.LKW]

 Hi  Karli Sjöberg
It is very upset as I am using even more older version 3.6 also could run
higher version of FreeBSD, yesterday I just tried install FreeBSD 11 in
oVirt 3.6 is no problem but newer version of oVirt not work !!!

2018-05-30 12:16 GMT+08:00 Karli Sjöberg :

> Paul, "reply all" next time
>
> Den 30 maj 2018 05:32 skrev "Paul.LKW" :
>
> Hi  Karli Sjöberg/  Alexandr Krivulya
>
>
> So the image says the virtual hardware is about the same, except for
> Cluster type. I've had issues before getting FreeBSD running in oVirt with
> Opteron. Since i then had two clusters: one AMD and one Intel, I worked
> around it by only using the Intel cluster for FreeBSD guests.
>
> I also tested booting FreeBSD ISO on the host metal (old Sun Fire, maybe
> X4440, something like that), so it should just be a oVirt/QEMU thing, but I
> never tried fixing it.
>
> /K
>
>
>
> 2018-05-30 2:06 GMT+08:00 Karli Sjöberg :
>
> On Wed, 2018-05-30 at 01:09 +0800, Paul.LKW wrote:
> > Hi Alexandr Krivulya:
> > Tried all configuration combination also could not boot still hang on
> > the screen captured !
>
> I just tried it as well, works fine, no problemo. My VM has:
> 1   vCPU
> 1GB vRAM
> 8GB vHDD
>
> In a Nehalem cluster.
>
> Alex, Paul, what´s yours?
>
> /K
>
> >
> > Alexandr Krivulya 於 29/5/2018 22:57 寫道:
> > > Hi!
> > > I procced with default instalation of 10.4-amd64 from ISO and it
> > > boots just fine. Can you provide some more info about VM
> > > configuration?
> > >
> > > 26.05.2018 20:59, Paul.LKW пишет:
> > > > HI All:
> > > > Any one have tried to boot up FreeBSD 10.4 successful? I tried
> > > > 10.3 is all working fine but no lucky in 10.4 at all even boot
> > > > from DVD !!!
> > > > Attached is the freezes point.
> > > >
> > > >
> > > >
> > > > BR,
> > > > Paul.LKW
> > > >
> > > >
> > > > ___
> > > > Users mailing list -- users@ovirt.org
> > > > To unsubscribe send an email to users-le...@ovirt.org
> > >
> > >
> > > ___
> > > Users mailing list -- users@ovirt.org
> > > To unsubscribe send an email to users-le...@ovirt.org
> > > Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> > > oVirt Code of Conduct: https://www.ovirt.org/community/about/commun
> > > ity-guidelines/
> > > List Archives: https://lists.ovirt.org/archives/list/us...@ovirt.or
> > > g/message/BCXCX5QMXL7SQUVBJMN3HFSQSS56VPJF/
> >
> > ___
> > Users mailing list -- users@ovirt.org
> > To unsubscribe send an email to users-le...@ovirt.org
> > Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> > oVirt Code of Conduct: https://www.ovirt.org/community/about/communit
> > y-guidelines/
> > List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/
> > message/6ZPGH2ZJ7LL65GV2ATVPRV4FX6SBHM7Z/
>
>
>
>
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> oVirt Code of Conduct: https://www.ovirt.org/community/about/community-
> guidelines/
> List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/
> message/NPIFXQ2XO36A5CJ2PLBJ6AWA7Y6PUB5X/
>
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/52WH6U7QW4RREJYUYUD4277IQDWOTQUH/

[ovirt-users] Re: Gluster problems, cluster performance issues

[Sahina Bose]

On Wed, May 30, 2018 at 10:42 AM, Jim Kusznir  wrote:

> hosted-engine --deploy failed (would not come up on my existing gluster
> storage).  However, I realized no changes were written to my existing
> storage.  So, I went back to trying to get my old engine running.
>
> hosted-engine --vm-status is now taking a very long time (5+minutes) to
> return, and it returns stail information everywhere.  I thought perhaps the
> lockspace is corrupt, so tried to clean that and metadata, but both are
> failing (--cleam-metadata has hung and I can't even ctrl-c out of it).
>
> How can I reinitialize all the lockspace/metadata safely?  There is no
> engine or VMs running currently
>

I think the first thing to make sure is that your storage is up and
running. So can you mount the gluster volumes and able to access the
contents there?
Please provide the gluster volume info and gluster volume status of the
volumes that you're using.



> --Jim
>
> On Tue, May 29, 2018 at 9:33 PM, Jim Kusznir  wrote:
>
>> Well, things went from bad to very, very bad
>>
>> It appears that during one of the 2 minute lockups, the fencing agents
>> decided that another node in the cluster was down.  As a result, 2 of the 3
>> nodes were simultaneously reset with fencing agent reboot.  After the nodes
>> came back up, the engine would not start.  All running VMs (including VMs
>> on the 3rd node that was not rebooted) crashed.
>>
>> I've now been working for about 3 hours trying to get the engine to come
>> up.  I don't know why it won't start.  hosted-engine --vm-start says its
>> starting, but it doesn't start (virsh doesn't show any VMs running).  I'm
>> currently running --deploy, as I had run out of options for anything else I
>> can come up with.  I hope this will allow me to re-import all my existing
>> VMs and allow me to start them back up after everything comes back up.
>>
>> I do have an unverified geo-rep backup; I don't know if it is a good
>> backup (there were several prior messages to this list, but I didn't get
>> replies to my questions.  It was running in what I believe to be "strange",
>> and the data directories are larger than their source).
>>
>> I'll see if my --deploy works, and if not, I'll be back with another
>> message/help request.
>>
>> When the dust settles and I'm at least minimally functional again, I
>> really want to understand why all these technologies designed to offer
>> redundancy conspired to reduce uptime and create failures where there
>> weren't any otherwise.  I thought with hosted engine, 3 ovirt servers and
>> glusterfs with minimum replica 2+arb or replica 3 should have offered
>> strong resilience against server failure or disk failure, and should have
>> prevented / recovered from data corruption.  Instead, all of the above
>> happened (once I get my cluster back up, I still have to try and recover my
>> webserver VM, which won't boot due to XFS corrupt journal issues created
>> during the gluster crashes).  I think a lot of these issues were rooted
>> from the upgrade from 4.1 to 4.2.
>>
>> --Jim
>>
>> On Tue, May 29, 2018 at 6:25 PM, Jim Kusznir  wrote:
>>
>>> I also finally found the following in my system log on one server:
>>>
>>> [10679.524491] INFO: task glusterclogro:14933 blocked for more than 120
>>> seconds.
>>> [10679.525826] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
>>> disables this message.
>>> [10679.527144] glusterclogro   D 97209832bf40 0 14933  1
>>> 0x0080
>>> [10679.527150] Call Trace:
>>> [10679.527161]  [] schedule+0x29/0x70
>>> [10679.527218]  [] _xfs_log_force_lsn+0x2e8/0x340 [xfs]
>>> [10679.527225]  [] ? wake_up_state+0x20/0x20
>>> [10679.527254]  [] xfs_file_fsync+0x107/0x1e0 [xfs]
>>> [10679.527260]  [] do_fsync+0x67/0xb0
>>> [10679.527268]  [] ? system_call_after_swapgs+0xbc/
>>> 0x160
>>> [10679.527271]  [] SyS_fsync+0x10/0x20
>>> [10679.527275]  [] system_call_fastpath+0x1c/0x21
>>> [10679.527279]  [] ? system_call_after_swapgs+0xc8/
>>> 0x160
>>> [10679.527283] INFO: task glusterposixfsy:14941 blocked for more than
>>> 120 seconds.
>>> [10679.528608] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
>>> disables this message.
>>> [10679.529956] glusterposixfsy D 972495f84f10 0 14941  1
>>> 0x0080
>>> [10679.529961] Call Trace:
>>> [10679.529966]  [] schedule+0x29/0x70
>>> [10679.530003]  [] _xfs_log_force_lsn+0x2e8/0x340 [xfs]
>>> [10679.530008]  [] ? wake_up_state+0x20/0x20
>>> [10679.530038]  [] xfs_file_fsync+0x107/0x1e0 [xfs]
>>> [10679.530042]  [] do_fsync+0x67/0xb0
>>> [10679.530046]  [] ? system_call_after_swapgs+0xbc/
>>> 0x160
>>> [10679.530050]  [] SyS_fdatasync+0x13/0x20
>>> [10679.530054]  [] system_call_fastpath+0x1c/0x21
>>> [10679.530058]  [] ? system_call_after_swapgs+0xc8/
>>> 0x160
>>> [10679.530062] INFO: task glusteriotwr13:15486 blocked for more than 120
>>> seconds.
>>> [10679.531805] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
>>> disables this message.
>>> [10679.533732] 

[ovirt-users] Simple API call to start VM

[Kirin van der Veer]

Hi oVirt users,
I have (what I hope) is a simple problem.
I want to make an https request to start a VM via the oVirt REST API.
Here is the command that I think should work:
curl --user "admin:SECRETPASSWORD" --request POST --header "Content-Type:
application/xml" --header "Accept: application/xml" --data ''
https://ovirtengine.localnet:443/api/vms/69c47a91-bbv1-4eda-b71d-7bddf82ee8ab/start

However I get a 404 in response (see below):


404 Not Found

Not Found
The requested URL /api/vms/60c47a91-bca1-4eda-b71d-7bddf82ee8ab/start
was not found on this server.


Where have I made a mistake here?

-- 




*IMPORTANT
NOTE. *If you are
NOT AN AUTHORISED RECIPIENT of this 
e-mail, please contact Planet Innovation Pty
Ltd by return e-mail or by 
telephone on +613 9945 7510.  In this case, you
should not read, print, 
re-transmit, store or act in reliance on this e-mail or
any attachments, 
and should destroy all copies of them.  This e-mail and
any attachments are 
confidential and may contain legally privileged information
and/or 
copyright material of Planet Innovation Pty Ltd or third parties. 
You 
should only re-transmit, distribute or commercialise the material if you

are authorised to do so.  Although we use virus scanning software, we deny

all liability for viruses or alike in any message or attachment. This

notice should not be removed.

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

[ovirt-users] Re: Gluster quorum

[Demeter Tibor]

Dear Jim, 

Thank you for your help, now it's working again!!! :) 
Have a nice day! 

Regards, 

Tibor 

- 2018. máj.. 29., 23:57, Jim Kusznir  írta: 

> I had the same problem when I upgraded to 4.2. I found that if I went to the
> brick in the UI and selected it, there was a "start" button in the upper-right
> of the gui. clicking that resolved this problem a few minutes later.
> I had to repeat for each volume that showed a brick down for which that brick
> was not actually down.

> --Jim

> On Tue, May 29, 2018 at 6:34 AM, Demeter Tibor < [ mailto:tdeme...@itsmart.hu 
> |
> tdeme...@itsmart.hu ] > wrote:

>> Hi,

>> I've successfully upgraded my hosts and I could raise the cluster level to 
>> 4.2.
>> Everything seems fine, but the monitoring problem does not resolved. My 
>> bricks
>> on first node are shown down (red) , but the glusterfs working fine (I 
>> verified
>> in terminal).

>> I've attached my engine.log.

>> Thanks in advance,

>> R,
>> Tibor

>> - 2018. máj.. 28., 14:59, Demeter Tibor < [ mailto:tdeme...@itsmart.hu |
>> tdeme...@itsmart.hu ] > írta:

>>> Hi,
>>> Ok I will try it.

>>> In this case, is it possible to remove and re-add a host that member of HA
>>> gluster ? This is an another task, but I need to separate my gluster network
>>> from my ovirtmgmt network.
>>> What is the recommended way for do this?

>>> It is not important now, but I need to do in future.

>>> I will attach my engine.log after upgrade my host.

>>> Thanks,
>>> Regards.

>>> Tibor

>>> - 2018. máj.. 28., 14:44, Sahina Bose < [ mailto:sab...@redhat.com |
>>> sab...@redhat.com ] > írta:

 On Mon, May 28, 2018 at 4:47 PM, Demeter Tibor < [ 
 mailto:tdeme...@itsmart.hu |
 tdeme...@itsmart.hu ] > wrote:

> Dear Sahina,

> Yes, exactly. I can check that check box, but I don't know how is safe 
> that. Is
> it safe?

 It is safe - if you can ensure that only one host is put into maintenance 
 at a
 time.

> I want to upgrade all of my host. If it will done, then the monitoring 
> will work
> perfectly?

 If it does not please provide engine.log again once you've upgraded all the
 hosts.

> Thanks.
> R.

> Tibor

> - 2018. máj.. 28., 10:09, Sahina Bose < [ mailto:sab...@redhat.com |
> sab...@redhat.com ] > írta:

>> On Mon, May 28, 2018 at 1:06 PM, Demeter Tibor < [ 
>> mailto:tdeme...@itsmart.hu |
>> tdeme...@itsmart.hu ] > wrote:

>>> Hi,

>>> Somebody could answer to my question please?
>>> It is very important for me, I could no finish my upgrade process (from 
>>> 4.1 to
>>> 4.2) since 9th May!

>> Can you explain how the upgrade process is blocked due to the monitoring?
>> If it's because you cannot move the host to maintenance, can you try 
>> with the
>> option "Ignore quorum checks" enabled?

>>> Meanwhile - I don't know why - one of my two gluster volume seems UP 
>>> (green) on
>>> the GUI. So, now only one is down.

>>> I need help. What can I do?

>>> Thanks in advance,

>>> Regards,

>>> Tibor

>>> - 2018. máj.. 23., 21:09, Demeter Tibor < [ 
>>> mailto:tdeme...@itsmart.hu |
>>> tdeme...@itsmart.hu ] > írta:

 Hi,

 I've updated again to the latest version, but there are no changes. 
 All of
 bricks on my first node are down in the GUI (in console are ok)
 An Interesting thing, the "Self-Heal info" column show "OK" for all 
 hosts and
 all bricks, but "Space used" column is zero for all hosts/bricks.
 Can I force remove and re-add my host to cluster awhile it is a 
 gluster member?
 Is it safe ?
 What can I do?

 I haven't update other hosts while gluster not working fine, or the 
 GUI does not
 detect . So my other hosts is remained 4.1 yet :(

 Thanks in advance,

 Regards

 Tibor

 - 2018. máj.. 23., 14:45, Denis Chapligin < [ 
 mailto:dchap...@redhat.com |
 dchap...@redhat.com ] > írta:

> Hello!

> On Tue, May 22, 2018 at 11:10 AM, Demeter Tibor < [ 
> mailto:tdeme...@itsmart.hu |
> tdeme...@itsmart.hu ] > wrote:

>> Is there any changes with this bug?

>> Still I haven't finish my upgrade process that i've started on 9th 
>> may:(

>> Please help me if you can.

> Looks like all required patches are already merged, so could you 
> please to
> update your engine again to the latest night build?

 ___
 Users mailing list -- [ mailto:users@ovirt.org | users@ovirt.org ]
 To unsubscribe send an email to [ mailto:users-le...@ovirt.org |
 users-le...@ovirt.org ]

>>> ___
>>> Users mailing list -- [ mailto:users@ovirt.org | users@ovirt.org ]

[ovirt-users] Re: Gluster problems, cluster performance issues

[Jim Kusznir]

hosted-engine --deploy failed (would not come up on my existing gluster
storage).  However, I realized no changes were written to my existing
storage.  So, I went back to trying to get my old engine running.

hosted-engine --vm-status is now taking a very long time (5+minutes) to
return, and it returns stail information everywhere.  I thought perhaps the
lockspace is corrupt, so tried to clean that and metadata, but both are
failing (--cleam-metadata has hung and I can't even ctrl-c out of it).

How can I reinitialize all the lockspace/metadata safely?  There is no
engine or VMs running currently

--Jim

On Tue, May 29, 2018 at 9:33 PM, Jim Kusznir  wrote:

> Well, things went from bad to very, very bad
>
> It appears that during one of the 2 minute lockups, the fencing agents
> decided that another node in the cluster was down.  As a result, 2 of the 3
> nodes were simultaneously reset with fencing agent reboot.  After the nodes
> came back up, the engine would not start.  All running VMs (including VMs
> on the 3rd node that was not rebooted) crashed.
>
> I've now been working for about 3 hours trying to get the engine to come
> up.  I don't know why it won't start.  hosted-engine --vm-start says its
> starting, but it doesn't start (virsh doesn't show any VMs running).  I'm
> currently running --deploy, as I had run out of options for anything else I
> can come up with.  I hope this will allow me to re-import all my existing
> VMs and allow me to start them back up after everything comes back up.
>
> I do have an unverified geo-rep backup; I don't know if it is a good
> backup (there were several prior messages to this list, but I didn't get
> replies to my questions.  It was running in what I believe to be "strange",
> and the data directories are larger than their source).
>
> I'll see if my --deploy works, and if not, I'll be back with another
> message/help request.
>
> When the dust settles and I'm at least minimally functional again, I
> really want to understand why all these technologies designed to offer
> redundancy conspired to reduce uptime and create failures where there
> weren't any otherwise.  I thought with hosted engine, 3 ovirt servers and
> glusterfs with minimum replica 2+arb or replica 3 should have offered
> strong resilience against server failure or disk failure, and should have
> prevented / recovered from data corruption.  Instead, all of the above
> happened (once I get my cluster back up, I still have to try and recover my
> webserver VM, which won't boot due to XFS corrupt journal issues created
> during the gluster crashes).  I think a lot of these issues were rooted
> from the upgrade from 4.1 to 4.2.
>
> --Jim
>
> On Tue, May 29, 2018 at 6:25 PM, Jim Kusznir  wrote:
>
>> I also finally found the following in my system log on one server:
>>
>> [10679.524491] INFO: task glusterclogro:14933 blocked for more than 120
>> seconds.
>> [10679.525826] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
>> disables this message.
>> [10679.527144] glusterclogro   D 97209832bf40 0 14933  1
>> 0x0080
>> [10679.527150] Call Trace:
>> [10679.527161]  [] schedule+0x29/0x70
>> [10679.527218]  [] _xfs_log_force_lsn+0x2e8/0x340 [xfs]
>> [10679.527225]  [] ? wake_up_state+0x20/0x20
>> [10679.527254]  [] xfs_file_fsync+0x107/0x1e0 [xfs]
>> [10679.527260]  [] do_fsync+0x67/0xb0
>> [10679.527268]  [] ? system_call_after_swapgs+0xbc/
>> 0x160
>> [10679.527271]  [] SyS_fsync+0x10/0x20
>> [10679.527275]  [] system_call_fastpath+0x1c/0x21
>> [10679.527279]  [] ? system_call_after_swapgs+0xc8/
>> 0x160
>> [10679.527283] INFO: task glusterposixfsy:14941 blocked for more than 120
>> seconds.
>> [10679.528608] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
>> disables this message.
>> [10679.529956] glusterposixfsy D 972495f84f10 0 14941  1
>> 0x0080
>> [10679.529961] Call Trace:
>> [10679.529966]  [] schedule+0x29/0x70
>> [10679.530003]  [] _xfs_log_force_lsn+0x2e8/0x340 [xfs]
>> [10679.530008]  [] ? wake_up_state+0x20/0x20
>> [10679.530038]  [] xfs_file_fsync+0x107/0x1e0 [xfs]
>> [10679.530042]  [] do_fsync+0x67/0xb0
>> [10679.530046]  [] ? system_call_after_swapgs+0xbc/
>> 0x160
>> [10679.530050]  [] SyS_fdatasync+0x13/0x20
>> [10679.530054]  [] system_call_fastpath+0x1c/0x21
>> [10679.530058]  [] ? system_call_after_swapgs+0xc8/
>> 0x160
>> [10679.530062] INFO: task glusteriotwr13:15486 blocked for more than 120
>> seconds.
>> [10679.531805] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
>> disables this message.
>> [10679.533732] glusteriotwr13  D 9720a83f 0 15486  1
>> 0x0080
>> [10679.533738] Call Trace:
>> [10679.533747]  [] schedule+0x29/0x70
>> [10679.533799]  [] _xfs_log_force_lsn+0x2e8/0x340 [xfs]
>> [10679.533806]  [] ? wake_up_state+0x20/0x20
>> [10679.533846]  [] xfs_file_fsync+0x107/0x1e0 [xfs]
>> [10679.533852]  [] do_fsync+0x67/0xb0
>> [10679.533858]  [] ? system_call_after_swapgs+0xbc/
>> 0x160
>> [10679.533863]  []