6:19 a.m.
As expected... this is a learning curve. My three node cluster.. in an
attempt to learn how to do admin work on it, debug it... I have now
redeployed the engine and even added second one on a node in cluster.
But.....
I now realize that my "production vms" are gone.
In the past, on a manual build with KVM + Gluster .. when I repaired a
damaged cluster I would just then browse to the xml file and import.
I think with oVirt, those days are gone. As the PostGres engine knows the
links to the disk / thin provision volumes / network / VM definition files.
######
Question:
1) Can someone point me to the manual on how to re-constitute a VM and
bring it back into oVirt where all "oVirt-engines" were redeployed. It is
only three or four VMs I typically care about (HA cluster and OCP ignition/
Ansible tower VM).
2) How do I make sure these core VMs are able to be reconstituted. Can I
create a dedicated volume where the VMs are full provisioned, and the path
structure is "human understandable".
3) I know that you can backup the engine. If I had been a smart person,
how does one backup and recover from this kind of situation. Does anyone
have any guides or good articles on this?
Thanks,
--
p <jeremey.wise(a)gmail.com>enguinpages
12:16 p.m.
Question:
1) Can someone point me to the manual on how to re-constitute a VM and >bring it back
into oVirt where all "oVirt-engines" were redeployed. It is >only three or
four VMs I typically care about (HA cluster and OCP >ignition/ Ansible tower VM).
Ensure that the old Engine is powered off. Next, add the storage domains in the new
HostedEngine and inside the storage engine , there is a "Import VM" tab which
will allow you to import your VMs.
2) How do I make sure these core VMs are able to be reconstituted.
Can I >create a dedicated volume where the VMs are full provisioned, and the path
>structure is "human understandable".
Usually when you power up a VM , the VM's xml is logged in the vdsm log.
Also , while the VM is running , you can find the xml of the VM in the /var/run/libvirt
(or whatever libvirt puts it).
3) I know that you can backup the engine. If I had been a smart
person, >how does one backup and recover from this kind of situation. Does
>anyone have any guides or good articles on this?
https://www.ovirt.org/images/Hosted-Engine-4.3-deep-dive.pdf -> page 52
Best Regards,
Strahil Nikolov
1:38 p.m.
Thanks for reply.. It really is appreciated.
1) Note about VM import
-> Can you provide details / Example. For me I click on
oVirt-> Compute -> Virtual Machines -> Import
-> Source Option (only ones making any sense would be "Export Domain"
rest are unrelated and KVM one would need xml.. which is I think gone now) So.. if I
choose "Export Domain" the "path" is to what file to import VM?
2) note about import from live VM in .. When engine is gone.. this would be intersting to
try.. but as I reboot.. and re-installed engine.. I think this cleared any hope of getting
the libvirt xml files out
[root@medusa libvirt]# tree /var/run/libvirt/
.
├── hostdevmgr
├── interface
│ └── driver.pid
├── libvirt-admin-sock
├── libvirt-sock
├── libvirt-sock-ro
├── network
│ ├── autostarted
│ ├── driver.pid
│ ├── nwfilter.leases
│ ├── ;vdsmdummy;.xml
│ └── vdsm-ovirtmgmt.xml
├── nodedev
│ └── driver.pid
├── nwfilter
│ └── driver.pid
├── nwfilter-binding
│ └── vnet0.xml
├── qemu
│ ├── autostarted
│ ├── driver.pid
│ ├── HostedEngine.pid
│ ├── HostedEngine.xml
│ └── slirp
├── secrets
│ └── driver.pid
├── storage
│ ├── autostarted
│ └── driver.pid
├── virtlockd-sock
├── virtlogd-admin-sock
└── virtlogd-sock
10 directories, 22 files
[root@medusa libvirt]#
8:24 a.m.
Importing is done from UI (Admin portal) -> Storage -> Domains -> Newly Added
domain -> "Import VM" -> select Vm and you can import.
Keep in mind that it is easier to import if all VM disks are on the same storage domain
(I've opened a RFE for multi-domain import).
Best Regards,
Strahil Nikolov
В петък, 25 септември 2020 г., 21:41:45 Гринуич+3, penguin pages
<jeremey.wise(a)gmail.com> написа:
Thanks for reply.. It really is appreciated.
1) Note about VM import
-> Can you provide details / Example. For me I click on
oVirt-> Compute -> Virtual Machines -> Import
-> Source Option (only ones making any sense would be "Export Domain"
rest are unrelated and KVM one would need xml.. which is I think gone now) So.. if I
choose "Export Domain" the "path" is to what file to import VM?
2) note about import from live VM in .. When engine is gone.. this would be intersting to
try.. but as I reboot.. and re-installed engine.. I think this cleared any hope of getting
the libvirt xml files out
[root@medusa libvirt]# tree /var/run/libvirt/
.
├── hostdevmgr
├── interface
│ └── driver.pid
├── libvirt-admin-sock
├── libvirt-sock
├── libvirt-sock-ro
├── network
│ ├── autostarted
│ ├── driver.pid
│ ├── nwfilter.leases
│ ├── ;vdsmdummy;.xml
│ └── vdsm-ovirtmgmt.xml
├── nodedev
│ └── driver.pid
├── nwfilter
│ └── driver.pid
├── nwfilter-binding
│ └── vnet0.xml
├── qemu
│ ├── autostarted
│ ├── driver.pid
│ ├── HostedEngine.pid
│ ├── HostedEngine.xml
│ └── slirp
├── secrets
│ └── driver.pid
├── storage
│ ├── autostarted
│ └── driver.pid
├── virtlockd-sock
├── virtlogd-admin-sock
└── virtlogd-sock
10 directories, 22 files
[root@medusa libvirt]#
_______________________________________________
Users mailing list -- users(a)ovirt.org
To unsubscribe send an email to users-leave(a)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/VUXIOEH2V4S...
9:47 p.m.
there is a "Import VM" tab which
will allow you to import your VMs.
Anyone have idea on how this is done?
I can see .meta and .lease files but not sure how this would be used to import VMs.
It would be nice to tell it to review current "disk / images" and compare to
what is in library ... because I think those VMs orphaned and the ones I imported...
reflect dead / garbage now on the volumes. And I see no easy way to clean up.
12:49 p.m.
Ok.. digging around a bit.
##############################
[root@medusa vmstore]# tree -h /media/data/
/media/data/
├── [ 48] 7801d608-0416-4e5e-a469-2fefa2398d06
│ ├── [ 89] dom_md
│ │ ├── [ 1.0M] ids
│ │ ├── [ 16M] inbox
│ │ ├── [ 2.0M] leases
│ │ ├── [ 549] metadata
│ │ ├── [ 16M] outbox
│ │ └── [ 1.2M] xleases
│ ├── [ 8.0K] images
│ │ ├── [ 8.0K] 060cb15c-efb4-45fd-82e3-9001312cffdf
│ │ │ ├── [ 160K] d3f7ab6e-d371-4748-bc6d-26557ce9812a
│ │ │ ├── [ 1.0M] d3f7ab6e-d371-4748-bc6d-26557ce9812a.lease
│ │ │ └── [ 430] d3f7ab6e-d371-4748-bc6d-26557ce9812a.meta
│ │ ├── [ 149] 138a359c-13e6-4448-b543-533894e41fca
│ │ │ ├── [ 1.7G] ece912a4-6756-4944-803c-c7ac58713ef4
│ │ │ ├── [ 1.0M] ece912a4-6756-4944-803c-c7ac58713ef4.lease
│ │ │ └── [ 304] ece912a4-6756-4944-803c-c7ac58713ef4.meta
│ │ ├── [ 149] 26def4e7-1153-417c-88c1-fd3dfe2b0fb9
│ │ │ ├── [ 100G] 0136657f-1f6f-4140-8c7b-f765316d4e3a
│ │ │ ├── [ 1.0M] 0136657f-1f6f-4140-8c7b-f765316d4e3a.lease
│ │ │ └── [ 316] 0136657f-1f6f-4140-8c7b-f765316d4e3a.meta
│ │ ├── [ 149] 2d684975-06e1-442e-a785-1cfcc70a9490
│ │ │ ├── [ 4.3G] 688ce708-5be2-4082-9337-7209081082bf
│ │ │ ├── [ 1.0M] 688ce708-5be2-4082-9337-7209081082bf.lease
│ │ │ └── [ 343] 688ce708-5be2-4082-9337-7209081082bf.meta
│ │ ├── [ 8.0K] 444ee51d-da70-419e-8d8e-a94aed28d0fa
│ │ │ ├── [ 112M] 23608ebc-f8a4-4482-875c-e12eaa69c8eb
│ │ │ ├── [ 1.0M] 23608ebc-f8a4-4482-875c-e12eaa69c8eb.lease
│ │ │ ├── [ 377] 23608ebc-f8a4-4482-875c-e12eaa69c8eb.meta
│ │ │ ├── [ 683M] 3f2f0fc7-cb3c-4bbc-9f7b-4f196588c78c
│ │ │ ├── [ 1.0M] 3f2f0fc7-cb3c-4bbc-9f7b-4f196588c78c.lease
│ │ │ └── [ 369] 3f2f0fc7-cb3c-4bbc-9f7b-4f196588c78c.meta
│ │ ├── [ 149] 54cfa3af-9045-4e9b-ba8d-4ac7181490da
│ │ │ ├── [ 113M] a1807521-7009-4896-9325-6a2a7c0e29ef
│ │ │ ├── [ 1.0M] a1807521-7009-4896-9325-6a2a7c0e29ef.lease
│ │ │ └── [ 288] a1807521-7009-4896-9325-6a2a7c0e29ef.meta
│ │ ├── [ 149] 5917ba35-689c-409b-a89c-37bd08f06e76
│ │ │ ├── [ 7.7G] ea6610cd-c0b9-457f-aaf5-d199a3bd1a83
│ │ │ ├── [ 1.0M] ea6610cd-c0b9-457f-aaf5-d199a3bd1a83.lease
│ │ │ └── [ 351] ea6610cd-c0b9-457f-aaf5-d199a3bd1a83.meta
│ │ ├── [ 8.0K] 6914d63d-e57f-4e9f-9ca2-a378ad2f0a4f
│ │ │ ├── [ 683M] 3f2f0fc7-cb3c-4bbc-9f7b-4f196588c78c
│ │ │ ├── [ 1.0M] 3f2f0fc7-cb3c-4bbc-9f7b-4f196588c78c.lease
│ │ │ ├── [ 369] 3f2f0fc7-cb3c-4bbc-9f7b-4f196588c78c.meta
│ │ │ ├── [ 100M] b0deed57-f5fe-4e44-8d0a-105029bdeae5
│ │ │ ├── [ 1.0M] b0deed57-f5fe-4e44-8d0a-105029bdeae5.lease
│ │ │ └── [ 377] b0deed57-f5fe-4e44-8d0a-105029bdeae5.meta
│ │ ├── [ 149] 7daa2083-29d8-4b64-a50a-d09ab1428513
│ │ │ ├── [ 100G] d96bf89f-351a-4c86-9865-9531d8f7a97b
│ │ │ ├── [ 1.0M] d96bf89f-351a-4c86-9865-9531d8f7a97b.lease
│ │ │ └── [ 316] d96bf89f-351a-4c86-9865-9531d8f7a97b.meta
│ │ ├── [ 8.0K] 7e523f3d-311a-4caf-ae34-6cd455274d5f
│ │ │ ├── [ 683M] 3f2f0fc7-cb3c-4bbc-9f7b-4f196588c78c
│ │ │ ├── [ 1.0M] 3f2f0fc7-cb3c-4bbc-9f7b-4f196588c78c.lease
│ │ │ ├── [ 369] 3f2f0fc7-cb3c-4bbc-9f7b-4f196588c78c.meta
│ │ │ ├── [ 4.6G] 55ebf216-b404-4c09-8cbc-91882f42cb94
│ │ │ ├── [ 1.0M] 55ebf216-b404-4c09-8cbc-91882f42cb94.lease
│ │ │ └── [ 316] 55ebf216-b404-4c09-8cbc-91882f42cb94.meta
│ │ ├── [ 149] 9ccb26cf-dd4a-4c9a-830c-ee084074d7a1
│ │ │ ├── [ 11G] a704ef38-6883-4857-b2fa-423033058927
│ │ │ ├── [ 1.0M] a704ef38-6883-4857-b2fa-423033058927.lease
│ │ │ └── [ 311] a704ef38-6883-4857-b2fa-423033058927.meta
│ │ ├── [ 149] a2bbc814-015a-4a37-8f58-68aa6ef73f8e
│ │ │ ├── [ 19G] a5cb25e3-28a0-4d88-b2ca-d3732765b5fb
│ │ │ ├── [ 1.0M] a5cb25e3-28a0-4d88-b2ca-d3732765b5fb.lease
│ │ │ └── [ 311] a5cb25e3-28a0-4d88-b2ca-d3732765b5fb.meta
│ │ ├── [ 149] adecc80f-8ce0-4ce0-9d73-d5de8f4a72e1
│ │ │ ├── [ 10G] cc010af4-ce51-4917-9f2c-db0ec9353103
│ │ │ ├── [ 1.0M] cc010af4-ce51-4917-9f2c-db0ec9353103.lease
│ │ │ └── [ 326] cc010af4-ce51-4917-9f2c-db0ec9353103.meta
│ │ ├── [ 149] b8bd6924-fcd3-4479-a7da-6b255431a308
│ │ │ ├── [ 20G] f5a891db-4492-49e4-bf6a-72182ba4bf15
│ │ │ ├── [ 1.0M] f5a891db-4492-49e4-bf6a-72182ba4bf15.lease
│ │ │ └── [ 314] f5a891db-4492-49e4-bf6a-72182ba4bf15.meta
│ │ ├── [ 149] ce4133ad-562f-4f23-add6-cd168a906267
│ │ │ ├── [ 118M] a09c8a84-1904-4632-892e-beb55abc873a
│ │ │ ├── [ 1.0M] a09c8a84-1904-4632-892e-beb55abc873a.lease
│ │ │ └── [ 313] a09c8a84-1904-4632-892e-beb55abc873a.meta
│ │ ├── [ 149] d0038fa8-eee1-4548-82b9-b7f79adb182c
│ │ │ ├── [ 7.7G] 7568e474-8ab5-4953-8cd3-a9c9b8df3595
│ │ │ ├── [ 1.0M] 7568e474-8ab5-4953-8cd3-a9c9b8df3595.lease
│ │ │ └── [ 349] 7568e474-8ab5-4953-8cd3-a9c9b8df3595.meta
│ │ ├── [ 149] f6679e35-fa56-4ed8-aa47-18492e00fd01
│ │ │ ├── [ 683M] 3f2f0fc7-cb3c-4bbc-9f7b-4f196588c78c
│ │ │ ├── [ 1.0M] 3f2f0fc7-cb3c-4bbc-9f7b-4f196588c78c.lease
│ │ │ └── [ 369] 3f2f0fc7-cb3c-4bbc-9f7b-4f196588c78c.meta
│ │ └── [ 8.0K] fff3c1de-e21e-4f03-8905-d587448f6543
│ │ ├── [ 160K] 6f4343b6-dc3d-40e3-b872-6a954b8d1a7b
│ │ ├── [ 1.0M] 6f4343b6-dc3d-40e3-b872-6a954b8d1a7b.lease
│ │ └── [ 430] 6f4343b6-dc3d-40e3-b872-6a954b8d1a7b.meta
│ └── [ 30] master
│ ├── [ 6] tasks
│ └── [ 6] vms
#########################
This kind of represents where my "production VMs" live
I assume... that their is no means to map host to those files.. but based on size i kind
of know which are which.
Ex: Three VMs I want back: ns01, ns02, ansible00
1) parse all the .meta files to get mapping structure Ex: from mount of gluster
/media/data/7801d608-0416-4e5e-a469-2fefa2398d06/find . |grep .meta | xargs cat | grep -A
5 ansible00
Ex: [root@medusa vmstore]# cat
/media/data/7801d608-0416-4e5e-a469-2fefa2398d06/images/b8bd6924-fcd3-4479-a7da-6b255431a308/f5a891db-
DESCRIPTION={"DiskAlias":"ansible00_boot","DiskDescription":"ansible00_boot"}
DISKTYPE=DATA
DOMAIN=7801d608-0416-4e5e-a469-2fefa2398d06
FORMAT=COW
GEN=0
IMAGE=7e523f3d-311a-4caf-ae34-6cd455274d5f
--
DESCRIPTION={"DiskAlias":"ansible00_var","DiskDescription":"ansible00_var"}
DISKTYPE=DATA
DOMAIN=7801d608-0416-4e5e-a469-2fefa2398d06
FORMAT=RAW
GEN=0
IMAGE=b8bd6924-fcd3-4479-a7da-6b255431a308
############
ansible00 7801d608-0416-4e5e-a469-2fefa2398d06
- Boot 7e523f3d-311a-4caf-ae34-6cd455274d5f (folder for image)
- VAR b8bd6924-fcd3-4479-a7da-6b255431a308 (folder for image)
# Now attempt import
[root@medusa b8bd6924-fcd3-4479-a7da-6b255431a308]# python3
/usr/share/doc/python3-ovirt-engine-sdk4/examples/upload_disk.py --engine-url
https://ovirte01.penguinpages.local/ --username admin@internal --password-file
/media/vmstore/.ovirt.password --cafile /media/vmstore/.ovirte01_pki-resource.cer
--sd-name data --disk-sparse
/media/data/7801d608-0416-4e5e-a469-2fefa2398d06/images/b8bd6924-fcd3-4479-a7da-6b255431a308/f5a891db-4492-49e4-bf6a-72182ba4bf15
Checking image...
Image format: raw
Disk format: raw
Disk content type: data
Disk provisioned size: 21474836480
Disk initial size: 21474836480
Disk name: f5a891db-4492-49e4-bf6a-72182ba4bf15.raw
Disk backup: False
Connecting...
Creating disk...
Disk ID: 77f1af5a-0912-484f-a2d3-d9564641e031
Creating image transfer...
Transfer ID: 7911904b-2573-4b57-b398-76de8f79670d
Transfer host name: medusa
Uploading image...
[ ------- ] 0 bytes, 0.00 seconds, 0 bytes/s
[root@medusa 7e523f3d-311a-4caf-ae34-6cd455274d5f]# python3
/usr/share/doc/python3-ovirt-engine-sdk4/examples/upload_disk.py --engine-url
https://ovirte01.penguinpages.local/ --username admin@internal --password-file
/media/vmstore/.ovirt.password --cafile /media/vmstore/.ovirte01_pki-resource.cer
--sd-name data --disk-sparse
/media/data/7801d608-0416-4e5e-a469-2fefa2398d06/images/7e523f3d-311a-4caf-ae34-6cd455274d5f/55ebf216-b404-4c09-8cbc-91882f42cb94
Checking image...
Image format: qcow2
Disk format: cow
Disk content type: data
Disk provisioned size: 10737418240
Disk initial size: 6278938624
Disk name: 55ebf216-b404-4c09-8cbc-91882f42cb94.qcow2
Disk backup: False
Connecting...
Creating disk...
Disk ID: bcf3d639-7b01-4c22-ac50-d20d7fd9ab29
Creating image transfer...
Transfer ID: e6cb5763-987b-453e-8a5b-34f7671c476a
Transfer host name: medusa
Uploading image...
[ ------- ] 0 bytes, 0.00 seconds, 0 bytes/s
# now in oVirt engine rename volumes and create new VM with definitions
77f1af5a-0912-484f-a2d3-d9564641e031 ansible00_var
bcf3d639-7b01-4c22-ac50-d20d7fd9ab29 ansible00_boot
oVirt Engine -> Storage -> disk -> select volume -> edit - change aliase to be
human name
# Attach to VM as disk .. and set "boot" disk and then power on.
One down.. two to go.
PS: And now dig into how to make an oVirt-Engine backup... and... restore it..
# Optional: Backup / Restore Process for Engine Ex: Make a replica saved on NAS
systemctl stop ovirt-engine
time engine-backup --scope=all --mode-backup
--file=/media/sw2_usb_A2/penguinpages_local_cluster/ovirte01_`date +%y%m%d%H%M%S`.bck
--log=/media/sw2_usb_A2/penguinpages_local_cluster/ovirte01_log_`date +%y%m%d%H%M%S`.log
# Restore would be.. ######### Needs testing!!!!
engine-backup --mode=restore
--file=/media/sw2_usb_A2/penguinpages_local_cluster/ovirte01_`date +%y%m%d%H%M%S`.bck
--log=/media/sw2_usb_A2/penguinpages_local_cluster/ovirte01_restore_log_`date
+%y%m%d%H%M%S`.log --provision-db --provision-dwh-db --restore-permissions
1520
days inactive
1521
days old
5 comments
3 participants
participants (3)
-
Jeremey Wise -
penguin pages
-
Strahil Nikolov