Re: [ovirt-users] Automatically migrate VM between hosts in the same cluster

[Luca Bertoncello]

Hi Alex

> 2) My question was: "what can I do, so that in case of Kernel Panic or 
> similar, the VM will be migrated (live or not) to another host?"
>
> You would make the VMs HA and acquire a fencing solution.

What do you mean now? Have two VM and build a cluster? This is not what we 
want...
If it's possible, I'd like to have more Host AS CLUSTER with migration of the 
VM between the nodes...
I think oVirt already do that, since I have to create Clusters. For me a 
Cluster is not just "more nodes with the same CPU", but also something with 
load balancing or high availability...

> 3) I'd like to have a shutdown-script on the host that put the host in 
> Maintenance and wait until it's done, so that I can just shutdown or reboot 
> it without any other action. Is it possible? It would help to manage the power
 > failure, too, assuming that other hosts have better UPS (it can be possible.)
>
> You could probably use the REST API on the Ovirt Engine for that.But it might 
> be better to have a highly available machine (VM or not) running something 
> like Nagios or Icinga which would perform the monitoring of your
>  hosts and connect to the REST API to perform maintenance and shutdown. You 
> might also consider a UPS service like NUT (unless you're already doing it).

Well, I already use NUT and we have Icinga monitoring the hosts.
But I can't understand what you mean and (more important!) how can I do it...

I checked the REST API and the CLI. I can write a little script to put an host 
in Maintenance or active it again, that's not the problem.
The problem is to have somewhat starting this script automatically...

Any suggestion? Icinga will not be the solution, since it checks the host every 
5 minutes or so, but we need to have this script started in seconds...

Thanks

Mit freundlichen Grüßen

Luca Bertoncello

-- 
Besuchen Sie unsere Webauftritte:

www.queo.bizAgentur für Markenführung und Kommunikation
www.queoflow.comIT-Consulting und Individualsoftwareentwicklung

Luca Bertoncello
Administrator
Telefon:+49 351 21 30 38 0
Fax:+49 351 21 30 38 99
E-Mail: l.bertonce...@queo-group.com

queo GmbH
Tharandter Str. 13
01159 Dresden
Sitz der Gesellschaft: Dresden
Handelsregistereintrag: Amtsgericht Dresden HRB 22352
Geschäftsführer: Rüdiger Henke, André Pinkert
USt-IdNr.: DE234220077
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] Python: Clone snapshot into VM

[gregor]

Hi,

this was also an idea but with the single backup script you have the
advantage of backing up more than one VM at a time to speed up the
overall backup time and therefore to backup to different clusters and
different export domains.

But I will change the tool to set a list of VM's in the configuration to
cover both ways.

greetings
gregor

On 2015-09-18 07:50, Karli Sjöberg wrote:
> tor 2015-09-17 klockan 21:24 +0200 skrev gregor:
>> Hi,
>>
>> thanks, the tool is ready and online on github.
> 
> Looks really cool. Good job! What do you think of making the backing up
> into a loop and fetching VMs from a list? My thinking is that you
> usually have more than one VM you´d want to back up, so something like
> this maybe:
> 
> def getVMsFromList(VMS_LIST):
> try:
> print 'Getting list of VMs from file \"%s\".' % (VMS_LIST)
> fo = open(VMS_LIST)
> output = []
> for line in fo:
> strippedline = line.strip('\r\n')
> output.append(strippedline)
> fo.close()
> return output
> except Exception as e:
> print 'Exception in getting list of VMs:\n%s' % str(e)
> exit(1)
> 
> And then you can loop:
> for LIST_VM_NAME in getVMsFromList('VMs.list'):
> 
> 
> Or to have the list of VMs in the config and then:
> config = Config(config_file, debug)
> VMS_LIST = vms_list
> for LIST_VM_NAME in getVMsFromList(VMS_LIST):
> 
> 
> /K
> 
>>
>> https://github.com/wefixit-AT/oVirtBackup
>>
>> cheers
>> gregor
>>
>> On 2015-09-16 15:11, Amador Pahim wrote:
>>> On 09/15/2015 11:57 AM, gregor wrote:
 Hi,

 I write currently a little backup tool in Python which use the following
 workflow:
 - create a snapshot -> works
 - clone snapshot into VM -> help needed
>>>
>>> snapshot =
>>> params.Snapshot(id=api.vms.get('my_vm01').snapshots.list(description='my_vm_snap_01')[0].id)
>>>
>>>
>>> snapshots = params.Snapshots(snapshot=[snapshot])
>>>
>>> api.vms.add(params.VM(name='new_vm', memory=2524971008,
>>> cluster=api.clusters.get("Default"), snapshots=snapshots))
>>>
 - delete the snapshot -> works
 - export VM to NFS share -> works
 - delete cloned VM -> TODO

 Is it possible to clone a snapshot into a VM like from the web-interface?

 The above workflow is a little bit resource expensive but it will when
 it is finished make Online-Full-backups of VM's.

 cheers
 gregor
 ___
 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
> 
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] Automatically migrate VM between hosts in the same cluster

[Alex Crow]

On 18/09/15 07:30, Luca Bertoncello wrote:


Hi all,

thank you very much for your answers.

So:

1)Of course, we have UPS. More than one, in our server room, and of 
course they will send an advice to the host if they are on battery




Good.

2)My question was: “what can I do, so that in case of Kernel Panic or 
similar, the VM will be migrated (live or not) to another host?”




You would make the VMs HA and acquire a fencing solution.

3)I’d like to have a shutdown-script on the host that put the host in 
Maintenance and wait until it’s done, so that I can just shutdown or 
reboot it without any other action. Is it possible? It would help to 
manage the power failure, too, assuming that other hosts have better 
UPS (it can be possible…)




