Re: [ovirt-users] VMs seems to be slow, while snapshot delete is happening

[Greg Padgett]

On 05/12/2016 03:46 AM, SATHEESARAN wrote:

Hi All,

I have created a VM with 60GB of disk space.
I have started I/O inside the VM, after sometime when the disk was 4GB full,
I took a snapshot of the disk from UI.

I/O kept continuing and the new image file ( overlay file ) was 15GB in
size.

Now I deleted the snapshot.
I think this would initiate block-merges.
During this time, my I/O was were slower, till the snapshot delete is
completed.

Its not very slow, but slow.
Is this a known behavior ?


Hi Satheesaran,

It sounds like this was a live merge, ie snapshot removal while the VM was 
running.  This is currently implemented as a block commit, where data from 
the snapshot (your 15GB overlay, in this case) is merged down.


For snapshot deletion to complete, this means that your concurrent I/O and 
the data already in the overlay have to be written into the next-lower 
image.  So in short, yes, depending on the storage system backing your VM, 
I/O may slow down a bit until completion.


HTH,
Greg


Advance thanks,
Satheesaran S
___
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] RemoveDiskSnapshots error's on engine log

[Greg Padgett]

On 05/11/2016 05:32 PM, Ivo Rütsche wrote:


Hi List

At the moment, we replace a filer and we have to move the VM's to
another filer. We have a lot of problems with it. Sometime we have to
restart the engine, sometime we have to move the image arround and
sometimes we don't have a chance to remove the snapshots. When the VM is
running, most of the time the snapshot remove never starts.

Now, i found these errors every second in the engine.log since today:

2016-05-11 23:25:29,102 ERROR
[org.ovirt.engine.core.bll.CommandsFactory]
(DefaultQuartzScheduler_Worker-90) [] Error in invocating CTOR of
command 'RemoveDiskSnapshots': null
2016-05-11 23:25:29,102 ERROR
[org.ovirt.engine.core.utils.timer.SchedulerUtilQuartzImpl]
(DefaultQuartzScheduler_Worker-90) [] Failed to invoke scheduled method
invokeCallbackMethods: null
2016-05-11 23:25:30,104 ERROR
[org.ovirt.engine.core.bll.CommandsFactory]
(DefaultQuartzScheduler_Worker-66) [] Error in invocating CTOR of
command 'RemoveDiskSnapshots': null
2016-05-11 23:25:30,104 ERROR
[org.ovirt.engine.core.utils.timer.SchedulerUtilQuartzImpl]
(DefaultQuartzScheduler_Worker-66) [] Failed to invoke scheduled method
invokeCallbackMethods: null
2016-05-11 23:25:31,105 ERROR
[org.ovirt.engine.core.bll.CommandsFactory]
(DefaultQuartzScheduler_Worker-76) [] Error in invocating CTOR of
command 'RemoveDiskSnapshots': null
2016-05-11 23:25:31,105 ERROR
[org.ovirt.engine.core.utils.timer.SchedulerUtilQuartzImpl]
(DefaultQuartzScheduler_Worker-76) [] Failed to invoke scheduled method
invokeCallbackMethods: null

I try everything, but i can't find the problem.

Anyone who have an idea, where i have to search?


Hi Ivo,

I'm not sure what would cause this to start happening after a successful 
deployment, but perhaps enabling debug logging would help narrow it down. 
 See [1] for instructions on that.


Greg

[1] 
http://old.ovirt.org/OVirt_Engine_Development_Environment#Enable_DEBUG_log_-_Runtime_Change.3B_No_Restart




Thank's for help.

Ivo

___
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] Problem remove snapshot

[Greg Padgett]

On 05/13/2016 02:42 PM, Marcelo Leandro wrote:

Hello Greg,
 You can help me?

Thanks.


Hi Marcelo,

I see in your engine log that one of the images can't be found when a 
merge is attempted:


  VDSErrorException: Failed to MergeVDS, error = Drive image file could
  not be found, code = 13

There were some recent fixes to Live Merge that help is progress beyond 
this particular error, see [1] for details on that.  The fix is in 3.6.6.


It might be helpful to check the vdsm log to see what happened on the host 
when the first merge on that snapshot was attempted.  It should be in the 
Host04 log around time 2016-05-11 19:33:43.


Thanks,
Greg

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1327140




2016-05-11 19:56 GMT-03:00 Marcelo Leandro <marcelol...@gmail.com
<mailto:marcelol...@gmail.com>>:

hello,

i have problem other vm now:
the vm contain two disk, only a09bfb5d-3922-406d-b4e0-daafad96ffec
mark illegal in snapshot tab.

information database:
  imagestatus |   storage_pool_id|
  storage_domain_id   |image_group_id|
  im
age_guid  |   parentid

-+--+--+--+
--+--
1 | 77e24b20-9d21-4952-a089-3c5c592b4e6d |
0dc658da-feed-498b-bfd2-3950f7198e11 |
e94d711c-b50b-43bd-a67c-cb4643808d9d | b9478a6c-28c5-4
03b-a889-226d16d399a5 | ----
1 | 77e24b20-9d21-4952-a089-3c5c592b4e6d |
6e5cce71-3438-4045-9d54-607123e0557e |
05aab51a-8342-4d1f-88c4-6d733da5959a | 023110fa-7d24-4
6ec-ada8-d617d7c2adaf | a09bfb5d-3922-406d-b4e0-daafad96ffec
4 | 77e24b20-9d21-4952-a089-3c5c592b4e6d |
6e5cce71-3438-4045-9d54-607123e0557e |
05aab51a-8342-4d1f-88c4-6d733da5959a | a09bfb5d-3922-4
06d-b4e0-daafad96ffec | ----

erro msg :
Failed to delete snapshot 'Backup the VM' for VM 'vm-name.


vm-disk-info.py output:

Disk e94d711c-b50b-43bd-a67c-cb4643808d9d
(sd:0dc658da-feed-498b-bfd2-3950f7198e11)
Volumes:
 b9478a6c-28c5-403b-a889-226d16d399a5
 Disk 05aab51a-8342-4d1f-88c4-6d733da5959a
(sd:6e5cce71-3438-4045-9d54-607123e0557e)
Warning: volume 023110fa-7d24-46ec-ada8-d617d7c2adaf is in chain but
illegal
 Volumes:
 a09bfb5d-3922-406d-b4e0-daafad96ffec

engine.log :

https://www.dropbox.com/s/yfsaexpzdz3ngm1/engine.rar?dl=0

Thanks.


2016-05-11 18:39 GMT-03:00 Greg Padgett <gpadg...@redhat.com
<mailto:gpadg...@redhat.com>>:

On 05/11/2016 09:49 AM, Marcelo Leandro wrote:

hello,
i have problem for delete one snapshot.
i see the  error:
Due to partial snapshot removal, Snapshot 'Backup the VM' of
VM 'vmname'
now contains only the following disks: 'vmdiskname'.


Failed to delete snapshot 'Backup the VM' for VM 'vmname'.


Hi Marcelo,

Can you try to remove the snapshot again and attach the engine log
if it fails?

Thanks,
Greg

information in db :
   imagestatus |   storage_pool_id|
   storage_domain_id   |image_group_id
 |
   im
age_guid  |   parentid

-+--+--+--+
--+--
 1 | 77e24b20-9d21-4952-a089-3c5c592b4e6d |
6e5cce71-3438-4045-9d54-607123e0557e |
bfb1e6b5-7a06-41e4-b8b4-2e237ed0c7ab | 1bb7bd08-5ee8-4
a3b-8978-c15e15d1c5e4 | 6008671c-2f9d-48de-94f3-cc7d6273de31
 4 | 77e24b20-9d21-4952-a089-3c5c592b4e6d |
6e5cce71-3438-4045-9d54-607123e0557e |
bfb1e6b5-7a06-41e4-b8b4-2e237ed0c7ab | 6008671c-2f9d-4
8de-94f3-cc7d6273de31 | ----


output the script vm-disk-info.py


   Disk bfb1e6b5-7a06-41e4-b8b4-2e237ed0c7ab
(sd:6e5cce71-3438-4045-9d54-607123e0557e)
Warning: volume 1bb7bd08-5ee8-4a3b-8978-c15e15d1c5e4 is in
chain but illegal
  Volumes:
  6008671c-2f9d-48de-94f3-cc7d6273de31
  1bb7bd08-5ee8-4a3b-8978-c15e15d1c5e4


output the  command md5sum :
volume :   1bb7bd08-5ee8-4a3b-8978-c15e15d1c5e4
4c05c8258ed5746da6ac2cdb80c8974e
1bb7bd08-5ee

Re: [ovirt-users] Problem remove snapshot

[Greg Padgett]

On 05/11/2016 09:49 AM, Marcelo Leandro wrote:

hello,
i have problem for delete one snapshot.
i see the  error:
Due to partial snapshot removal, Snapshot 'Backup the VM' of VM 'vmname'
now contains only the following disks: 'vmdiskname'.


Failed to delete snapshot 'Backup the VM' for VM 'vmname'.


Hi Marcelo,

Can you try to remove the snapshot again and attach the engine log if it 
fails?


Thanks,
Greg


information in db :
  imagestatus |   storage_pool_id|
  storage_domain_id   |image_group_id|
  im
age_guid  |   parentid
-+--+--+--+
--+--
1 | 77e24b20-9d21-4952-a089-3c5c592b4e6d |
6e5cce71-3438-4045-9d54-607123e0557e |
bfb1e6b5-7a06-41e4-b8b4-2e237ed0c7ab | 1bb7bd08-5ee8-4
a3b-8978-c15e15d1c5e4 | 6008671c-2f9d-48de-94f3-cc7d6273de31
4 | 77e24b20-9d21-4952-a089-3c5c592b4e6d |
6e5cce71-3438-4045-9d54-607123e0557e |
bfb1e6b5-7a06-41e4-b8b4-2e237ed0c7ab | 6008671c-2f9d-4
8de-94f3-cc7d6273de31 | ----


output the script vm-disk-info.py


  Disk bfb1e6b5-7a06-41e4-b8b4-2e237ed0c7ab
(sd:6e5cce71-3438-4045-9d54-607123e0557e)
Warning: volume 1bb7bd08-5ee8-4a3b-8978-c15e15d1c5e4 is in chain but illegal
 Volumes:
 6008671c-2f9d-48de-94f3-cc7d6273de31
 1bb7bd08-5ee8-4a3b-8978-c15e15d1c5e4


output the  command md5sum :
volume :   1bb7bd08-5ee8-4a3b-8978-c15e15d1c5e4
4c05c8258ed5746da6ac2cdb80c8974e  1bb7bd08-5ee8-4a3b-8978-c15e15d1c5e4

ec74d4d8189a5ea24720349868ff7ab7  1bb7bd08-5ee8-4a3b-8978-c15e15d1c5e4

the volume change

output the command md5sum :
volume: 6008671c-2f9d-48de-94f3-cc7d6273de31

86daf229ad0b65fb8be3a3de6b0ee840  6008671c-2f9d-48de-94f3-cc7d6273de31

86daf229ad0b65fb8be3a3de6b0ee840  6008671c-2f9d-48de-94f3-cc7d6273de31

the volume not change

Thanks.


___
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] Can't remove snapshot

[Greg Padgett]

On 03/18/2016 03:10 PM, Nir Soffer wrote:

On Fri, Mar 18, 2016 at 7:55 PM, Nathanaël Blanchet <blanc...@abes.fr> wrote:

Hello,

I can create snapshot when no one exists but I'm not able to remove it
after.


Do you try to remove it when the vm is running?


It concerns many of my vms, and when stopping them, they can't boot anymore
because of the illegal status of the disks, this leads me in a critical
situation

VM fedora23 is down with error. Exit message: Unable to get volume size for
domain 5ef8572c-0ab5-4491-994a-e4c30230a525 volume
e5969faa-97ea-41df-809b-cc62161ab1bc

As far as I didn't initiate any live merge, am I concerned by this bug
https://bugzilla.redhat.com/show_bug.cgi?id=1306741?
I'm running 3.6.2, will upgrade to 3.6.3 solve this issue?


If you tried to remove a snapshot while the vm is running you did
initiate live merge, and this bug may effect you.

Adding Greg for adding more info about this.



Hi Nathanaël,

From the logs you pasted below, showing RemoveSnapshotSingleDiskCommand 
(not ..SingleDiskLiveCommand), it looks like a non-live snapshot.  In that 
case, bug 1306741 would not affect you.


To dig deeper, we'd need to know the root cause of why the image could not 
be deleted.  You should be able to find some clues in your engine log 
above the snippet you pasted below, or perhaps something in the vdsm log 
will reveal the reason.


Thanks,
Greg



