4:35 a.m.
Does this work with volume groups? I have several virtual disks
presented to the VM which are part of a volume group.
[root@voyager media]# fsarchiver probe
[======DISK======] [=============NAME==============] [====SIZE====] [MAJ] [MIN]
[vda ] [ ] [ 40.00 GB] [252] [ 0]
[vdb ] [ ] [ 100.00 GB] [252] [ 16]
[vdc ] [ ] [ 20.00 GB] [252] [ 32]
[vdd ] [ ] [ 40.00 GB] [252] [ 48]
[=====DEVICE=====] [==FILESYS==] [======LABEL======] [====SIZE====] [MAJ] [MIN]
[vda1 ] [ext4 ] [<unknown> ] [ 500.00 MB] [252] [ 1]
[vda2 ] [LVM2_member] [<unknown> ] [ 39.51 GB] [252] [ 2]
[vdb1 ] [LVM2_member] [<unknown> ] [ 100.00 GB] [252] [ 17]
[vdc1 ] [LVM2_member] [<unknown> ] [ 20.00 GB] [252] [ 33]
[dm-0 ] [ext4 ] [<unknown> ] [ 4.00 GB] [253] [ 0]
[dm-1 ] [swap ] [<unknown> ] [ 3.94 GB] [253] [ 1]
[dm-2 ] [ext4 ] [<unknown> ] [ 119.99 GB] [253] [ 2]
[dm-3 ] [ext4 ] [<unknown> ] [ 15.00 GB] [253] [ 3]
[dm-4 ] [ext4 ] [<unknown> ] [ 8.00 GB] [253] [ 4]
[dm-5 ] [ext4 ] [<unknown> ] [ 8.00 GB] [253] [ 5]
I'm thinking that during restore, I can just re-create the volume
groups and logical volumes and then restore each file system backup to
that logical volume. Or better yet, since I know how much space I'm
actually using, just create one logical volume of the right size. I
kept adding virtual disks as needed to store repos in /var/satellite
I also want to verify the syntax I'm using:
fsarchiver savefs -Aa -e "/mnt/media/*" -j 2
/mnt/media/voyager/boot.fsa /dev/vda1
Seemed to work fine for backing up /boot
Are there any other recommended options I should be using for backing
up live file systems mounted read / write?
I've also stopped all of the spacewalk services and other services on
the VM in order to minimize open files being skipped, etc.
Volume group structure.
[root@voyager media]# pvdisplay
--- Physical volume ---
PV Name /dev/vdb1
VG Name satellite
PV Size 100.00 GiB / not usable 3.00 MiB
Allocatable yes (but full)
PE Size 4.00 MiB
Total PE 25599
Free PE 0
Allocated PE 25599
PV UUID g3uGGu-p0b3-eSIJ-Bwy7-YOTD-GKnd-prWP7a
--- Physical volume ---
PV Name /dev/vdc1
VG Name satellite
PV Size 20.00 GiB / not usable 3.89 MiB
Allocatable yes (but full)
PE Size 4.00 MiB
Total PE 5119
Free PE 0
Allocated PE 5119
PV UUID W35GYr-T6pg-3e0o-s8I7-aqtc-fxcD-Emh62K
--- Physical volume ---
PV Name /dev/vda2
VG Name vg_voyager
PV Size 39.51 GiB / not usable 3.00 MiB
Allocatable yes
PE Size 4.00 MiB
Total PE 10114
Free PE 146
Allocated PE 9968
PV UUID hJCdct-iR6Q-NPYi-eBZN-dZdP-x4YP-U1zyvE
[root@voyager media]# vgdisplay
--- Volume group ---
VG Name satellite
System ID
Format lvm2
Metadata Areas 2
Metadata Sequence No 4
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 1
Open LV 1
Max PV 0
Cur PV 2
Act PV 2
VG Size 119.99 GiB
PE Size 4.00 MiB
Total PE 30718
Alloc PE / Size 30718 / 119.99 GiB
Free PE / Size 0 / 0
VG UUID fXvCp3-N0uG-rBRc-FWVJ-Kpv3-AH9L-1PnYUy
--- Volume group ---
VG Name vg_voyager
System ID
Format lvm2
Metadata Areas 1
Metadata Sequence No 9
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 5
Open LV 5
Max PV 0
Cur PV 1
Act PV 1
VG Size 39.51 GiB
PE Size 4.00 MiB
Total PE 10114
Alloc PE / Size 9968 / 38.94 GiB
Free PE / Size 146 / 584.00 MiB
VG UUID 3txqia-eDtn-j5wn-iixS-gfpv-90b9-ButDqh
[root@voyager media]# lvdisplay
--- Logical volume ---
LV Path /dev/satellite/lv_packages
LV Name lv_packages
VG Name satellite
LV UUID 03VUWu-bxGf-hG2b-c3cx-m3lu-7Dlp-iaiWzu
LV Write Access read/write
LV Creation host, time voyager, 2012-11-11 12:53:54 -0500
LV Status available
# open 1
LV Size 119.99 GiB
Current LE 30718
Segments 2
Allocation inherit
Read ahead sectors auto
- currently set to 256
Block device 253:2
--- Logical volume ---
LV Path /dev/vg_voyager/lv_var
LV Name lv_var
VG Name vg_voyager
LV UUID serQHO-uSog-ci5m-Xx7B-AElf-GTqi-HYCRY6
LV Write Access read/write
LV Creation host, time voyager, 2012-11-11 01:55:01 -0500
LV Status available
# open 1
LV Size 15.00 GiB
Current LE 3840
Segments 2
Allocation inherit
Read ahead sectors auto
- currently set to 256
Block device 253:3
--- Logical volume ---
LV Path /dev/vg_voyager/lv_root
LV Name lv_root
VG Name vg_voyager
LV UUID Kc43IB-5EWZ-N05E-FrN5-NgcQ-kWTv-LxfSig
LV Write Access read/write
LV Creation host, time voyager, 2012-11-11 01:55:05 -0500
LV Status available
# open 1
LV Size 4.00 GiB
Current LE 1024
Segments 1
Allocation inherit
Read ahead sectors auto
- currently set to 256
Block device 253:0
--- Logical volume ---
LV Path /dev/vg_voyager/lv_home
LV Name lv_home
VG Name vg_voyager
LV UUID F7aJrw-FqwN-yML2-7bbX-kcuQ-12pX-1QG8Gp
LV Write Access read/write
LV Creation host, time voyager, 2012-11-11 01:55:09 -0500
LV Status available
# open 1
LV Size 8.00 GiB
Current LE 2048
Segments 1
Allocation inherit
Read ahead sectors auto
- currently set to 256
Block device 253:4
--- Logical volume ---
LV Path /dev/vg_voyager/lv_swap
LV Name lv_swap
VG Name vg_voyager
LV UUID S5uYT4-Q3x4-3icm-SEFW-yZVW-DhLl-vSkcLc
LV Write Access read/write
LV Creation host, time voyager, 2012-11-11 01:55:14 -0500
LV Status available
# open 1
LV Size 3.94 GiB
Current LE 1008
Segments 1
Allocation inherit
Read ahead sectors auto
- currently set to 256
Block device 253:1
--- Logical volume ---
LV Path /dev/vg_voyager/lv_tmp
LV Name lv_tmp
VG Name vg_voyager
LV UUID 2QeEXe-7zpq-0yLV-NT0u-9ZgY-mk8w-30n2Nz
LV Write Access read/write
LV Creation host, time voyager, 2012-11-11 01:55:14 -0500
LV Status available
# open 1
LV Size 8.00 GiB
Current LE 2048
Segments 1
Allocation inherit
Read ahead sectors auto
- currently set to 256
Block device 253:5
On Mon, Apr 22, 2013 at 3:53 PM, Joop <jvdwege(a)xs4all.nl> wrote:
Chris Smith wrote:
>
> List,
>
> I have lost the ability to manage the hosts or VM's using ovirt engine
> web interface. The data center is offline, and I
> can't actually perform any operations with the hosts or VM's. I don't
> think that there
> are any actions I can perform in the web interface at all.
>
> What's odd is that I can tell the host to go into maintenance mode
> using the ovirt-engine web interface and it seems to go into
> maintenance mode. It even shows the wrench icon next to the host. I
> can also try and activate it after it susposedly goes into maintenance
> mode, and It states that the host was activated, but the host never
> actually comes up or contends for SPM status, and the data center
> never comes online.
>
> >From the logs it seems that at least PKI is broken between the engine
> and the hosts as I see numerous certificate errors on both the
> ovirt-engine and clients.
>
> vdsm.log shows:
>
> Traceback (most recent call last):
> File "/usr/lib64/python2.7/SocketServer.py", line 582, in
> process_request_thread
> self.finish_request(request, client_address)
> File "/usr/lib/python2.7/site-packages/vdsm/SecureXMLRPCServer.py",
> line 66, in finish_request
> request.do_handshake()
> File "/usr/lib64/python2.7/ssl.py", line 305, in do_handshake
> self._sslobj.do_handshake()
> SSLError: [Errno 1] _ssl.c:504: error:14094416:SSL
> routines:SSL3_READ_BYTES:sslv3 alert certificate unknown
>
> and engine.log shows:
>
> 2013-04-18 18:42:43,632 ERROR
> [org.ovirt.engine.core.
> engineencryptutils.EncryptionUtils]
> (QuartzScheduler_Worker-68) Failed to decryptData must start with zero
> 2013-04-18 18:42:43,642 ERROR
> [org.ovirt.engine.core.vdsbroker.vdsbroker.VdsBrokerCommand]
> (QuartzScheduler_Worker-68) XML RPC error in command
>
>
> Alon Bar-Lev was able to offer several good pointers in another thread
> titled "Certificates and PKI seem to be broken after yum update" and
> eventually concluded that the installation seems to be corrupted more
> than just the certificates, truststore, and keystore, and suggested
> that I start a new thread to ask about how to rescue the storage
> domain structure.
>
> The storage used for the data center is ISCSI, which is intact and
> working. In fact 2 of the VM's are still online and running on one of
> the original FC17 hosts systems.
>
> I'm not able to reinstall any of the existing hosts from the ovirt-engine
> web
> interface. I attempted to reinstall one of the hosts (not the SPM)
> which failed.
>
> I also tried to bring up a new, third host and add it to the cluster.
> I setup another Fedora 17 box up and tried to add it to the
> cluster, but it states that there are no available servers in the
> cluster to probe the new host.
>
> This is a test environment that I would like to fix, but I'm also
> willing to just run engine cleanup and start over.
>
> That said, there are 3 VM's that I would like to keep. Two are online
> and running, and I'm able to see them with virsh on that host. I was
> wondering about using virsh to backup these vm's.
>
> The third VM exists in the database, and was set to run on the host
> that I attempted to reinstall, but that VM isn't running, and when I
> use virsh on it's host, virsh can't seem to find it, when I perform
> the list commands, and I can't start it with virsh <vm-name>
>
> What is the best way to proceed? It seems like it would be easier to
> export the VM's using virsh from the host that they run on if
> possible, then update ovirt to the latest version, recreate everything
> and then import the VM's back in to the new environment.
>
> Will this work? Is there a procedure I can follow to do this?
>
> Here's some additional information about the installed ovirt packages
> on the ovirt-engine
>
> [
If you want a backup of the currently running hosts you can use fsarchiver.
There is a statically linked version consisting of one executable on the
website of fsarchiver and you can use options to overrule the fact that
you're backing up a live system.
You can't shutdown the VM's, I think, and then do an export to an export
domain since you don't have a master storage domain thats why the above
workaround with fsarchiver. You can ofcourse use you're favourite backup
programme.
Joop
--
irc: jvandewege