You could probably use the REST API on the Ovirt Engine for that.But it 
might be better to have a highly available machine (VM or not) running 
something like Nagios or Icinga which would perform the monitoring of 
your hosts and connect to the REST API to perform maintenance and 
shutdown. You might also consider a UPS service like NUT (unless you're 
already doing it).


Cheers

Alex


Thanks a lot

Mit freundlichen Grüßen

Luca Bertoncello

--
Besuchen Sie unsere Webauftritte:

www.queo.biz 



Agentur für Markenführung und Kommunikation

www.queoflow.com 



IT-Consulting und Individualsoftwareentwicklung


Luca Bertoncello
Administrator

Telefon:



+49 351 21 30 38 0

Fax:



+49 351 21 30 38 99

E-Mail:



l.bertonce...@queo-group.com 


queo GmbH
Tharandter Str. 13
01159 Dresden
Sitz der Gesellschaft: Dresden
Handelsregistereintrag: Amtsgericht Dresden HRB 22352
Geschäftsführer: Rüdiger Henke, André Pinkert
USt-IdNr.: DE234220077

*From:*users-boun...@ovirt.org [mailto:users-boun...@ovirt.org] *On 
Behalf Of *matthew lagoe

*Sent:* Thursday, September 17, 2015 9:56 PM
*To:* 'Alex Crow'; 'Yaniv Kaul'
*Cc:* users@ovirt.org
*Subject:* Re: [ovirt-users] Automatically migrate VM between hosts in 
the same cluster


There are PDU’s that you can monitor power draw per port and that 
would kind of tell you if a PSU failed as the load would be 0


*From:*users-boun...@ovirt.org  
[mailto:users-boun...@ovirt.org] *On Behalf Of *Alex Crow

*Sent:* Thursday, September 17, 2015 12:31 PM
*To:* Yaniv Kaul mailto:yk...@redhat.com>>
*Cc:* users@ovirt.org 
*Subject:* Re: [ovirt-users] Automatically migrate VM between hosts in 
the same cluster


I don't really think this is practical:

- If the PSU failed, your UPS could alert you. If you have one...


If you have only one PSU in a host, a UPS is not going to stop you 
losing all the VMs on that host. OK, if you had N+1 PSUs, you may be 
able to monitor for this (IPMI/LOM/DRAC etc)and use the API to put a 
host into maintenance. Also a lot of people rely on low-cost white-box 
servers and decide that it's OK if a single PSU in a host dies, as, 
well, we have HA to start on other hosts. If they have N+1 PSUs in the 
hosts do they really have to migrate everything off? Swings and 
roundabouts really.


I'm also not sure I've seen any practical DC setups where a UPS can 
monitor the load for every single attached physical machine and figure 
out that one of the redundant PSUs in it has failed - I'd love to know 
if there are as that would be really cool.


- If the machine is going down in an ordinary flow, surely it can
be done.


Isn't that what "Maintenance mode" is for?

Â


Even if it was a network failure and the host was still up,
how would you live migrate a VM from a host you can't even
talk to?

It could be suspended to disk (local) - if the disk is available.

Then the decision if it is to be resumed from local disk or not
(as it might be HA'ed and is running elsewhere) need to be taken
later, of course.


Yes, but that's not even remotely possible with Ovirt right now. I was 
trying to be practical as the OP has only just started using Ovirt and 
I think it might be a bit much to ask him to start coding up what he'd 
like.


Â


The only way you could do it was if you somehow magically knew
far enough in advance that the host was about to fail (!) and
that gave enough time to migrate the machines off. But how
would you ever know that "machine quux.bar.net
 is going to fail in 7 minutes"?

I completely agree there are situations in which you can't foresee
the failure.Â

But in many, you can. In those cases, it makes sense for the host
to self-initiate 'move to maintenance' mode. The policy of what to
do when 'self-moving-to-maintenance-mode' could be pre-fetched
from the engine.

Y.


Hmm, I would love that to be true. But I've seen so many so called 
"corner-cases" that I now think the fai

Re: [ovirt-users] Automatically migrate VM between hosts in the same cluster

[Luca Bertoncello]

Hi all,

thank you very much for your answers.
So:


1)  Of course, we have UPS. More than one, in our server room, and of 
course they will send an advice to the host if they are on battery

2)  My question was: “what can I do, so that in case of Kernel Panic or 
similar, the VM will be migrated (live or not) to another host?”

3)  I’d like to have a shutdown-script on the host that put the host in 
Maintenance and wait until it’s done, so that I can just shutdown or reboot it 
without any other action. Is it possible? It would help to manage the power 
failure, too, assuming that other hosts have better UPS (it can be possible…)

Thanks a lot

Mit freundlichen Grüßen

Luca Bertoncello

--
Besuchen Sie unsere Webauftritte:
www.queo.biz

Agentur für Markenführung und Kommunikation

www.queoflow.com

IT-Consulting und Individualsoftwareentwicklung


Luca Bertoncello
Administrator
Telefon:

+49 351 21 30 38 0

Fax:

+49 351 21 30 38 99

E-Mail:

l.bertonce...@queo-group.com


queo GmbH
Tharandter Str. 13
01159 Dresden
Sitz der Gesellschaft: Dresden
Handelsregistereintrag: Amtsgericht Dresden HRB 22352
Geschäftsführer: Rüdiger Henke, André Pinkert
USt-IdNr.: DE234220077


From: users-boun...@ovirt.org [mailto:users-boun...@ovirt.org] On Behalf Of 
matthew lagoe
Sent: Thursday, September 17, 2015 9:56 PM
To: 'Alex Crow'; 'Yaniv Kaul'
Cc: users@ovirt.org
Subject: Re: [ovirt-users] Automatically migrate VM between hosts in the same 
cluster