2016-03-18 18:26:57,652 ERROR
[org.ovirt.engine.core.bll.RemoveSnapshotCommand]
(org.ovirt.thread.pool-8-thread-39) [a1e222d] Ending command
'org.ovirt.engine.core.bll.RemoveSnapshotCommand' with failure.
2016-03-18 18:26:57,663 ERROR
[org.ovirt.engine.core.bll.RemoveSnapshotCommand]
(org.ovirt.thread.pool-8-thread-39) [a1e222d] Could not delete image
'46e9ecc8-e168-4f4d-926c-e769f5df1f2c' from snapshot
'88fcf167-4302-405e-825f-ad7e0e9f6564'
2016-03-18 18:26:57,678 WARN
[org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
(org.ovirt.thread.pool-8-thread-39) [a1e222d] Correlation ID: a1e222d, Job
ID: 00d3e364-7e47-4022-82ff-f772cd79d4a1, Call Stack: null, Custom Event ID:
-1, Message: Due to partial snapshot removal, Snapshot 'test' of VM
'fedora23' now contains only the following disks: 'fedora23_Disk1'.
2016-03-18 18:26:57,695 ERROR
[org.ovirt.engine.core.bll.RemoveSnapshotSingleDiskCommand]
(org.ovirt.thread.pool-8-thread-39) [724e99fd] Ending command
'org.ovirt.engine.core.bll.RemoveSnapshotSingleDiskCommand' with failure.
2016-03-18 18:26:57,708 ERROR
[org.ovirt.engine.core.dal.dbbroker.auditloghandlin

Thank you for your help.


Le 23/02/2016 19:51, Greg Padgett a écrit :


On 02/22/2016 07:10 AM, Marcelo Leandro wrote:


Hello,

The bug with snapshot  it will be fixed in ovirt 3.6.3?

thanks.



Hi Marcelo,

Yes, the bug below (bug 1301709) is now targeted to 3.6.3.

Thanks,
Greg


2016-02-18 11:34 GMT-03:00 Adam Litke <ali...@redhat.com>:


On 18/02/16 10:37 +0100, Rik Theys wrote:



Hi,

On 02/17/2016 05:29 PM, Adam Litke wrote:



On 17/02/16 11:14 -0500, Greg Padgett wrote:



On 02/17/2016 03:42 AM, Rik Theys wrote:



Hi,

On 02/16/2016 10:52 PM, Greg Padgett wrote:



On 02/16/2016 08:50 AM, Rik Theys wrote:



   From the above I conclude that the disk with id that ends with



Similar to what I wrote to Marcelo above in the thread, I'd
recommend
running the "VM disk info gathering tool" attached to [1].  It's
the
best way to ensure the merge was completed and determine which
image
is
the "bad" one that is no longer in use by any volume chains.




I've ran the disk info gathering tool and this outputs (for the
affected
VM):

VM lena
  Disk b2390535-744f-4c02-bdc8-5a897226554b
(sd:a7ba2db3-517c-408a-8b27-ea45989d6416)
  Volumes:
  24d78600-22f4-44f7-987b-fbd866736249

The id of the volume is the ID of the snapshot that is marked
"illegal".
So the "bad" image would be the dc39 one, which according to the UI
is
in use by the "Active VM" snapshot. Can this make sense?




It looks accurate.  Live merges are "backwards" merges, so the merge
would have pushed data from the volume associated with "Active VM"
into the volume associated with the snapshot you're trying to remove.

Upon completion, we "pivot" so that the VM uses that older volume,
and
we update the engine database to reflect this (basically we
re-associate that older volume with, in your case, "Active VM").

In your case, it seems the pivot operation was done, but the database
wasn't updated to reflect it.  Given snapshot/image associations
e.g.:

   VM Name  Snapshot Name  Volume
   ---  -  --
   My-VMActive VM  123-abc
   My-VMMy-Snapshot789-def

My-VM in your case is actually running on volume 789-def.  If you run
the db fixup script and supply ("My-VM", "My-Snapshot", "123-abc")
(note the volume is the newer, "bad" one), then it will switch the

Re: [ovirt-users] Can't remove snapshot

[Greg Padgett]

On 02/22/2016 07:10 AM, Marcelo Leandro wrote:

Hello,

The bug with snapshot  it will be fixed in ovirt 3.6.3?

thanks.



Hi Marcelo,

Yes, the bug below (bug 1301709) is now targeted to 3.6.3.

Thanks,
Greg


2016-02-18 11:34 GMT-03:00 Adam Litke <ali...@redhat.com>:

On 18/02/16 10:37 +0100, Rik Theys wrote:


Hi,

On 02/17/2016 05:29 PM, Adam Litke wrote:


On 17/02/16 11:14 -0500, Greg Padgett wrote:


On 02/17/2016 03:42 AM, Rik Theys wrote:


Hi,

On 02/16/2016 10:52 PM, Greg Padgett wrote:


On 02/16/2016 08:50 AM, Rik Theys wrote:


  From the above I conclude that the disk with id that ends with


Similar to what I wrote to Marcelo above in the thread, I'd recommend
running the "VM disk info gathering tool" attached to [1].  It's the
best way to ensure the merge was completed and determine which image
is
the "bad" one that is no longer in use by any volume chains.



I've ran the disk info gathering tool and this outputs (for the
affected
VM):

VM lena
 Disk b2390535-744f-4c02-bdc8-5a897226554b
(sd:a7ba2db3-517c-408a-8b27-ea45989d6416)
 Volumes:
 24d78600-22f4-44f7-987b-fbd866736249

The id of the volume is the ID of the snapshot that is marked
"illegal".
So the "bad" image would be the dc39 one, which according to the UI is
in use by the "Active VM" snapshot. Can this make sense?



It looks accurate.  Live merges are "backwards" merges, so the merge
would have pushed data from the volume associated with "Active VM"
into the volume associated with the snapshot you're trying to remove.

Upon completion, we "pivot" so that the VM uses that older volume, and
we update the engine database to reflect this (basically we
re-associate that older volume with, in your case, "Active VM").

In your case, it seems the pivot operation was done, but the database
wasn't updated to reflect it.  Given snapshot/image associations e.g.:

  VM Name  Snapshot Name  Volume
  ---  -  --
  My-VMActive VM  123-abc
  My-VMMy-Snapshot789-def

My-VM in your case is actually running on volume 789-def.  If you run
the db fixup script and supply ("My-VM", "My-Snapshot", "123-abc")
(note the volume is the newer, "bad" one), then it will switch the
volume association for you and remove the invalid entries.

Of course, I'd shut down the VM, and back up the db beforehand.



I've executed the sql script and it seems to have worked. Thanks!


"Active VM" should now be unused; it previously (pre-merge) was the
data written since the snapshot was taken.  Normally the larger actual
size might be from qcow format overhead.  If your listing above is
complete (ie one volume for the vm), then I'm not sure why the base
volume would have a larger actual size than virtual size.

Adam, Nir--any thoughts on this?



There is a bug which has caused inflation of the snapshot volumes when
performing a live merge.  We are submitting fixes for 3.5, 3.6, and
master right at this moment.



Which bug number is assigned to this bug? Will upgrading to a release
with a fix reduce the disk usage again?



See https://bugzilla.redhat.com/show_bug.cgi?id=1301709 for the bug.
It's about a clone disk failure after the problem occurs.
Unfortunately, there is not an automatic way to repair the raw base
volumes if they were affected by this bug.  They will need to be
manually shrunk using lvreduce if you are certain that they are
inflated.


--
Adam Litke

___
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] Master Storage Domain Locked

[Greg Padgett]

On 02/19/2016 11:21 PM, Rob Abshear wrote:

We lost power to an ovirt 3.5.1.1-1.el7.centos cluster.  When things came
back, the master storage domain was locked.  All of the nodes are non
operational.  Is there a procedure for unlocking a storage domain?  I have
used the unlock-entity script for other object types.


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



Hi Rob,

Is this still relevant?  If so, can you send engine logs covering the time 
when the domain went to locked status?  (We may need vdsm logs too.)  It's 
possible something went wrong in the environment, or perhaps it's a bug.


Thanks,
Greg


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

Re: [ovirt-users] Manually assign DC and Cluster to Blank template

[Greg Padgett]

On 02/18/2016 02:49 AM, nico...@devels.es wrote:

El 2016-02-17 22:55, Greg Padgett escribió:

On 02/16/2016 07:56 AM, nico...@devels.es wrote:

Hi,

We upgraded from oVirt 3.5 and 3.6 and deleted the Default cluster, so
now we have the Blank template with no DC and no Cluster, thus our
users
can't use it.

Is there a way to manually set these two parameters to the current DC
and Cluster values for the Blank template? I tried editing it but see
no
option to set them.

Thanks.

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



Hi Nicolás,

Removing the default cluster should be ok, since the templates don't
bind VMs to a DC/Cluster--you should be able to specify the DC/Cluster
when creating a VM.

HTH,
Greg


Hi Greg,

I'll elaborate a bit further on the issue. I'm attaching a screenshot of
the 'Templates' tab on the webadmin pane - As you can see, all of them
have a Data Center and a Cluster assigned (columns 4 and 5) but the
Blank template (because we deleted the default DC). Even if this
template has the 'Everyone' permission, as we're granting permissions to
our users on the Data Center, they are not able to see the Blank
template in the list when deploying new machines in the userportal view,
so currently they necessarily need to choose a template from the list
which is not Blank, and that's an issue to some of them.

That's why I was wondering if there's a manual way to assign the DC and
Cluster to the Blank template, even modifying it directly in the DB, so
the users see it in the userportal.

Any hint is very appreciated.

Regards,

Nicolás



The default template is unbound to a DC/Cluster by design, so while 
forcing an assignment in the db could work (not sure), it's not supported 
and likely to break at some point.  See [1] for details on that 3.6 change.


However, since the root issue seems to be users not being able to use the 
template, you should be able to assign permissions that allow this from 
the Templates > Permissions sub-tab.  If this isn't working, it could be a 
bug.


[1] 
http://wiki.ovirt.org/develop/release-management/features/virt/blank-to-defaults/


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

Re: [ovirt-users] Manually assign DC and Cluster to Blank template

[Greg Padgett]

On 02/16/2016 07:56 AM, nico...@devels.es wrote:

Hi,

We upgraded from oVirt 3.5 and 3.6 and deleted the Default cluster, so
now we have the Blank template with no DC and no Cluster, thus our users
can't use it.

Is there a way to manually set these two parameters to the current DC
and Cluster values for the Blank template? I tried editing it but see no
option to set them.

Thanks.

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



Hi Nicolás,

Removing the default cluster should be ok, since the templates don't bind 
VMs to a DC/Cluster--you should be able to specify the DC/Cluster when 
creating a VM.


HTH,
Greg

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

Re: [ovirt-users] Can't remove snapshot

[Greg Padgett]

On 02/17/2016 03:42 AM, Rik Theys wrote:

Hi,

On 02/16/2016 10:52 PM, Greg Padgett wrote:

On 02/16/2016 08:50 AM, Rik Theys wrote:

Hi,

I'm trying to determine the correct "bad_img" uuid in my case.

The VM has two snapshots:

* The "Active VM" snapshot which has a disk that has an actual size
that's 5GB larger than the virtual size. It has a creation date that
matches the timestamp at which I created the second snapshot. The "disk
snapshot id" for this snapshot ends with dc39.

* A "before jessie upgrade" snapshot that has status "illegal". It has
an actual size that's 2GB larger than the virtual size. The creation
date matches the date the VM was initialy created. The disk snapshot id
ends with 6249.

  From the above I conclude that the disk with id that ends with 6249 is
the "bad" img I need to specify.


Similar to what I wrote to Marcelo above in the thread, I'd recommend
running the "VM disk info gathering tool" attached to [1].  It's the
best way to ensure the merge was completed and determine which image is
the "bad" one that is no longer in use by any volume chains.


I've ran the disk info gathering tool and this outputs (for the affected
VM):

VM lena
 Disk b2390535-744f-4c02-bdc8-5a897226554b
(sd:a7ba2db3-517c-408a-8b27-ea45989d6416)
 Volumes:
 24d78600-22f4-44f7-987b-fbd866736249

The id of the volume is the ID of the snapshot that is marked "illegal".
So the "bad" image would be the dc39 one, which according to the UI is
in use by the "Active VM" snapshot. Can this make sense?


It looks accurate.  Live merges are "backwards" merges, so the merge would 
have pushed data from the volume associated with "Active VM" into the 
volume associated with the snapshot you're trying to remove.


Upon completion, we "pivot" so that the VM uses that older volume, and we 
update the engine database to reflect this (basically we re-associate that 
older volume with, in your case, "Active VM").


In your case, it seems the pivot operation was done, but the database 
wasn't updated to reflect it.  Given snapshot/image associations e.g.:


  VM Name  Snapshot Name  Volume
  ---  -  --
  My-VMActive VM  123-abc
  My-VMMy-Snapshot789-def

My-VM in your case is actually running on volume 789-def.  If you run the 
db fixup script and supply ("My-VM", "My-Snapshot", "123-abc") (note the 
volume is the newer, "bad" one), then it will switch the volume 
association for you and remove the invalid entries.


Of course, I'd shut down the VM, and back up the db beforehand.

I'm not terribly familiar with how vdsm handles block storage, but I'd 
image you could then e.g. `lvchange -an` the bad volume's LV, start the 
VM, and verify that the data is current without having the to-be-removed 
volume active, just to make sure everything lines up before running the 
vdsClient verb to remove the volume.



Both the "Active VM" and the defective snapshot have an actual size
that's bigger than the virtual size of the disk. When I remove the bad
disk image/snapshot, will the actual size of the "Active VM" snapshot
return to the virtual size of the disk? What's currently stored in the
"Active VM" snapshot?


"Active VM" should now be unused; it previously (pre-merge) was the data 
written since the snapshot was taken.  Normally the larger actual size 
might be from qcow format overhead.  If your listing above is complete (ie 
one volume for the vm), then I'm not sure why the base volume would have a 
larger actual size than virtual size.


Adam, Nir--any thoughts on this?


