Re: [ovirt-users] NFS IO timeout configuration

[Yaniv Kaul]

On Tue, Jan 12, 2016 at 10:45 PM, Markus Stockhausen <
stockhau...@collogia.de> wrote:

> >> Von: Yaniv Kaul [yk...@redhat.com]
> >> Gesendet: Dienstag, 12. Januar 2016 13:15
> >> An: Markus Stockhausen
> >> Cc: users@ovirt.org; Mike Hildebrandt
> >> Betreff: Re: [ovirt-users] NFS IO timeout configuration
> >>
> >> On Tue, Jan 12, 2016 at 9:32 AM, Markus Stockhausen
> stockhau...@collogia.de> wrote:
> >> Hi there,
> >>
> >> we got a nasty situation yesterday in our OVirt 3.5.6 environment.
> >> We ran a LSM that failed during the cleanup operation. To be precise
> >> when the process deleted an image on the source NFS storage.
> >
> > Can you share with us your NFS server details?
> >Is the NFS connection healthy (can be seen with nfsstat)
> >Generally, delete on NFS should be a pretty quick operation.
> > Y.
>
> Hi Yaniv,
>
> we usually have no problems with our NFS server. From our observations we
> only have issues when deleting files with many extents. This applies to all
> OVirt images files. Several of them have more than 50.000 extents, a few
> even more than 300.000.
>
> > xfs_bmap 1cb5906f-65d8-4174-99b1-74f5b3cbc537
> ...
> 52976: [629122144..629130335]: 10986198592..10986206783
> 52977: [629130336..629130343]: 10986403456..10986403463
> 52978: [629130344..629138535]: 10986206792..10986214983
> 52979: [629138536..629138543]: 10986411656..10986411663
> 52980: [629138544..629145471]: 10986214992..10986221919
> 52981: [629145472..629145575]: 10809903560..10809903663
> 52982: [629145576..629145599]: 10737615056..10737615079
>
> Our XFS is mounted with:
>
> /dev/mapper/vg00-lvdata on /var/nas4 type xfs
> (rw,noatime,nodiratime,allocsize=16m)
>
> Why we use allocsize=16M? We once started with allocize=512MB. This
> led to sparse files that did not save much bytes. Because a single byte
> written
> resulted in a 512MB allocation. Thin allocation of these files resulted in
> long runtimes
> for formatting disks inside the VMS. So we reduced to 16MB as a balanced
> config
>
> This works quite well but not for remove operations.
>
> Better ideas?
>

Sounds like an XFS issue more than NFS.
I've consulted with one of our XFS gurus - here's his reply:

For vm image files, users should set up extent size hints to define
> the minimum extent allocation size in a file - allocsize does
> nothing for random writes into sparse files. I typically use a hint
> of 1MB for all my vm images`
>

Y.


>
> Markus
>
>
>
>
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] API Importing a VM from an export domain fails

[Juan Hernández]

On 01/12/2016 08:44 PM, Tim Bielawa wrote:
> Hello virt folks,
> 
> Background:
> 
> I'm using the REST API to import a VM from an attached export domain.
> The VM was imported using the virt-v2v tool. I've tried this with cURL
> and with the python SDK, both yield the same error message.
> 
> RHEVM Version: 3.5.6.0-1
> Python SDK Version: 3.5.6.0-1
> 
> According to the documentation, importing should follow this syntax:
> 
>> POST
> /ovirt-engine/api/storagedomains/{storagedomain:id}/vms/{vm:id}/import
> 
> With a small  body attached. In theory (by the documentation and
> bug tracker [1]) either of these XML documents (both in the same paste)
> should work:
> 
> http://fpaste.org/309944/52627148/
> 
> However, this fails with the following error message (full response in [2])
> 
>> Cannot import VM. Storage Domain type not specified.
> 
> 
> Steps to reproduce:
> 
> 1. Import a VM into an export storage domain
> 2. Create an XML document with an action like this (filling in the
> correct values for the ID variables)
> 
> 
>   
>   
> export
>   
>   True
>   
> IMPORTED_VM
>   
> 
> 
> 
> 3. POST to the import location (again, substitute the correct ID
> variables in the location)
> 
> /ovirt-engine/api/storagedomains//vms//import
> 
> 
> 
> Where is this storage domain type supposed to be defined, if not inside
> of the storage_domain element as demonstrated in the documentation?
> 
> I would appreciate any advice you can offer or pointers to useful
> resources/documentation.
> 
> Thanks!
> 
> 
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1147011#c13
> [2] http://fpaste.org/309949/14526274/
> 
> -- 
> Tim Bielawa
> 1BA0 4FAB 4C13 FBA0 A036  4958 AD05 E75E 0333 AE37
> 

The bug that you are referring to (bug 1147011) isn't fixed in version
3.5, and there are no plans to fix it, as far as I know. It will be
fixed on only in 3.6. This means that you have to apply the workaround
that Sven Kieske mentions in the description of the bug. So the XML
document to send should look like this:

  


true

  TBIELAWA_IMPORTED_VM

  
  
true
  


  

With the Python SDK should be something like this:

  # Find the target cluster and storage domain:
  target_cluster_id = api.clusters.get(name="mycluster").get_id()
  target_sd_id = api.storagedomains.get(name="mydata").get_id()

  # Find the export storage domain:
  export_sd = api.storagedomains.get(name="myexport")

  # Find the VM:
  vm = export_sd.vms.get(name="myvm")

  # Import the VM:
  vm.import_vm(
  params.Action(
  cluster=params.Cluster(id=target_cluster_id),
  storage_domain=params.StorageDomain(id=target_sd_id),
  clone=True,
  vm=params.VM(
  name="TBIELAWA_IMPORTED_VM",
  snapshots=params.Snapshots(
  collapse_snapshots=True
  )
  )
  )
  )

-- 
Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta
3ºD, 28016 Madrid, Spain
Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 - Red Hat S.L.
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

[ovirt-users] Howto Remove Direct LUNs from ovirt hosts?

[gflwqs gflwqs]

Hi list,
I have a scenario where i want to clone production data to developer vm:s:

1. Create a snapshot from a direct LUN from a "production" vm in a ISCSI
SAN from which i take snapshots (built in functionality in the disk array.)
2. Take the snapshot and attach it as a direct LUN in a "developer" vm in
ovirt.
3. Mount it and let the developers work with the data.
4. After some time the developer says they want to refresh the data.
5. Unmont the disk and deattach it from the "developer" vm.
6. Remove it from multipath and remove the iscsi sessions.
7. Repeat all previous steps when developer needs "fresh" data.

I have succeeded with most of the steps above using the ovirt API.
However step 6 is not done automatically when i remove the direct LUN from
ovirt?
If i don't do this step manually i end up with a syslog with error messages
from multipath and stale iscsi session which potentially can make ovirt
storage fail.

Here is my questions:

Does anybod know:

- Why is:nt there an API and a button in webui to remove the multipath maps
and iscsi sessions?

- Does anybody here has a suggestion of how to do step 6 from a script? (a
hook maybe?)

Thanks!
/Christian
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] API Importing a VM from an export domain fails

[Tim Bielawa]

Beautiful!!

Oh man, thanks so much. I never would have figured that out on my own.

On Wed, Jan 13, 2016 at 12:28 PM, Juan Hernández 
wrote:

> On 01/13/2016 05:54 PM, Tim Bielawa wrote:
> >
> > On Wed, Jan 13, 2016 at 5:01 AM, Juan Hernández  > > wrote:
> >
> > On 01/12/2016 08:44 PM, Tim Bielawa wrote:
> > > Hello virt folks,
> > >
> > > Background:
> > >
> > > I'm using the REST API to import a VM from an attached export
> domain.
> > > The VM was imported using the virt-v2v tool. I've tried this with
> cURL
> > > and with the python SDK, both yield the same error message.
> > >
> > > RHEVM Version: 3.5.6.0-1
> > > Python SDK Version: 3.5.6.0-1
> > >
> > > According to the documentation, importing should follow this
> syntax:
> > >
> > >> POST
> > >
> /ovirt-engine/api/storagedomains/{storagedomain:id}/vms/{vm:id}/import
> > >
> > > With a small  body attached. In theory (by the
> > documentation and
> > > bug tracker [1]) either of these XML documents (both in the same
> > paste)
> > > should work:
> > >
> > > http://fpaste.org/309944/52627148/
> > >
> > > However, this fails with the following error message (full
> > response in [2])
> > >
> > >> Cannot import VM. Storage Domain type not specified.
> > >
> > >
> > > Steps to reproduce:
> > >
> > > 1. Import a VM into an export storage domain
> > > 2. Create an XML document with an action like this (filling in the
> > > correct values for the ID variables)
> > >
> > > 
> > >   
> > >   
> > > export
> > >   
> > >   True
> > >   
> > > IMPORTED_VM
> > >   
> > > 
> > >
> > >
> > > 3. POST to the import location (again, substitute the correct ID
> > > variables in the location)
> > >
> > >
> >
> /ovirt-engine/api/storagedomains//vms//import
> > >
> > >
> > >
> > > Where is this storage domain type supposed to be defined, if not
> > inside
> > > of the storage_domain element as demonstrated in the documentation?
> > >
> > > I would appreciate any advice you can offer or pointers to useful
> > > resources/documentation.
> > >
> > > Thanks!
> > >
> > >
> > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1147011#c13
> > > [2] http://fpaste.org/309949/14526274/
> > >
> > > --
> > > Tim Bielawa
> > > 1BA0 4FAB 4C13 FBA0 A036  4958 AD05 E75E 0333 AE37
> > >
> >
> > The bug that you are referring to (bug 1147011) isn't fixed in
> version
> > 3.5, and there are no plans to fix it, as far as I know. It will be
> > fixed on only in 3.6. This means that you have to apply the
> workaround
> > that Sven Kieske mentions in the description of the bug. So the XML
> > document to send should look like this:
> >
> >   
> > 
> > 
> > true
> > 
> >   TBIELAWA_IMPORTED_VM
> >
> >   
> >   
> > true
> >   
> >
> > 
> >   
> >
> > With the Python SDK should be something like this:
> >
> >   # Find the target cluster and storage domain:
> >   target_cluster_id = api.clusters.get(name="mycluster").get_id()
> >   target_sd_id = api.storagedomains.get(name="mydata").get_id()
> >
> >   # Find the export storage domain:
> >   export_sd = api.storagedomains.get(name="myexport")
> >
> >   # Find the VM:
> >   vm = export_sd.vms.get(name="myvm")
> >
> >   # Import the VM:
> >   vm.import_vm(
> >   params.Action(
> >   cluster=params.Cluster(id=target_cluster_id),
> >   storage_domain=params.StorageDomain(id=target_sd_id),
> >   clone=True,
> >   vm=params.VM(
> >   name="TBIELAWA_IMPORTED_VM",
> >   snapshots=params.Snapshots(
> >   collapse_snapshots=True
> >   )
> >   )
> >   )
> >   )
> >
> > --
> > Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta
> > 3ºD, 28016 Madrid, Spain
> > Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 - Red Hat
> > S.L.
> >
> >
> >
> > Thanks for the tips Juan, I appreciate the response.
> >
> > I didn't understand how that work-around was supposed to work the first
> > time I read that in the BZ, thanks for clarifying with those examples.
> >
> > Unfortunately though, I've integrated what you offered into my script
> > and am still running into walls. I found the ParseHelper.toXml function
> > and used that to debug what the params.Action is evaluating to before
> > calling the import_vm() method on the target import VM:
> >
> >> 
> >> 
> >> 
> >> 
> >> vm.example.com 

Re: [ovirt-users] Blog on Hyperconverged Infrastructure using oVirt and Gluster

[Ramesh Nachimuthu]

Sorry, There is a mistake in the link. Use 
http://blogs-ramesh.blogspot.in/2016/01/ovirt-and-gluster-hyperconvergence.html


Regards,
Ramesh

On 01/12/2016 05:10 PM, Ramesh Nachimuthu wrote:

Hi Folks,

  Have you ever wondered about Hyperconverged Ovirt and Gluster Setup. 
Here is an answer[1]. I wrote a blog explaining how to setup oVirt in 
a hyper-converged mode with Gluster.


[1] 
http://blogs-ramesh.blogspot.in/2016/01/ovirt-and-gluster-hyperconvergence.htm

*
*Regards,
Ramesh


___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] Ovirt supported thinclient appliance

[RK RK]

All,

Any more suggested appliance for this please?

On Wed, Jan 13, 2016 at 12:36 AM, René Koch  wrote:

> Hi,
>
> There aren't too many thin clients out there which support oVirt/RHEV.
>
> I did a few VDI projects with oVirt and RHEV and I can recommend the Igel
> UD5 Thin Client:
> https://www.igel.com/en/products/igel-thin-clients/ud5-series.html
>
> It's not the cheapest one and not the smallest one, but has good
> performance and the management software for these thin clients is great.
>
>
> Regards,
> René
>
> --
> *From: *"RK RK" 
> *To: *"users" 
> *Sent: *Tuesday, January 12, 2016 5:06:13 PM
> *Subject: *[ovirt-users] Ovirt supported thinclient appliance
>
> Hi all,
>
> I am planning to setup oVirt 3.6.1 Virtualization setup for 100 desktop
> users in my software development company.
>
> Anyone please suggest me a good and cost-effective thinclient
> appliance(available in india) to use with my oVirt environment with support
> for SPICE protocol.
>
> --
>
> With Regards,
> RK,
> +91 9840483044
>
> ___
> Users mailing list
> Users@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
>



-- 

With Regards,
RK,
+91 9840483044
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

[ovirt-users] [ANN] oVirt 3.6.2 Second Release Candidate is now available for testing

[Sandro Bonazzola]

The oVirt Project is pleased to announce the availability
of the Second Release Candidate of oVirt 3.6.2 for testing, as of January
13th, 2016

This release is available now for Fedora 22,
Red Hat Enterprise Linux 6.7, CentOS Linux 6.7 (or similar) and
Red Hat Enterprise Linux >= 7.2, CentOS Linux >= 7.2 (or similar).

This release supports Hypervisor Hosts running
Red Hat Enterprise Linux >= 7.2, CentOS Linux >= 7.2 (or similar) and
Fedora 22.
Highly experimental support for Debian 8.2 Jessie has been added too.

This release candidate includes updated packages for:
- ovirt-engine
- ovirt-engine-reports
- ovirt-engine-sdk-python
- ovirt-hosted-engine-setup
- ovirt-hosted-engine-ha
- ovirt-engine-extension-aaa-jdbc
- vdsm
- vdsm-json-rpc

This release of oVirt 3.6.2 includes numerous bug fixes.
See the release notes [1] for an initial list of the new features and bugs
fixed.

Please refer to release notes [1] for Installation / Upgrade instructions.
A new oVirt Live ISO will be soon available [2].

Please note that mirrors[3] may need usually one day before being
synchronized.

* Read more about the oVirt 3.6.2 release highlights:
http://www.ovirt.org/OVirt_3.6.2_Release_Notes
* Get more oVirt Project updates on Twitter: https://twitter.com/ovirt
* Read more about oVirt Project community events:
http://www.ovirt.org/Upcoming_events

[1] http://www.ovirt.org/OVirt_3.6.2_Release_Notes
[2] http://resources.ovirt.org/pub/ovirt-3.6-pre/iso/
[3] http://www.ovirt.org/Repository_mirrors#Current_mirrors


-- 
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] Howto Remove Direct LUNs from ovirt hosts?

[Nir Soffer]

On Wed, Jan 13, 2016 at 3:07 PM, gflwqs gflwqs  wrote:
> Hi list,
> I have a scenario where i want to clone production data to developer vm:s:
>
> 1. Create a snapshot from a direct LUN from a "production" vm in a ISCSI SAN
> from which i take snapshots (built in functionality in the disk array.)
> 2. Take the snapshot and attach it as a direct LUN in a "developer" vm in
> ovirt.
> 3. Mount it and let the developers work with the data.
> 4. After some time the developer says they want to refresh the data.
> 5. Unmont the disk and deattach it from the "developer" vm.
> 6. Remove it from multipath and remove the iscsi sessions.
> 7. Repeat all previous steps when developer needs "fresh" data.
>
> I have succeeded with most of the steps above using the ovirt API.
> However step 6 is not done automatically when i remove the direct LUN from
> ovirt?

We do not manage removal of devices from hosts. Even if you remove the
device manually, we will find and it back when we do iscsi
and fc scan, to find new devices or to resize existing devices.

Devices and sessions are cleaned up when you deactivate a storage
domain, or put the host to maintenance.

> If i don't do this step manually i end up with a syslog with error messages
> from multipath and stale iscsi session which potentially can make ovirt
> storage fail.

Since EL 7.2 and on Fedora 22 or later, you may get error messages
about such stale devices, but it should not effect ovirt storage.
See https://bugzilla.redhat.com/880738

If it still does not work for you, please open a bug about it, describing
the use case.

Nir

>
> Here is my questions:
>
> Does anybod know:
>
> - Why is:nt there an API and a button in webui to remove the multipath maps
> and iscsi sessions?
>
> - Does anybody here has a suggestion of how to do step 6 from a script? (a
> hook maybe?)
>
> Thanks!
> /Christian
>
>
> ___
> Users mailing list
> Users@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
>
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] [ovirt-devel] oVirt goes to FOSDEM 2016 - the full scoop!

[Doron Fediuck]

In the past we had Joop coming with his cool setup.
We used it in the booth to demo live migration.

Does anyone wish to do the same this year?

On Wed, Jan 6, 2016 at 8:36 PM, Mikey Ariel  wrote:

> FOSDEM 2016 is just a few short weeks away, and I'm happy to share with
> you the full details about our community presence at the conference.
>
> ===
> Virt & IaaS Devroom
> ===
>
> Just a reminder that the full schedule is published on the FOSDEM
> website[1], and we have some great presentations from our community members
> for you to learn from.
>
> ===
> oVirt/Foreman Stand
> ===
>
> This year we will share a stand with our friends from the Foreman project.
> Stop by to say hello, grab swag, and enjoy some cool demos!
>
> **STAND VOLUNTEERS WANTED**
>
> If you're attending FOSDEM and would like to help us out, we'd love to
> have you there! This is a great opportunity to chat about oVirt with FOSDEM
> attendees and meet other community members from all over the world.
>
> Special surprise swag is reserved for booth volunteers! Please sign up for
> booth shifts in the etherpad[2] (lines 11-33). One of our core contributors
> will also be at the booth to support and co-pilot each shift.
>
> ===
> Social Event on Saturday
> ===
>
> In previous years, we had informal social gatherings for our community
> members on Saturday evening. These evenings are yet another excellent
> opportunity to meet and chat with the oVirt community outside the hectic
> FOSDEM venue.
>
> This year we'd like to hold an event again if there is enough demand, so
> please write your name/IRCnick/Twitter/G+/email in the etherpad[2] (line 86
> and down) **by January 15**.
>
> If there is enough interest, we will reserve a nice pub in the center of
> Brussels and buy the first round :)
>
> See you in Brussels!
>
> [1] https://fosdem.org/2016/schedule/track/virtualisation_and_iaas/
> [2] http://etherpad.ovirt.org/p/ovirt-fosdem-2016
>
> --
> Mikey Ariel
> Community Lead, oVirt
> www.ovirt.org
>
> "To be is to do" (Socrates)
> "To do is to be" (Jean-Paul Sartre)
> "Do be do be do" (Frank Sinatra)
>
> Mobile: +420-702-131-141
> IRC: mariel / thatdocslady
> Twitter: @ThatDocsLady
> ___
> Devel mailing list
> de...@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>
>
>
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] API Importing a VM from an export domain fails

[Tim Bielawa]

On Wed, Jan 13, 2016 at 5:01 AM, Juan Hernández  wrote:

> On 01/12/2016 08:44 PM, Tim Bielawa wrote:
> > Hello virt folks,
> >
> > Background:
> >
> > I'm using the REST API to import a VM from an attached export domain.
> > The VM was imported using the virt-v2v tool. I've tried this with cURL
> > and with the python SDK, both yield the same error message.
> >
> > RHEVM Version: 3.5.6.0-1
> > Python SDK Version: 3.5.6.0-1
> >
> > According to the documentation, importing should follow this syntax:
> >
> >> POST
> > /ovirt-engine/api/storagedomains/{storagedomain:id}/vms/{vm:id}/import
> >
> > With a small  body attached. In theory (by the documentation and
> > bug tracker [1]) either of these XML documents (both in the same paste)
> > should work:
> >
> > http://fpaste.org/309944/52627148/
> >
> > However, this fails with the following error message (full response in
> [2])
> >
> >> Cannot import VM. Storage Domain type not specified.
> >
> >
> > Steps to reproduce:
> >
> > 1. Import a VM into an export storage domain
> > 2. Create an XML document with an action like this (filling in the
> > correct values for the ID variables)
> >
> > 
> >   
> >   
> > export
> >   
> >   True
> >   
> > IMPORTED_VM
> >   
> > 
> >
> >
> > 3. POST to the import location (again, substitute the correct ID
> > variables in the location)
> >
> >
>  /ovirt-engine/api/storagedomains//vms//import
> >
> >
> >
> > Where is this storage domain type supposed to be defined, if not inside
> > of the storage_domain element as demonstrated in the documentation?
> >
> > I would appreciate any advice you can offer or pointers to useful
> > resources/documentation.
> >
> > Thanks!
> >
> >
> > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1147011#c13
> > [2] http://fpaste.org/309949/14526274/
> >
> > --
> > Tim Bielawa
> > 1BA0 4FAB 4C13 FBA0 A036  4958 AD05 E75E 0333 AE37
> >
>
> The bug that you are referring to (bug 1147011) isn't fixed in version
> 3.5, and there are no plans to fix it, as far as I know. It will be
> fixed on only in 3.6. This means that you have to apply the workaround
> that Sven Kieske mentions in the description of the bug. So the XML
> document to send should look like this:
>
>   
> 
> 
> true
> 
>   TBIELAWA_IMPORTED_VM
>
>   
>   
> true
>   
>
> 
>   
>
> With the Python SDK should be something like this:
>
>   # Find the target cluster and storage domain:
>   target_cluster_id = api.clusters.get(name="mycluster").get_id()
>   target_sd_id = api.storagedomains.get(name="mydata").get_id()
>
>   # Find the export storage domain:
>   export_sd = api.storagedomains.get(name="myexport")
>
>   # Find the VM:
>   vm = export_sd.vms.get(name="myvm")
>
>   # Import the VM:
>   vm.import_vm(
>   params.Action(
>   cluster=params.Cluster(id=target_cluster_id),
>   storage_domain=params.StorageDomain(id=target_sd_id),
>   clone=True,
>   vm=params.VM(
>   name="TBIELAWA_IMPORTED_VM",
>   snapshots=params.Snapshots(
>   collapse_snapshots=True
>   )
>   )
>   )
>   )
>
> --
> Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta
> 3ºD, 28016 Madrid, Spain
> Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 - Red Hat S.L.
>


Thanks for the tips Juan, I appreciate the response.

I didn't understand how that work-around was supposed to work the first
time I read that in the BZ, thanks for clarifying with those examples.

Unfortunately though, I've integrated what you offered into my script and
am still running into walls. I found the ParseHelper.toXml function and
used that to debug what the params.Action is evaluating to before calling
the import_vm() method on the target import VM:

> 
> 
> 
> 
> vm.example.com
> 
> true
> 
> 
 >true
> 

It's basically identical to what you offered in your example. Yet still, I
run into this problem:

Traceback (most recent call last):
>   File "./rhev-test.py", line 300, in 
> result = latest_image.import_vm(import_params)
>   File
> "/usr/lib/python2.7/site-packages/ovirtsdk/infrastructure/brokers.py", line
> 18763, in import_vm
> headers={"Correlation-Id":correlation_id}
>   File
> "/usr/lib/python2.7/site-packages/ovirtsdk/infrastructure/proxy.py", line
> 118, in request
> persistent_auth=self._persistent_auth)
>   File
> "/usr/lib/python2.7/site-packages/ovirtsdk/infrastructure/proxy.py", line
> 146, in __doRequest
> persistent_auth=persistent_auth
>   File "/usr/lib/python2.7/site-packages/ovirtsdk/web/connection.py", line
> 134, in doRequest
> raise RequestError, response
> ovirtsdk.infrastructure.errors.RequestError:
> status: 400
> reason: Bad Request
> detail: Cannot import VM. Storage Domain type not specified.



Just to be absolutely sure about this, I ran some 

Re: [ovirt-users] API Importing a VM from an export domain fails

[Juan Hernández]

On 01/13/2016 05:54 PM, Tim Bielawa wrote:
> 
> On Wed, Jan 13, 2016 at 5:01 AM, Juan Hernández  > wrote:
> 
> On 01/12/2016 08:44 PM, Tim Bielawa wrote:
> > Hello virt folks,
> >
> > Background:
> >
> > I'm using the REST API to import a VM from an attached export domain.
> > The VM was imported using the virt-v2v tool. I've tried this with cURL
> > and with the python SDK, both yield the same error message.
> >
> > RHEVM Version: 3.5.6.0-1
> > Python SDK Version: 3.5.6.0-1
> >
> > According to the documentation, importing should follow this syntax:
> >
> >> POST
> > /ovirt-engine/api/storagedomains/{storagedomain:id}/vms/{vm:id}/import
> >
> > With a small  body attached. In theory (by the
> documentation and
> > bug tracker [1]) either of these XML documents (both in the same
> paste)
> > should work:
> >
> > http://fpaste.org/309944/52627148/
> >
> > However, this fails with the following error message (full
> response in [2])
> >
> >> Cannot import VM. Storage Domain type not specified.
> >
> >
> > Steps to reproduce:
> >
> > 1. Import a VM into an export storage domain
> > 2. Create an XML document with an action like this (filling in the
> > correct values for the ID variables)
> >
> > 
> >   
> >   
> > export
> >   
> >   True
> >   
> > IMPORTED_VM
> >   
> > 
> >
> >
> > 3. POST to the import location (again, substitute the correct ID
> > variables in the location)
> >
> >   
>  /ovirt-engine/api/storagedomains//vms//import
> >
> >
> >
> > Where is this storage domain type supposed to be defined, if not
> inside
> > of the storage_domain element as demonstrated in the documentation?
> >
> > I would appreciate any advice you can offer or pointers to useful
> > resources/documentation.
> >
> > Thanks!
> >
> >
> > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1147011#c13
> > [2] http://fpaste.org/309949/14526274/
> >
> > --
> > Tim Bielawa
> > 1BA0 4FAB 4C13 FBA0 A036  4958 AD05 E75E 0333 AE37
> >
> 
> The bug that you are referring to (bug 1147011) isn't fixed in version
> 3.5, and there are no plans to fix it, as far as I know. It will be
> fixed on only in 3.6. This means that you have to apply the workaround
> that Sven Kieske mentions in the description of the bug. So the XML
> document to send should look like this:
> 
>   
> 
> 
> true
> 
>   TBIELAWA_IMPORTED_VM
> 
>   
>   
> true
>   
> 
> 
>   
> 
> With the Python SDK should be something like this:
> 
>   # Find the target cluster and storage domain:
>   target_cluster_id = api.clusters.get(name="mycluster").get_id()
>   target_sd_id = api.storagedomains.get(name="mydata").get_id()
> 
>   # Find the export storage domain:
>   export_sd = api.storagedomains.get(name="myexport")
> 
>   # Find the VM:
>   vm = export_sd.vms.get(name="myvm")
> 
>   # Import the VM:
>   vm.import_vm(
>   params.Action(
>   cluster=params.Cluster(id=target_cluster_id),
>   storage_domain=params.StorageDomain(id=target_sd_id),
>   clone=True,
>   vm=params.VM(
>   name="TBIELAWA_IMPORTED_VM",
>   snapshots=params.Snapshots(
>   collapse_snapshots=True
>   )
>   )
>   )
>   )
> 
> --
> Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta
> 3ºD, 28016 Madrid, Spain
> Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 - Red Hat
> S.L.
> 
> 
> 
> Thanks for the tips Juan, I appreciate the response.
> 
> I didn't understand how that work-around was supposed to work the first
> time I read that in the BZ, thanks for clarifying with those examples.
> 
> Unfortunately though, I've integrated what you offered into my script
> and am still running into walls. I found the ParseHelper.toXml function
> and used that to debug what the params.Action is evaluating to before
> calling the import_vm() method on the target import VM:
> 
>> 
>> 
>> 
>> 
>> vm.example.com 
>> 
>> true
>> 
>> 
>  >true
>> 
> 
> It's basically identical to what you offered in your example. Yet still,
> I run into this problem:
> 
> Traceback (most recent call last):
>   File "./rhev-test.py", line 300, in 
> result = latest_image.import_vm(import_params)
>   File
> "/usr/lib/python2.7/site-packages/ovirtsdk/infrastructure/brokers.py",
> line 18763, in import_vm
> 

Re: [ovirt-users] [ovirt-devel] oVirt goes to FOSDEM 2016 - the full scoop!

[Joop]

On 13-1-2016 18:02, Doron Fediuck wrote:
> In the past we had Joop coming with his cool setup.
> We used it in the booth to demo live migration.
>
Is that an invitation to come and bring my stuff :-)

> Does anyone wish to do the same this year?
I won't mind if someone else brings some stuff to demo but in case not
I'll if someone else can arrange for a monitor that would be cool.

Regards,

Joop

___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users