There are PDU’s that you can monitor power draw per port and that would kind of 
tell you if a PSU failed as the load would be 0

From: users-boun...@ovirt.org 
[mailto:users-boun...@ovirt.org] On Behalf Of Alex Crow
Sent: Thursday, September 17, 2015 12:31 PM
To: Yaniv Kaul mailto:yk...@redhat.com>>
Cc: users@ovirt.org
Subject: Re: [ovirt-users] Automatically migrate VM between hosts in the same 
cluster

I don't really think this is practical:

- If the PSU failed, your UPS could alert you. If you have one...

If you have only one PSU in a host, a UPS is not going to stop you losing all 
the VMs on that host. OK, if you had N+1 PSUs, you may be able to monitor for 
this (IPMI/LOM/DRAC etc)and use the API to put a host into maintenance. Also a 
lot of people rely on low-cost white-box servers and decide that it's OK if a 
single PSU in a host dies, as, well, we have HA to start on other hosts. If 
they have N+1 PSUs in the hosts do they really have to migrate everything off? 
Swings and roundabouts really.

I'm also not sure I've seen any practical DC setups where a UPS can monitor the 
load for every single attached physical machine and figure out that one of the 
redundant PSUs in it has failed - I'd love to know if there are as that would 
be really cool.

- If the machine is going down in an ordinary flow, surely it can be done.

Isn't that what "Maintenance mode" is for?

Â

Even if it was a network failure and the host was still up, how would you live 
migrate a VM from a host you can't even talk to?

