[ovirt-users] Re: extending vm disk when vm is up

[Nir Soffer]

On Fri, Apr 9, 2021 at 12:00 AM Nathanaël Blanchet  wrote:
>
> Hello,
>
> Why it is not possible to extend disk size into UI when a vm is up while
> it is possible to do the same with API/SDK/ansible?

It should work.

Which version are you using? Do you see any errors in engine log?
Any errors in the browser console?

Nir

> --
> Nathanaël Blanchet
>
> Supervision réseau
> SIRE
> 227 avenue Professeur-Jean-Louis-Viala
> 34193 MONTPELLIER CEDEX 5
> Tél. 33 (0)4 67 54 84 55
> Fax  33 (0)4 67 54 84 14
> blanc...@abes.fr
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/privacy-policy.html
> oVirt Code of Conduct: 
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives: 
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/ZQJFANDIRQTLYYXDKFS3J62D7WCTM7D6/
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/BSNKK47DZBLMO553HF2N5V5QTNMLEMFX/

[ovirt-users] extending vm disk when vm is up

[Nathanaël Blanchet]

Hello,

Why it is not possible to extend disk size into UI when a vm is up while 
it is possible to do the same with API/SDK/ansible?


--
Nathanaël Blanchet

Supervision réseau
SIRE
227 avenue Professeur-Jean-Louis-Viala
34193 MONTPELLIER CEDEX 5   
Tél. 33 (0)4 67 54 84 55
Fax  33 (0)4 67 54 84 14
blanc...@abes.fr
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/ZQJFANDIRQTLYYXDKFS3J62D7WCTM7D6/

[ovirt-users] Re: ova import

[eevans]

I'm extracting the ova into vm and disk. The disk does not have a  file 
extension but am importing it into ovirt. 
If this works, I'll let you know.
However, the fact that it thin provisions the drive even though I chose 
preallocated bothers me. WHen extracted, the disk file is the right size. 
Something about v2v isn't importing correctly or not able to seperate the disk 
and create it properly.
I'll keep you posted.
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/NC4S2LN5RTRZWZBPIGRK5ODUOJLYTMOW/

[ovirt-users] Re: How to detach FC Storage Domain

[Miguel Garcia]

Another quetion, I had done this before with NFS storage domain types and can 
list vms, templates and disk in reattached storage domain but for this FC I do 
not see any.
Do I need to perform an additioal action?
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/7KAK6MGWDVTECGDSC77OUYZLIACRFRGS/

[ovirt-users] Re: How to detach FC Storage Domain

[Miguel Garcia]

Thank you, it worked.
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/BP4YK4OX54HSHOS6YHJPD2RBBM6NYTYX/

[ovirt-users] Re: How to detach FC Storage Domain

[Shani Leviim]

Hi Miguel,
You can try to destroy the storage domain:
Storage > Storage domain > select the domain > 3 dots menu > destroy.

Then just add it again to the desired DC.


*Regards,*

*Shani Leviim*


On Thu, Apr 8, 2021 at 6:30 PM Miguel Garcia 
wrote:

> I have added some FC storage domains into incorrect Data Center, I'm
> trying to detach them by moving to Storage -> Storage domain select storage
> domain -> Data Center tab and click on detach button then got the following
> error: Failing detaching storage domain from Data Center
>
> In log files so far found next lines:
>
> 2021-03-25 22:58:41,621-04 INFO
> [org.ovirt.engine.core.vdsbroker.irsbroker.DetachStorageDomainVDSCommand]
> (EE-ManagedThreadFactory-engine-Thread-2636)
> [0a08dff7-13c4-49c2-b451-0dea136941ec] START,
> DetachStorageDomainVDSCommand(
> DetachStorageDomainVDSCommandParameters:{storagePoolId='68b8d8e9-af51-457d-9b9d-36e37ad60d55',
> ignoreFailoverLimit='false',
> storageDomainId='a1f6a779-a65f-427c-b034-174e1150361d',
> masterDomainId='----', masterVersion='1',
> force='false'}), log id: 42974429
> 2021-03-25 22:58:42,941-04 ERROR
> [org.ovirt.engine.core.vdsbroker.irsbroker.DetachStorageDomainVDSCommand]
> (EE-ManagedThreadFactory-engine-Thread-2636)
> [0a08dff7-13c4-49c2-b451-0dea136941ec] Failed in 'DetachStorageDomainVDS'
> method
> 2021-03-25 22:58:42,944-04 ERROR
> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
> (EE-ManagedThreadFactory-engine-Thread-2636)
> [0a08dff7-13c4-49c2-b451-0dea136941ec] EVENT_ID:
> IRS_BROKER_COMMAND_FAILURE(10,803), VDSM command DetachStorageDomainVDS
> failed: Storage domain does not exist:
> (u'a1f6a779-a65f-427c-b034-174e1150361d',)
> 2021-03-25 22:58:42,945-04 ERROR
> [org.ovirt.engine.core.vdsbroker.irsbroker.DetachStorageDomainVDSCommand]
> (EE-ManagedThreadFactory-engine-Thread-2636)
> [0a08dff7-13c4-49c2-b451-0dea136941ec] Command
> 'DetachStorageDomainVDSCommand(
> DetachStorageDomainVDSCommandParameters:{storagePoolId='68b8d8e9-af51-457d-9b9d-36e37ad60d55',
> ignoreFailoverLimit='false',
> storageDomainId='a1f6a779-a65f-427c-b034-174e1150361d',
> masterDomainId='----', masterVersion='1',
> force='false'})' execution failed: IRSGenericException: IRSErrorException:
> Failed to DetachStorageDomainVDS, error = Storage domain does not exist:
> (u'a1f6a779-a65f-427c-b034-174e1150361d',), code = 358
>
> Seems that the storage domain does not exists. Is there a way to force
> detach action?
>
> Thanks in advance
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/privacy-policy.html
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/Q6TXNCIUDBJZPAXJBE3RQR7WYRVDO7GP/
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/2Y5XILF7NMUJOSN7VABNXLEQNHJAWVEI/

[ovirt-users] How to detach FC Storage Domain

[Miguel Garcia]

I have added some FC storage domains into incorrect Data Center, I'm trying to 
detach them by moving to Storage -> Storage domain select storage domain -> 
Data Center tab and click on detach button then got the following error: 
Failing detaching storage domain from Data Center

In log files so far found next lines:

2021-03-25 22:58:41,621-04 INFO  
[org.ovirt.engine.core.vdsbroker.irsbroker.DetachStorageDomainVDSCommand] 
(EE-ManagedThreadFactory-engine-Thread-2636) 
[0a08dff7-13c4-49c2-b451-0dea136941ec] START, DetachStorageDomainVDSCommand( 
DetachStorageDomainVDSCommandParameters:{storagePoolId='68b8d8e9-af51-457d-9b9d-36e37ad60d55',
 ignoreFailoverLimit='false', 
storageDomainId='a1f6a779-a65f-427c-b034-174e1150361d', 
masterDomainId='----', masterVersion='1', 
force='false'}), log id: 42974429
2021-03-25 22:58:42,941-04 ERROR 
[org.ovirt.engine.core.vdsbroker.irsbroker.DetachStorageDomainVDSCommand] 
(EE-ManagedThreadFactory-engine-Thread-2636) 
[0a08dff7-13c4-49c2-b451-0dea136941ec] Failed in 'DetachStorageDomainVDS' method
2021-03-25 22:58:42,944-04 ERROR 
[org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] 
(EE-ManagedThreadFactory-engine-Thread-2636) 
[0a08dff7-13c4-49c2-b451-0dea136941ec] EVENT_ID: 
IRS_BROKER_COMMAND_FAILURE(10,803), VDSM command DetachStorageDomainVDS failed: 
Storage domain does not exist: (u'a1f6a779-a65f-427c-b034-174e1150361d',)
2021-03-25 22:58:42,945-04 ERROR 
[org.ovirt.engine.core.vdsbroker.irsbroker.DetachStorageDomainVDSCommand] 
(EE-ManagedThreadFactory-engine-Thread-2636) 
[0a08dff7-13c4-49c2-b451-0dea136941ec] Command 'DetachStorageDomainVDSCommand( 
DetachStorageDomainVDSCommandParameters:{storagePoolId='68b8d8e9-af51-457d-9b9d-36e37ad60d55',
 ignoreFailoverLimit='false', 
storageDomainId='a1f6a779-a65f-427c-b034-174e1150361d', 
masterDomainId='----', masterVersion='1', 
force='false'})' execution failed: IRSGenericException: IRSErrorException: 
Failed to DetachStorageDomainVDS, error = Storage domain does not exist: 
(u'a1f6a779-a65f-427c-b034-174e1150361d',), code = 358