Would cloning the VM (and removing the original VM afterwards) work as
an alternate way to clean this up? Or will the clone operation also
clone the snapshots?


It would try to clone everything in the engine db, so no luck there.


Regards,

Rik


If indeed the "bad" image (whichever one it is) is no longer in use,
then it's possible the image wasn't successfully removed from storage.
There are 2 ways to fix this:

   a) Run the db fixup script to remove the records for the merged image,
  and run the vdsm command by hand to remove it from storage.
   b) Adjust the db records so a merge retry would start at the right
  place, and re-run live merge.

Given that your merge retries were failing, option a) seems most likely
to succeed.  The db fixup script is attached to [1]; as parameters you
would need to provide the vm name, snapshot name, and the id of the
unused image as verified by the disk info tool.

To remove the stale LV, the vdsm deleteVolume verb would then be run
from `vdsClient` -- but note that this must be run _on the SPM host_.
It will not only perform lvremove, but also do housekeeping on other
storage metadata to keep everything consistent.  For 

Re: [ovirt-users] Can't remove snapshot

[Greg Padgett]

On 02/16/2016 05:51 PM, Marcelo Leandro wrote:

Hello Greg,
I not see disk image at the storage:

[root@srv-qemu01 ~]# cd
/rhev/data-center/77e24b20-9d21-4952-a089-3c5c592b4e6d/c2dc0101-748e-4a7b-9913-47993eaa52bd/images/b7a27d0c-57cc-490e-a3f8-b4981310a9b0/
[root@srv-qemu01 b7a27d0c-57cc-490e-a3f8-b4981310a9b0]# ls
2e59f7f2-9e30-460e-836a-5e0d3d625059

But in DB i see :

SELECT imagestatus,storage_pool_id, storage_domain_id, image_group_id,
image_guid, parentid FROM
storage_domains,image_storage_domain_map,images,vm_static,vm_device
WHERE image_storage_domain_map.image_id = images.image_guid AND
storage_domains.id = image_storage_domain_map.storage_domain_id AND
vm_static.vm_guid = vm_device.vm_id AND images.image_group_id =
vm_device.device_id AND vm_device.device = 'disk' AND
vm_static.vm_name = 'Servidor-Cliente';
  imagestatus |   storage_pool_id|
storage_domain_id   |image_group_id|
image_guid  |   parentid

-+--+--+--+--+---
---
1 | 77e24b20-9d21-4952-a089-3c5c592b4e6d |
c2dc0101-748e-4a7b-9913-47993eaa52bd |
b7a27d0c-57cc-490e-a3f8-b4981310a9b0 |
 | 2e59f7f2-9e30-460e-836
a-5e0d3d625059
4 | 77e24b20-9d21-4952-a089-3c5c592b4e6d |
c2dc0101-748e-4a7b-9913-47993eaa52bd |
b7a27d0c-57cc-490e-a3f8-b4981310a9b0 |
2e59f7f2-9e30-460e-836a-5e0d3d625059 | ---000
0-

in this case I have that update the imagem with you describe?