It could be suspended to disk (local) - if the disk is available.
Then the decision if it is to be resumed from local disk or not (as it might be 
HA'ed and is running elsewhere) need to be taken later, of course.

Yes, but that's not even remotely possible with Ovirt right now. I was trying 
to be practical as the OP has only just started using Ovirt and I think it 
might be a bit much to ask him to start coding up what he'd like.


Â

The only way you could do it was if you somehow magically knew far enough in 
advance that the host was about to fail (!) and that gave enough time to 
migrate the machines off. But how would you ever know that "machine 
quux.bar.net is going to fail in 7 minutes"?

I completely agree there are situations in which you can't foresee the failure.Â
But in many, you can. In those cases, it makes sense for the host to 
self-initiate 'move to maintenance' mode. The policy of what to do when 
'self-moving-to-maintenance-mode' could be pre-fetched from the engine.
Y.

Hmm, I would love that to be true. But I've seen so many so called 
"corner-cases" that I now think the failure area in a datacenter is a fractal 
with infinite corners. Yes, you could monitor SMART on local drives, pick up 
uncorrected ECC errors, use "sensors" to check for sagging voltages or high 
temps, but I don't think you can ever hope to catch everything, and you could 
end up doing a migration "storm" for . I've had more than enough of "Enterprise 
Spec" switches suddenly going nuts and spamming corrupt MACs all over the LAN 
to know you can't ever account for everything.

I think it's better to adopt the model of redundancy in software and services, 
so no-one even notices if a VM host goes away, there's always something else to 
take up the slack. Just like the origins of the Internet - the network sh

Re: [ovirt-users] Python: Clone snapshot into VM

[Karli Sjöberg]

tor 2015-09-17 klockan 21:24 +0200 skrev gregor:
> Hi,
> 
> thanks, the tool is ready and online on github.

Looks really cool. Good job! What do you think of making the backing up
into a loop and fetching VMs from a list? My thinking is that you
usually have more than one VM you´d want to back up, so something like
this maybe:

def getVMsFromList(VMS_LIST):
try:
print 'Getting list of VMs from file \"%s\".' % (VMS_LIST)
fo = open(VMS_LIST)
output = []
for line in fo:
strippedline = line.strip('\r\n')
output.append(strippedline)
fo.close()
return output
except Exception as e:
print 'Exception in getting list of VMs:\n%s' % str(e)
exit(1)

And then you can loop:
for LIST_VM_NAME in getVMsFromList('VMs.list'):


Or to have the list of VMs in the config and then:
config = Config(config_file, debug)
VMS_LIST = vms_list
for LIST_VM_NAME in getVMsFromList(VMS_LIST):


/K

> 
> https://github.com/wefixit-AT/oVirtBackup
> 
> cheers
> gregor
> 
> On 2015-09-16 15:11, Amador Pahim wrote:
> > On 09/15/2015 11:57 AM, gregor wrote:
> >> Hi,
> >>
> >> I write currently a little backup tool in Python which use the following
> >> workflow:
> >> - create a snapshot -> works
> >> - clone snapshot into VM -> help needed
> > 
> > snapshot =
> > params.Snapshot(id=api.vms.get('my_vm01').snapshots.list(description='my_vm_snap_01')[0].id)
> > 
> > 
> > snapshots = params.Snapshots(snapshot=[snapshot])
> > 
> > api.vms.add(params.VM(name='new_vm', memory=2524971008,
> > cluster=api.clusters.get("Default"), snapshots=snapshots))
> > 
> >> - delete the snapshot -> works
> >> - export VM to NFS share -> works
> >> - delete cloned VM -> TODO
> >>
> >> Is it possible to clone a snapshot into a VM like from the web-interface?
> >>
> >> The above workflow is a little bit resource expensive but it will when
> >> it is finished make Online-Full-backups of VM's.
> >>
> >> cheers
> >> gregor
> >> ___
> >> 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

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

Re: [ovirt-users] Automatically migrate VM between hosts in the same cluster

[matthew lagoe]

There are PDU’s that you can monitor power draw per port and that would kind of 
tell you if a PSU failed as the load would be 0

 

From: users-boun...@ovirt.org [mailto:users-boun...@ovirt.org] On Behalf Of 
Alex Crow
Sent: Thursday, September 17, 2015 12:31 PM
To: Yaniv Kaul 
Cc: users@ovirt.org
Subject: Re: [ovirt-users] Automatically migrate VM between hosts in the same 
cluster

 

I don't really think this is practical:




- If the PSU failed, your UPS could alert you. If you have one...


If you have only one PSU in a host, a UPS is not going to stop you losing all 
the VMs on that host. OK, if you had N+1 PSUs, you may be able to monitor for 
this (IPMI/LOM/DRAC etc)and use the API to put a host into maintenance. Also a 
lot of people rely on low-cost white-box servers and decide that it's OK if a 
single PSU in a host dies, as, well, we have HA to start on other hosts. If 
they have N+1 PSUs in the hosts do they really have to migrate everything off? 
Swings and roundabouts really.

I'm also not sure I've seen any practical DC setups where a UPS can monitor the 
load for every single attached physical machine and figure out that one of the 
redundant PSUs in it has failed - I'd love to know if there are as that would 
be really cool.




- If the machine is going down in an ordinary flow, surely it can be done. 


Isn't that what "Maintenance mode" is for?




 


Even if it was a network failure and the host was still up, how would you live 
migrate a VM from a host you can't even talk to?

 

It could be suspended to disk (local) - if the disk is available.

Then the decision if it is to be resumed from local disk or not (as it might be 
HA'ed and is running elsewhere) need to be taken later, of course.


Yes, but that's not even remotely possible with Ovirt right now. I was trying 
to be practical as the OP has only just started using Ovirt and I think it 
might be a bit much to ask him to start coding up what he'd like.




 

 


The only way you could do it was if you somehow magically knew far enough in 
advance that the host was about to fail (!) and that gave enough time to 
migrate the machines off. But how would you ever know that "machine 
quux.bar.net   is going to fail in 7 minutes"?

 

I completely agree there are situations in which you can't foresee the 
failure. 

But in many, you can. In those cases, it makes sense for the host to 
self-initiate 'move to maintenance' mode. The policy of what to do when 
'self-moving-to-maintenance-mode' could be pre-fetched from the engine.

Y.


Hmm, I would love that to be true. But I've seen so many so called 
"corner-cases" that I now think the failure area in a datacenter is a fractal 
with infinite corners. Yes, you could monitor SMART on local drives, pick up 
uncorrected ECC errors, use "sensors" to check for sagging voltages or high 
temps, but I don't think you can ever hope to catch everything, and you could 
end up doing a migration "storm" for . I've had more than enough of "Enterprise 
Spec" switches suddenly going nuts and spamming corrupt MACs all over the LAN 
to know you can't ever account for everything.

I think it's better to adopt the model of redundancy in software and services, 
so no-one even notices if a VM host goes away, there's always something else to 
take up the slack. Just like the origins of the Internet - the network should 
be dumb and the applications should cope with it! Any infrastructure that can't 
cope with the loss of a few VMs for a few minutes probably needs a refresh.

Cheers

Alex





. 

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

Re: [ovirt-users] Automatically migrate VM between hosts in the same cluster

[Alex Crow]

I don't really think this is practical:


- If the PSU failed, your UPS could alert you. If you have one...


If you have only one PSU in a host, a UPS is not going to stop you 
losing all the VMs on that host. OK, if you had N+1 PSUs, you may be 
able to monitor for this (IPMI/LOM/DRAC etc)and use the API to put a 
host into maintenance. Also a lot of people rely on low-cost white-box 
servers and decide that it's OK if a single PSU in a host dies, as, 
well, we have HA to start on other hosts. If they have N+1 PSUs in the 
hosts do they really have to migrate everything off? Swings and 
roundabouts really.


I'm also not sure I've seen any practical DC setups where a UPS can 
monitor the load for every single attached physical machine and figure 
out that one of the redundant PSUs in it has failed - I'd love to know 
if there are as that would be really cool.


- If the machine is going down in an ordinary flow, surely it can be 
done.


Isn't that what "Maintenance mode" is for?



Even if it was a network failure and the host was still up, how
would you live migrate a VM from a host you can't even talk to?


It could be suspended to disk (local) - if the disk is available.
Then the decision if it is to be resumed from local disk or not (as it 
might be HA'ed and is running elsewhere) need to be taken later, of 
course.


Yes, but that's not even remotely possible with Ovirt right now. I was 
trying to be practical as the OP has only just started using Ovirt and I 
think it might be a bit much to ask him to start coding up what he'd like.





The only way you could do it was if you somehow magically knew far
enough in advance that the host was about to fail (!) and that
gave enough time to migrate the machines off. But how would you
ever know that "machine quux.bar.net  is
going to fail in 7 minutes"?


I completely agree there are situations in which you can't foresee the 
failure.
But in many, you can. In those cases, it makes sense for the host to 
self-initiate 'move to maintenance' mode. The policy of what to do 
when 'self-moving-to-maintenance-mode' could be pre-fetched from the 
engine.

Y.


Hmm, I would love that to be true. But I've seen so many so called 
"corner-cases" that I now think the failure area in a datacenter is a 
fractal with infinite corners. Yes, you could monitor SMART on local 
drives, pick up uncorrected ECC errors, use "sensors" to check for 
sagging voltages or high temps, but I don't think you can ever hope to 
catch everything, and you could end up doing a migration "storm" for . 
I've had more than enough of "Enterprise Spec" switches suddenly going 
nuts and spamming corrupt MACs all over the LAN to know you can't ever 
account for everything.


I think it's better to adopt the model of redundancy in software and 
services, so no-one even notices if a VM host goes away, there's always 
something else to take up the slack. Just like the origins of the 
Internet - the network should be dumb and the applications should cope 
with it! Any infrastructure that can't cope with the loss of a few VMs 
for a few minutes probably needs a refresh.


Cheers

Alex





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

Re: [ovirt-users] Daily online VM backups

[gregor]

Hi, no this was not my intention. I was searching what is currently
available and possible. After this I wrote a little
online-fullbackup-tool and published it on github.

https://github.com/wefixit-AT/oVirtBackup

cheers
gregor

ps: sorry for double sending, I forget to cc it to the list

On 2015-08-31 12:26, Jiri Belka wrote:
>> From: "gregor" 
>> To: Users@ovirt.org
>> Sent: Sunday, August 30, 2015 11:01:49 AM
>> Subject: [ovirt-users] Daily online VM backups
>>
>> Hi,
>>
>> what is the best way to make daily backups of my VM's without shutting
>> them down?
>>
>> I found the Backup-Restore API and other stuff but no running
>> tool/script which I can use. I plan to integrate it into backuppc. Or is
>> there any "Best practice guide for backup"? ;-)
>>
>> In the meantime I integrated engine-backup into backuppc as a pre-script.
> 
> IIUC you know the technical part of the topic but you want
> somebody will write for you backup scripts?
> 
> j.
> 
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] Python: Clone snapshot into VM

[gregor]

Hi,

thanks, the tool is ready and online on github.

https://github.com/wefixit-AT/oVirtBackup

cheers
gregor

On 2015-09-16 15:11, Amador Pahim wrote:
> On 09/15/2015 11:57 AM, gregor wrote:
>> Hi,
>>
>> I write currently a little backup tool in Python which use the following
>> workflow:
>> - create a snapshot -> works
>> - clone snapshot into VM -> help needed
> 
> snapshot =
> params.Snapshot(id=api.vms.get('my_vm01').snapshots.list(description='my_vm_snap_01')[0].id)
> 
> 
> snapshots = params.Snapshots(snapshot=[snapshot])
> 
> api.vms.add(params.VM(name='new_vm', memory=2524971008,
> cluster=api.clusters.get("Default"), snapshots=snapshots))
> 
>> - delete the snapshot -> works
>> - export VM to NFS share -> works
>> - delete cloned VM -> TODO
>>
>> Is it possible to clone a snapshot into a VM like from the web-interface?
>>
>> The above workflow is a little bit resource expensive but it will when
>> it is finished make Online-Full-backups of VM's.
>>
>> cheers
>> gregor
>> ___
>> 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] Storage and ISO Domain and Engine VM