Seems that the storage domain does not exists. Is there a way to force detach 
action?

Thanks in advance
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/Q6TXNCIUDBJZPAXJBE3RQR7WYRVDO7GP/

[ovirt-users] Re: Destroyed VM blocking hosts/filling logs

[David Kerry]

Hi Shani,

Thank you!  I've successfully nuked the zombie VMs from this host, and after a 
reboot,
everything is back to normal again.

Not sure how these VMs got stuck like this in the first place, but at least I 
have
an option for cleaning it up now.


David Kerry

On 2021-04-08 10:28 a.m., Shani Leviim wrote:

You can find your virsh user and password in 
/etc/ovirt-hosted-engine/virsh_auth.conf
The content should be something like this:

sudo cat /etc/ovirt-hosted-engine/virsh_auth.conf
[credentials-vdsm]
authname=vdsm@ovirt
password=mypassword


*Regards,
*
*Shani Leviim
*


On Thu, Apr 8, 2021 at 5:20 PM David Kerry mailto:dav...@riavera.com>> wrote:

Hi Shani,

I actually came across that option and attempted it at one point,
but vdsm has locked me out of using that command it seems.

Eg:

[root@ovirt-node217 ~]# virsh undefine vm-s2
Please enter your authentication name: admin
Please enter your password:
error: failed to connect to the hypervisor
error: authentication failed: authentication failed

No known username/password seems to work.

Is there some magic user to use for this, or some way
to bypass the authentication?

Thanks

David

On 2021-04-08 10:10 a.m., Shani Leviim wrote:
 > Hi David,
 > Yes - this one will remove completely the VM from the DB.
 >
 > You can use the virsh command to delete the VM guests:
 > https://www.cyberciti.biz/faq/howto-linux-delete-a-running-vm-guest-on-kvm/ 
 
>
 >
 > *Regards,
 > *
 > *Shani Leviim
 > *
 >
 >
 > On Thu, Apr 8, 2021 at 4:32 PM David Kerry mailto:dav...@riavera.com> >> 