"""Arguments in your case would be the VM name, snapshot name, and the
UUID of the image that is missing from your storage.  (You may need to
manually mark the image as illegal first, [2]). ""

Thanks.


I believe it would still be prudent to verify that image 
7f8bb099-9a18-4e89-bf48-57e56e5770d2 is supposed to be missing, by running 
the disk info tool from:

  https://bugzilla.redhat.com/show_bug.cgi?id=1306741.

Once we verify that it's ok to remove the image, then I'd proceed to clean 
up the db records via the image cleanup sql script.


Thanks,
Greg

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

Re: [ovirt-users] Can't remove snapshot

[Greg Padgett]

On 02/16/2016 08:50 AM, Rik Theys wrote:

Hi,

I'm trying to determine the correct "bad_img" uuid in my case.

The VM has two snapshots:

* The "Active VM" snapshot which has a disk that has an actual size
that's 5GB larger than the virtual size. It has a creation date that
matches the timestamp at which I created the second snapshot. The "disk
snapshot id" for this snapshot ends with dc39.

* A "before jessie upgrade" snapshot that has status "illegal". It has
an actual size that's 2GB larger than the virtual size. The creation
date matches the date the VM was initialy created. The disk snapshot id
ends with 6249.

 From the above I conclude that the disk with id that ends with 6249 is
the "bad" img I need to specify.


Similar to what I wrote to Marcelo above in the thread, I'd recommend 
running the "VM disk info gathering tool" attached to [1].  It's the best 
way to ensure the merge was completed and determine which image is the 
"bad" one that is no longer in use by any volume chains.


If indeed the "bad" image (whichever one it is) is no longer in use, then 
it's possible the image wasn't successfully removed from storage.  There 
are 2 ways to fix this:


  a) Run the db fixup script to remove the records for the merged image,
 and run the vdsm command by hand to remove it from storage.
  b) Adjust the db records so a merge retry would start at the right
 place, and re-run live merge.

Given that your merge retries were failing, option a) seems most likely to 
succeed.  The db fixup script is attached to [1]; as parameters you would 
need to provide the vm name, snapshot name, and the id of the unused image 
as verified by the disk info tool.


To remove the stale LV, the vdsm deleteVolume verb would then be run from 
`vdsClient` -- but note that this must be run _on the SPM host_.  It will 
not only perform lvremove, but also do housekeeping on other storage 
metadata to keep everything consistent.  For this verb I believe you'll 
need to supply not only the unused image id, but also the pool, domain, 
and image group ids from your database queries.


I hope that helps.

Greg

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1306741



However, I grepped the output from 'lvs' on the SPM host of the cluster
and both disk id's are returned:

[root@amazone ~]# lvs | egrep 'cd39|6249'
   24d78600-22f4-44f7-987b-fbd866736249
a7ba2db3-517c-408a-8b27-ea45989d6416 -wi-ao   34.00g

   81458622-aa54-4f2f-b6d8-75e7db36cd39
a7ba2db3-517c-408a-8b27-ea45989d6416 -wi---5.00g


I expected the "bad" img would no longer be found?

The SQL script only cleans up the database and not the logical volumes.
Would running the script not keep a stale LV around?

Also, from the lvs output it seems the "bad" disk is bigger than the
"good" one.

Is it possible the snapshot still needs to be merged?? If so, how can I
initiate that?

Regards,

Rik


On 02/16/2016 02:02 PM, Rik Theys wrote:

Hi Greg,



2016-02-09 21:30 GMT-03:00 Greg Padgett <gpadg...@redhat.com>:

On 02/09/2016 06:08 AM, Michal Skrivanek wrote:




On 03 Feb 2016, at 10:37, Rik Theys <rik.th...@esat.kuleuven.be> wrote:



I can see the snapshot in the "Disk snapshot" tab of the storage. It has
a status of "illegal". Is it OK to (try to) remove this snapshot? Will
this impact the running VM and/or disk image?



No, it’s not ok to remove it while live merge(apparently) is still ongoing
I guess that’s a live merge bug?



Indeed, this is bug 1302215.

I wrote a sql script to help with cleanup in this scenario, which you can
find attached to the bug along with a description of how to use it[1].

However, Rik, before trying that, would you be able to run the attached
script [2] (or just the db query within) and forward the output to me? I'd
like to make sure everything looks as it should before modifying the db
directly.


I ran the following query on the engine database:

select images.* from images join snapshots ON (images.vm_snapshot_id =
snapshots.snapshot_id)
join vm_static on (snapshots.vm_id = vm_static.vm_guid)
where vm_static.vm_name = 'lena' and snapshots.description='before
jessie upgrade';

The resulting output is:

   image_guid  | creation_date  |size
 |   it_guid|   parentid
   | images
tatus |lastmodified|vm_snapshot_id
   | volume_type | volume_format |image_group_id|
 _create_da
te  | _update_date  | active |
volume_classification
--++-+--+--+---
--++--+-+---+--

Re: [ovirt-users] Can't remove snapshot

[Greg Padgett]

ete
2016-02-16 08:46:42,850 INFO
[org.ovirt.engine.core.vdsbroker.VmAnalyzer]
(DefaultQuartzScheduler_Worker-84) [] VM job
'77669e28-4aa2-4038-b7b6-1a949a1d039e': In progress, updating
2016-02-16 08:46:42,854 INFO
[org.ovirt.engine.core.vdsbroker.vdsbroker.FullListVDSCommand]
(DefaultQuartzScheduler_Worker-84) [] START,
FullListVDSCommand(HostName = ,
FullListVDSCommandParameters:{runAsync='true',
hostId='aebc403a-ec4e-4346-9029-6353d5d76f01',
vds='Host[,aebc403a-ec4e-4346-9029-6353d5d76f01]',
vmIds='[6af1f9c3-7210-45c3-90dc-bd7793346c0c]'}), log id: 74961dad

I cannot see the snapshot disk at the storage domain:

[root@ ~]# cd 
/rhev/data-center/77e24b20-9d21-4952-a089-3c5c592b4e6d/c1938052-7524-404c-bac9-f238227269ea/images/b7a27d0c-57cc-490e-a3f8-b4981310a9b0/
[root@ b7a27d0c-57cc-490e-a3f8-b4981310a9b0]# ls
2e59f7f2-9e30-460e-836a-5e0d3d625059  2e59f7f2-9e30-460e-836a-5e0d3d625059.meta

Thanks.

2016-02-09 21:30 GMT-03:00 Greg Padgett <gpadg...@redhat.com>:

On 02/09/2016 06:08 AM, Michal Skrivanek wrote:




On 03 Feb 2016, at 10:37, Rik Theys <rik.th...@esat.kuleuven.be> wrote:

Hi,

In the mean time I've noticed the following entries in our periodic
logcheck output:

Feb  3 09:05:53 orinoco journal: block copy still active: disk 'vda' not
ready for pivot yet
Feb  3 09:05:53 orinoco journal: vdsm root ERROR Unhandled
exception#012Traceback (most recent call last):#012  File
"/usr/lib/python2.7/site-packages/vdsm/utils.py", line 734, in
wrapper#012return f(*a, **kw)#012  File
"/usr/share/vdsm/virt/vm.py", line 5168, in run#012
self.tryPivot()#012  File "/usr/share/vdsm/virt/vm.py", line 5137, in
tryPivot#012ret = self.vm._dom.blockJobAbort(self.drive.name,
flags)#012  File "/usr/share/vdsm/virt/virdomain.py", line 68, in f#012
ret = attr(*args, **kwargs)#012  File
"/usr/lib/python2.7/site-packages/vdsm/libvirtconnection.py", line 124,
in wrapper#012ret = f(*args, **kwargs)#012  File
"/usr/lib64/python2.7/site-packages/libvirt.py", line 733, in
blockJobAbort#012if ret == -1: raise libvirtError
('virDomainBlockJobAbort() failed', dom=self)#012libvirtError: block
copy still active: disk 'vda' not ready for pivot yet

This is from the host running the VM.

Note that this host is not the SPM of the cluster. I always thought all
operations on disk volumes happened on the SPM host?

My question still remains:


I can see the snapshot in the "Disk snapshot" tab of the storage. It has
a status of "illegal". Is it OK to (try to) remove this snapshot? Will
this impact the running VM and/or disk image?



No, it’s not ok to remove it while live merge(apparently) is still ongoing
I guess that’s a live merge bug?



Indeed, this is bug 1302215.

I wrote a sql script to help with cleanup in this scenario, which you can
find attached to the bug along with a description of how to use it[1].

However, Rik, before trying that, would you be able to run the attached
script [2] (or just the db query within) and forward the output to me? I'd
like to make sure everything looks as it should before modifying the db
directly.

Thanks,
Greg

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1302215#c13
(Also note that the engine should be stopped before running this.)

[2] Arguments are the ovirt db name, db user, and the name of the vm you
were performing live merge on.



Thanks,
michal




Regards,

Rik

On 02/03/2016 10:26 AM, Rik Theys wrote:


Hi,

I created a snapshot of a running VM prior to an OS upgrade. The OS
upgrade has now been succesful and I would like to remove the snapshot.
I've selected the snapshot in the UI and clicked Delete to start the
task.

After a few minutes, the task has failed. When I click delete again on
the same snapshot, the failed message is returned after a few seconds.


  From browsing through the engine log (attached) it seems the snapshot


was correctly merged in the first try but something went wrong in the
finalizing fase. On retries, the log indicates the snapshot/disk image
no longer exists and the removal of the snapshot fails for this reason.

Is there any way to clean up this snapshot?

I can see the snapshot in the "Disk snapshot" tab of the storage. It has
a status of "illegal". Is it OK to (try to) remove this snapshot? Will
this impact the running VM and/or disk image?

Regards,

Rik



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




--
Rik Theys
System Engineer
KU Leuven - Dept. Elektrotechniek (ESAT)
Kasteelpark Arenberg 10 bus 2440  - B-3001 Leuven-Heverlee
+32(0)16/32.11.07

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



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

Re: [ovirt-users] Can't remove snapshot

[Greg Padgett]

On 02/09/2016 06:08 AM, Michal Skrivanek wrote:



On 03 Feb 2016, at 10:37, Rik Theys  wrote:

Hi,

In the mean time I've noticed the following entries in our periodic
logcheck output:

Feb  3 09:05:53 orinoco journal: block copy still active: disk 'vda' not
ready for pivot yet
Feb  3 09:05:53 orinoco journal: vdsm root ERROR Unhandled
exception#012Traceback (most recent call last):#012  File
"/usr/lib/python2.7/site-packages/vdsm/utils.py", line 734, in
wrapper#012return f(*a, **kw)#012  File
"/usr/share/vdsm/virt/vm.py", line 5168, in run#012
self.tryPivot()#012  File "/usr/share/vdsm/virt/vm.py", line 5137, in
tryPivot#012ret = self.vm._dom.blockJobAbort(self.drive.name,
flags)#012  File "/usr/share/vdsm/virt/virdomain.py", line 68, in f#012
   ret = attr(*args, **kwargs)#012  File
"/usr/lib/python2.7/site-packages/vdsm/libvirtconnection.py", line 124,
in wrapper#012ret = f(*args, **kwargs)#012  File
"/usr/lib64/python2.7/site-packages/libvirt.py", line 733, in
blockJobAbort#012if ret == -1: raise libvirtError
('virDomainBlockJobAbort() failed', dom=self)#012libvirtError: block
copy still active: disk 'vda' not ready for pivot yet

This is from the host running the VM.

Note that this host is not the SPM of the cluster. I always thought all
operations on disk volumes happened on the SPM host?

My question still remains:


I can see the snapshot in the "Disk snapshot" tab of the storage. It has
a status of "illegal". Is it OK to (try to) remove this snapshot? Will
this impact the running VM and/or disk image?


No, it’s not ok to remove it while live merge(apparently) is still ongoing
I guess that’s a live merge bug?


Indeed, this is bug 1302215.

I wrote a sql script to help with cleanup in this scenario, which you can 
find attached to the bug along with a description of how to use it[1].


However, Rik, before trying that, would you be able to run the attached 
script [2] (or just the db query within) and forward the output to me? I'd 
like to make sure everything looks as it should before modifying the db 
directly.


Thanks,
Greg

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1302215#c13
(Also note that the engine should be stopped before running this.)

[2] Arguments are the ovirt db name, db user, and the name of the vm you 
were performing live merge on.



Thanks,
michal




Regards,

Rik

On 02/03/2016 10:26 AM, Rik Theys wrote:

Hi,

I created a snapshot of a running VM prior to an OS upgrade. The OS
upgrade has now been succesful and I would like to remove the snapshot.
I've selected the snapshot in the UI and clicked Delete to start the task.

After a few minutes, the task has failed. When I click delete again on
the same snapshot, the failed message is returned after a few seconds.


 From browsing through the engine log (attached) it seems the snapshot

was correctly merged in the first try but something went wrong in the
finalizing fase. On retries, the log indicates the snapshot/disk image
no longer exists and the removal of the snapshot fails for this reason.

Is there any way to clean up this snapshot?

I can see the snapshot in the "Disk snapshot" tab of the storage. It has
a status of "illegal". Is it OK to (try to) remove this snapshot? Will
this impact the running VM and/or disk image?

Regards,

Rik



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




--
Rik Theys
System Engineer
KU Leuven - Dept. Elektrotechniek (ESAT)
Kasteelpark Arenberg 10 bus 2440  - B-3001 Leuven-Heverlee
+32(0)16/32.11.07

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





vm_snapshots.sh
Description: application/shellscript
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] Data(Master)

[Greg Padgett]

On 12/14/2015 01:57 AM, Sandvik Agustin wrote:

Hi,
This is what inside my /etc/lvm/archive/
"ls /etc/lvm/archive/
39757758-c149-41da-8479-74b4d21635a0_0-1936952678.vg

4a0a7b1a-a98c-4bc4-86eb-b215cfa8da24_0-147069828.vg

4a0a7b1a-a98c-4bc4-86eb-b215cfa8da24_1-849682777.vg

4a0a7b1a-a98c-4bc4-86eb-b215cfa8da24_2-1626145851.vg

4c0c34ec-d44b-4f3e-8e10-76b82b5fa118_0-1451865950.vg

4c0c34ec-d44b-4f3e-8e10-76b82b5fa118_1-587463327.vg

4c0c34ec-d44b-4f3e-8e10-76b82b5fa118_2-321869468.vg

4c0c34ec-d44b-4f3e-8e10-76b82b5fa118_3-117963502.vg

aa2ae33a-47ad-43a2-a623-cbea4770cbd0_0-1774160120.vg

aa2ae33a-47ad-43a2-a623-cbea4770cbd0_1-937915900.vg

afb04ab7-ecc5-4079-9700-43b6d01c8a5b_0-1996551186.vg

afb04ab7-ecc5-4079-9700-43b6d01c8a5b_1-5564790.vg

afb04ab7-ecc5-4079-9700-43b6d01c8a5b_2-617819029.vg

cce50b8e-a566-4ba9-a2b9-a978e44f3684_0-1336023522.vg

cce50b8e-a566-4ba9-a2b9-a978e44f3684_1-210534184.vg

cce50b8e-a566-4ba9-a2b9-a978e44f3684_2-159368298.vg

HostVG_0-1625691793.vg"

And this is what inside my /etc/lvm/backup/
"ls /etc/lvm/backup/
39757758-c149-41da-8479-74b4d21635a0  afb04ab7-ecc5-4079-9700-43b6d01c8a5b
4a0a7b1a-a98c-4bc4-86eb-b215cfa8da24  cce50b8e-a566-4ba9-a2b9-a978e44f3684
4c0c34ec-d44b-4f3e-8e10-76b82b5fa118  HostVG
aa2ae33a-47ad-43a2-a623-cbea4770cbd0"

How do I find my UUID of old master storage domain?

Thanks,
Sandvik


Hi Sandvik,

Executing the following (all one line) on your engine machine will list 
the domain ids, names, and timestamp when that domain was master:


  psql  -U  -c 'select id, storage_name,
last_time_used_as_master from storage_domain_static'

(where of course  and  are the properties you set up 
during your initial engine installation.)


Greg

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

Re: [ovirt-users] Data(Master)

[Greg Padgett]

On 12/01/2015 02:39 PM, Sandvik Agustin wrote:

Hi users,

I'm using oVirt 3.4 on rhel 6.5 and it's working perfectly, but when i'm
setting up another Hypervisor and ovirt-engine I accidentally attach my
working storage "Data(Master)" to my 2nd one, and my problem is i'm unable
to re-attach it to my first one, is it possible to re-attach it without
loosing my vm guest disk images? And when I accidentally attach it to my
2nd one, It prompt me that "This operation might be unrecoverable and
distructive" is there a change that my 25 vm guest disk images will be
erased? God Bless.



Hi Sandvik,

I'm guessing this was iSCSI storage based on the error message.

If so, unfortunately the LVM metadata for the original storage domain will 
have been overwritten due to attaching the domain to the second setup, so 
it can't simply be re-attached to the first.


However, the images are probably still (mostly?) intact as long as the 
storage has been relatively untouched. If you feel it's worthwhile and are 
comfortable getting your hands a little dirty you may be able to recover 
some of the images by finding them on the LUN.


To do this, I'd check your hypervisors' /etc/lvm/archive directories and 
look for an lvm metadata backup as in [1],[2]. You want to look for a VG 
with the UUID of your old master storage domain. The LV names within would 
correspond to your old VM disk image UUIDs.  If you find this (via the 
backup, `pvck`, or even by scouring the first MB or so of the LUN), you 
might be able to recover it via some hints in [1] or [2] (of course 
maintenance/detach the domain from the second hypervisor first).  You can 
then copy the data onto a new storage domain.


Hope that helps,
Greg

[1] 
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Logical_Volume_Manager_Administration/mdatarecover.html


[2] 
http://serverfault.com/questions/223361/how-to-recover-logical-volume-deleted-with-lvremove




TIA
Sandvik


___
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] Live Storage Migration

[Greg Padgett]

On 09/14/2015 05:20 AM, Markus Stockhausen wrote:

Hi,

somehow I got lost about the possibility to do a live storage migration.
We are using OVirt 3.5.4 + FC20 Nodes (virt-preview - qemu 2.1.3)

 From the WebUI I have the following possibilites:

1) disk without snapshot: VMs tab -> Disks -> Move: Button is active
but it does not allow to do a migration. No selectable storage domain
although we have 2 NFS systems. Gives warning hints about
"you are doing live migration, bla bla, ..."

2) disk with snapshot: VMs tab -> Disk -> Move: Button greyed out

3) BUT! Disks tab -> Move: Works! No hints about "live migration"
I do not dare to click go ...

While 1/2 might be consistent they do not match to 3. Maybe someone
can give a hint what should work, what not and where me might have
an error.


Hi Markus,

Is this still relevant?  If so...

Live storage migration requires the following (from the code that 
determines if the "Move" buttons in 1/2 above are greyed or not):


 - cluster and dc version must be at least 3.2
 - vm must be stateful and up or paused
 - disk to migrate must be the active layer (ie not a snapshot)
 - disk images must be 'OK'

Is it possible one of these changed for the VM(s) in question?

Thanks,
Greg


Thanks.

Markus



___
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 3.5.4.2-1 - Snapshot Failure

[Greg Padgett]

On 09/18/2015 04:55 AM, Christian Rebel wrote:

Dear all,

I upgraded to 3.5.4.2-1.el7.centos, but I have still the Problem that I
can´t create  a snapshot!

Below some parts of the vdsm logs, does anyone have an idea to fix it,
please help...


Hi Christian, can you attach the full engine and vdsm log?  They may 
provide further clues about what went wrong.



###

167fb52d-0a51-4fea-9517-c668933ef4e2::ERROR::2015-09-18
09:33:33,957::task::866::Storage.TaskManager.Task::(_setError)
Task=`167fb52d-0a51-4fea-9517-c668933ef4e2`::Unexpected error

efb2447e-db4c-4dbd-84e4-5f8039949000::ERROR::2015-09-18
09:33:34,433::task::866::Storage.TaskManager.Task::(_setError)
Task=`efb2447e-db4c-4dbd-84e4-5f8039949000`::Unexpected error

167fb52d-0a51-4fea-9517-c668933ef4e2::ERROR::2015-09-18
09:33:34,802::task::866::Storage.TaskManager.Task::(_setError)
Task=`167fb52d-0a51-4fea-9517-c668933ef4e2`::Unexpected error

efb2447e-db4c-4dbd-84e4-5f8039949000::ERROR::2015-09-18
09:33:34,987::task::866::Storage.TaskManager.Task::(_setError)
Task=`efb2447e-db4c-4dbd-84e4-5f8039949000`::Unexpected error

VolumeDoesNotExist: Volume does not exist:
('36fd2e26-31a3-4284-8193-abd11c01a0f4',)

VolumeDoesNotExist: Volume does not exist:
('786e719d-7f54-4501-9e8d-688c1e482309',)

167fb52d-0a51-4fea-9517-c668933ef4e2::ERROR::2015-09-18
09:33:32,883::volume::264::Storage.Volume::(clone) cannot clone image
6281b597-020d-4ea7-a954-bb798a0ca4f1 volume
2a2015a1-f62c-4e32-8b04-77ece2ba4cc1 to
/rhev/data-center/0002-0002-0002-0002-0021/937822d9-8a59-490f-95b7-48371ae32253/images/6281b597-020d-4ea7-a954-bb798a0ca4f1/4e522ef0-279f-4c02-b581-c233d666eee1

efb2447e-db4c-4dbd-84e4-5f8039949000::ERROR::2015-09-18
09:33:34,375::volume::264::Storage.Volume::(clone) cannot clone image
e7e99288-ad83-406e-9cb6-7a5aa443de9b volume
c5762dec-d9d1-4842-84d1-05896d4d27fb to
/rhev/data-center/0002-0002-0002-0002-0021/937822d9-8a59-490f-95b7-48371ae32253/images/e7e99288-ad83-406e-9cb6-7a5aa443de9b/c60aa316-a16a-413e-81f3-e24858c3c7a7

CannotCloneVolume: Cannot clone volume:
u"src=/rhev/data-center/0002-0002-0002-0002-0021/937822d9-8a59-490f-95b7-48371ae32253/images/6281b597-020d-4ea7-a954-bb798a0ca4f1/2a2015a1-f62c-4e32-8b04-77ece2ba4cc1,
dst=/rhev/data-center/0002-0002-0002-0002-0021/937822d9-8a59-490f-95b7-48371ae32253/images/6281b597-020d-4ea7-a954-bb798a0ca4f1/4e522ef0-279f-4c02-b581-c233d666eee1:
Volume does not exist: ('36fd2e26-31a3-4284-8193-abd11c01a0f4',)"

CannotCloneVolume: Cannot clone volume:
u"src=/rhev/data-center/0002-0002-0002-0002-0021/937822d9-8a59-490f-95b7-48371ae32253/images/e7e99288-ad83-406e-9cb6-7a5aa443de9b/c5762dec-d9d1-4842-84d1-05896d4d27fb,
dst=/rhev/data-center/0002-0002-0002-0002-0021/937822d9-8a59-490f-95b7-48371ae32253/images/e7e99288-ad83-406e-9cb6-7a5aa443de9b/c60aa316-a16a-413e-81f3-e24858c3c7a7:
Volume does not exist: ('786e719d-7f54-4501-9e8d-688c1e482309',)"

VolumeCreationError: Error creating a new volume: (u'Volume creation
4e522ef0-279f-4c02-b581-c233d666eee1 failed: Cannot clone volume:
u"src=/rhev/data-center/0002-0002-0002-0002-0021/937822d9-8a59-490f-95b7-48371ae32253/images/6281b597-020d-4ea7-a954-bb798a0ca4f1/2a2015a1-f62c-4e32-8b04-77ece2ba4cc1,
dst=/rhev/data-center/0002-0002-0002-0002-0021/937822d9-8a59-490f-95b7-48371ae32253/images/6281b597-020d-4ea7-a954-bb798a0ca4f1/4e522ef0-279f-4c02-b581-c233d666eee1:
Volume does not exist: (\'36fd2e26-31a3-4284-8193-abd11c01a0f4\',)"',)

VolumeCreationError: Error creating a new volume: (u'Volume creation
c60aa316-a16a-413e-81f3-e24858c3c7a7 failed: Cannot clone volume:
u"src=/rhev/data-center/0002-0002-0002-0002-0021/937822d9-8a59-490f-95b7-48371ae32253/images/e7e99288-ad83-406e-9cb6-7a5aa443de9b/c5762dec-d9d1-4842-84d1-05896d4d27fb,
dst=/rhev/data-center/0002-0002-0002-0002-0021/937822d9-8a59-490f-95b7-48371ae32253/images/e7e99288-ad83-406e-9cb6-7a5aa443de9b/c60aa316-a16a-413e-81f3-e24858c3c7a7:
Volume does not exist: (\'786e719d-7f54-4501-9e8d-688c1e482309\',)"',)

167fb52d-0a51-4fea-9517-c668933ef4e2::DEBUG::2015-09-18
09:33:33,959::task::919::Storage.TaskManager.Task::(_runJobs)
Task=`167fb52d-0a51-4fea-9517-c668933ef4e2`::aborting: Task is aborted:
'Error creating a new volume' - code 205

efb2447e-db4c-4dbd-84e4-5f8039949000::DEBUG::2015-09-18
09:33:34,440::task::919::Storage.TaskManager.Task::(_runJobs)
Task=`efb2447e-db4c-4dbd-84e4-5f8039949000`::aborting: Task is aborted:
'Error creating a new volume' - code 205



___
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] Locked NFS SD

[Greg Padgett]

On 04/13/2015 05:11 AM, shimano wrote:

Hi guys,

One of my storage domains stay locked for a few days after trying to move
it to maintenance mode. How can I cancel this task or kick it to finish?


Hi,

Do you know the reason it was locked?  Can you provide engine logs?
(The domain status can be updated manually in the DB, but it would be best 
to understand the issue first and do something less invasive if possible.)


Thanks,
Greg





___
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] VM Import problems

[Greg Padgett]

On 02/06/2015 05:27 PM, Donny Davis wrote:

So should I detach the domain, update the tarball then reattach it.


That should do it, or even just putting the storage into maintenance 
rather than detaching it, then retry importing the vms you still need.



The problem lies with machines that have already been imported once before.

Thanks



On Feb 6, 2015 3:23 PM, Greg Padgett gpadg...@redhat.com wrote:


On 02/05/2015 04:37 PM, Donny Davis wrote:

I need some help getting my users vm’s imported back into the system after
the failure yesterday. I reattached the storage and half of the vm’s
imported without issue. The other half of the vms give this error

Error while executing action: Cannot import VM. Storage Domain doesn't exist

Funny part is, I only had one storage domain… and I imported it back into
the engine… I’m confused.

Donny



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



Hi Donny,

Are there any additional details accompanying this error in the engine
log?  It sounds like a bug, just not yet sure where to look.

As for a possible hack/workaround (maybe someone else will have a
safer/easier idea here!), the OVFs holding the domain ids in question are
in a tarball on the imported storage.  If the import failure is happening
because the storageId in the OVFs is wrong, it should be possible to
update them to the correct value and retry the import.

Note that by default the tarball is on the storage in 2 places--I'd change
them both, but of course don't forget to make a backup first.

HTH,
Greg



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

Re: [ovirt-users] VM Import problems

[Greg Padgett]

On 02/05/2015 04:37 PM, Donny Davis wrote:

I need some help getting my users vm’s imported back into the system after
the failure yesterday. I reattached the storage and half of the vm’s
imported without issue. The other half of the vms give this error

Error while executing action: Cannot import VM. Storage Domain doesn't exist

Funny part is, I only had one storage domain… and I imported it back into
the engine… I’m confused.

Donny



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



Hi Donny,

Are there any additional details accompanying this error in the engine 
log?  It sounds like a bug, just not yet sure where to look.


As for a possible hack/workaround (maybe someone else will have a 
safer/easier idea here!), the OVFs holding the domain ids in question are 
in a tarball on the imported storage.  If the import failure is happening 
because the storageId in the OVFs is wrong, it should be possible to 
update them to the correct value and retry the import.


Note that by default the tarball is on the storage in 2 places--I'd change 
them both, but of course don't forget to make a backup first.


HTH,
Greg

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

Re: [ovirt-users] Live merge still scheduled for 3.5?

[Greg Padgett]

On 08/01/2014 03:23 PM, Adam Litke wrote:

On 01/08/14 10:35 +0100, Dan Kenigsberg wrote:

On Thu, Jul 31, 2014 at 12:58:08PM -0400, Bob Doolittle wrote:

Hi,

This feature page:
http://www.ovirt.org/Features/Live_Merge
Says the Live merge feature is targeting 3.5 (and has not been updated since
April).

But this 3.5 tracking spreadsheet:
http://bit.ly/17qBn6F
linked from this page:
https://www.ovirt.org/OVirt_3.5_release-management
makes no mention of it.

So, is Live merge still slated for 3.5 and looking good for release?


Yes, thought more work is needed:
Bug 1124970 - Merge upstream live merge fixes into 3.5 branch


Or should the feature page be updated?

It will be nice to be able to delete a snapshot while the VM is running,
particularly since snapshot deletion takes s looong. :)


Adam, could you update the documentation?


Greg, could you please take a pass at the feature page to update from
an engine perspective as well?  There have been a lot of changes since
my initial April writeup.



Adam - Sure, I added some details about the engine changes to the page.

Bob - As Adam said, the project is still a work-in-progress but the bulk 
of the changes are in.  I checked out the link you sent and found the 
project at (currently) line 56 of the 3.5 planning tab.  It's colored 
green, so don't worry. :)


Best,
Greg

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

[ovirt-users] oVirt 3.5 2nd test day report - hosted engine

[Greg Padgett]

Hi all,

Today I tested Hosted Engine on iSCSI (setup and operation) on Fedora 20. 
 The first part of setup went smoothly, but there were some hiccups I 
eventually ran into:


 - HA services didn't start after setup [1]
 - HA agent failed without reporting an error [2][3]

I also noticed that when an iSCSI target has multiple LUNs, a random (?) 
one would be chosen by setup.  I ended up running setup again with only 
one LUN available to make sure this didn't cause further errors.


After setup of the first host completed, things seemed to be working well. 
 However, after completing 2nd host setup and rebooting the first host, I 
have errors in both agent.log files. [4]


I'll follow up with msivak and jmoskovc to see if these are errors on my 
part or something I can help troubleshoot.


Thanks,
Greg


[1] https://bugzilla.redhat.com/show_bug.cgi?id=1123285
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1124624
[3] http://gerrit.ovirt.org/#/c/30814/
[4] First host:
  Error: 'path to storage domain 35ff13aa-7ff1-4add-9869-651267e36921 not
  found in /rhev/data-center/mnt' - trying to restart agent
  [followed by agent existing after too many retries]
Second host:
  Exception: Failed to start monitoring domain (sd_uuid=35ff13aa-
  7ff1-4add-9869-651267e36921, host_id=2): timeout during domain
  acquisition
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [Users] Hosted Engine recovery failure of all HA - nodes

[Greg Padgett]

Hi Andrew and Martin,

On 04/09/2014 04:07 AM, Andrew Lau wrote:

Hi,

On Apr 9, 2014 5:43 PM, Martin Sivak msi...@redhat.com
mailto:msi...@redhat.com wrote:
 
  Hi,
 
   I noticed this happens too, I think the issue is after N attempts the
   ovirt-ha-agent process will kill itself if it believes it can't access
   the storage or it fails in some other way.
 
  If the agent can't access storage or VDSM it waits for 60 seconds and
tries again. After three (iirc) failed attempts it shuts down.

Is there any reason it shuts down? Could it not be possible to just have
it sleep for x minutes? Have that sleep time exponentially scale after
each fail.


It looks like this is a side effect of a fix for a different bug,
https://bugzilla.redhat.com/show_bug.cgi?id=1008505
in which the agent would try to run when it wasn't fully configured.


 
   The ovirt-ha-broker service
   however still remains and continues to calculate the score.
 
  The broker acts only as a data link, the score is computed by the
agent. The broker is used to propagate it to storage (and to collect data).

Thanks for clarifying, I remember seeing some reference to score in the
broker log. Assumed incorrectly.
 
   It'll be
   nice I guess if it could pro-actively restart the ha-agent every now
   and then.
 
  We actually have a bug that is related to this:
https://bugzilla.redhat.com/show_bug.cgi?id=1030441
 
  Greg, are you still working on it?


Sorry, not currently looking at that one.


 
What is the supposed procedure after a shutdown (graceful / ungraceful)
of Hosted-Engine HA nodes? Should the engine recover by itself? Should
the running VM's be restarted automatically?
 
  If the agent-broker pair recovers and sanlock is not preventing taking
the lock (which was not released properly) then the engine VM should be
started automatically.
 
   If all the nodes come up at the same time, in my testing, it took 10
   minutes for the ha-agents to settle and then finally decide which host
   to bring up the engine.
 
  We set a 10 minute mandatory down time for a host when a VM start is
not successful. That might be because the sanlock still things somebody is
running the VM. The /var/log/ovirt-hosted-engine-ha/agent.log would help here.
 
  Regards
  --
  Martin Sivák
  msi...@redhat.com mailto:msi...@redhat.com
  Red Hat Czech
  RHEV-M SLA / Brno, CZ
 
  - Original Message -
   On Wed, Apr 9, 2014 at 2:09 AM, Daniel Helgenberger
   daniel.helgenber...@m-box.de mailto:daniel.helgenber...@m-box.de
wrote:
Hello,
   
I have an oVirt 3.4 hosted engine lab setup witch I am evaluating for
production use.
   
I simulated an ungraceful shutdown of all HA nodes (powercut) while
the engine was running. After powering up, the system did not recover
itself (it seemed).
I had to restart the ovirt-hosted-ha service (witch was in a locked
state) and then manually run 'hosted-engine --vm-start'.
  
   I noticed this happens too, I think the issue is after N attempts the
   ovirt-ha-agent process will kill itself if it believes it can't access
   the storage or it fails in some other way. The ovirt-ha-broker service
   however still remains and continues to calculate the score. It'll be
   nice I guess if it could pro-actively restart the ha-agent every now
   and then.
  
   
What is the supposed procedure after a shutdown (graceful / ungraceful)
of Hosted-Engine HA nodes? Should the engine recover by itself? Should
the running VM's be restarted automatically?
  
   I don't think any other VMs get restarted automatically, this is
   because the engine is used to ensure that the VM hasn't been restarted
   on another host. This is where power management etc comes into play.
  
   If all the nodes come up at the same time, in my testing, it took 10
   minutes for the ha-agents to settle and then finally decide which host
   to bring up the engine. Then technically... (untested) any VMs which
   you've marked as HA should be automatically brought back up by the
   engine. This would be 15-20 minutes to recover which feels a little
   slow.. although fairly automatic.
  
   
Thanks,
Daniel
   
   
   
   
   
   
___
Users mailing list
Users@ovirt.org mailto:Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
   
   ___
   Users mailing list
   Users@ovirt.org mailto:Users@ovirt.org
   http://lists.ovirt.org/mailman/listinfo/users
  



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

Re: [Users] hosted engine help

[Greg Padgett]

On 03/11/2014 04:09 PM, Sandro Bonazzola wrote:

Il 07/03/2014 01:10, Jason Brooks ha scritto:

Hey everyone, I've been testing out oVirt 3.4 w/ hosted engine, and
while I've managed to bring the engine up, I've only been able to do it
manually, using hosted-engine --vm-start.

The ovirt-ha-agent service fails reliably for me, erroring out with
RequestError: Request failed: success.

I've pasted error passages from the ha agent and vdsm logs below.

Any pointers?

Regards, Jason

***

ovirt-ha-agent.log

MainThread::CRITICAL::2014-03-06
18:48:30,622::agent::103::ovirt_hosted_engine_ha.agent.agent.Agent::(run) Could 
not start ha-agent
Traceback (most recent call last):
   File
/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/agent/agent.py, line 
97, in run
 self._run_agent()
   File
/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/agent/agent.py, line 
154, in _run_agent

hosted_engine.HostedEngine(self.shutdown_requested).start_monitoring()
   File
/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/agent/hosted_engine.py,
 line 303, in start_monitoring
 for old_state, state, delay in self.fsm:
   File
/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/lib/fsm/machine.py, 
line 125, in next
 new_data = self.refresh(self._state.data)
   File
/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/agent/state_machine.py,
 line 77, in refresh
 stats.update(self.hosted_engine.collect_stats())
   File
/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/agent/hosted_engine.py,
 line 623, in collect_stats
 constants.SERVICE_TYPE)
   File
/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/lib/brokerlink.py, 
line 171, in get_stats_from_storage
 result = self._checked_communicate(request)
   File
/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/lib/brokerlink.py, 
line 198, in _checked_communicate
 raise RequestError(Request failed: {0}.format(msg))
RequestError: Request failed: success


vdsm.log

Thread-29::ERROR::2014-03-06 18:48:11,101::API::1607::vds::(_getHaInfo)
failed to retrieve Hosted Engine HA info
Traceback (most recent call last):
   File /usr/share/vdsm/API.py, line 1598, in _getHaInfo
 stats = instance.get_all_stats()
   File
/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/client/client.py, 
line 86, in get_all_stats
 constants.SERVICE_TYPE)
   File
/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/lib/brokerlink.py, 
line 171, in get_stats_from_storage
 result = self._checked_communicate(request)
   File
/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/lib/brokerlink.py, 
line 198, in _checked_communicate
 raise RequestError(Request failed: {0}.format(msg))
RequestError: Request failed: success



Greg, Martin, Request failed: success ?


Hi Jason,

I talked to Martin about this and opened a bug [1]/submitted a patch [2]. 
 Based on your mail, I'm not sure if you experienced a race condition or 
some other issue.  This patch should help the former case, but if you're 
still experiencing problems then we would need to investigate further.


Thanks,
Greg

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1075126
[2] http://gerrit.ovirt.org/#/c/25621/




___
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: [Users] Fwd: Sample code for setting NIC - CloudInit

[Greg Padgett]

On 02/20/2014 02:26 PM, Juan Hernandez wrote:

On 02/20/2014 04:28 PM, Juan Hernandez wrote:

On 02/20/2014 10:40 AM, Tejesh M wrote:

I wrote this code to assign IP address to VM interface eth0, but not
luck. Also, have attached debug log.



I'm attaching a complete examaple of how to do this. However, I think
that setting the DNS information doesn't currently work. Apparently
cloud-init is expecting a network configuration containing the DNS
settings inside the network interface, something like this:

iface eth0 inet static
   dns-nameservers 1.1.2.2 1.2.3.4
   dns-search google.com
   address 192.168.1.102
   netmask 255.255.0.0
   gateway 192.168.2.1
auto eth0

But we actually pass them outside of the network interface, like this:

dns-nameservers 1.1.2.2 1.2.3.4
dns-search google.com
iface eth0 inet static
   address 192.168.1.102
   netmask 255.255.0.0
   gateway 192.168.2.1
auto eth0

I need to check it.



I have modified the code that generates the cloud-init files to put the
DNS configuration inside the iface configuration, and then it works:

http://gerrit.ovirt.org/24850

So this is probably a bug, either in our side or in cloud-init itself.
Greg, Shahar, you know cloud-init better, what do you think?



It looks like our bug.  Cloud-init wants to see a standard debian/ubuntu 
style /etc/network/interfaces, and the documentation for that format 
supports your change.  Thanks for posting the patch!



_*Java Code:*_
   org.ovirt.engine.sdk.entities.User userData = new User();
   userData.setUserName(root);
   userData.setPassword(password);
   Users usersData = new Users();
   usersData.getUsers().add(userData);
   CloudInit cloudData = new CloudInit();


   cloudData.setUsers(usersData);
   Host hostData = new Host();
   hostData.setAddress(vmName);
   cloudData.setHost(hostData);

   org.ovirt.engine.sdk.entities.CloudInit.Network
networkConfiguration=new org.ovirt.engine.sdk.entities.CloudInit.Network();

   DNS dns = new DNS();
   dns.setServers(createServersList(1.1.2.2, 1.2.3.4));
   dns.setSearchDomains(createServersList(google.com
http://google.com));
   networkConfiguration.setDns(dns);
   networkConfiguration.setNics(new Nics());

   Nics nics = networkConfiguration.getNics();
   nics.getNics().add(createNic(eth0, STATIC,
createNetwork(192.168.1.102, 255.255.0.0, 192.168.2.1), true));

   networkConfiguration.setNics(nics);

   cloudData.setNetwork(networkConfiguration);

   Initialization initData = new Initialization();

   initData.setCloudInit(cloudData);

   VM vmDataForStart = new VM();
   vmDataForStart.setInitialization(initData);
   Action actionData = new Action();
   actionData.setVm(vmDataForStart);

   // Send the request to start the VM to the server:
   api.getVMs().get(vmName).start(actionData);






On Thu, Feb 20, 2014 at 1:39 PM, Moti Asayag masa...@redhat.com
mailto:masa...@redhat.com wrote:



 - Original Message -
  From: Tejesh M tejes...@gmail.com mailto:tejes...@gmail.com
  To: Moti Asayag masa...@redhat.com mailto:masa...@redhat.com
  Cc: users@oVirt.org users@ovirt.org mailto:users@ovirt.org
  Sent: Thursday, February 20, 2014 8:52:52 AM
  Subject: Re: [Users] Fwd: Sample code for setting NIC - CloudInit
 
  I'm not getting below class:
 
  import org.ovirt.engine.sdk.entities.*NetworkConfiguration*;

 Which version of ovirt-engine-sdk-java are you using ?

 I used ovirt-engine-sdk-java-3.4.0.1-1, added to my project's pom.xml:

 dependency
 groupIdorg.ovirt.engine.sdk/groupId
 artifactIdovirt-engine-sdk-java/artifactId
 version3.4.0.1-1/version
 typejar/type
 scopecompile/scope
 /dependency

 
 
  On Thu, Feb 20, 2014 at 4:11 AM, Moti Asayag masa...@redhat.com
 mailto:masa...@redhat.com wrote:
 
  
  
   - Original Message -
From: Tejesh M tejes...@gmail.com mailto:tejes...@gmail.com
To: users@oVirt.org users@ovirt.org mailto:users@ovirt.org
Sent: Wednesday, February 19, 2014 3:24:40 PM
Subject: [Users] Fwd: Sample code for setting NIC - CloudInit
   
Hi,
   
Can someone share me sample java code for assigning IP address
 for VM on
   eth0
through Java SDK via CloudInit ?
   
  
   Hi Tejesh,
  
   I've attached a sample code that sends the required request (as
 the output
   is demonstrated in debug mode).
   Note that the code is jdk-7 compliant.
   I haven't configured cloud-init and haven't tested it end-to-end.
   Please try to test it on your environment and provide a feedback
 for it.
  
   

Re: [Users] Linux sysprep

[Greg Padgett]

On 08/21/2013 07:25 AM, René Koch (ovido) wrote:
[snip]

I'm just playing around with the payload feature but I can't access the
cd/floppy in my vm.
I adapted Yuriy's script
(http://lists.ovirt.org/pipermail/users/2013-June/014907.html - which is
working fine btw) to create payload xml content and write it with
hooking.write_domxml(domxml).

In vdsm.log I can see that my python script exits with status code 0 and
that the content seems to be added to the vm definition:

Thread-130844::DEBUG::2013-08-21
12:43:52,669::libvirtvm::1520::vm.Vm::(_run)
vmId=`79dc3123-4584-4dd9-b0f0-c28ede13d672`::?xml version=1.0
encoding=utf-8?domain type=kvm
namecentos6/name
snip
/cpu
payloadspayload type=cdromfile
name=unattended.txtcontenthostname:
centos6/content/file/payload/payloads/domain


But in my vm I can't mount the cd drive:
# mount /dev/sr0 /media
mount: you must specify the filesystem type

Is there a special filesystem I have to specify?

Furthermore shouldn't I be able to see the payloads content added to
this vm via REST-API? Because I can't.

Maybe I'm doing some wrong?


Thanks,
René


That's a neat script.  I haven't used it--instead I just send xml to the 
rest api, something like this, which looks a lot like yours:


vm id=6aec2d40-e36f-4b02-ab75-933d93f4cb8b 
href=/api/vms/6aec2d40-e36f-4b02-ab75-933d93f4cb8b

  payloads
payload type=cdrom
  file name=meta-data.txtcontentsome content/content   /file
/payload
  /payloads
/vm

To attach the payload via the rest api, note that you'd need to send a put 
request to /api/vms/uuid rather than pass the xml in the run/start 
action, because that's not yet supported.  Doing this, inside my vm I see:


  [root@cloud-init-test ~]# blkid
  /dev/sr1: UUID=2013-08-21-19-39-40-00 LABEL=CDROM TYPE=iso9660

And I can mount it without any problems.  You can also check the qemu 
process listing on the host--for instance, mine shows:


/usr/bin/qemu-system-x86_64 [...] -drive 
file=/var/run/vdsm/payload/29e331f9-42df-46e1-aad1-88101b134606.fe53caf3339d55b2b37a893e19e9f10a.img


While the vm is running, you can check that file with `file` (should 
report ISO 9660), mount it on the host, etc.


HTH,
Greg

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

Re: [Users] cant remove disks from iscsi domain

[Greg Padgett]

On 08/21/2013 04:10 PM, Dafna Ron wrote:

there is a is an exception in the log related to a quota calculation

2013-08-21 17:52:32,694 ERROR
[org.ovirt.engine.core.utils.timer.SchedulerUtilQu   artzImpl]
(DefaultQuartzScheduler_Worker-7) failed to invoke sceduled method upd
ateQuotaCache: java.lang.reflect.InvocationTargetException
 at sun.reflect.GeneratedMethodAccessor175.invoke(Unknown Source)
[:1.7.0   _25]
 at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:43) [rt.jar:1.7.0_25]
 at java.lang.reflect.Method.invoke(Method.java:606)
[rt.jar:1.7.0_25]
 at
org.ovirt.engine.core.utils.timer.JobWrapper.execute(JobWrapper.java:
60) [scheduler.jar:]
 at org.quartz.core.JobRunShell.run(JobRunShell.java:213)
[quartz.jar:]
 at
org.quartz.simpl.SimpleThreadPool$WorkerThread.run(SimpleThreadPool.j
ava:557) [quartz.jar:]
Caused by: org.springframework.jdbc.BadSqlGrammarException:
PreparedStatementCal   lback; bad SQL grammar [select * from
calculateallstorageusage()]; nested excep   tion is
org.postgresql.util.PSQLException: ERROR: column quota_limitation.quota
_id must appear in the GROUP BY clause or be used in an aggregate function
   Where: PL/pgSQL function calculateallstorageusage line 3 at RETURN QUERY


in any case this is a bug.
I'm adding Doron to this mail, perhaps this was reported in the past and
already solved in later versions.
if not it should be reported and fixed.

Dafna




If I'm not mistaken, it looks like this bug:

https://bugzilla.redhat.com/show_bug.cgi?id=905891

Greg





On 08/21/2013 05:26 PM, Yura Demchenko wrote:

21.08.2013 19:18, Dafna Ron пишет:

from the logs it appears to be a quota issue.
do you have quota enabled?


Yes, quota in enforced mode. But VMs/disks in question belongs to
unlimited quota (defined quota policy with no limits on storage/cpu/ram)



On 08/21/2013 03:20 PM, Yuriy Demchenko wrote:

Hi,

I've recently encountered a problem with removing disks from iscsi
domain in my test lab - just cant remove any.
Remove operation fails with message User admin@internal failed to
initiate removing of disk pg-slave1_opt from domain iscsi-store and
re-elections of SPM. After that - disk is marked as illegal in ovirt
webinterface, however, it is _in fact_ removed from storage -
lvdisplay doesn't show it and free space is updated correctly.
And this happens with just about every disk/vm i try to remove.

ovirt 3.2.2-el6
centos 6.4
vdsm-4.10.3-17.el6
lvm2-2.02.98-9.el6

Any tips? logs in attach



___
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: [Users] Linux sysprep

[Greg Padgett]

On 08/19/2013 10:17 AM, René Koch (ovido) wrote:

Hi,

Has anyone an idea what's the easiest way to sysprep Linux (CentOS 6 and
RHEL 6) machines?

The use case is the following: I want to create a lot of virtual
machines (e.g. 100) by cloning from one template.
So I create a master vm, create a template and a pool with 100 vms
assigned to it and set all 100 vms to prestarted.

The problem is now, that when I run sys-unconfig before creating the
template, which does a touch /.unconfigured I have to go through the
sysconfig-tui and set a new root password for all 100 hosts.

So what I'm looking for is a script like the sysprep tool for windows
which sets parameters for me automatically.
I only need to change:
* Hostname + set DHCP_HOSTNAME in ifcfg-eth0 (Hostname == Pool-VM-Name)
for some dhcp/ddns magic :)
* Clear udev network-rules
* remove SSH-Keys
* Remove RHN ID and join Satellite/Spacewalk-server
* root-password,... should stay the same

My first question is: does oVirt provide such a functionality for Linux
guest out-of-the-box? I couldn't find one.


I think I could solve this with virt-sysprep and virt-file, but I'm
unsure if I can use it with oVirt (or only with plain libvirt):
http://libguestfs.org/virt-sysprep.1.html
http://libguestfs.org/virt-edit.1.html

For this tools it's required that the vm is not running, as it changes
files on the disk. If I'm using a before-vm-start hook, it should be
save to access the disk and change content with virt-sysprep/virt-file,
right?
But do I have access to the disk in a before-vm-start hook?
If using NFS storage I should be able to access all disks on the
NFS-share, but for iSCSI/FC-LUNS - are they available on the hypervisor
in this stage?


Another option would be to write a custom script which is started during
boot and disables itself after successful run (in the same way as
firstboot - I already have such a script for RHN Satellite/Spacewalk
joins). The problem here is: How do I get the (oVirt) name of this vm
(would need something like virt-whoami :) )? Is the (internal oVirt) ID
of this vm stored somewhere in the filesystem of this vm? I don't think
so


Thanks a lot for suggestions,
René



Hi René,

You may be able to accomplish at least some of what you want using 
Cloud-Init, some features of which we've integrated into oVirt [1].  It 
went in recently so may not be in whichever version you're running, but 
you can probably borrow some of the concepts to get the job done.


Just a few ideas:
 - create a vm payload [2] and attach it to the VM which can hold your 
config info e.g. vm name, which a custom script could pick up.  No need 
for the latest oVirt with this option.
 - create a Cloud-Init config disk yourself and attach it as a payload, 
and let Cloud-Init do the initialization.  There are several formats; 
oVirt uses Config-Drive-v2.  Example at [3].  Depending on the config disk 
format, you may need the latest oVirt/vdsm to assign a volume label to the 
vm payload.
 - use the latest oVirt and its Cloud-Init functionality; for fields not 
handled, attach a file and let a script handle it.


HTH,
Greg

[1] http://www.ovirt.org/Features/Cloud-Init_Integration
[2] http://www.ovirt.org/Features/VMPayload
[3] 
http://docs.openstack.org/trunk/openstack-compute/admin/content/config-drive.html


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

Re: [Users] Linux sysprep

[Greg Padgett]

On 08/19/2013 04:26 PM, René Koch wrote:


-Original message-

From:Greg Padgett gpadg...@redhat.com
Sent: Monday 19th August 2013 21:16
To: René Koch r.k...@ovido.at
Cc: ovirt-users users@ovirt.org
Subject: Re: [Users] Linux sysprep

On 08/19/2013 10:17 AM, René Koch (ovido) wrote:

Hi,

Has anyone an idea what's the easiest way to sysprep Linux (CentOS 6 and
RHEL 6) machines?

The use case is the following: I want to create a lot of virtual
machines (e.g. 100) by cloning from one template.
So I create a master vm, create a template and a pool with 100 vms
assigned to it and set all 100 vms to prestarted.

The problem is now, that when I run sys-unconfig before creating the
template, which does a touch /.unconfigured I have to go through the
sysconfig-tui and set a new root password for all 100 hosts.

So what I'm looking for is a script like the sysprep tool for windows
which sets parameters for me automatically.
I only need to change:
* Hostname + set DHCP_HOSTNAME in ifcfg-eth0 (Hostname == Pool-VM-Name)
for some dhcp/ddns magic :)
* Clear udev network-rules
* remove SSH-Keys
* Remove RHN ID and join Satellite/Spacewalk-server
* root-password,... should stay the same

My first question is: does oVirt provide such a functionality for Linux
guest out-of-the-box? I couldn't find one.


I think I could solve this with virt-sysprep and virt-file, but I'm
unsure if I can use it with oVirt (or only with plain libvirt):
http://libguestfs.org/virt-sysprep.1.html
http://libguestfs.org/virt-edit.1.html

For this tools it's required that the vm is not running, as it changes
files on the disk. If I'm using a before-vm-start hook, it should be
save to access the disk and change content with virt-sysprep/virt-file,
right?
But do I have access to the disk in a before-vm-start hook?
If using NFS storage I should be able to access all disks on the
NFS-share, but for iSCSI/FC-LUNS - are they available on the hypervisor
in this stage?


Another option would be to write a custom script which is started during
boot and disables itself after successful run (in the same way as
firstboot - I already have such a script for RHN Satellite/Spacewalk
joins). The problem here is: How do I get the (oVirt) name of this vm
(would need something like virt-whoami :) )? Is the (internal oVirt) ID
of this vm stored somewhere in the filesystem of this vm? I don't think
so


Thanks a lot for suggestions,
René



Hi René,

You may be able to accomplish at least some of what you want using
Cloud-Init, some features of which we've integrated into oVirt [1].  It
went in recently so may not be in whichever version you're running, but
you can probably borrow some of the concepts to get the job done.


Thanks a lot for your answer - this definitely points me into the right way.



Great, happy to help.





Just a few ideas:
   - create a vm payload [2] and attach it to the VM which can hold your
config info e.g. vm name, which a custom script could pick up.  No need
for the latest oVirt with this option.



For some strange reason I totally missed the vm payload feature (and it seems 
to be introduced already in oVirt 3.1 according to the release notes).
Can I attach a vm payload via webadmin portal of oVirt 3.2 (and if yes - how?) 
or only via REST-API?

So if I understand this right, I would do the following:
- use before_vm_start_hook which creates the payload and updates vm xml definition - add payloads 
with e.g. file name unattended.txt andcontent hostname=pool-vm95
- have script started in host which mounts the floppy, reads the content of 
unattended.txt and do some magic



Only REST API.  It sounds like you're on the right track with it.





   - create a Cloud-Init config disk yourself and attach it as a payload,
and let Cloud-Init do the initialization.  There are several formats;
oVirt uses Config-Drive-v2.  Example at [3].  Depending on the config disk
format, you may need the latest oVirt/vdsm to assign a volume label to the
vm payload.
   - use the latest oVirt and its Cloud-Init functionality; for fields not
handled, attach a file and let a script handle it.



cloud-init sounds very interesting, but this requires oVirt 3.3, right?
I'm running oVirt 3.2 at the moment.



Yeah, 3.3 for the integrated features.  You could use it standalone in 
3.2, i.e. attach a config disk you made yourself--but compared to the 
approach above, the effort might not be worth it considering what you want 
to accomplish.




Regards,
René




HTH,
Greg

[1] http://www.ovirt.org/Features/Cloud-Init_Integration
[2] http://www.ovirt.org/Features/VMPayload
[3]
http://docs.openstack.org/trunk/openstack-compute/admin/content/config-drive.html




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

Re: [Users] Disk quota and templates bug?

[Greg Padgett]

On 05/29/2013 10:05 AM, Jure Kranjc wrote:

Hi,
we've encountered an quota allocation problem which seems like a bug.
Using engine 3.2.2. on CentOS, datacenter in enforced quota mode. Scenario:

- Create a virtual machine, seal it and create template from it. Assign
some quota to it.
- Create a new user, set new quota limits to his username
- This user creates a new VM from this template. In new server/desktop
dialog, resource allocation, new disk gets set to user's quota (user only
has permission for it's own quota). Create VM.
- When VM is created it inherits the templates quota and not user's, as it
should. So user is using templates disk quota. Quota for memory and vcpu
works ok.

No errors in engine.log.
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


Hi Jure,

Thanks for reporting this.  I'm not well-versed enough with storage quotas 
to assess, but adding Doron who should be able to help.


Thanks,
Greg

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

Re: [Users] Obtain VM name from within VM?

[Greg Padgett]

On 05/25/2013 04:01 AM, Itamar Heim wrote:

On 05/25/2013 02:07 AM, Jonathan Daugherty wrote:

Hi,

I'm interested to know whether it is possible to obtain a VM's name from
within a VM.  In particular I'd like to obtain VM names from within
Linux guests for the purpose of setting up dynamic DNS based on the VM
name.  I don't see the VM name in the output of dmidecode and there
doesn't appear to be an entry in the ovirt guest API to obtain it.  (In
any case I can't run the ovirt guest agent on my VMs, so I'd like some
other way to get it.)

Thanks!



greg is working on cloud-init support[1] which should take care of both
passing this info to linux guests (and maybe solve the ddns issue as well
while at it - greg?)


I'm not aware of any DDNS support in cloud-init, just basic DNS setup. 
Cloud-init provides methods to run custom scripts (not sure we'll do that 
in first out but you can set it up in the image), so I'm sure you could 
use that or some other method to run scripts for the DDNS update once 
you've got the vm name propagated.


Thanks,
Greg



in the meantime, you could try and do this manually by passing it via the
vm payload field, which is mounted to the guest as a block device.

[1]
http://gerrit.ovirt.org/#/q/status:open+project:ovirt-engine+branch:master+topic:cloud-init,n,z



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

Re: [Users] NFS Advanced Parameters Greyed out on Existing Storage Domains

[Greg Padgett]

On 02/14/2013 12:45 AM, Chris Noffsinger wrote:

Thank you for the speedy clarification.



No problem.


So as I understand this BZ for the errata, the nfs_mount_options were
being ignored in vdsm.conf and then after the errata, they are no longer
ignored?
https://bugzilla.redhat.com/show_bug.cgi?id=826921



Correct, also note the caveat that if you enable the advanced nfs options 
in the ui, they will take priority over the vdsm.conf options.




On Wed, Feb 13, 2013 at 8:57 PM, Greg Padgett gpadg...@redhat.com
mailto:gpadg...@redhat.com wrote:

On 02/13/2013 12:33 AM, Chris Noffsinger wrote:

So I have read this BZ
https://bugzilla.redhat.com/__show_bug.cgi?id=855729
https://bugzilla.redhat.com/show_bug.cgi?id=855729

and these related ovirt BZs http://gerrit.ovirt.org/#/c/__8110/
http://gerrit.ovirt.org/#/c/8110/
http://gerrit.ovirt.org/#/c/__8797/
http://gerrit.ovirt.org/#/c/8797/
http://gerrit.ovirt.org/#/c/__8798/
http://gerrit.ovirt.org/#/c/8798/

So forgive me but I am a little confused.  I have some existing NFS
Storage domains that I was not paying attention and attached
without doing
any advanced parameters in RHEV 3.1

Now the NFS Advanced Parameters box is greyed out.

So now that I have attached these domains I cannot change the
advanced nfs
option such as change it to Nfs4 from 3 or rsize and wsize?

Maybe if I was using upstream oVirt instead of Rhev 3.1 I would be
able to
make the changes in vdsm.conf and they would be honored?


It's the same in oVirt 3.1 and RHEV 3.1, see this bug:
https://bugzilla.redhat.com/__show_bug.cgi?id=835543
https://bugzilla.redhat.com/show_bug.cgi?id=835543

As long as VDSM is current, you should be able to change the the
nfs_mount_options in vdsm.conf to get what you want.  You would need
to use this route instead of/in addition to the advanced options
anyway, because they only allow modification of nfs version, retrans,
and timeout and not rsize/wsize.

(2 other options are a) modify the db directly
(storage_server_connections table) for the available advanced options
(not rsize/wsize), or b) attach the sd as posix and specify the mount
options, but IMO the vdsm.conf method above is easier and cleaner.)

Hope that helps,
Greg


--
Chris Noffsinger


_
Users mailing list
Users@ovirt.org mailto:Users@ovirt.org
http://lists.ovirt.org/__mailman/listinfo/users
http://lists.ovirt.org/mailman/listinfo/users





--
Chris Noffsinger


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

Re: [Users] NFS Advanced Parameters Greyed out on Existing Storage Domains

[Greg Padgett]

On 02/13/2013 12:33 AM, Chris Noffsinger wrote:

So I have read this BZ https://bugzilla.redhat.com/show_bug.cgi?id=855729

and these related ovirt BZs http://gerrit.ovirt.org/#/c/8110/
http://gerrit.ovirt.org/#/c/8797/ http://gerrit.ovirt.org/#/c/8798/

So forgive me but I am a little confused.  I have some existing NFS
Storage domains that I was not paying attention and attached without doing
any advanced parameters in RHEV 3.1

Now the NFS Advanced Parameters box is greyed out.

So now that I have attached these domains I cannot change the advanced nfs
option such as change it to Nfs4 from 3 or rsize and wsize?

Maybe if I was using upstream oVirt instead of Rhev 3.1 I would be able to
make the changes in vdsm.conf and they would be honored?


It's the same in oVirt 3.1 and RHEV 3.1, see this bug:
https://bugzilla.redhat.com/show_bug.cgi?id=835543

As long as VDSM is current, you should be able to change the the 
nfs_mount_options in vdsm.conf to get what you want.  You would need to 
use this route instead of/in addition to the advanced options anyway, 
because they only allow modification of nfs version, retrans, and timeout 
and not rsize/wsize.


(2 other options are a) modify the db directly (storage_server_connections 
table) for the available advanced options (not rsize/wsize), or b) attach 
the sd as posix and specify the mount options, but IMO the vdsm.conf 
method above is easier and cleaner.)


Hope that helps,
Greg



--
Chris Noffsinger


___
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: [Users] custom nfs mount options

[Greg Padgett]

On 01/24/2013 08:03 AM, Alex Leonhardt wrote:

same here, ovirt 3.1 from dreyou's repo ...

vdsm-python-4.10.0-0.44.14.el6.x86_64
vdsm-cli-4.10.0-0.44.14.el6.noarch
vdsm-xmlrpc-4.10.0-0.44.14.el6.noarch
vdsm-4.10.0-0.44.14.el6.x86_64

Alex



On 24 January 2013 12:33, Alexandru Vladulescu avladule...@bfproject.ro
mailto:avladule...@bfproject.ro wrote:

On 01/24/2013 02:25 PM, Itamar Heim wrote:

On 24/01/2013 04:24, Alexandru Vladulescu wrote:


Hi guys,

I remember asking the same thing a couple of weeks ago. Itamar
answered
to be the same, should check the vdsm.conf file for nfs mount
options.
Because I did not had the time to do test this until now, I
return with
the test results.

Well Alex it seems to be right, on the 3.1 version, if you go
and edit
the /etc/vdsm/vdsm.conf file, on line 146, I uncommented the
nfs_mount_options parameter and changed it to :

nfs_mount_options =
soft,nosharecache,noatime,__rsize=8192,wsize=8192

Went in Ovirt interface, put the node from Hosts tab into
Maintenance,
so that the ISO domain and Master Domain will get unmounted
automatically; restarted the vdsm service on the hypervisior
server and
activate the node back from GUI. Upon mount command, there is
no change
or difference between what I have added and what was configured
automatically before.


I remember something about you must not pass any nfs option from
ovirt, or it will override the vdsm.conf.
are you trying to set nfs options from both engine and vdsm.conf?

Basically, I had 2 questions, one was like Alex asked and it is in the
current topic, and the other was suggestion to add these nfs
configuration parameters changes into the GUI in Storage tab. I asked
if besides the retrans, timeo and vers is it possible to add anything
else in the future GUI devel.

Must mention, I test on 3.1 version from dreyou's repo.


This is key.  There was a bug where vdsm did not take the vdsm.conf 
nfs_mount_options into consideration [1], which was fixed upstream in 
4.10.1--so after the version you are running.  There was also a 
complementary patch in engine--the two work together to fix this issue.


If you had the fix, you would simply need to be sure to not check the 
Override Default Options checkbox for your NFS storage in the UI. 
However, without the fix, I think the most straightforward way to 
accomplish what you want is to configure the storage using a Posix domain 
as Itamar suggested earlier in the thread.


I'll leave the question of adding additional, custom parameters in the UI 
for others to answer.  Seems like it could be useful, but can be 
accomplished other ways.


[1] http://bugzilla.redhat.com/826921





   type nfs

(rw,soft,nosharecache,timeo=__10,retrans=6,vers=4,addr=x.x.__x.x,clientaddr=x.x.x.x)


Might this be a bug on vdsm to be fixed ?

Alex.


On 01/24/2013 01:45 PM, Alex Leonhardt wrote:

So I've tried some bits Itamar asked me to - however,
still get the
same mount options shown.

I tried service vdsmd reconfigure; service vdsmd restart
- the mount
for HV03:/vmfs/data should now have the new mount options,
but no luck.

Anyone time to help ?

Alex



On 24 January 2013 10:54, Alex Leonhardt
alex.t...@gmail.com mailto:alex.t...@gmail.com
mailto:alex.t...@gmail.com mailto:alex.t...@gmail.com
wrote:

 I've got now :

 nfs_mount_options =
soft,nosharecache,rsize=32768,__wsize=32768,noatime


 However, when I check the mounts on the host, it does
not show
 these addtitional options used ? (only
soft,nosharecache), here
 the mount output:

 HV02:/vmfs/data.old2 on
/rhev/data-center/mnt/HV02:___vmfs_data.old2
 type nfs

(rw,soft,nosharecache,timeo=__600,retrans=6,nfsvers=3,addr=__x.x.x8)
 HV02:/vmfs/data on
/rhev/data-center/mnt/HV02:___vmfs_data type nfs

(rw,soft,nosharecache,timeo=__600,retrans=6,vers=3,addr=x.x.__x8)
 HV03:/vmfs/data on
/rhev/data-center/mnt/HV03:___vmfs_data type nfs

(rw,soft,nosharecache,timeo=__600,retrans=6,nfsvers=3,addr=__127.0.0.1)

 Above is after I restarted HV03 so it really should
have mounted
 

Re: [Users] Engine constantly trying to remove disks that aren´t there

[Greg Padgett]

On 10/26/2012 08:21 AM, Karli Sjöberg wrote:

Hi,

today I had a VM that had a couple of hard drives created, that I wanted
destroyed, so I shift-clicked to mark all of them:


This screen showed up:


I clicked OK, the disks were deleted, but ever since then, these
messages keep appearing in the event log:


engine.log keeps printing this:
2012-10-26 14:14:50,285 INFO  [org.ovirt.engine.core.bll.AsyncTaskManager]
(QuartzScheduler_Worker-63) AsyncTaskManager::PollAndUpdateAsyncTasks: 1
tasks, 1 tasks to poll now
2012-10-26 14:14:50,441 INFO  [org.ovirt.engine.core.bll.SPMAsyncTask]
(QuartzScheduler_Worker-63) BaseAsyncTask::OnTaskEndSuccess: Task
a50a874d-5a81-4268-a085-2602df29def1 (Parent Command RemoveDisk,
Parameters Type
org.ovirt.engine.core.common.asynctasks.AsyncTaskParameters) ended
successfully.
2012-10-26 14:14:50,442 INFO  [org.ovirt.engine.core.bll.EntityAsyncTask]
(QuartzScheduler_Worker-63) EntityAsyncTask::EndActionIfNecessary: All
tasks of entity d9d60b31-c8e4-4d24-8b2e-29b654789057 has ended -
executing EndAction
2012-10-26 14:14:50,443 INFO  [org.ovirt.engine.core.bll.EntityAsyncTask]
(QuartzScheduler_Worker-63) EntityAsyncTask::EndAction: Ending action for
1 tasks (entity ID: d9d60b31-c8e4-4d24-8b2e-29b654789057): calling
EndAction for action type RemoveDisk.
2012-10-26 14:14:50,445 INFO  [org.ovirt.engine.core.bll.EntityAsyncTask]
(pool-3-thread-47) EntityAsyncTask::EndCommandAction [within
thread]context: Attempting to EndAction RemoveDisk
2012-10-26 14:14:50,471 INFO
  [org.ovirt.engine.core.bll.RemoveDiskCommand] (pool-3-thread-47) Ending
command successfully: org.ovirt.engine.core.bll.RemoveDiskCommand
2012-10-26 14:14:50,484 WARN
  [org.ovirt.engine.core.compat.backendcompat.TypeCompat]
(pool-3-thread-47) Unable to get value of property: diskAlias for class
org.ovirt.engine.core.bll.RemoveDiskCommand
2012-10-26 14:14:50,510 ERROR [org.ovirt.engine.core.bll.EntityAsyncTask]
(pool-3-thread-47) EntityAsyncTask::EndCommandAction [within thread]:
EndAction for action type RemoveDisk threw an exception:
java.lang.NullPointerException
at
org.ovirt.engine.core.bll.RemoveDiskCommand.getVmsForDiskId(RemoveDiskCommand.java:146)
[engine-bll.jar:]
at
org.ovirt.engine.core.bll.RemoveDiskCommand.endCommand(RemoveDiskCommand.java:281)
[engine-bll.jar:]
at
org.ovirt.engine.core.bll.RemoveDiskCommand.EndSuccessfully(RemoveDiskCommand.java:272)
[engine-bll.jar:]
at
org.ovirt.engine.core.bll.CommandBase.InternalEndSuccessfully(CommandBase.java:465)
[engine-bll.jar:]
at
org.ovirt.engine.core.bll.CommandBase.endActionInTransactionScope(CommandBase.java:420)
[engine-bll.jar:]
at
org.ovirt.engine.core.bll.CommandBase.runInTransaction(CommandBase.java:1205)
[engine-bll.jar:]
at
org.ovirt.engine.core.utils.transaction.TransactionSupport.executeInSuppressed(TransactionSupport.java:168)
[engine-utils.jar:]
at
org.ovirt.engine.core.utils.transaction.TransactionSupport.executeInScope(TransactionSupport.java:107)
[engine-utils.jar:]
at org.ovirt.engine.core.bll.CommandBase.EndAction(CommandBase.java:366)
[engine-bll.jar:]
at org.ovirt.engine.core.bll.Backend.endAction(Backend.java:356)
[engine-bll.jar:]
at sun.reflect.GeneratedMethodAccessor149.invoke(Unknown Source)
[:1.7.0_06-icedtea]
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[rt.jar:1.7.0_06-icedtea]
at java.lang.reflect.Method.invoke(Method.java:601) [rt.jar:1.7.0_06-icedtea]
at
org.jboss.as.ee.component.ManagedReferenceMethodInterceptorFactory$ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptorFactory.java:72)
[jboss-as-ee-7.1.1.Final.jar:7.1.1.Final]
at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
[jboss-invocation.jar:1.1.1.Final]
at
org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:374)
[jboss-invocation.jar:1.1.1.Final]
at
org.ovirt.engine.core.utils.ThreadLocalSessionCleanerInterceptor.injectWebContextToThreadLocal(ThreadLocalSessionCleanerInterceptor.java:11)
[engine-utils.jar:]
at sun.reflect.GeneratedMethodAccessor68.invoke(Unknown Source)
[:1.7.0_06-icedtea]
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[rt.jar:1.7.0_06-icedtea]
at java.lang.reflect.Method.invoke(Method.java:601) [rt.jar:1.7.0_06-icedtea]
at
org.jboss.as.ee.component.ManagedReferenceLifecycleMethodInterceptorFactory$ManagedReferenceLifecycleMethodInterceptor.processInvocation(ManagedReferenceLifecycleMethodInterceptorFactory.java:123)
[jboss-as-ee-7.1.1.Final.jar:7.1.1.Final]
at
org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
[jboss-invocation.jar:1.1.1.Final]
at
org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53)
[jboss-invocation.jar:1.1.1.Final]
at
org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:36)
[jboss-as-ee-7.1.1.Final.jar:7.1.1.Final]
at

Re: [Users] Quota Memory Max in UI

[Greg Padgett]

On 10/25/2012 02:14 PM, Dead Horse wrote:

I noticed that (using latest GIT Master) the Quota UI will only allow
entering of an integer number 1 - 65535 into the Memory limit to quota
field. Thus in MB this limits max memory per quota to 64GB. I am assuming
this to be a bug as obviously one would want to allow for much more than 64GB.

- DHC


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



Thanks for bringing this up.  I see it, too, and don't know why there 
would be such a limit.


Would you mind opening up a bug to help track the issue?

Thanks,
Greg

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

Re: [Users] Problems with F17 and ovirt 3.1

[Greg Padgett]

On 08/20/2012 04:48 AM, Alex Lourie wrote:

I think it's the internals of the backend. Adding host, creating all the 
required objects, filling the DB, creting configurations, etc.

We actually are using ovirtsdk for doing that, so it's something internal in 
that lib.



One message stood out to me, being very similar to a problem I saw.  I'd 
like to try and rule it out, if possible (see below).



- Original Message -
From: Itamar Heim ih...@redhat.com
To: Alex Lourie alou...@redhat.com
Cc: Veli-Matti Leppänen ve...@velhot.net, users@ovirt.org, Eli Mesika 
emes...@redhat.com
Sent: Monday, August 20, 2012 11:17:18 AM
Subject: Re: [Users] Problems with F17 and ovirt 3.1

On 08/20/2012 11:12 AM, Alex Lourie wrote:

The actual operation of creating host is taking time. I believe we've handled 
its timeout before, but it is possible that our waiting period is still too 
short.


which part is taking the time if all rpms are already pre-installed?



I will look into this.

Veli, could you open a bug please? Thank you.

- Original Message -
From: Itamar Heim ih...@redhat.com
To: Eli Mesika emes...@redhat.com
Cc: Veli-Matti Leppänen ve...@velhot.net, users@ovirt.org, Alex Lourie 
alou...@redhat.com
Sent: Sunday, August 19, 2012 7:33:27 PM
Subject: Re: [Users] Problems with F17 and ovirt 3.1

On 08/19/2012 12:14 PM, Eli Mesika wrote:



- Original Message -

From: Veli-Matti Leppänen ve...@velhot.net
To: users@ovirt.org
Sent: Sunday, August 19, 2012 11:47:46 AM
Subject: Re: [Users] Problems with F17 and ovirt 3.1


On 2012-08-19 10:48, Eli Mesika wrote:

- Original Message -

From: Veli-Matti Leppänen ve...@velhot.net
To: users@ovirt.org
Sent: Saturday, August 18, 2012 1:13:23 PM
Subject: Re: [Users] Problems with F17 and ovirt 3.1

Hi.

I tried to install ovirt 3.1 on clean F17 hosts. I tried
all-in-one
and plain manager + node installation, but every time host is just
non-responsive.

vdsmd service does not start
[root@maila ~]# service vdsmd start
Redirecting to /bin/systemctl start  vdsmd.service
Job canceled.
and there is no vdsm log.


Veli, does your host have a /var/lib/vdsm/netconfback directory present?  I 
have found that this can cause the Job canceled message due to some 
interactions between systemd services.


In my case, removing that directory and restarting vdsmd solved the issue 
(of course be sure to inspect the old network setup in the netconfback 
directory before deleting it, in case you may need it).




selinux or iptables is not the issue, cause setting selinux to
permissive mode or flushing the firewall does not help.

any ideas where to start?


There was an excellent step-by-step video showing how to install
all-in-one on top of f17
please follow and check again

http://blog.jebpages.com/archives/up-and-running-with-ovirt-3-1-edition/



I followed that video. Installation times out during adding local
host.
Web admin console shows it installing and after that it goes to
non-responsing state.

Hi again
please refer to the following (taken from the same site)

I’ve found that the all-in-one installer sometimes times out during the install 
process. If the script times out during the final “AIO: Adding Local host (This 
may take several minutes)” step, you can proceed to the web admin console to 
complete the process. If it times out at an earlier point, like waiting for the 
jboss-as server to start, you should run “engine-cleanup” and then re-run 
“engine-setup”.





/Vellu


---
__
Veli-Matti Leppänen
ve...@velhot.net
Velzi @ IRC

___
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



Eli/Alex - what are we timing out on?
1. all-in-one rpm is supposed to require vdsm rpms so the add host
wouldn't really need to install them
2. all-in-one is skipping the reboot





___
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