[Joop]

On 16-9-2015 15:44, Richard Neuboeck wrote:
> There is one obvious error in the web UI that I've overlooked so > far. 
> 'Events' lists the following: > > 'The Hosted Engine Storage
Domain doesn't no exist. It should be > imported into the setup.' > >
Except finding the github link to the source code googling didn't >
reveal any hints on what to do to remedy this problem. > >
Go to the Storage tab and Import Domain, fill in the required fields and
path to your hosted-engine storage domain. Things should proceed from
there, I hope.
This info is somewhere on the wiki in the beta releasenotes.

Joop


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

Re: [ovirt-users] P2V shrink disk

[Federico Alberto Sayd]

On 17/09/15 09:32, wodel youchi wrote:

Hi,

I am not sure if it's the right place to post this question.

I tried to do a P2V operation of a Win2k3 server to ovirt 3.5


the physical server is RAID5 of 3x146Go configured, about 290 Go 
usable space, but the server uses about 20Go only.


I am wondering how to shrink the disk of the migrated physical 
machine, do I have to do it before using P2V tool?


The same question for Linux servers.

Thanks.


___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
You can use clonezilla to migrate your physical server to an oVirt VM. 
Prepare a vm with a disk of the same size and configure as thin 
provision. Boot both servers with clonezilla and clone using the 
network. Clonezilla only copies the used block in your source disk. Note 
that you need to include some ide drivers in your source server before 
clone in order your Windows server can boot up[1]


[1] https://support.microsoft.com/en-us/kb/314082
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

[ovirt-users] [ANN] oVirt 3.6.0 Sixth Beta Release is now available for testing

[Sandro Bonazzola]

The oVirt Project is pleased to announce the availability
of the Sixth Beta release of oVirt 3.6 for testing, as of September 17th,
2015.

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.1, CentOS Linux 7.1 (or similar).

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

This release of oVirt 3.6.0 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.
New oVirt Node ISO and oVirt Live ISO will be available soon as well[2].

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

Please refer to the release notes for known issues in this release.

[1] http://www.ovirt.org/OVirt_3.6_Release_Notes
[2] http://plain.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] Automatically migrate VM between hosts in the same cluster

[Yaniv Kaul]

On Thu, Sep 17, 2015 at 6:00 PM, Alex Crow  wrote:

>
>
> On 17/09/15 15:44, Luca Bertoncello wrote:
>
>> Hello Alex
>>
>> You can't live migrate on a host failure - as the host has gone down and
>>> all the
>>> running VMs on it have as well! It would require clairvoyance to enable
>>> live
>>> migration in that situation.
>>>
>> Is it possible to enable that? How?
>>
>
> No, it's physically impossible. If your host running VM "foo" has
> unexpectedly gone down (ie the PSU failed), VM "foo" has also gone down.
> Therefore it is not possible to live migrate the VM "foo" since it is not
> longer running!
>

- If the PSU failed, your UPS could alert you. If you have one...
- If the machine is going down in an ordinary flow, surely it can be done.