wrote:
 >
 >     Hi Shani,
 >
 >     These VMs in particular are running just fine on other hosts (and
 >     I'd like to keep them that way, preferably).
 >
 >     It looks like this command would delete the whole VM from the
 >     entire system instead of just removing the stuck/shutdown instances
 >     from the hosts it's not running on any more.
 >
 >     Can you confirm this is what it would do?  If so, is there another
 >     option to remove these stuck "ghost" VM instances from the hosts 
they are
 >     no longer running on?
 >
 >
 >     Thanks
 >
 >     David
 >
 >
 >     On 2021-04-08 3:20 a.m., Shani Leviim wrote:
 >      > Hi David,
 >      > You can delete the VM from the DB using this command:
 >      > SELECT DeleteVm('');
 >      >
 >      > *Regards,
 >      > *
 >      > *Shani Leviim
 >      > *
 >      >
 >      >
 >      > On Wed, Apr 7, 2021 at 4:23 PM David Kerry mailto:dav...@riavera.com> 
>  
      >
 >      >     Hello,
 >      >
 >      >     This seems to be what the engine is trying to do, and failing 
at for some reason.
 >      >
 >      >     eg:
 >      >
 >      >     [root@ovirt-node217 ~]# vdsm-client Host getVMList 
fullStatus=True
 >      >     [
 >      >          "8b3964bc-cd3f-4f13-84c6-1811193c93eb",
 >      >          "132668b6-9992-451f-95ac-dbcbeb03f5f1"
 >      >     ]
 >      >
 >      >     For reference:
 >      >
 >      >     [root@ovirt-node217 ~]# virsh -r list --all
 >      >       Id    Name   State
 >      >     
 >      >       - vm-s2                      shut off
 >      >       - vm-s1                      shut off
 >      >
 >      >     And in the console, it shows a count of "2" beside this host, 
but on the host detail
 >      >     page, under the virtual-machine tab, the list is empty (these 
VMs are actually
 >      >     running on a different host).
 >      >
 >      >     [root@ovirt-node217 ~]# vdsm-client VM destroy 
vmID="8b3964bc-cd3f-4f13-84c6-1811193c93eb"
 >      >     vdsm-client: Command VM.destroy with args {'vmID': 
'8b3964bc-cd3f-4f13-84c6-1811193c93eb'} failed:
 >      >     (code=100, message=General Exception: ("'1048576'",))
 >      >
 >      >     I guess what I need is a way to remove/clean-up these VMs 
manually since ovirt
 >      >     does not seem to be able to do it by itself.
 >      >
 >      >     This condition also blocks the host from being put into 
maintenance mode.
 >      >
 >      >     When I reboot the host manually and "confirm host was 
rebooted", the 

[ovirt-users] [ANN] oVirt 4.4.6 Third Release Candidate is now available for testing

[Lev Veyde]

oVirt 4.4.6 Third Release Candidate is now available for testing

The oVirt Project is pleased to announce the availability of oVirt 4.4.6
Third Release Candidate for testing, as of April 8th, 2021.

This update is the sixth in a series of stabilization updates to the 4.4
series.
How to prevent hosts entering emergency mode after upgrade from oVirt 4.4.1

Note: Upgrading from 4.4.2 GA or later should not require re-doing these
steps, if already performed while upgrading from 4.4.1 to 4.4.2 GA. These
are only required to be done once.

Due to Bug 1837864  -
Host enter emergency mode after upgrading to latest build

If you have your root file system on a multipath device on your hosts you
should be aware that after upgrading from 4.4.1 to 4.4.6 you may get your
host entering emergency mode.

In order to prevent this be sure to upgrade oVirt Engine first, then on
your hosts:

   1.

   Remove the current lvm filter while still on 4.4.1, or in emergency mode
   (if rebooted).
   2.

   Reboot.
   3.

   Upgrade to 4.4.6 (redeploy in case of already being on 4.4.6).
   4.

   Run vdsm-tool config-lvm-filter to confirm there is a new filter in
   place.
   5.

   Only if not using oVirt Node:
   - run "dracut --force --add multipath” to rebuild initramfs with the
   correct filter configuration
   6.

   Reboot.

Documentation

   -

   If you want to try oVirt as quickly as possible, follow the instructions
   on the Download  page.
   -

   For complete installation, administration, and usage instructions, see
   the oVirt Documentation .
   -

   For upgrading from a previous version, see the oVirt Upgrade Guide
   .
   -

   For a general overview of oVirt, see About oVirt
   .

Important notes before you try it

Please note this is a pre-release build.

The oVirt Project makes no guarantees as to its suitability or usefulness.

This pre-release must not be used in production.
Installation instructions

For installation instructions and additional information please refer to:

https://ovirt.org/documentation/

This release is available now on x86_64 architecture for:

* Red Hat Enterprise Linux 8.3 or newer

* CentOS Linux (or similar) 8.3 or newer

This release supports Hypervisor Hosts on x86_64 and ppc64le architectures
for:

* Red Hat Enterprise Linux 8.3 or newer

* CentOS Linux (or similar) 8.3 or newer

* oVirt Node 4.4 based on CentOS Linux 8.3 (available for x86_64 only)

See the release notes [1] for installation instructions and a list of new
features and bugs fixed.

Notes:

- oVirt Appliance is already available for CentOS Linux 8

- oVirt Node NG is already available for CentOS Linux 8

- We found a few issues while testing on CentOS Stream so we are still
basing oVirt 4.4.6 Node and Appliance on CentOS Linux.

Additional Resources:

* Read more about the oVirt 4.4.6 release highlights:
http://www.ovirt.org/release/4.4.6/

* Get more oVirt project updates on Twitter: https://twitter.com/ovirt

* Check out the latest project news on the oVirt blog:
http://www.ovirt.org/blog/


[1] http://www.ovirt.org/release/4.4.6/

[2] http://resources.ovirt.org/pub/ovirt-4.4-pre/iso/

-- 

Lev Veyde

Senior Software Engineer, RHCE | RHCVA | MCITP

Red Hat Israel



l...@redhat.com | lve...@redhat.com

TRIED. TESTED. TRUSTED. 
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/ODKN6XHBFNWI5ZMPUHNYTYE3SOUKTLXR/

[ovirt-users] Re: Q: Sparsify/fstrim don't reduce actual disk image size

[Nir Soffer]

On Thu, Apr 8, 2021 at 10:04 AM Andrei Verovski  wrote:
>
> Hi,
>
> Many thanks, its worked ! Actual size shrunk from 584 to 9 GB, now I have 
> space to backup.
>
> Is there any guidelines how to format QCOW2 images (for Linux) so they can be 
> shrunk in an efficient way?
> With this NextCloud/Collabora LVM I did in the following order:
> swap
> ext2 boot
> ext4 root
> ext4 var (large, for data, all cloud data stored here)
>
> Ext4 partitions on LVM.
>
> Or this is not predictable how data will span QCOW2 space?

I think there is no way to avoid this issue with ovirt block storage.

Regardless of how the data is laid out in the qcow2 image, when we don't
have enough space ovirt extend the disk. This happens many times until
the disk reaches the virtual size (actually more because of qcow2 metadata).

For example we start with 1g image:

[xx--]

Now you write more and ovirt extend the image:

[--]

This repeats many times...

[xxx---]

When you sparsify, some clusters are marked as zero (or discarded), but if
they are not at the end of the image we cannot shrink the image.

[xxxxx---x-xxxxx-x--xx--xx-]

When  you copy the image to a new image the discarded or zero parts are
skipped and the new image contains only the actual data.

If qemu will support a way to defragment an image (best online):

[---]

ovirt can shrink the logical volume after that.

[]

Adding qemu-block since this is an interesting use case that may be useful
to more qemu users.

Nir

> > On 7 Apr 2021, at 18:43, Nir Soffer  wrote:
> >
> > On Wed, Apr 7, 2021 at 5:36 PM Andrei Verovski  wrote:
> >>
> >> Hi !
> >>
> >> I have VM (under oVirt) with single disk thin provision (~600 GB)
> >
> > I guess you are using block storage?
> >
> >> running NextCloud on Debian 9.
> >> Right now VM HD is almost empty. Unfortunately, it occupies 584 GB 
> >> (virtual size = 600 GB)
> >> All partition (except swap and boot) are EXT4 with discard option.
> >
> > You don't need to use discard mount option. fstrim works without it.
> >
> >> in oVirt “enable discard = on”.
> >>
> >> # fstrim -av runs successfully:
> >> /var: 477.6 GiB (512851144704 bytes) trimmed on 
> >> /dev/mapper/vg--system-lv4--data
> >> /boot: 853.8 MiB (895229952 bytes) trimmed on 
> >> /dev/mapper/vg--system-lv2--boot
> >> /: 88.4 GiB (94888611840 bytes) trimmed on /dev/mapper/vg--system-lv3—sys
> >>
> >> When fstrim runs again, it trims zero. I even run “Sparsify” in oVirt. 
> >> Unfortunately, actual size is still 584 GB.
> >>
> >> Here is /etc/fstab
> >> /dev/mapper/vg--system-lv3--sys /   ext4
> >> discard,noatime,nodiratime,errors=remount-ro 0   1
> >> /dev/mapper/vg--system-lv2--boot /boot   ext2defaults0 
> >>   2
> >> /dev/mapper/vg--system-lv4--data /varext4
> >> discard,noatime,nodiratime 0   2
> >> /dev/mapper/vg--system-lv1--swap noneswapsw  0 
> >>   0
> >>
> >> When disk was partitioned/formatted, swap and boot were created first and 
> >> positioned at the beginning.
> >>
> >> What is wrong here? Is it possible to fix all this ?
> >
> > Discarding data mark the areas in the qcow2 image as zero, but it does not 
> > move
> > actual data around (which is very slow). So if the clusters were at
> > the end of the
> > image they remain there, and the actual file size is the same.
> >
> > The only way to reclaim the space is:
> > 1. sparsify disk - must be done *before* copying the disk.
> > 2. move this to another storage domain
> > 3. move disk back to the original storage domain
> >
> > We may have an easier and more efficient way in the future that
> > works with single storage domain, but it will have to copy the
> > entire disk. If the disk is really mostly empty it should be fast.
> >
> > Nir
> >
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/5AFMLQDU7E2SQQYMUNITPPX4TA4XLSOE/

[ovirt-users] Re: [Help] The engine is not stable on HostedEngine with GlusterFS Herperverged deployment

[mengz . you]

Hi, 

Sorry, what's your meanings for "choose to add it to the hosted-engine 
cluster"? I just add the 4th without choose to hosted-engine run (means the 
hosted-egnine vm will not mirgrated the 4th host, just in 1, 2, 3 hosts".

Sorry, where the -ha logs? on hosts or engine vm?  

And, whether this related to DNS server? seems lots of queries to DNS server
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/3IRHRPJWXZ744Z5ESZWJKTVFFSKWXFFP/

[ovirt-users] Re: Destroyed VM blocking hosts/filling logs

[Benny Zlotnik]

username: vdsm@ovirrt, password: shibboleth

On Thu, Apr 8, 2021 at 5:25 PM David Kerry  wrote:
>
> Hi Shani,
>
> I actually came across that option and attempted it at one point,
> but vdsm has locked me out of using that command it seems.
>
> Eg:
>
> [root@ovirt-node217 ~]# virsh undefine vm-s2
> Please enter your authentication name: admin
> Please enter your password:
> error: failed to connect to the hypervisor
> error: authentication failed: authentication failed
>
> No known username/password seems to work.
>
> Is there some magic user to use for this, or some way
> to bypass the authentication?
>
> Thanks
>
> David
>
> On 2021-04-08 10:10 a.m., Shani Leviim wrote:
> > Hi David,
> > Yes - this one will remove completely the VM from the DB.
> >
> > You can use the virsh command to delete the VM guests:
> > https://www.cyberciti.biz/faq/howto-linux-delete-a-running-vm-guest-on-kvm/ 
> > 
> >
> > *Regards,
> > *
> > *Shani Leviim
> > *
> >
> >
> > On Thu, Apr 8, 2021 at 4:32 PM David Kerry  > > wrote:
> >
> > Hi Shani,
> >
> > These VMs in particular are running just fine on other hosts (and
> > I'd like to keep them that way, preferably).
> >
> > It looks like this command would delete the whole VM from the
> > entire system instead of just removing the stuck/shutdown instances
> > from the hosts it's not running on any more.
> >
> > Can you confirm this is what it would do?  If so, is there another
> > option to remove these stuck "ghost" VM instances from the hosts they 
> > are
> > no longer running on?
> >
> >
> > Thanks
> >
> > David
> >
> >
> > On 2021-04-08 3:20 a.m., Shani Leviim wrote:
> >  > Hi David,
> >  > You can delete the VM from the DB using this command:
> >  > SELECT DeleteVm('');
> >  >
> >  > *Regards,
> >  > *
> >  > *Shani Leviim
> >  > *
> >  >
> >  >
> >  > On Wed, Apr 7, 2021 at 4:23 PM David Kerry  >   > >> wrote:
> >  >
> >  > Hello,
> >  >
> >  > This seems to be what the engine is trying to do, and failing at 
> > for some reason.
> >  >
> >  > eg:
> >  >
> >  > [root@ovirt-node217 ~]# vdsm-client Host getVMList 
> > fullStatus=True
> >  > [
> >  >  "8b3964bc-cd3f-4f13-84c6-1811193c93eb",
> >  >  "132668b6-9992-451f-95ac-dbcbeb03f5f1"
> >  > ]
> >  >
> >  > For reference:
> >  >
> >  > [root@ovirt-node217 ~]# virsh -r list --all
> >  >   IdName   State
> >  > 
> >  >   - vm-s2  shut off
> >  >   - vm-s1  shut off
> >  >
> >  > And in the console, it shows a count of "2" beside this host, 
> > but on the host detail
> >  > page, under the virtual-machine tab, the list is empty (these 
> > VMs are actually
> >  > running on a different host).
> >  >
> >  > [root@ovirt-node217 ~]# vdsm-client VM destroy 
> > vmID="8b3964bc-cd3f-4f13-84c6-1811193c93eb"
> >  > vdsm-client: Command VM.destroy with args {'vmID': 
> > '8b3964bc-cd3f-4f13-84c6-1811193c93eb'} failed:
> >  > (code=100, message=General Exception: ("'1048576'",))
> >  >
> >  > I guess what I need is a way to remove/clean-up these VMs 
> > manually since ovirt
> >  > does not seem to be able to do it by itself.
> >  >
> >  > This condition also blocks the host from being put into 
> > maintenance mode.
> >  >
> >  > When I reboot the host manually and "confirm host was rebooted", 
> > the VMs
> >  > are still there and still stuck.
> >  >
> >  > Sincerely,
> >  >
> >  > David
> >  >
> >  >
> >  > On 2021-04-07 6:01 a.m., Shani Leviim wrote:
> >  >> Hi,
> >  >> You can try with the vdsm-client tool:
> >  >> https://www.ovirt.org/develop/developer-guide/vdsm/vdsm-client.html 
> >  
> >  > >
> >  >>
> >  >> Stopping a VM:
> >  >> 1) Get the vmId:
> >  >> # vdsm-client Host getVMList fullStatus=True
> >  >>
> >  >> 2) Destroy the VM
> >  >> # vdsm-client VM destroy vmID=
> >  >>
> >  >> *Regards,
> >  >> *
> >  >> *Shani Leviim
> >  >> *
> >  >>
> >  >>
> >  >> On Sat, Apr 3, 2021 at 7:50 AM  >   > >> wrote:
> >  >>
> >   

