- Users - oVirt List Archives

Re: [Users] oVirt or RHEV ?
by Martijn Grendelman 06 Feb '14

06 Feb '14

Martijn Grendelman schreef op 6-2-2014 17:02: > Hi, > > Dan Yasny schreef op 6-2-2014 16:38: >> This is the same question as in RHEL or Fedora IMO: do you want the >> bleeding edge features and lower code stability and reliability, or do >> you want to have techsupport (and that means a real SLA and an >> escalation path up to the engineering, if need be) behind you, stable >> and reliable, well tested code, but less of the advanced features. > > Thank you, this is what I thought. > > It's still a hard decision. If the stability and "testedness" of RHEL is > anything to go by, it's not reassuring at all (although it may be better > than Fedora, I don't know), although I must say that RedHat support is > helpful at times. > > Thanks again, I think I know enough :-) Or not ;-) Would it be possible (and doable) to migrate from oVirt to RHEV? If we start out with oVirt, but after some time we decide that RHEV would be a better fit after all, would it be possible to hook up existing oVirt/VDSM hosts to a RHEV engine, or am I thinking way too simple now? Cheers, Martijn. >> >> >> On Thu, Feb 6, 2014 at 8:06 AM, Martijn Grendelman >> <martijn.grendelman(a)isaac.nl <mailto:martijn.grendelman@isaac.nl>> wrote: >> >> Hi, >> >> This may be the wrong place to ask, but I'm looking for input to form an >> opinion on an "oVirt or RHEV" question within my company. >> >> I have been running oVirt for about 5 months now, and I'm quite >> comfortable with its features and maintenance procedures. We are now >> planning to build a private virtualization cluster for hosting clients' >> applications as well as our own. Some people in the company are >> questioning whether we should buy RHEV, but at this point, I can't see >> the benefits. >> >> Can anyone on this list shed a light on when RHEV might be a better >> choice than oVirt? What are the benefits? The trade-offs? >> >> I am looking for pragmatic, real-world things, not marketing mumbo >> jumbo. That, I can get from redhat.com <http://redhat.com> ;-) >> >> Best regards, >> Martijn. >> _______________________________________________ >> Users mailing list >> Users(a)ovirt.org <mailto:Users@ovirt.org> >> http://lists.ovirt.org/mailman/listinfo/users >> >> > _______________________________________________ > Users mailing list > Users(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/users >

6 6

Re: [Users] oVirt or RHEV ?
by Martijn Grendelman 06 Feb '14

06 Feb '14

Hi, Dan Yasny schreef op 6-2-2014 16:38: > This is the same question as in RHEL or Fedora IMO: do you want the > bleeding edge features and lower code stability and reliability, or do > you want to have techsupport (and that means a real SLA and an > escalation path up to the engineering, if need be) behind you, stable > and reliable, well tested code, but less of the advanced features. Thank you, this is what I thought. It's still a hard decision. If the stability and "testedness" of RHEL is anything to go by, it's not reassuring at all (although it may be better than Fedora, I don't know), although I must say that RedHat support is helpful at times. Thanks again, I think I know enough :-) Best regards, Martijn Grendelman > > > > > On Thu, Feb 6, 2014 at 8:06 AM, Martijn Grendelman > <martijn.grendelman(a)isaac.nl <mailto:martijn.grendelman@isaac.nl>> wrote: > > Hi, > > This may be the wrong place to ask, but I'm looking for input to form an > opinion on an "oVirt or RHEV" question within my company. > > I have been running oVirt for about 5 months now, and I'm quite > comfortable with its features and maintenance procedures. We are now > planning to build a private virtualization cluster for hosting clients' > applications as well as our own. Some people in the company are > questioning whether we should buy RHEV, but at this point, I can't see > the benefits. > > Can anyone on this list shed a light on when RHEV might be a better > choice than oVirt? What are the benefits? The trade-offs? > > I am looking for pragmatic, real-world things, not marketing mumbo > jumbo. That, I can get from redhat.com <http://redhat.com> ;-) > > Best regards, > Martijn. > _______________________________________________ > Users mailing list > Users(a)ovirt.org <mailto:Users@ovirt.org> > http://lists.ovirt.org/mailman/listinfo/users > >

1 0

Re: [Users] Storage server
by Koen Vanoppen 06 Feb '14

06 Feb '14

Thanks. Found the command! For further reference to users: update storageconnection <storageconnectionid> --address <IP-Address> Kind regards, Koen 2014-02-06 Itamar Heim <iheim(a)redhat.com>: > On 02/06/2014 01:48 PM, Koen Vanoppen wrote: > >> I would like to keep the vms... >> I know that there is a command in the CLI "update storageconnection", >> but how do I use this to change only the IP of the storage connection? >> >> Kind regards, >> >> Koen >> On Feb 6, 2014 12:55 PM, "Itamar Heim" <iheim(a)redhat.com >> <mailto:iheim@redhat.com>> wrote: >> >> On 02/06/2014 12:54 PM, Koen Vanoppen wrote: >> >> What if I remove the "old ip" storage domains and import the >> same iscsi >> luns with the new IP, would that work? >> >> >> removing a domain *deletes* all disks/vms, other than that... >> >> (we are working on ability to detach/attach domains post 3.4) >> >> >> Kind Regards >> >> >> 2014-02-06 Koen Vanoppen <vanoppen.koen(a)gmail.com >> <mailto:vanoppen.koen@gmail.com> >> <mailto:vanoppen.koen@gmail.__com >> >> <mailto:vanoppen.koen@gmail.com>>>: >> >> Can I change the storagedomain ip from the ovirt-shell? >> Thanks in advance >> >> >> 2014-02-06 Itamar Heim <iheim(a)redhat.com >> <mailto:iheim@redhat.com> <mailto:iheim@redhat.com >> <mailto:iheim@redhat.com>>>: >> >> On 02/06/2014 12:03 PM, Koen Vanoppen wrote: >> >> Can I change the storagedomain ip from the >> ovirt-shell? >> Thanks in advance >> >> >> please reply to list, thanks >> >> >> >> 2014-02-06 Itamar Heim <iheim(a)redhat.com >> <mailto:iheim@redhat.com> >> <mailto:iheim@redhat.com <mailto:iheim@redhat.com>> >> <mailto:iheim@redhat.com <mailto:iheim@redhat.com> >> <mailto:iheim@redhat.com <mailto:iheim@redhat.com >> >>>>: >> >> >> >> On 02/06/2014 05:16 AM, Koen Vanoppen wrote: >> >> It's not on DNS... The storage server in >> ovirt is >> on IP... So... >> What >> are my options in this case? >> >> >> you would need to 'edit the connection'. since >> 3.3.1 >> this is >> possible via the rest api without hacking the >> db: >> http://www.ovirt.org/Features/______Manage_Storage_Connections >> <http://www.ovirt.org/Features/____Manage_Storage_Connections> >> >> <http://www.ovirt.org/__Features/__Manage_Storage___Connections >> <http://www.ovirt.org/Features/__Manage_Storage_Connections>> >> >> >> >> <http://www.ovirt.org/____Features/Manage_Storage_____Connections< >> http://www.ovirt.org/__Features/Manage_Storage___Connections> >> >> <http://www.ovirt.org/__Features/Manage_Storage___Connections >> <http://www.ovirt.org/Features/Manage_Storage_Connections>>> >> >> Thanx! >> >> Kind regards, >> Koen >> >> On Feb 5, 2014 9:08 AM, "Itamar Heim" >> <iheim(a)redhat.com <mailto:iheim@redhat.com> >> <mailto:iheim@redhat.com <mailto:iheim@redhat.com>> >> <mailto:iheim@redhat.com >> <mailto:iheim@redhat.com> <mailto:iheim@redhat.com >> <mailto:iheim@redhat.com>>> >> <mailto:iheim@redhat.com >> <mailto:iheim@redhat.com> <mailto:iheim@redhat.com >> <mailto:iheim@redhat.com>> >> <mailto:iheim@redhat.com <mailto:iheim@redhat.com> >> <mailto:iheim@redhat.com <mailto:iheim@redhat.com>>>>> wrote: >> >> On 02/04/2014 03:10 PM, Elad Ben >> Aharon wrote: >> >> Actually, the best way to do it >> would be >> to create another >> storage domain and migrate all >> the VMs's >> disks to it >> (you can do >> it while the VMs are running), >> then you >> won't suffer >> from a down >> time. >> >> >> notice this will create a snapshot >> for your >> vms and may >> change them >> from raw to qcow. also, this not >> supported for >> shared disks. >> >> If you don't have the option to >> do so, the >> best way to >> do it >> would be to shut down the VMs, >> put the >> storage domain to >> 'Maintenance' and then perform >> the storage >> server network >> change. When the connection to >> the storage >> is fixed, >> activate >> the domain and resume the VMs >> manually. >> >> >> that's assuming the domain was added >> using dns >> and not ip >> address, >> and that the dns expiration/caching >> on all >> hosts will >> notice the new >> ip address. >> >> >> >> ----- Original Message ----- >> From: "Koen Vanoppen" >> <vanoppen.koen(a)gmail.com >> <mailto:vanoppen.koen@gmail.com> >> <mailto:vanoppen.koen@gmail.__com <mailto:vanoppen.koen@gmail.com >> >> >> <mailto:vanoppen.koen@gmail. >> <mailto:vanoppen.koen@gmail.>____com >> <mailto:vanoppen.koen@gmail.__com >> <mailto:vanoppen.koen@gmail.com>>> >> <mailto:vanoppen.koen@gmail >> <mailto:vanoppen.koen@gmail>. >> <mailto:vanoppen.koen@gmail >> <mailto:vanoppen.koen@gmail>.>______com >> >> <mailto:vanoppen.koen@gmail. >> <mailto:vanoppen.koen@gmail.>____com >> <mailto:vanoppen.koen@gmail.__com >> <mailto:vanoppen.koen@gmail.com>>>>> >> To: "Elad Ben Aharon" >> <ebenahar(a)redhat.com <mailto:ebenahar@redhat.com> >> <mailto:ebenahar@redhat.com >> <mailto:ebenahar@redhat.com>> >> <mailto:ebenahar@redhat.com >> <mailto:ebenahar@redhat.com> >> <mailto:ebenahar@redhat.com >> <mailto:ebenahar@redhat.com>>> >> <mailto:ebenahar@redhat.com >> <mailto:ebenahar@redhat.com> >> <mailto:ebenahar@redhat.com >> <mailto:ebenahar@redhat.com>> >> <mailto:ebenahar@redhat.com >> <mailto:ebenahar@redhat.com> >> <mailto:ebenahar@redhat.com >> <mailto:ebenahar@redhat.com>>>>__>__, users(a)ovirt.org >> >> <mailto:users@ovirt.org> >> <mailto:users@ovirt.org <mailto:users@ovirt.org>> >> <mailto:users@ovirt.org >> <mailto:users@ovirt.org> <mailto:users@ovirt.org >> <mailto:users@ovirt.org>>> >> <mailto:users@ovirt.org >> <mailto:users@ovirt.org> >> <mailto:users@ovirt.org <mailto:users@ovirt.org>> >> <mailto:users@ovirt.org <mailto:users@ovirt.org> >> <mailto:users@ovirt.org <mailto:users@ovirt.org>>>> >> >> >> Sent: Tuesday, February 4, 2014 >> 2:57:57 PM >> Subject: Re: [Users] Storage server >> >> For the moment, nothing is going >> on. The >> change is >> planned on >> Thursday. So, >> correct me if I'm wrong, you say >> that the >> fastest and >> easiest >> way is to >> suspend all the machines, make >> the change >> of the >> storage server, >> rediscover >> the iscsi server and then bring >> the vm's >> back up? >> >> Kind regards, >> Koen >> On Feb 4, 2014 1:47 PM, "Elad Ben >> Aharon" >> <ebenahar(a)redhat.com >> <mailto:ebenahar@redhat.com> <mailto:ebenahar@redhat.com >> <mailto:ebenahar@redhat.com>> >> <mailto:ebenahar@redhat.com >> <mailto:ebenahar@redhat.com> <mailto:ebenahar@redhat.com >> <mailto:ebenahar@redhat.com>>> >> <mailto:ebenahar@redhat.com >> <mailto:ebenahar@redhat.com> >> <mailto:ebenahar@redhat.com >> <mailto:ebenahar@redhat.com>> >> >> <mailto:ebenahar@redhat.com >> <mailto:ebenahar@redhat.com> >> <mailto:ebenahar@redhat.com >> <mailto:ebenahar@redhat.com>>>>__> wrote: >> >> Hi, >> >> I suppose that those VMs are >> now in >> 'Paused' state, >> correct >> me if I'm >> wrong. >> After connectivity with >> storage comes >> back, all VMs >> which >> couldn't detect >> their disks should be resumed >> from >> 'Paused' to 'Up' >> state >> automatically. It >> shouldn't take them a long >> time to >> change their >> state (a few >> minutes). >> >> ----- Original Message ----- >> From: "Koen Vanoppen" >> <vanoppen.koen(a)gmail.com >> <mailto:vanoppen.koen@gmail.com> >> <mailto:vanoppen.koen@gmail.__com <mailto:vanoppen.koen@gmail.com >> >> >> <mailto:vanoppen.koen@gmail. >> <mailto:vanoppen.koen@gmail.>____com >> <mailto:vanoppen.koen@gmail.__com >> <mailto:vanoppen.koen@gmail.com>>> >> <mailto:vanoppen.koen@gmail >> <mailto:vanoppen.koen@gmail>. >> <mailto:vanoppen.koen@gmail >> <mailto:vanoppen.koen@gmail>.>______com >> >> <mailto:vanoppen.koen@gmail. >> <mailto:vanoppen.koen@gmail.>____com >> <mailto:vanoppen.koen@gmail.__com >> <mailto:vanoppen.koen@gmail.com>>>>> >> To: users(a)ovirt.org >> <mailto:users@ovirt.org> >> <mailto:users@ovirt.org <mailto:users@ovirt.org>> >> <mailto:users@ovirt.org <mailto:users@ovirt.org> >> <mailto:users@ovirt.org <mailto:users@ovirt.org>>> >> <mailto:users@ovirt.org >> <mailto:users@ovirt.org> <mailto:users@ovirt.org >> <mailto:users@ovirt.org>> >> <mailto:users@ovirt.org <mailto:users@ovirt.org> >> <mailto:users@ovirt.org <mailto:users@ovirt.org>>>> >> Sent: Tuesday, February 4, >> 2014 2:32:46 PM >> Subject: [Users] Storage server >> >> Dear All, >> >> At work, the network guys >> have come to >> a discovery >> that they >> have made a >> mistake in their network >> configuration... The >> Storage server >> that we use as >> ISCSI target in oVirt, is in >> the wrong >> VLAN, so the >> wrong IP >> address... >> >> What is the best way to make >> sure that >> all of our >> vms (40) >> that are using >> this scsi storage will come >> up again >> after the storage >> server has changed >> his ip? >> What are the best steps to be >> taken...? >> We are using oVirt Engine >> Version: >> 3.3.1-2.el6 >> >> Kind Regards, >> >> Koen >> >> >> >> _______________________________________________________ >> >> Users mailing list >> Users(a)ovirt.org <mailto:Users@ovirt.org> <mailto:Users@ovirt.org >> <mailto:Users@ovirt.org>> >> <mailto:Users@ovirt.org <mailto:Users@ovirt.org> >> <mailto:Users@ovirt.org <mailto:Users@ovirt.org>>> >> <mailto:Users@ovirt.org <mailto:Users@ovirt.org> >> <mailto:Users@ovirt.org <mailto:Users@ovirt.org>> >> <mailto:Users@ovirt.org >> <mailto:Users@ovirt.org> <mailto:Users@ovirt.org >> <mailto:Users@ovirt.org>>>> >> http://lists.ovirt.org/________mailman/listinfo/users >> <http://lists.ovirt.org/______mailman/listinfo/users> >> >> >> <http://lists.ovirt.org/______mailman/listinfo/users >> <http://lists.ovirt.org/____mailman/listinfo/users>> >> >> <http://lists.ovirt.org/______mailman/listinfo/users >> <http://lists.ovirt.org/____mailman/listinfo/users> >> <http://lists.ovirt.org/____mailman/listinfo/users >> <http://lists.ovirt.org/__mailman/listinfo/users>>> >> >> >> <http://lists.ovirt.org/______mailman/listinfo/users >> <http://lists.ovirt.org/____mailman/listinfo/users> >> <http://lists.ovirt.org/____mailman/listinfo/users >> <http://lists.ovirt.org/__mailman/listinfo/users>> >> >> <http://lists.ovirt.org/____mailman/listinfo/users >> <http://lists.ovirt.org/__mailman/listinfo/users> >> <http://lists.ovirt.org/__mailman/listinfo/users >> <http://lists.ovirt.org/mailman/listinfo/users>>>> >> >> >> >> _______________________________________________________ >> >> Users mailing list >> Users(a)ovirt.org <mailto:Users@ovirt.org> <mailto:Users@ovirt.org >> <mailto:Users@ovirt.org>> >> <mailto:Users@ovirt.org <mailto:Users@ovirt.org> >> <mailto:Users@ovirt.org <mailto:Users@ovirt.org>>> >> <mailto:Users@ovirt.org <mailto:Users@ovirt.org> >> <mailto:Users@ovirt.org <mailto:Users@ovirt.org>> >> <mailto:Users@ovirt.org >> <mailto:Users@ovirt.org> <mailto:Users@ovirt.org >> <mailto:Users@ovirt.org>>>> >> http://lists.ovirt.org/________mailman/listinfo/users >> <http://lists.ovirt.org/______mailman/listinfo/users> >> >> >> <http://lists.ovirt.org/______mailman/listinfo/users >> <http://lists.ovirt.org/____mailman/listinfo/users>> >> >> <http://lists.ovirt.org/______mailman/listinfo/users >> <http://lists.ovirt.org/____mailman/listinfo/users> >> <http://lists.ovirt.org/____mailman/listinfo/users >> <http://lists.ovirt.org/__mailman/listinfo/users>>> >> >> >> <http://lists.ovirt.org/______mailman/listinfo/users >> <http://lists.ovirt.org/____mailman/listinfo/users> >> <http://lists.ovirt.org/____mailman/listinfo/users >> <http://lists.ovirt.org/__mailman/listinfo/users>> >> >> <http://lists.ovirt.org/____mailman/listinfo/users >> <http://lists.ovirt.org/__mailman/listinfo/users> >> <http://lists.ovirt.org/__mailman/listinfo/users >> <http://lists.ovirt.org/mailman/listinfo/users>>>> >> >> >> >> >> >> >> >> >> >> _________________________________________________ >> Users mailing list >> Users(a)ovirt.org <mailto:Users@ovirt.org> >> http://lists.ovirt.org/__mailman/listinfo/users >> <http://lists.ovirt.org/mailman/listinfo/users> >> >> >> >> >> _______________________________________________ >> Users mailing list >> Users(a)ovirt.org >> http://lists.ovirt.org/mailman/listinfo/users >> >> > juan replied to that >

2 2

Re: [Users] Storage server
by Koen Vanoppen 06 Feb '14

06 Feb '14

Can I change the storagedomain ip from the ovirt-shell? Thanks in advance 2014-02-06 Itamar Heim <iheim(a)redhat.com>: > On 02/06/2014 12:03 PM, Koen Vanoppen wrote: > >> Can I change the storagedomain ip from the ovirt-shell? >> Thanks in advance >> > > please reply to list, thanks > > >> >> 2014-02-06 Itamar Heim <iheim(a)redhat.com <mailto:iheim@redhat.com>>: >> >> >> On 02/06/2014 05:16 AM, Koen Vanoppen wrote: >> >> It's not on DNS... The storage server in ovirt is on IP... So... >> What >> are my options in this case? >> >> >> you would need to 'edit the connection'. since 3.3.1 this is >> possible via the rest api without hacking the db: >> http://www.ovirt.org/Features/__Manage_Storage_Connections >> >> <http://www.ovirt.org/Features/Manage_Storage_Connections> >> >> Thanx! >> >> Kind regards, >> Koen >> >> On Feb 5, 2014 9:08 AM, "Itamar Heim" <iheim(a)redhat.com >> <mailto:iheim@redhat.com> >> <mailto:iheim@redhat.com <mailto:iheim@redhat.com>>> wrote: >> >> On 02/04/2014 03:10 PM, Elad Ben Aharon wrote: >> >> Actually, the best way to do it would be to create >> another >> storage domain and migrate all the VMs's disks to it >> (you can do >> it while the VMs are running), then you won't suffer >> from a down >> time. >> >> >> notice this will create a snapshot for your vms and may >> change them >> from raw to qcow. also, this not supported for shared disks. >> >> If you don't have the option to do so, the best way to >> do it >> would be to shut down the VMs, put the storage domain to >> 'Maintenance' and then perform the storage server network >> change. When the connection to the storage is fixed, >> activate >> the domain and resume the VMs manually. >> >> >> that's assuming the domain was added using dns and not ip >> address, >> and that the dns expiration/caching on all hosts will >> notice the new >> ip address. >> >> >> >> ----- Original Message ----- >> From: "Koen Vanoppen" <vanoppen.koen(a)gmail.com >> <mailto:vanoppen.koen@gmail.com> >> <mailto:vanoppen.koen@gmail.__com >> <mailto:vanoppen.koen@gmail.com>>> >> To: "Elad Ben Aharon" <ebenahar(a)redhat.com >> <mailto:ebenahar@redhat.com> >> <mailto:ebenahar@redhat.com >> <mailto:ebenahar@redhat.com>>>, users(a)ovirt.org >> <mailto:users@ovirt.org> >> <mailto:users@ovirt.org <mailto:users@ovirt.org>> >> >> Sent: Tuesday, February 4, 2014 2:57:57 PM >> Subject: Re: [Users] Storage server >> >> For the moment, nothing is going on. The change is >> planned on >> Thursday. So, >> correct me if I'm wrong, you say that the fastest and >> easiest >> way is to >> suspend all the machines, make the change of the >> storage server, >> rediscover >> the iscsi server and then bring the vm's back up? >> >> Kind regards, >> Koen >> On Feb 4, 2014 1:47 PM, "Elad Ben Aharon" >> <ebenahar(a)redhat.com <mailto:ebenahar@redhat.com> >> <mailto:ebenahar@redhat.com >> >> <mailto:ebenahar@redhat.com>>> wrote: >> >> Hi, >> >> I suppose that those VMs are now in 'Paused' state, >> correct >> me if I'm >> wrong. >> After connectivity with storage comes back, all VMs >> which >> couldn't detect >> their disks should be resumed from 'Paused' to 'Up' >> state >> automatically. It >> shouldn't take them a long time to change their >> state (a few >> minutes). >> >> ----- Original Message ----- >> From: "Koen Vanoppen" <vanoppen.koen(a)gmail.com >> <mailto:vanoppen.koen@gmail.com> >> <mailto:vanoppen.koen@gmail.__com >> <mailto:vanoppen.koen@gmail.com>>> >> To: users(a)ovirt.org <mailto:users@ovirt.org> >> <mailto:users@ovirt.org <mailto:users@ovirt.org>> >> Sent: Tuesday, February 4, 2014 2:32:46 PM >> Subject: [Users] Storage server >> >> Dear All, >> >> At work, the network guys have come to a discovery >> that they >> have made a >> mistake in their network configuration... The >> Storage server >> that we use as >> ISCSI target in oVirt, is in the wrong VLAN, so the >> wrong IP >> address... >> >> What is the best way to make sure that all of our >> vms (40) >> that are using >> this scsi storage will come up again after the >> storage >> server has changed >> his ip? >> What are the best steps to be taken...? >> We are using oVirt Engine Version: 3.3.1-2.el6 >> >> Kind Regards, >> >> Koen >> >> ___________________________________________________ >> Users mailing list >> Users(a)ovirt.org <mailto:Users@ovirt.org> <mailto:Users@ovirt.org >> <mailto:Users@ovirt.org>> >> http://lists.ovirt.org/____mailman/listinfo/users >> <http://lists.ovirt.org/__mailman/listinfo/users> >> <http://lists.ovirt.org/__mailman/listinfo/users >> <http://lists.ovirt.org/mailman/listinfo/users>> >> >> ___________________________________________________ >> Users mailing list >> Users(a)ovirt.org <mailto:Users@ovirt.org> <mailto:Users@ovirt.org >> <mailto:Users@ovirt.org>> >> http://lists.ovirt.org/____mailman/listinfo/users >> <http://lists.ovirt.org/__mailman/listinfo/users> >> <http://lists.ovirt.org/__mailman/listinfo/users >> <http://lists.ovirt.org/mailman/listinfo/users>> >> >> >> >> >> >

3 5

[Users] Python SDK list vms slow, excessive cpu usage
by Sander Grendelman 06 Feb '14

06 Feb '14

Fetching the list of vms through the API with the python SDK takes several seconds[1] with 100% cpu usage in the python script. When I look at the engine log there is only one (fast) fetch from the API. The rest of the time is spent in the SDK processing a relatively small bit of XML data (only 26 VMs in my environment). This seems an excessive amount of CPU for processing ~6KB of XML. I've included some sample code [2] and output [3]. Attached is the cProfile output for this call and a visualization. [1] ~6,5 seconds on an oVirt VM with 1 vcpu on older hardware, ~3,5 seconds on a fast physical machine with an i5 cpu. [2] Sample code, add your own url/credentials/certificate: #!/usr/bin/python """Get ovirt VM names""" import time from ovirtsdk.api import API from ovirtsdk.xml import params def print_elapsed(logString): elapsed = time.time() - startTime print "%fs %s" % (elapsed, logString) startTime = time.time() print_elapsed("before connect") api = API( url="https://my.engine.url/api", username="user@domain", password="password", ca_file="./ca.crt", ) print_elapsed("after connect") print_elapsed("before fetch list") vmList = api.vms.list() print_elapsed("after fetch list") print_elapsed("before use list") count = 0 for vm in vmList: vmName = vm.get_name() count += 1 print "\t number of VMs %d" % count [3] Example of output: [grendelmans@bungee src]$ /usr/bin/time ./vm_list_test.py 0.000003s before connect 0.338248s after connect 0.338299s before fetch list 6.795967s after fetch list 6.796041s before use list number of VMs 26 6.796181s after use list 7.28user 0.05system 0:07.64elapsed 96%CPU (0avgtext+0avgdata 84624maxresident)k 0inputs+0outputs (0major+5605minor)pagefaults 0swaps [grendelmans@bungee src]$

5 6

Re: [Users] Storage server
by Itamar Heim 06 Feb '14

06 Feb '14

On 02/06/2014 05:16 AM, Koen Vanoppen wrote: > It's not on DNS... The storage server in ovirt is on IP... So... What > are my options in this case? you would need to 'edit the connection'. since 3.3.1 this is possible via the rest api without hacking the db: http://www.ovirt.org/Features/Manage_Storage_Connections > Thanx! > > Kind regards, > Koen > > On Feb 5, 2014 9:08 AM, "Itamar Heim" <iheim(a)redhat.com > <mailto:iheim@redhat.com>> wrote: > > On 02/04/2014 03:10 PM, Elad Ben Aharon wrote: > > Actually, the best way to do it would be to create another > storage domain and migrate all the VMs's disks to it (you can do > it while the VMs are running), then you won't suffer from a down > time. > > > notice this will create a snapshot for your vms and may change them > from raw to qcow. also, this not supported for shared disks. > > If you don't have the option to do so, the best way to do it > would be to shut down the VMs, put the storage domain to > 'Maintenance' and then perform the storage server network > change. When the connection to the storage is fixed, activate > the domain and resume the VMs manually. > > > that's assuming the domain was added using dns and not ip address, > and that the dns expiration/caching on all hosts will notice the new > ip address. > > > > ----- Original Message ----- > From: "Koen Vanoppen" <vanoppen.koen(a)gmail.com > <mailto:vanoppen.koen@gmail.com>> > To: "Elad Ben Aharon" <ebenahar(a)redhat.com > <mailto:ebenahar@redhat.com>>, users(a)ovirt.org > <mailto:users@ovirt.org> > Sent: Tuesday, February 4, 2014 2:57:57 PM > Subject: Re: [Users] Storage server > > For the moment, nothing is going on. The change is planned on > Thursday. So, > correct me if I'm wrong, you say that the fastest and easiest > way is to > suspend all the machines, make the change of the storage server, > rediscover > the iscsi server and then bring the vm's back up? > > Kind regards, > Koen > On Feb 4, 2014 1:47 PM, "Elad Ben Aharon" <ebenahar(a)redhat.com > <mailto:ebenahar@redhat.com>> wrote: > > Hi, > > I suppose that those VMs are now in 'Paused' state, correct > me if I'm > wrong. > After connectivity with storage comes back, all VMs which > couldn't detect > their disks should be resumed from 'Paused' to 'Up' state > automatically. It > shouldn't take them a long time to change their state (a few > minutes). > > ----- Original Message ----- > From: "Koen Vanoppen" <vanoppen.koen(a)gmail.com > <mailto:vanoppen.koen@gmail.com>> > To: users(a)ovirt.org <mailto:users@ovirt.org> > Sent: Tuesday, February 4, 2014 2:32:46 PM > Subject: [Users] Storage server > > Dear All, > > At work, the network guys have come to a discovery that they > have made a > mistake in their network configuration... The Storage server > that we use as > ISCSI target in oVirt, is in the wrong VLAN, so the wrong IP > address... > > What is the best way to make sure that all of our vms (40) > that are using > this scsi storage will come up again after the storage > server has changed > his ip? > What are the best steps to be taken...? > We are using oVirt Engine Version: 3.3.1-2.el6 > > Kind Regards, > > Koen > > _________________________________________________ > Users mailing list > Users(a)ovirt.org <mailto:Users@ovirt.org> > http://lists.ovirt.org/__mailman/listinfo/users > <http://lists.ovirt.org/mailman/listinfo/users> > > _________________________________________________ > Users mailing list > Users(a)ovirt.org <mailto:Users@ovirt.org> > http://lists.ovirt.org/__mailman/listinfo/users > <http://lists.ovirt.org/mailman/listinfo/users> > >

1 0

[Users] Import VMware
by Maurice James 06 Feb '14

06 Feb '14

--_14551f3c-807e-4ead-9bc7-e8dee89e0f36_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Is it possible to import vmware images into ovirt 3.3=2C Or is a running Es= x instance still required? = --_14551f3c-807e-4ead-9bc7-e8dee89e0f36_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <html> <head> <style></style></head> <body class=3D'hmmessage'><div dir=3D'ltr'>Is it possible to import vmware = images into ovirt 3.3=2C Or is a running Esx instance still required? = </div></body> </html>= --_14551f3c-807e-4ead-9bc7-e8dee89e0f36_--

4 9

[Users] Mixing tagged and untagged VLANs
by Trey Dockendorf 06 Feb '14

06 Feb '14

Using 3.3.2 I seem unable to mix tagged and untagged VLANs on a single interface. I'm trying to put the following logical networks on a host's eth0. ovirtmgmt: - Display Network - Migration Network - NOT VM Network - NO VLAN private: - VM network - NO VLAN ipmi: - VM Network - VLAN 2 In the host's network setup ovirtmgmt is already linked to eth0. If I attach 'ipmi (VLAN 2)' then try and attach 'private' the message is "Cannot have more than one non-VLAN network on one interface". Same occurs if I try and attach 'private' when only 'ovirtmgmt' is assigned to eth0. Is it not possible to have multiple untagged VLAN networks associated to one interface in oVirt? Thanks - Trey

3 3

[Users] ovirt 3.3.3 host deploy push an "old" vdsm
by Gianluca Cecchi 05 Feb '14

05 Feb '14

Hello, fedora 19 engine 3.3.3 with ovirt-host-deploy-1.1.3-1.fc19.noarch when I deploy a fedora 19 host from web admin gui I get on it vdsm-4.13.0-11.fc19.x86_64 (it seems updated at november 2013) If after that I explicitly enable ovirt 3.3.3 yum repo and run yum update on host it correctly passes to : vdsm-4.13.3-3.fc19.x86_64 Gianluca

3 4

[Users] Putting a Gluster host into an ISCSI DC
by Gianluca Cecchi 05 Feb '14

05 Feb '14

Hello, in a test infra I would to temporarily put a Host that is part of Gluster DC and has gluster volumes active into an ISCSI DC. I put Gluster DC in maintenance, stop glustervolume and put both hosts in maintenance. Then I try to edit host and put into the ISCSI DC. But I receive error Error while executing action: node02: Cannot Edit host. Server having Gluster volume Is there any basic check so that I cannot do this at all? Any tip? Thanks, Gianluca

3 3