>
> Even if it was a network failure and the host was still up, how would you
> live migrate a VM from a host you can't even talk to?
>

It could be suspended to disk (local) - if the disk is available.
Then the decision if it is to be resumed from local disk or not (as it
might be HA'ed and is running elsewhere) need to be taken later, of course.



>
> The only way you could do it was if you somehow magically knew far enough
> in advance that the host was about to fail (!) and that gave enough time to
> migrate the machines off. But how would you ever know that "machine
> quux.bar.net is going to fail in 7 minutes"?


I completely agree there are situations in which you can't foresee the
failure.
But in many, you can. In those cases, it makes sense for the host to
self-initiate 'move to maintenance' mode. The policy of what to do when
'self-moving-to-maintenance-mode' could be pre-fetched from the engine.
Y.


>
>
>> However you can enable HA in VMs. If the host they are running on fails
>>> they
>>> will be restarted automatically on another host. NB. This
>>> *requires* power management so the failed host can be fenced.
>>>
>> Well, we don't have a Power-Management, right now...
>> We have Dell hardware, but this PC (right now I just experiment, so I
>> don't use "real servers") does not have any PM...
>> Maybe there is an emulator or other solution to check how does it work?
>>
>
> You can use "Manual Fencing" but I don't even know if that is enabled in
> Ovirt. However it would need your intervention (Ie you are told that a host
> has failed, and asked, if it is not powered off, to go and power it off by
> hand. Once you have confirmed that is done, the VMs will start on the other
> host.
>
> The reason you have to fence the failed machine is to make sure you don't
> end up with two of the same VM running, which would completely corrupt the
> image on the shared storage. When using plain old libvirt, I have more than
> once accidentally started the same VM on two hosts, and the VM was utterly
> unrecoverable afterwards.
>
>
>> On the Servers we have Drac6, but oVirt has just Drac5 or Drac7... It
>> does not work with Drac6?
>>
>
> I don't know. Maybe just try both, and run the test on the PM config tab?
>
> Otherwise how about picking up a second-hand APC network switched PDU off
> ebay? That is actually one of the best ways to enable fencing.
>
> Cheers
>
> Alex
>
>
> --
> This message is intended only for the addressee and may contain
> confidential information. Unless you are that person, you may not
> disclose its contents or use it in any way and are requested to delete
> the message along with any attachments and notify us immediately.
> "Transact" is operated by Integrated Financial Arrangements plc. 29
> Clement's Lane, London EC4N 7AE. Tel: (020) 7608 4900 Fax: (020) 7608
> 5300. (Registered office: as above; Registered in England and Wales
> under number: 3727592). Authorised and regulated by the Financial
> Conduct Authority (entered on the Financial Services Register; no. 190856).
>
> .
>
> ___
> 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] Automatically migrate VM between hosts in the same cluster

[Alex Crow]

On 17/09/15 15:44, Luca Bertoncello wrote:

Hello Alex


You can't live migrate on a host failure - as the host has gone down and all the
running VMs on it have as well! It would require clairvoyance to enable live
migration in that situation.

Is it possible to enable that? How?


No, it's physically impossible. If your host running VM "foo" has 
unexpectedly gone down (ie the PSU failed), VM "foo" has also gone down. 
Therefore it is not possible to live migrate the VM "foo" since it is 
not longer running!


Even if it was a network failure and the host was still up, how would 
you live migrate a VM from a host you can't even talk to?


The only way you could do it was if you somehow magically knew far 
enough in advance that the host was about to fail (!) and that gave 
enough time to migrate the machines off. But how would you ever know 
that "machine quux.bar.net is going to fail in 7 minutes"?





However you can enable HA in VMs. If the host they are running on fails they
will be restarted automatically on another host. NB. This
*requires* power management so the failed host can be fenced.

Well, we don't have a Power-Management, right now...
We have Dell hardware, but this PC (right now I just experiment, so I don't use 
"real servers") does not have any PM...
Maybe there is an emulator or other solution to check how does it work?


You can use "Manual Fencing" but I don't even know if that is enabled in 
Ovirt. However it would need your intervention (Ie you are told that a 
host has failed, and asked, if it is not powered off, to go and power it 
off by hand. Once you have confirmed that is done, the VMs will start on 
the other host.


The reason you have to fence the failed machine is to make sure you 
don't end up with two of the same VM running, which would completely 
corrupt the image on the shared storage. When using plain old libvirt, I 
have more than once accidentally started the same VM on two hosts, and 
the VM was utterly unrecoverable afterwards.




On the Servers we have Drac6, but oVirt has just Drac5 or Drac7... It does not 
work with Drac6?


I don't know. Maybe just try both, and run the test on the PM config tab?

Otherwise how about picking up a second-hand APC network switched PDU 
off ebay? That is actually one of the best ways to enable fencing.


Cheers

Alex


--
This message is intended only for the addressee and may contain
confidential information. Unless you are that person, you may not
disclose its contents or use it in any way and are requested to delete
the message along with any attachments and notify us immediately.
"Transact" is operated by Integrated Financial Arrangements plc. 29
Clement's Lane, London EC4N 7AE. Tel: (020) 7608 4900 Fax: (020) 7608
5300. (Registered office: as above; Registered in England and Wales
under number: 3727592). Authorised and regulated by the Financial
Conduct Authority (entered on the Financial Services Register; no. 190856).

.

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

Re: [ovirt-users] Automatically migrate VM between hosts in the same cluster

[Luca Bertoncello]

Hello Alex

> You can't live migrate on a host failure - as the host has gone down and all 
> the
> running VMs on it have as well! It would require clairvoyance to enable live
> migration in that situation.

Is it possible to enable that? How?

> However you can enable HA in VMs. If the host they are running on fails they
> will be restarted automatically on another host. NB. This
> *requires* power management so the failed host can be fenced.

Well, we don't have a Power-Management, right now...
We have Dell hardware, but this PC (right now I just experiment, so I don't use 
"real servers") does not have any PM...
Maybe there is an emulator or other solution to check how does it work?

On the Servers we have Drac6, but oVirt has just Drac5 or Drac7... It does not 
work with Drac6?

Thank you very much

Mit freundlichen Grüßen

Luca Bertoncello

-- 
Besuchen Sie unsere Webauftritte:

www.queo.bizAgentur für Markenführung und Kommunikation
www.queoflow.comIT-Consulting und Individualsoftwareentwicklung

Luca Bertoncello
Administrator
Telefon:+49 351 21 30 38 0
Fax:+49 351 21 30 38 99
E-Mail: l.bertonce...@queo-group.com

queo GmbH
Tharandter Str. 13
01159 Dresden
Sitz der Gesellschaft: Dresden
Handelsregistereintrag: Amtsgericht Dresden HRB 22352
Geschäftsführer: Rüdiger Henke, André Pinkert
USt-IdNr.: DE234220077
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] Automatically migrate VM between hosts in the same cluster

[Alex Crow]

On 17/09/15 14:25, Luca Bertoncello wrote:

Hi list!

I'm new by oVirt. Right now I configured a Cluster with two hosts and a VM.
I can migrate the VM between the two hosts without any problem, but what I need 
is, that the VM automatically migrate if an host is down.

The migration occurs just if I set an host in "Maintenance", but this is not 
(only!) what I need...

Can someone help me to configure oVirt (3.5) to automatically check the hosts 
and migrate the VM on host failure?

Thanks a lot!

Mit freundlichen Grüßen

Luca Bertoncello



You can't live migrate on a host failure - as the host has gone down and 
all the running VMs on it have as well! It would require clairvoyance to 
enable live migration in that situation.


However you can enable HA in VMs. If the host they are running on fails 
they will be restarted automatically on another host. NB. This 
*requires* power management so the failed host can be fenced.


Alex

--
This message is intended only for the addressee and may contain
confidential information. Unless you are that person, you may not
disclose its contents or use it in any way and are requested to delete
the message along with any attachments and notify us immediately.
"Transact" is operated by Integrated Financial Arrangements plc. 29
Clement's Lane, London EC4N 7AE. Tel: (020) 7608 4900 Fax: (020) 7608
5300. (Registered office: as above; Registered in England and Wales
under number: 3727592). Authorised and regulated by the Financial
Conduct Authority (entered on the Financial Services Register; no. 190856).

.

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

[ovirt-users] Automatically migrate VM between hosts in the same cluster

[Luca Bertoncello]

Hi list!

I'm new by oVirt. Right now I configured a Cluster with two hosts and a VM.
I can migrate the VM between the two hosts without any problem, but what I need 
is, that the VM automatically migrate if an host is down.

The migration occurs just if I set an host in "Maintenance", but this is not 
(only!) what I need...

Can someone help me to configure oVirt (3.5) to automatically check the hosts 
and migrate the VM on host failure?

Thanks a lot!

Mit freundlichen Grüßen

Luca Bertoncello

-- 
Besuchen Sie unsere Webauftritte:

www.queo.bizAgentur für Markenführung und Kommunikation
www.queoflow.comIT-Consulting und Individualsoftwareentwicklung

Luca Bertoncello
Administrator
Telefon:+49 351 21 30 38 0
Fax:+49 351 21 30 38 99
E-Mail: l.bertonce...@queo-group.com

queo GmbH
Tharandter Str. 13
01159 Dresden
Sitz der Gesellschaft: Dresden
Handelsregistereintrag: Amtsgericht Dresden HRB 22352
Geschäftsführer: Rüdiger Henke, André Pinkert
USt-IdNr.: DE234220077
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] P2V shrink disk

[Alex Crow]

On 17/09/15 13:40, Alex Crow wrote:



On 17/09/15 13:32, wodel youchi wrote:

Hi,

I am not sure if it's the right place to post this question.

I tried to do a P2V operation of a Win2k3 server to ovirt 3.5


the physical server is RAID5 of 3x146Go configured, about 290 Go 
usable space, but the server uses about 20Go only.


I am wondering how to shrink the disk of the migrated physical 
machine, do I have to do it before using P2V tool?


The same question for Linux servers.

Thanks.



I just use a parted Live CD. You can do it before or after, whichever 
is more convenient. I normally do it after a P2V or V2V as it's so 
easy to use an ISO image in Ovirt.


Cheers

Alex



Actually that wouldn't work as such if you're P2V'ing straight to Ovirt. 
I'd suggest P2V'ing into Libvirt/Qemu-KVM, then running Parted Live on 
that VM. Shut down the VM and use qemu-img to shrink the image file, 
then do a V2V into Ovirt.


Cheers

Alex



--
This message is intended only for the addressee and may contain
confidential information. Unless you are that person, you may not
disclose its contents or use it in any way and are requested to delete
the message along with any attachments and notify us immediately.
"Transact" is operated by Integrated Financial Arrangements plc. 29
Clement's Lane, London EC4N 7AE. Tel: (020) 7608 4900 Fax: (020) 7608
5300. (Registered office: as above; Registered in England and Wales
under number: 3727592). Authorised and regulated by the Financial
Conduct Authority (entered on the Financial Services Register; no. 190856).

.

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

Re: [ovirt-users] P2V shrink disk

[Alex Crow]

On 17/09/15 13:32, wodel youchi wrote:

Hi,

I am not sure if it's the right place to post this question.

I tried to do a P2V operation of a Win2k3 server to ovirt 3.5


the physical server is RAID5 of 3x146Go configured, about 290 Go 
usable space, but the server uses about 20Go only.


I am wondering how to shrink the disk of the migrated physical 
machine, do I have to do it before using P2V tool?


The same question for Linux servers.

Thanks.



I just use a parted Live CD. You can do it before or after, whichever is 
more convenient. I normally do it after a P2V or V2V as it's so easy to 
use an ISO image in Ovirt.


Cheers

Alex


.

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

[ovirt-users] P2V shrink disk

[wodel youchi]

Hi,

I am not sure if it's the right place to post this question.

I tried to do a P2V operation of a Win2k3 server to ovirt 3.5


the physical server is RAID5 of 3x146Go configured, about 290 Go usable
space, but the server uses about 20Go only.

I am wondering how to shrink the disk of the migrated physical machine, do
I have to do it before using P2V tool?

The same question for Linux servers.

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

Re: [ovirt-users] ovirt 3.6 webadmin vm attributes empty

[Marc Werner]

Datacenter is up.
[cid:image001.png@01D0F14D.C4FBB370]

Von: Amador Pahim [mailto:apa...@redhat.com]
Gesendet: Mittwoch, 16. September 2015 15:35
An: Marc Werner; 'users@ovirt.org'
Betreff: Re: [ovirt-users] ovirt 3.6 webadmin vm attributes empty

Is the DataCenter Up?

On 09/15/2015 07:21 AM, Marc Werner wrote:
Hi
If I try to edit a vm most of dialog is empty and I cant chos e anything.
Is that a known bug?


Best regards
Marc
[cid:image002.png@01D0F14D.C4FBB370]

ovirt-engine.noarch 
   
3.6.0-0.0.master.20150909083445.gitbcc44ff.el6  
   @ovirt-3.6
ovirt-engine-backend.noarch 
   
3.6.0-0.0.master.20150909083445.gitbcc44ff.el6  
   @ovirt-3.6
ovirt-engine-cli.noarch 
   3.6.0.1-0.1.20150821.gitac5082d.el6  
  
@ovirt-3.6
ovirt-engine-dbscripts.noarch   
   
3.6.0-0.0.master.20150909083445.gitbcc44ff.el6  
   @ovirt-3.6
ovirt-engine-extension-aaa-jdbc.noarch  
   
1.0.0-0.0.master.20150831142838.git4d9c713.el6  
   @ovirt-3.6
ovirt-engine-extensions-api-impl.noarch 
   
3.6.0-0.0.master.20150909083445.gitbcc44ff.el6  
   @ovirt-3.6
ovirt-engine-jboss-as.x86_64
   7.1.1-1.el6  
  
@ovirt-3.5-pre
ovirt-engine-lib.noarch 
   
3.6.0-0.0.master.20150909083445.gitbcc44ff.el6  
   @ovirt-3.6
ovirt-engine-restapi.noarch 
   
3.6.0-0.0.master.20150909083445.gitbcc44ff.el6  
   @ovirt-3.6
ovirt-engine-sdk-python.noarch  
   3.6.0.1-0.1.20150821.gitc8ddcd8.el6  
  
@ovirt-3.6
ovirt-engine-setup.noarch   
   
3.6.0-0.0.master.20150909083445.gitbcc44ff.el6  
   @ovirt-3.6
ovirt-engine-setup-base.noarch  
   
3.6.0-0.0.master.20150909083445.gitbcc44ff.el6  
   @ovirt-3.6
ovirt-engine-setup-plugin-ovirt-engine.noarch   
   
3.6.0-0.0.master.20150909083445.gitbcc44ff.el6  
   @ovirt-3.6
ovirt-engine-setup-plugin-ovirt-engine-common.noarch
   
3.6.0-0.0.master.20150909083445.gitbcc44ff.el6  
   @ovirt-3.6
ovirt-engine-setup-plugin-vmconsole-proxy-helper.noarch 
   
3.6.0-0.0.master.20150909083445.gitbcc44ff.el6  
   @ovirt-3.6
ovirt-engine-setup-plugin-websocket-proxy.noarch
   
3.6.0-0.0.master.20150909083445.gitbcc44ff.el6  
   @ovirt-3.6
ovirt-engine-tools.noarch   
   
3.6.0-0.0.master.20150909083445.gitbcc44ff.el6  
   @ovirt-3.6
ovirt-engine-userportal.noarch  
   
3.6.0-0.0.master.20150909083445.gitbcc44ff.el6  
   

[ovirt-users] [ANN] oVirt 3.5.5 First Release Candidate is now available for testing

[Sandro Bonazzola]

The oVirt Project is pleased to announce the availability
of the First Release Candidate of oVirt 3.5.5 for testing, as of September
17th, 2015.

This release is available now for
Red Hat Enterprise Linux 6.7, CentOS Linux 6.7 (or similar) and
Red Hat Enterprise Linux 7.1, CentOS Linux 7.1 (or similar).

This release supports Hypervisor Hosts running
Red Hat Enterprise Linux 7.1, CentOS Linux 7.1 (or similar), Fedora 21.

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

Please refer to release notes [1] for Installation / Upgrade instructions.
New oVirt Node ISO and oVirt Live ISO will be available soon as well[2].

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

Please refer to the release notes for known issues in this release.
Please test add yourself to the test page[4] if you're testing this release.

[1] http://www.ovirt.org/OVirt_3.5.5_Release_Notes
[2] http://plain.resources.ovirt.org/pub/ovirt-3.5-pre/iso/
[3] http://www.ovirt.org/Repository_mirrors#Current_mirrors
[4] http://www.ovirt.org/Testing/oVirt_3.5.5_Testing

-- 
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