[ovirt-users] Re: Destroyed VM blocking hosts/filling logs

[Shani Leviim]

You can find your virsh user and password in
/etc/ovirt-hosted-engine/virsh_auth.conf
The content should be something like this:

sudo cat /etc/ovirt-hosted-engine/virsh_auth.conf
[credentials-vdsm]
authname=vdsm@ovirt
password=mypassword



*Regards,*

*Shani Leviim*


On Thu, Apr 8, 2021 at 5:20 PM David Kerry  wrote:

> Hi Shani,
>
> I actually came across that option and attempted it at one point,
> but vdsm has locked me out of using that command it seems.
>
> Eg:
>
> [root@ovirt-node217 ~]# virsh undefine vm-s2
> Please enter your authentication name: admin
> Please enter your password:
> error: failed to connect to the hypervisor
> error: authentication failed: authentication failed
>
> No known username/password seems to work.
>
> Is there some magic user to use for this, or some way
> to bypass the authentication?
>
> Thanks
>
> David
>
> On 2021-04-08 10:10 a.m., Shani Leviim wrote:
> > Hi David,
> > Yes - this one will remove completely the VM from the DB.
> >
> > You can use the virsh command to delete the VM guests:
> >
> https://www.cyberciti.biz/faq/howto-linux-delete-a-running-vm-guest-on-kvm/
> <
> https://www.cyberciti.biz/faq/howto-linux-delete-a-running-vm-guest-on-kvm/
> >
> >
> > *Regards,
> > *
> > *Shani Leviim
> > *
> >
> >
> > On Thu, Apr 8, 2021 at 4:32 PM David Kerry  dav...@riavera.com>> wrote:
> >
> > Hi Shani,
> >
> > These VMs in particular are running just fine on other hosts (and
> > I'd like to keep them that way, preferably).
> >
> > It looks like this command would delete the whole VM from the
> > entire system instead of just removing the stuck/shutdown instances
> > from the hosts it's not running on any more.
> >
> > Can you confirm this is what it would do?  If so, is there another
> > option to remove these stuck "ghost" VM instances from the hosts
> they are
> > no longer running on?
> >
> >
> > Thanks
> >
> > David
> >
> >
> > On 2021-04-08 3:20 a.m., Shani Leviim wrote:
> >  > Hi David,
> >  > You can delete the VM from the DB using this command:
> >  > SELECT DeleteVm('');
> >  >
> >  > *Regards,
> >  > *
> >  > *Shani Leviim
> >  > *
> >  >
> >  >
> >  > On Wed, Apr 7, 2021 at 4:23 PM David Kerry   >> wrote:
> >  >
> >  > Hello,
> >  >
> >  > This seems to be what the engine is trying to do, and failing
> at for some reason.
> >  >
> >  > eg:
> >  >
> >  > [root@ovirt-node217 ~]# vdsm-client Host getVMList
> fullStatus=True
> >  > [
> >  >  "8b3964bc-cd3f-4f13-84c6-1811193c93eb",
> >  >  "132668b6-9992-451f-95ac-dbcbeb03f5f1"
> >  > ]
> >  >
> >  > For reference:
> >  >
> >  > [root@ovirt-node217 ~]# virsh -r list --all
> >  >   IdName   State
> >  > 
> >  >   - vm-s2  shut off
> >  >   - vm-s1  shut off
> >  >
> >  > And in the console, it shows a count of "2" beside this host,
> but on the host detail
> >  > page, under the virtual-machine tab, the list is empty (these
> VMs are actually
> >  > running on a different host).
> >  >
> >  > [root@ovirt-node217 ~]# vdsm-client VM destroy
> vmID="8b3964bc-cd3f-4f13-84c6-1811193c93eb"
> >  > vdsm-client: Command VM.destroy with args {'vmID':
> '8b3964bc-cd3f-4f13-84c6-1811193c93eb'} failed:
> >  > (code=100, message=General Exception: ("'1048576'",))
> >  >
> >  > I guess what I need is a way to remove/clean-up these VMs
> manually since ovirt
> >  > does not seem to be able to do it by itself.
> >  >
> >  > This condition also blocks the host from being put into
> maintenance mode.
> >  >
> >  > When I reboot the host manually and "confirm host was
> rebooted", the VMs
> >  > are still there and still stuck.
> >  >
> >  > Sincerely,
> >  >
> >  > David
> >  >
> >  >
> >  > On 2021-04-07 6:01 a.m., Shani Leviim wrote:
> >  >> Hi,
> >  >> You can try with the vdsm-client tool:
> >  >>
> https://www.ovirt.org/develop/developer-guide/vdsm/vdsm-client.html <
> https://www.ovirt.org/develop/developer-guide/vdsm/vdsm-client.html> <
> https://www.ovirt.org/develop/developer-guide/vdsm/vdsm-client.html <
> https://www.ovirt.org/develop/developer-guide/vdsm/vdsm-client.html>>
> >  >>
> >  >> Stopping a VM:
> >  >> 1) Get the vmId:
> >  >> # vdsm-client Host getVMList fullStatus=True
> >  >>
> >  >> 2) Destroy the VM
> >  >> # vdsm-client VM destroy vmID=
> >  >>
> >  >> *Regards,
> >  >> *
> >  >> *Shani Leviim
> >  >> *
> >  >>
> >  

[ovirt-users] Re: Destroyed VM blocking hosts/filling logs

[David Kerry]

Hi Shani,

I actually came across that option and attempted it at one point,
but vdsm has locked me out of using that command it seems.

Eg:

[root@ovirt-node217 ~]# virsh undefine vm-s2
Please enter your authentication name: admin
Please enter your password:
error: failed to connect to the hypervisor
error: authentication failed: authentication failed

No known username/password seems to work.

Is there some magic user to use for this, or some way
to bypass the authentication?

Thanks

David

On 2021-04-08 10:10 a.m., Shani Leviim wrote:

Hi David,
Yes - this one will remove completely the VM from the DB.

You can use the virsh command to delete the VM guests:
https://www.cyberciti.biz/faq/howto-linux-delete-a-running-vm-guest-on-kvm/ 


*Regards,
*
*Shani Leviim
*


On Thu, Apr 8, 2021 at 4:32 PM David Kerry mailto:dav...@riavera.com>> wrote:

Hi Shani,

