Re: [one-users] Images problem

Hi, though I haven't tried any of the following approaches... it may still help you:) There's a component called "scp-wave" [1] in the ONE ecosystem catalogue that may speed up image transfers. You may implement a special TM MAD that supports read-write snapshots when cloning images, for inst

Re: [one-users] In Onemc LCM state is unknown

Hi, it's just a tipp: you may try restarting your vm-s eg: onevm restart 44 This worked for us when powering of the vm from within the vm itself. Your situation is not the same, but similar... Hope it helps, Cheers Gyula Feladó: users-boun...@lists.opennebu

Re: [one-users] vm State Issue

Hi, to my undertsanding ONE shutdown uses virsh shutdown for KVM VMM [1] . However virsh shutdown is not guaranteed to succeed. As the virsh man [2] says: shutdown domain-id Gracefully shuts down a domain. This coordinates with the domain OS to perform graceful shutdown, so there is no guarantee

Re: [one-users] integrating cgroup into OpenNebula-KVM?

ldve: 2010. július 13. 19:28 Címzett: Csom Gyula Másolatot kap: opennebula user list Tárgy: Re: [one-users] integrating cgroup into OpenNebula-KVM? Thank you very much Gyula. I am very interested in learning your solutions. So please post it. Curious to know, what cgroups subsystems are you using.

Re: [one-users] integrating cgroup into OpenNebula-KVM?

Hi, regarding ONE plans I have no clue:) Otherwise in our system (currently under development) we are using cgroups also (especially we are using it in order to guarantee CPU performance which is required for vms like web application servers or kinda). We are using cgroups in the following way:

Re: [one-users] hooks on migration

Hi, I've ran through the codebase and couldn't understand the situtation:) 1. When a live migrate succeedes the VMM Driver [1] seems to call the LCM deploy_success_action() [2] method which in turn sets the VM's lcm state to RUNNING. vm->set_state(VirtualMachine::RUNNING); vmpoo

Re: [one-users] Image upload within the core

Thanks for the explanations! Cheers, Gyula Feladó: tinov...@gmail.com [tinov...@gmail.com] ; meghatalmazó: Tino Vazquez [tin...@fdi.ucm.es] Küldve: 2010. június 30. 15:14 Címzett: Csom Gyula Másolatot kap: desha...@gmail.com; users@lists.opennebula.org

Re: [one-users] Image upload within the core

Cheers, Gyula Feladó: tinov...@gmail.com [tinov...@gmail.com] ; meghatalmazó: Tino Vazquez [tin...@fdi.ucm.es] Küldve: 2010. június 24. 16:13 Címzett: Csom Gyula Másolatot kap: desha...@gmail.com; users@lists.opennebula.org Tárgy: Re: [one-users] Image upload within the core

Re: [one-users] onehost problem with kvm

...@gmail.com] Küldve: 2010. június 24. 15:06 Címzett: Csom Gyula Másolatot kap: Andrea Turli; users@lists.opennebula.org Tárgy: Re: [one-users] onehost problem with kvm Hello, I made the same mistake. That path in the git repository is for the development version, the foundation for 1.6, so it is normal

Re: [one-users] Image upload within the core

sourceforge.net/ Feladó: Todd Deshane [desha...@gmail.com] Küldve: 2010. június 23. 23:53 Címzett: Csom Gyula Másolatot kap: users@lists.opennebula.org Tárgy: Re: [one-users] Image upload within the core Hi Gyula, I can't answer the roadmap question, but just to

[one-users] Image upload within the core

Hi! Do you have plans to support image uploads? Is it on your 1.6 roadmap? I ask this in order to coordinate our (extension) development with your roadmap. Some background: Currently we are in the procces to specify our golden image management service, eg: what features to provide exactly ?

Re: [one-users] onehost problem with kvm

Hi, We met a similar problem and it turned out that the IM MAD responsible for KVM-specific monitoring is kvm.rb. Unfotunately the script found in the ONE v.1.4 download was not in synch with

Re: [one-users] Cannot suspend or migrate/livemigrate a VM

Hi Daniele, we are just testing live migration as well, with one of my colleagues. So far we have discovered the following that might help you: The built in ONE KVM driver [1] uses ssh libvirt transport [2], that is ONE calls virsh by passing a qemu+ssh URI, something like this: virsh -c qemu:/