These VMs in particular are running just fine on other hosts (and
I'd like to keep them that way, preferably).

It looks like this command would delete the whole VM from the
entire system instead of just removing the stuck/shutdown instances
from the hosts it's not running on any more.

Can you confirm this is what it would do?  If so, is there another
option to remove these stuck "ghost" VM instances from the hosts they are
no longer running on?


Thanks

David


On 2021-04-08 3:20 a.m., Shani Leviim wrote:
 > Hi David,
 > You can delete the VM from the DB using this command:
 > SELECT DeleteVm('');
 >
 > *Regards,
 > *
 > *Shani Leviim
 > *
 >
 >
 > On Wed, Apr 7, 2021 at 4:23 PM David Kerry mailto:dav...@riavera.com> >> 
wrote:
 >
 >     Hello,
 >
 >     This seems to be what the engine is trying to do, and failing at for 
some reason.
 >
 >     eg:
 >
 >     [root@ovirt-node217 ~]# vdsm-client Host getVMList fullStatus=True
 >     [
 >          "8b3964bc-cd3f-4f13-84c6-1811193c93eb",
 >          "132668b6-9992-451f-95ac-dbcbeb03f5f1"
 >     ]
 >
 >     For reference:
 >
 >     [root@ovirt-node217 ~]# virsh -r list --all
 >       Id    Name   State
 >     
 >       - vm-s2                      shut off
 >       - vm-s1                      shut off
 >
 >     And in the console, it shows a count of "2" beside this host, but on 
the host detail
 >     page, under the virtual-machine tab, the list is empty (these VMs 
are actually
 >     running on a different host).
 >
 >     [root@ovirt-node217 ~]# vdsm-client VM destroy 
vmID="8b3964bc-cd3f-4f13-84c6-1811193c93eb"
 >     vdsm-client: Command VM.destroy with args {'vmID': 
'8b3964bc-cd3f-4f13-84c6-1811193c93eb'} failed:
 >     (code=100, message=General Exception: ("'1048576'",))
 >
 >     I guess what I need is a way to remove/clean-up these VMs manually 
since ovirt
 >     does not seem to be able to do it by itself.
 >
 >     This condition also blocks the host from being put into maintenance 
mode.
 >
 >     When I reboot the host manually and "confirm host was rebooted", the 
VMs
 >     are still there and still stuck.
 >
 >     Sincerely,
 >
 >     David
 >
 >
 >     On 2021-04-07 6:01 a.m., Shani Leviim wrote:
 >>     Hi,
 >>     You can try with the vdsm-client tool:
 >> https://www.ovirt.org/develop/developer-guide/vdsm/vdsm-client.html 
 
>
 >>
 >>     Stopping a VM:
 >>     1) Get the vmId:
 >>     # vdsm-client Host getVMList fullStatus=True
 >>
 >>     2) Destroy the VM
 >>     # vdsm-client VM destroy vmID=
 >>
 >>     *Regards,
 >>     *
 >>     *Shani Leviim
 >>     *
 >>
 >>
 >>     On Sat, Apr 3, 2021 at 7:50 AM mailto:dav...@riavera.com> 
>> wrote:
 >>
 >>         Hello,
 >>
 >>         I've somehow gotten one of my VMs stuck in a state that ovirt 
seems to be rather confused about its
 >>         existence of now.  I'm running oVirt 4.3.10 and using oVirt 
Node on all the hosts.
 >>
 >>         My engine and host event logs are now filling up very rapidly 
with this error:
 >>
 >>         VDSM node217 command DestroyVDS failed: General Exception: 
("'1048576'",)
 >>
 >>         I was playing with hugetable support, and that error number or 
string looks suspiciously
 >>         like the "hugetable size" custom property I set on 

[ovirt-users] Re: Destroyed VM blocking hosts/filling logs

[Shani Leviim]

Hi David,
Yes - this one will remove completely the VM from the DB.

You can use the virsh command to delete the VM guests:
https://www.cyberciti.biz/faq/howto-linux-delete-a-running-vm-guest-on-kvm/


*Regards,*

*Shani Leviim*


On Thu, Apr 8, 2021 at 4:32 PM David Kerry  wrote:

> Hi Shani,
>
> These VMs in particular are running just fine on other hosts (and
> I'd like to keep them that way, preferably).
>
> It looks like this command would delete the whole VM from the
> entire system instead of just removing the stuck/shutdown instances
> from the hosts it's not running on any more.
>
> Can you confirm this is what it would do?  If so, is there another
> option to remove these stuck "ghost" VM instances from the hosts they are
> no longer running on?
>
>
> Thanks
>
> David
>
>
> On 2021-04-08 3:20 a.m., Shani Leviim wrote:
> > Hi David,
> > You can delete the VM from the DB using this command:
> > SELECT DeleteVm('');
> >
> > *Regards,
> > *
> > *Shani Leviim
> > *
> >
> >
> > On Wed, Apr 7, 2021 at 4:23 PM David Kerry  dav...@riavera.com>> wrote:
> >
> > Hello,
> >
> > This seems to be what the engine is trying to do, and failing at for
> some reason.
> >
> > eg:
> >
> > [root@ovirt-node217 ~]# vdsm-client Host getVMList fullStatus=True
> > [
> >  "8b3964bc-cd3f-4f13-84c6-1811193c93eb",
> >  "132668b6-9992-451f-95ac-dbcbeb03f5f1"
> > ]
> >
> > For reference:
> >
> > [root@ovirt-node217 ~]# virsh -r list --all
> >   IdName   State
> > 
> >   - vm-s2  shut off
> >   - vm-s1  shut off
> >
> > And in the console, it shows a count of "2" beside this host, but on
> the host detail
> > page, under the virtual-machine tab, the list is empty (these VMs
> are actually
> > running on a different host).
> >
> > [root@ovirt-node217 ~]# vdsm-client VM destroy
> vmID="8b3964bc-cd3f-4f13-84c6-1811193c93eb"
> > vdsm-client: Command VM.destroy with args {'vmID':
> '8b3964bc-cd3f-4f13-84c6-1811193c93eb'} failed:
> > (code=100, message=General Exception: ("'1048576'",))
> >
> > I guess what I need is a way to remove/clean-up these VMs manually
> since ovirt
> > does not seem to be able to do it by itself.
> >
> > This condition also blocks the host from being put into maintenance
> mode.
> >
> > When I reboot the host manually and "confirm host was rebooted", the
> VMs
> > are still there and still stuck.
> >
> > Sincerely,
> >
> > David
> >
> >
> > On 2021-04-07 6:01 a.m., Shani Leviim wrote:
> >> Hi,
> >> You can try with the vdsm-client tool:
> >> https://www.ovirt.org/develop/developer-guide/vdsm/vdsm-client.html
> 
> >>
> >> Stopping a VM:
> >> 1) Get the vmId:
> >> # vdsm-client Host getVMList fullStatus=True
> >>
> >> 2) Destroy the VM
> >> # vdsm-client VM destroy vmID=
> >>
> >> *Regards,
> >> *
> >> *Shani Leviim
> >> *
> >>
> >>
> >> On Sat, Apr 3, 2021 at 7:50 AM  dav...@riavera.com>> wrote:
> >>
> >> Hello,
> >>
> >> I've somehow gotten one of my VMs stuck in a state that ovirt
> seems to be rather confused about its
> >> existence of now.  I'm running oVirt 4.3.10 and using oVirt
> Node on all the hosts.
> >>
> >> My engine and host event logs are now filling up very rapidly
> with this error:
> >>
> >> VDSM node217 command DestroyVDS failed: General Exception:
> ("'1048576'",)
> >>
> >> I was playing with hugetable support, and that error number or
> string looks suspiciously
> >> like the "hugetable size" custom property I set on the VM.
> >>
> >> This VM was migrated to another host at one point as well, and
> now that host is also
> >> generating the same error as well.
> >>
> >> When I try to move these hosts to maintenance mode, they get
> stuck in "Preparing for
> >> Maintenance" while it tries to migrate/deal with the VM that's
> not there any more.
> >>
> >> Forcibly rebooting the hosts does not change anything.  The VM
> state/host seems to be
> >> captured somewhere persistent in this case.
> >>
> >> The VM in question is not running, and I can start it up on
> another host successfully,
> >> but ovirt still thinks it exists on the other 2 hosts no matter
> what I do.
> >>
> >> Is there perhaps some way to delete it from the engine database
> directly to straighten
> >> things out?
> >>
> >> Here's a dump of the vdsm log on one of the hosts.  I haven't
> been able to pinpoint what
> >> the exact issue is or how to fix it, but hopefully someone here
> will have seen this before?
> >>
> >> 2021-04-03 04:40:35,515+ INFO  (jsonrpc/1) [api.virt] START
> 

[ovirt-users] Re: Destroyed VM blocking hosts/filling logs

[David Kerry]

Hi Shani,

These VMs in particular are running just fine on other hosts (and
I'd like to keep them that way, preferably).

It looks like this command would delete the whole VM from the
entire system instead of just removing the stuck/shutdown instances
from the hosts it's not running on any more.

Can you confirm this is what it would do?  If so, is there another
option to remove these stuck "ghost" VM instances from the hosts they are
no longer running on?


Thanks

David


On 2021-04-08 3:20 a.m., Shani Leviim wrote:

Hi David,
You can delete the VM from the DB using this command:
SELECT DeleteVm('');

*Regards,
*
*Shani Leviim
*


On Wed, Apr 7, 2021 at 4:23 PM David Kerry mailto:dav...@riavera.com>> wrote:

Hello,

This seems to be what the engine is trying to do, and failing at for some 
reason.

eg:

[root@ovirt-node217 ~]# vdsm-client Host getVMList fullStatus=True
[
     "8b3964bc-cd3f-4f13-84c6-1811193c93eb",
     "132668b6-9992-451f-95ac-dbcbeb03f5f1"
]

For reference:

[root@ovirt-node217 ~]# virsh -r list --all
  Id    Name   State

  - vm-s2                      shut off
  - vm-s1                      shut off

And in the console, it shows a count of "2" beside this host, but on the 
host detail
page, under the virtual-machine tab, the list is empty (these VMs are 
actually
running on a different host).

[root@ovirt-node217 ~]# vdsm-client VM destroy 
vmID="8b3964bc-cd3f-4f13-84c6-1811193c93eb"
vdsm-client: Command VM.destroy with args {'vmID': 
'8b3964bc-cd3f-4f13-84c6-1811193c93eb'} failed:
(code=100, message=General Exception: ("'1048576'",))

I guess what I need is a way to remove/clean-up these VMs manually since 
ovirt
does not seem to be able to do it by itself.

This condition also blocks the host from being put into maintenance mode.

When I reboot the host manually and "confirm host was rebooted", the VMs
are still there and still stuck.

Sincerely,

David


On 2021-04-07 6:01 a.m., Shani Leviim wrote:

Hi,
You can try with the vdsm-client tool:
https://www.ovirt.org/develop/developer-guide/vdsm/vdsm-client.html 


Stopping a VM:
1) Get the vmId:
# vdsm-client Host getVMList fullStatus=True

2) Destroy the VM
# vdsm-client VM destroy vmID=

*Regards,
*
*Shani Leviim
*


On Sat, Apr 3, 2021 at 7:50 AM mailto:dav...@riavera.com>> wrote:

Hello,

I've somehow gotten one of my VMs stuck in a state that ovirt seems to 
be rather confused about its
existence of now.  I'm running oVirt 4.3.10 and using oVirt Node on all 
the hosts.

My engine and host event logs are now filling up very rapidly with this 
error:

VDSM node217 command DestroyVDS failed: General Exception: 
("'1048576'",)

I was playing with hugetable support, and that error number or string 
looks suspiciously
like the "hugetable size" custom property I set on the VM.

This VM was migrated to another host at one point as well, and now that 
host is also
generating the same error as well.

When I try to move these hosts to maintenance mode, they get stuck in 
"Preparing for
Maintenance" while it tries to migrate/deal with the VM that's not 
there any more.

Forcibly rebooting the hosts does not change anything.  The VM 
state/host seems to be
captured somewhere persistent in this case.

The VM in question is not running, and I can start it up on another 
host successfully,
but ovirt still thinks it exists on the other 2 hosts no matter what I 
do.

Is there perhaps some way to delete it from the engine database 
directly to straighten
things out?

Here's a dump of the vdsm log on one of the hosts.  I haven't been able 
to pinpoint what
the exact issue is or how to fix it, but hopefully someone here will 
have seen this before?

2021-04-03 04:40:35,515+ INFO  (jsonrpc/1) [api.virt] START 
destroy(gracefulAttempts=1) from=:::10.100.0.210,58150, 
vmId=58abf0cf-d7b9-4067-a86a-e619928368e7 (api:48)
2021-04-03 04:40:35,516+ INFO  (jsonrpc/1) [virt.vm] 
(vmId='58abf0cf-d7b9-4067-a86a-e619928368e7') Release VM resources (vm:5186)
2021-04-03 04:40:35,516+ WARN  (jsonrpc/1) [virt.vm] 
(vmId='58abf0cf-d7b9-4067-a86a-e619928368e7') trying to set state to Powering 
down when already Down (vm:626)
2021-04-03 04:40:35,516+ INFO  (jsonrpc/1) [virt.vm] 
(vmId='58abf0cf-d7b9-4067-a86a-e619928368e7') Stopping connection 
(guestagent:455)
2021-04-03 04:40:35,517+ INFO  (jsonrpc/1) [vdsm.api] START 
teardownImage(sdUUID='a08af6be-3802-4bb1-9fa5-4b6a10227290', 
spUUID='78dc095a-5238-11e8-b8bf-00163e6a7af9', 

[ovirt-users] Re: [Help] The engine is not stable on HostedEngine with GlusterFS Herperverged deployment

[Yedidyah Bar David]

On Thu, Apr 8, 2021 at 2:40 PM  wrote:
>
> Hi, Didi
>
> The "aways" means, when I operates on Admin Portal normally, somtimes the 
> operation reports a dialog box with 503 error.
> And wait some times, it reback to login page, then I can login to do some 
> operations again.

This indeed sounds like the engine or engine vm are/were sometimes
rebooted/restarted, which might be due to misconfiguration somewhere.

>
> I do not add the 4th nodes to glusterfs, just add it to oVirt cluster as 
> computer host.

OK, and did you choose to add it to the hosted-engine cluster?

Did you check the -ha logs?

Best regards,
-- 
Didi
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/FEF62KGUIVLT5D5CNEYLBEPK4UICB3K6/

[ovirt-users] Re: [Help] The engine is not stable on HostedEngine with GlusterFS Herperverged deployment

[mengz . you]

Hi, Didi

The "aways" means, when I operates on Admin Portal normally, somtimes the 
operation reports a dialog box with 503 error. 
And wait some times, it reback to login page, then I can login to do some 
operations again.  

I do not add the 4th nodes to glusterfs, just add it to oVirt cluster as 
computer host.
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/CBSZNEV42NZQZVXAW2YBVPZGIJZCLVP6/

[ovirt-users] Re: ova import

[Arik Hadas]

On Thu, Apr 8, 2021 at 12:04 PM Gianluca Cecchi 
wrote:

> On Thu, Apr 8, 2021 at 10:49 AM Arik Hadas  wrote:
>
>>
>> On Thu, Apr 8, 2021 at 3:50 AM  wrote:
>>
>>> I am running Ovirt 4.3 and exported machines as ova which includes
>>> disks. When I re import them. the disks are thin provisioned and the vm
>>> will not boot.
>>> Any idea how to get the import to  preallocate disks?  I have vms that
>>> will not boot.
>>>
>> It states no bootable disk is available.
>>> It seems the virt2vm isn't working correctly.
>>> ANy help would be appreciated.
>>>
>>
>> There's no option to change the format of the imported disks at the
>> moment so they'd keep being thin-provisioned as they are within the OVA.
>> I doubt that's the reason for the failure of those VMs to boot though -
>> can you please share the engine.log that shows the configuration that a VM
>> that didn't manage to boot started with?
>>
>>
>>> Eric
>>>
>>
> There were some threads in July 2020 about ova export zero size disks, and
> so unusable import.
> See these bugzillas for more information and also see suggestions about
> how to put a single line fix to your 4.3 install as there was no backport
> but solution only on 4.4
> https://bugzilla.redhat.com/show_bug.cgi?id=1862115
> https://bugzilla.redhat.com/show_bug.cgi?id=1813028
>

Good point.
It's indeed more likely to be the reason than what I had in mind :)


>
> HIH,
> Gianluca
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/GV3DTJ5UNE5Z2IRC5PEEE2B7W24CL36O/

[ovirt-users] Re: cannot export - "r.original_template is undefined"

[Shani Leviim]

The UI messages may not appear on the engine log as they are.
It's mostly related to the operation itself (in your case, ExportVmCommand).

For a better understanding, looking at your logs (ui.log and engine.log) is
essential.
Please share them (here/private).

Also, since it looks like a bug, consider open one at Bugzilla and attach
those logs there and the steps to reproduce.


*Regards,*

*Shani Leviim*


On Wed, Apr 7, 2021 at 8:24 PM Diggy Mc  wrote:

>
> Attached is a screenshot of the error in the GUI.  Also, I could not
> find any relevant entries in either the engine or UI log files.
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/JTS6D3M6PG466T3NSBR6YNBDDNU2XMZQ/

[ovirt-users] Re: ova import

[Gianluca Cecchi]

On Thu, Apr 8, 2021 at 10:49 AM Arik Hadas  wrote:

>
> On Thu, Apr 8, 2021 at 3:50 AM  wrote:
>
>> I am running Ovirt 4.3 and exported machines as ova which includes disks.
>> When I re import them. the disks are thin provisioned and the vm will not
>> boot.
>> Any idea how to get the import to  preallocate disks?  I have vms that
>> will not boot.
>>
> It states no bootable disk is available.
>> It seems the virt2vm isn't working correctly.
>> ANy help would be appreciated.
>>
>
> There's no option to change the format of the imported disks at the moment
> so they'd keep being thin-provisioned as they are within the OVA.
> I doubt that's the reason for the failure of those VMs to boot though -
> can you please share the engine.log that shows the configuration that a VM
> that didn't manage to boot started with?
>
>
>> Eric
>>
>
There were some threads in July 2020 about ova export zero size disks, and
so unusable import.
See these bugzillas for more information and also see suggestions about how
to put a single line fix to your 4.3 install as there was no backport but
solution only on 4.4
https://bugzilla.redhat.com/show_bug.cgi?id=1862115
https://bugzilla.redhat.com/show_bug.cgi?id=1813028

HIH,
Gianluca
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/AIJC5SA6XSW737KNSZVPTFFO7AHWFSHT/

[ovirt-users] Re: ova import

[Arik Hadas]

On Thu, Apr 8, 2021 at 3:50 AM  wrote:

> I am running Ovirt 4.3 and exported machines as ova which includes disks.
> When I re import them. the disks are thin provisioned and the vm will not
> boot.
> Any idea how to get the import to  preallocate disks?  I have vms that
> will not boot.
>
It states no bootable disk is available.
> It seems the virt2vm isn't working correctly.
> ANy help would be appreciated.
>

There's no option to change the format of the imported disks at the moment
so they'd keep being thin-provisioned as they are within the OVA.
I doubt that's the reason for the failure of those VMs to boot though - can
you please share the engine.log that shows the configuration that a VM that
didn't manage to boot started with?


> Eric
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/privacy-policy.html
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/GYGBNMSMEZZJA6GZPVRSMLTBRCXCAILK/
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/6XD5J6II2BOD2TENFLYRFV3R7NHZPCAS/

[ovirt-users] Re: Destroyed VM blocking hosts/filling logs

[Shani Leviim]

Hi David,
You can delete the VM from the DB using this command:
SELECT DeleteVm('');


*Regards,*

*Shani Leviim*


On Wed, Apr 7, 2021 at 4:23 PM David Kerry  wrote:

> Hello,
>
> This seems to be what the engine is trying to do, and failing at for some
> reason.
>
> eg:
>
> [root@ovirt-node217 ~]# vdsm-client Host getVMList fullStatus=True
> [
> "8b3964bc-cd3f-4f13-84c6-1811193c93eb",
> "132668b6-9992-451f-95ac-dbcbeb03f5f1"
> ]
>
> For reference:
>
> [root@ovirt-node217 ~]# virsh -r list --all
>  IdName   State
> 
>  - vm-s2  shut off
>  - vm-s1  shut off
>
> And in the console, it shows a count of "2" beside this host, but on the
> host detail
> page, under the virtual-machine tab, the list is empty (these VMs are
> actually
> running on a different host).
>
> [root@ovirt-node217 ~]# vdsm-client VM destroy
> vmID="8b3964bc-cd3f-4f13-84c6-1811193c93eb"
> vdsm-client: Command VM.destroy with args {'vmID':
> '8b3964bc-cd3f-4f13-84c6-1811193c93eb'} failed:
> (code=100, message=General Exception: ("'1048576'",))
>
> I guess what I need is a way to remove/clean-up these VMs manually since
> ovirt
> does not seem to be able to do it by itself.
>
> This condition also blocks the host from being put into maintenance mode.
>
> When I reboot the host manually and "confirm host was rebooted", the VMs
> are still there and still stuck.
>
> Sincerely,
>
> David
>
>
> On 2021-04-07 6:01 a.m., Shani Leviim wrote:
>
> Hi,
> You can try with the vdsm-client tool:
> https://www.ovirt.org/develop/developer-guide/vdsm/vdsm-client.html
>
> Stopping a VM:
> 1) Get the vmId:
> # vdsm-client Host getVMList fullStatus=True
>
> 2) Destroy the VM
> # vdsm-client VM destroy vmID=
>
>
> *Regards, *
>
> *Shani Leviim *
>
>
> On Sat, Apr 3, 2021 at 7:50 AM  wrote:
>
>> Hello,
>>
>> I've somehow gotten one of my VMs stuck in a state that ovirt seems to be
>> rather confused about its
>> existence of now.  I'm running oVirt 4.3.10 and using oVirt Node on all
>> the hosts.
>>
>> My engine and host event logs are now filling up very rapidly with this
>> error:
>>
>> VDSM node217 command DestroyVDS failed: General Exception: ("'1048576'",)
>>
>> I was playing with hugetable support, and that error number or string
>> looks suspiciously
>> like the "hugetable size" custom property I set on the VM.
>>
>> This VM was migrated to another host at one point as well, and now that
>> host is also
>> generating the same error as well.
>>
>> When I try to move these hosts to maintenance mode, they get stuck in
>> "Preparing for
>> Maintenance" while it tries to migrate/deal with the VM that's not there
>> any more.
>>
>> Forcibly rebooting the hosts does not change anything.  The VM state/host
>> seems to be
>> captured somewhere persistent in this case.
>>
>> The VM in question is not running, and I can start it up on another host
>> successfully,
>> but ovirt still thinks it exists on the other 2 hosts no matter what I do.
>>
>> Is there perhaps some way to delete it from the engine database directly
>> to straighten
>> things out?
>>
>> Here's a dump of the vdsm log on one of the hosts.  I haven't been able
>> to pinpoint what
>> the exact issue is or how to fix it, but hopefully someone here will have
>> seen this before?
>>
>> 2021-04-03 04:40:35,515+ INFO  (jsonrpc/1) [api.virt] START
>> destroy(gracefulAttempts=1) from=:::10.100.0.210,58150,
>> vmId=58abf0cf-d7b9-4067-a86a-e619928368e7 (api:48)
>> 2021-04-03 04:40:35,516+ INFO  (jsonrpc/1) [virt.vm]
>> (vmId='58abf0cf-d7b9-4067-a86a-e619928368e7') Release VM resources (vm:5186)
>> 2021-04-03 04:40:35,516+ WARN  (jsonrpc/1) [virt.vm]
>> (vmId='58abf0cf-d7b9-4067-a86a-e619928368e7') trying to set state to
>> Powering down when already Down (vm:626)
>> 2021-04-03 04:40:35,516+ INFO  (jsonrpc/1) [virt.vm]
>> (vmId='58abf0cf-d7b9-4067-a86a-e619928368e7') Stopping connection
>> (guestagent:455)
>> 2021-04-03 04:40:35,517+ INFO  (jsonrpc/1) [vdsm.api] START
>> teardownImage(sdUUID='a08af6be-3802-4bb1-9fa5-4b6a10227290',
>> spUUID='78dc095a-5238-11e8-b8bf-00163e6a7af9',
>> imgUUID='9c896907-59b0-4983-9478-b36b2c2eb01e', volUUID=None)
>> from=:::10.100.0.210,58150, task_id=fc946d20-126a-4fd0-9078-91
>> 4b4a64b1d9 (api:48)
>> 2021-04-03 04:40:35,518+ INFO  (jsonrpc/1) [storage.StorageDomain]
>> Removing image rundir link
>> u'/var/run/vdsm/storage/a08af6be-3802-4bb1-9fa5-4b6a10227290/9c896907-59b0-4983-9478-b36b2c2eb01e'
>> (fileSD:592)
>> 2021-04-03 04:40:35,518+ INFO  (jsonrpc/1) [vdsm.api] FINISH
>> teardownImage return=None from=:::10.100.0.210,58150,
>> task_id=fc946d20-126a-4fd0-9078-914b4a64b1d9 (api:54)
>> 2021-04-03 04:40:35,519+ INFO  (jsonrpc/1) [vdsm.api] START
>> teardownImage(sdUUID='b891448d-dd92-4a7b-a51a-22abc3d7da67',
>> spUUID='78dc095a-5238-11e8-b8bf-00163e6a7af9',
>> 

[ovirt-users] Re: Q: Sparsify/fstrim don't reduce actual disk image size

[Andrei Verovski]

Hi,

Many thanks, its worked ! Actual size shrunk from 584 to 9 GB, now I have space 
to backup.

Is there any guidelines how to format QCOW2 images (for Linux) so they can be 
shrunk in an efficient way?
With this NextCloud/Collabora LVM I did in the following order:
swap
ext2 boot
ext4 root
ext4 var (large, for data, all cloud data stored here)

Ext4 partitions on LVM.

Or this is not predictable how data will span QCOW2 space?


> On 7 Apr 2021, at 18:43, Nir Soffer  wrote:
> 
> On Wed, Apr 7, 2021 at 5:36 PM Andrei Verovski  wrote:
>> 
>> Hi !
>> 
>> I have VM (under oVirt) with single disk thin provision (~600 GB)
> 
> I guess you are using block storage?
> 
>> running NextCloud on Debian 9.
>> Right now VM HD is almost empty. Unfortunately, it occupies 584 GB (virtual 
>> size = 600 GB)
>> All partition (except swap and boot) are EXT4 with discard option.
> 
> You don't need to use discard mount option. fstrim works without it.
> 
>> in oVirt “enable discard = on”.
>> 
>> # fstrim -av runs successfully:
>> /var: 477.6 GiB (512851144704 bytes) trimmed on 
>> /dev/mapper/vg--system-lv4--data
>> /boot: 853.8 MiB (895229952 bytes) trimmed on 
>> /dev/mapper/vg--system-lv2--boot
>> /: 88.4 GiB (94888611840 bytes) trimmed on /dev/mapper/vg--system-lv3—sys
>> 
>> When fstrim runs again, it trims zero. I even run “Sparsify” in oVirt. 
>> Unfortunately, actual size is still 584 GB.
>> 
>> Here is /etc/fstab
>> /dev/mapper/vg--system-lv3--sys /   ext4
>> discard,noatime,nodiratime,errors=remount-ro 0   1
>> /dev/mapper/vg--system-lv2--boot /boot   ext2defaults0   
>> 2
>> /dev/mapper/vg--system-lv4--data /varext4
>> discard,noatime,nodiratime 0   2
>> /dev/mapper/vg--system-lv1--swap noneswapsw  0   
>> 0
>> 
>> When disk was partitioned/formatted, swap and boot were created first and 
>> positioned at the beginning.
>> 
>> What is wrong here? Is it possible to fix all this ?
> 
> Discarding data mark the areas in the qcow2 image as zero, but it does not 
> move
> actual data around (which is very slow). So if the clusters were at
> the end of the
> image they remain there, and the actual file size is the same.
> 
> The only way to reclaim the space is:
> 1. sparsify disk - must be done *before* copying the disk.
> 2. move this to another storage domain
> 3. move disk back to the original storage domain
> 
> We may have an easier and more efficient way in the future that
> works with single storage domain, but it will have to copy the
> entire disk. If the disk is really mostly empty it should be fast.
> 
> Nir
> 
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/Z4DWCAZLITWXZFUCLLWTSIFIFUUBDPJ7/

[ovirt-users] Re: oVirt longevity after CentOS 8, RHV changes

[Sandro Bonazzola]

Il giorno mar 6 apr 2021 alle ore 18:45 Sandro Bonazzola <
sbona...@redhat.com> ha scritto:

>
>
> Il giorno ven 2 apr 2021 alle ore 17:12 David White via Users <
> users@ovirt.org> ha scritto:
>
>> I'm replying to Thomas's thread below, but am creating a new subject so
>> as not to hijack the original thread.
>>
>> I'm sure that this topic has come up before.
>
>
> It has been raised in different places multiple times, just mentioning a
> few:
>
> -
> https://www.reddit.com/r/ovirt/comments/lrpl4h/rhv_moving_to_openshift_virtualization_what/
> -
> https://lists.ovirt.org/archives/list/users@ovirt.org/thread/DE3S4POHD37CSGWCGMNTBTCHQERWD7E3/#VIYHOW3WDR6N4APWIXQQONVHNXT3LK5L
> -
> https://lists.ovirt.org/archives/list/users@ovirt.org/thread/A3Z7SWWOTGASTLZKPRNPFGZES5FHIJ7L/#OGMDBFAQD5VDTXJPFTCC2BAPPZ2IDMFK
>
> but don't worry, this one won't be the last :-)
>
>
>
>> I first joined this list last fall, when I began planning and testing
>> with oVirt, but as of the past few weeks, I'm paying closer attention to
>> the mailing list now that I'm actually using oVirt and am getting ready to
>> deploy to a production environment.
>>
>> I'll also try to jump in and help other people as time permits and as my
>> experience grow.
>>
>
> On behalf of the other users, thanks for doing it!
>
>
>>
>> I echo Thomas's concerns here. While I'm thankful for Red Hat's gesture
>> to allow people to use up to 16 Red Hat installs at no charge, I'm
>> concerned about the longevity of oVirt, now that Red Hat is no longer going
>> to support RHV going forward.
>>
>> What is the benefit to Red Hat / IBM of supporting this platform now that
>> it is no longer being commercialized as a Red Hat product? What is to
>> prevent Red Hat from pulling the plug on this project, similar to what
>> happened to CentOS 8?
>>
>
> CentOS Linux is a downstream project with a trademark owned by Red Hat
> that delivered rebuilds of a Red Hat product.
> oVirt is an upstream open source project that is consumed by Red Hat,
> Oracle, OpenEuler, KylinOS (and I don't know how many others) for their
> downstream products.
> Despite Red Hat published a life cycle page for Red Hat Virtualization 4.4
> will reach end of life in 2026 that has nothing to do with the life of the
> oVirt project which depends only on how long the community will keep
> investing in it.
>
> > As a user of oVirt (4.5, installed on Red Hat 8.3), how can I and others
> help to contribute to the project to ensure its longevity?
>
> Thanks for asking! A few way community can help keep oVirt project healthy:
> - Helping new users as you are doing
> - Submitting patches (kudos to community user Jean-Louis Dupond who
> recently pushed patches fixing the issues he found while using oVirt)
> - Testing release candidates and reporting issues
> - Contributing to oVirt documentation
> - Donating hardware / virtual machines (yes: time, good will and code are
> not enough to keep a project healthy)
> - Getting other distributions engaged with oVirt (like AlmaLinux,
> RockyLinux, Fedora, OpenSUSE, Gentoo, Debian, ...) so they can package
> oVirt and ship it in their repositories
>

Forgot to mention helping with translations!




>
> The more people are going to contribute to the project the longer the
> community will live, as for any other open source project.
>
> Also a note for any company / community out there willing to put 10 or
> more developers working on the oVirt project: as strategic contributor you
> can ask to join the oVirt Board:
> https://www.ovirt.org/community/about/board.html and help defining the
> oVirt project future.
>
>
>
>>
>> Or should I really just go find an alternative in the future? (I had been
>> planning to use oVirt for a while, and did some testing last fall, so the
>> announcement of RHV's (commercial) demise was poor timing for me, because I
>> don't have time to switch gears and change my plans to use something else,
>> like Proxmox or something.
>>
>> From what I've seen, this is a great product, and I guess I can
>> understand Red Hat's decision to pull the plug on the commercial project,
>> now that OpenShift supports full VMs. But my understanding is that
>> OpenShift is a lot more complicated and requires more resources. I really
>> don't need a full kubernetes environment. I just need a stable
>> virtualization platform.
>>
>
> I'm happy to read positive feedback on oVirt :-)
>
> --
>
> Sandro Bonazzola
>
> MANAGER, SOFTWARE ENGINEERING, EMEA R RHV
>
> Red Hat EMEA 
>
> sbona...@redhat.com
> 
>
> *Red Hat respects your work life balance. Therefore there is no need to
> answer this email out of your office hours.*
>
>
>

-- 

Sandro Bonazzola

MANAGER, SOFTWARE ENGINEERING, EMEA R RHV

Red Hat EMEA 

sbona...@redhat.com


*Red Hat respects your work life balance. Therefore there is no need to
answer this email out of your office hours.