+7 (495) 320-70-49
- Назад
- Телефоны
- +7 (495) 320-70-49
- Заказать звонок
info@proxmox.su
Москва, Бакунинская улица, 69с1
Пн-Пт: 09-00 до 18-00
Сб-Вс: выходной

VZDUMP завис – не могу завершить задачу vzdump., Proxmox Виртуальная Среда

Alex24

Guest

21.01.2016 11:34:00

Привет! Вчера запустил бэкап. Передача завершена, но задача постоянно работает. INFO: status: 100% (88046829568/88046829568), sparse 39% (34989350912), duration 9145, 12/0 MB/s INFO: transferred 88046 MB in 9145 seconds (9 MB/s) Пытался остановить задачу через GUI. Выполнил : "ps aux | grep vzdump" и убил 2 процесса из 3, но не могу убить последний процесс -9: root@proxmox-1-3:/var/lib/vz# ps aux | grep vzdump root 360203 0.0 0.0 202840 36388 ? Ds Jan20 0:17 task UPID roxmox-1-3:00057F0B:270FDD6C:569F9539:vzdump::root@pam: Остановил VM и сделал : qm unlock VMID и снова попытался убить, но не могу отменить эту задачу бэкапа. Как убить эту задачу бэкапа без перезагрузки гипервизора, пожалуйста? Спасибо.

speedlnx Guest	#2 0 15.02.2016 20:12:00 У меня та же проблема.

robhost Guest	#3 0 03.03.2016 15:31:00 И у меня так же.

speedlnx Guest	#4 0 05.03.2016 15:35:00 Проблема была вызвана файловой системой/целью резервного копирования. Я изменил целевой сервер для резервного копирования с ftp/samba/cifs на NFS, и теперь всё работает без проблем.

robhost Guest	#5 0 05.03.2016 18:27:00 У нас была проблема с NFS, так как NFS-сервер зависал или возникали сетевые неполадки. Возможным решением будет изменение опций монтирования NFS с hard на soft, как это показано вот здесь (в файле /etc/pve/storage.cfg).

speedlnx Guest	#6 0 06.03.2016 16:59:00 Работает и у меня с опцией "hard". Может, у тебя сеть медленная? Вот мои опции для точки монтирования NFS: rw,relatime,vers=3,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=x.x.x.x,mountvers=3,mountport=37202,mountproto=udp,local_lock=none,addr=x.x.x.x

robhost Guest	#7 0 06.03.2016 18:13:00 Проблема не в скорости сети, проблема в том, что ядро ждёт бесконечно, например, если NFS-хост недоступен.

bizzarrone

Guest

29.07.2016 10:23:00

После каждого восстановления (restore) GUI всех ВМ и даже самого хоста зависает. Я пробовал на local-lvm (RAID1), на внешнем RAID5 lvm thin – всегда одно и то же.
pve-manager/4.2-2/725d76f0 (запущенный kernel: 4.4.6-1-pve)
Linux prox01 4.4.6-1-pve #1 SMP Thu Apr 21 11:25:40 CEST 2016 x86_64 GNU/Linux
prox01:~# megaclisas-status

-- Controller information --
-- ID | H/W Model | RAM | Temp | BBU | Firmware
c0 | ServeRAID M5014 SAS/SATA Controller | 256MB | N/A | Good | FW: 12.15.0-0199

-- Array information --
-- ID | Type | Size | Strpsz | Flags | DskCache | Status | OS Path | CacheCade |InProgress
c0u0 | RAID-1 | 278G | 128 KB | RA,WB | Default | Optimal | /dev/sda | None |None
c0u1 | RAID-5 | 4087G | 128 KB | RA,WB | Default | Optimal | /dev/sdb | None |None

-- Disk information --
-- ID | Type | Drive Model | Size | Status | Speed | Temp | Slot ID | LSI Device ID
c0u0p0 | HDD | IBM-ESXSST300MM0006 B56MS0K3SK0L0221B5C5 | 278.4 Gb | Online, Spun Up | 6.0Gb/s | 32C | [252:1] | 8
c0u0p1 | HDD | IBM-ESXSST300MM0006 B56MS0K3SJ4D0221B5C5 | 278.4 Gb | Online, Spun Up | 6.0Gb/s | 32C | [252:0] | 9
c0u1p0 | HDD | IBM-ESXSAL13SEB900 SB35Y4I01EH3SB35SB35SB35 | 837.2 Gb | Online, Spun Up | 6.0Gb/s | 34C | [252:4] | 10
c0u1p1 | HDD | IBM-ESXSAL13SEB900 SB35Y4I033H3SB35SB35SB35 | 837.2 Gb | Online, Spun Up | 6.0Gb/s | 35C | [252:5] | 11
c0u1p2 | HDD | IBM-ESXSAL13SEB900 SB35Y4I01XH3SB35SB35SB35 | 837.2 Gb | Online, Spun Up | 6.0Gb/s | 34C | [252:6] | 12
c0u1p3 | HDD | IBM-ESXSAL13SEB900 SB35Y4I03BH3SB35SB35SB35 | 837.2 Gb | Online, Spun Up | 6.0Gb/s | 34C | [252:7] | 13
c0u1p4 | HDD | IBM-ESXSAL13SEB900 SB35Y4I02JH3SB35SB35SB35 | 837.2 Gb | Online, Spun Up | 6.0Gb/s | 35C | [252:3] | 14
c0u1p5 | HDD | IBM-ESXSAL13SEB900 SB35Y4I02VH3SB35SB35SB35 | 837.2 Gb | Online, Spun Up | 6.0Gb/s | 34C | [252:2] | 15

pvs
PV VG Fmt Attr PSize PFree
/dev/sda3 pve lvm2 a-- 278.34g 15.81g
/dev/sdb1 pve2 lvm2 a-- 4.09t 418.39g

vgs
VG #PV #LV #SN Attr VSize VFree
pve 1 5 0 wz--n- 278.34g 15.81g
pve2 1 14 0 wz--n- 4.09t 418.39g

lvs
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert
root pve twi-aotz-- 184.84g 41.34 20.79
swap pve -wi-ao---- 69.50g
vm-107-disk-1 pve -wi-ao---- 8.00g
data pve Vwi-a-tz-- 110.00g
data2 pve Vwi-a-tz-- 30.00g
snap_vm-113-disk-1_AfterAdmin pve2 twi-aotz-- 3.68t
vm-113-disk-1 pve2 Vri---tz-k 40.00g
vm-105-disk-1 pve2 Vwi-a-tz-- 50.00g
vm-106-disk-1 pve2 Vwi-a-tz-- 80.00g
vm-106-disk-2 pve2 Vwi-a-tz-- 70.00g
vm-724-disk-1 pve2 Vwi-a-tz-- 20.00g
vm-724-disk-2 pve2 Vwi-a-tz-- 100.00g
vm-726-disk-1 pve2 Vwi-a-tz-- 40.00g
vm-990-disk-1 pve2 Vwi-a-tz-- 45.00g

bizzarrone

Guest

29.07.2016 10:27:00

Кажется, lvm thin зависал при восстановлении VD. Попробую другой тип хранилища. [..] Работает без зависаний! Оказывается, проблема действительно связана с lvm-thin и, возможно, с конкретным типом RAID. `data3` — это "директория" типа хранилища на LVM, LV не тонкий.

/dev/mapper/pve2-data3 на /mnt/data3 типа ext4 (rw,relatime,data=ordered)
sdb 8:16 0 4.1T 0 disk
└─sdb1 8:17 0 4.1T 0 part
├─pve2-data2_tmeta 251:1 0 120M 0 lvm
└─pve2-data2-tpool 251:3 0 3.7T 0 lvm
│ ├─pve2-data2 251:4 0 3.7T 0 lvm
│ ├─pve2-vm--637--disk--1 251:5 0 40G 0 lvm
│ ├─pve2-vm--113--disk--1 251:6 0 40G 0 lvm
│ ├─pve2-vm--990--disk--1 251:7 0 45G 0 lvm
│ ├─pve2-vm--105--disk--1 251:8 0 50G 0 lvm
│ ├─pve2-vm--105--disk--2 251:9 0 80G 0 lvm
│ ├─pve2-vm--106--disk--1 251:10 0 70G 0 lvm
│ ├─pve2-vm--106--disk--2 251:11 0 30G 0 lvm
│ ├─pve2-vm--625--disk--1 251:12 0 40G 0 lvm
│ ├─pve2-vm--638--disk--1 251:13 0 52G 0 lvm
│ ├─pve2-vm--726--disk--1 251:14 0 40G 0 lvm
│ ├─pve2-vm--724--disk--1 251:20 0 20G 0 lvm
│ ├─pve2-vm--724--disk--2 251:21 0 100G 0 lvm
│ ├─pve2-vm--108--disk--1 251:24 0 12G 0 lvm
│ └─pve2-vm--720--disk--1 251:26 0 46G 0 lvm
└─pve2-data3 251:25 0 83.7G 0 lvm

Туда восстановил, и там не зависло! Потом перенес диск на local-lvm или новое хранилище-lvm, и он перенесся без зависаний... Только комбинация vzdump и lvm-thin вызывает проблемы!

Proxmox Virtual Environment 4.2-2/725d76f0
Виртуальная машина 720 ('adc') на узле '-prox01'
Восстанавливает архив vma:
vma extract -v -r /var/tmp/vzdumptmp50170.fifo /mnt/netapp/dump/vzdump-qemu-107-2016_07_28-16_33_28.vma /var/tmp/vzdumptmp50170
CFG: size: 339 name: qemu-server.conf
DEV: dev_id=1 size: 118111600640 devname: drive-ide0
DEV: dev_id=2 size: 32212254720 devname: drive-virtio0
CTIME: Thu Jul 28 16:33:30 2016
Logical volume "vm-107-disk-1" создано. Новый идентификатор тома 'local-lvm:vm-107-disk-1'
отображает 'drive-ide0' на '/dev/pve/vm-107-disk-1' (запись нулей = 0)
Logical volume "vm-107-disk-2" создано. Новый идентификатор тома 'local-lvm:vm-107-disk-2'
отображает 'drive-virtio0' на '/dev/pve/vm-107-disk-2' (запись нулей = 0)
progress 1% (read 1503264768 bytes, duration 2 sec)
progress 2% (read 3006529536 bytes, duration 10 sec)
[..]
progress 100% (read 150323855360 bytes, duration 537 sec)
общее количество прочитанных байтов 150323855360, экономия места благодаря разреженным блокам 4К 0.0568%
ЗАДАЧА УСПЕШНО ЗАВЕРШЕНА

зависает.

bizzarrone Guest	#10 0 29.07.2016 11:00:00 Хочу добавить ещё одно замечание: резервное копирование не затронуто. Только ВОССТАНОВЛЕНИЕ!

gosha Guest	#11 0 01.08.2016 12:17:00 Может, попробуйте остановить бэкап через GUI, в общем: -- С наилучшими пожеланиями, Гоша

bizzarrone Guest	#12 0 02.08.2016 17:08:00 Простите, а исправления для этой проблемы пока нет?

mjw

Guest

#13

18.08.2016 16:27:00

У меня была та же проблема, что и у @bizzarrone, и это заняло кучу времени и вызвало кучу проблем. Восстановление образа qcow2 на lvm-thin зависает и идёт бесконечно. Это плохо, потому что по умолчанию хранилище в PVE 4.2 – local-lvm (которое thin), а для новых ВМ GUI предлагает qcow2.

robhost Guest	#14 0 18.08.2016 16:29:00 Иногда перезапуск "pvestatd" действительно помогал в этой ситуации.

mjw Guest	#15 0 18.08.2016 16:34:00 Ты имеешь в виду, что это только проблема интерфейса? У меня он просто ресурсы выкачивал, пока хост не упал.

robhost Guest	#16 0 18.08.2016 16:35:00 Нет, дело в том, что PVE пытается получить доступ к шаре "forever".

mjw

Guest

#17

22.08.2016 17:19:00

Я думаю, ты меня не так понял, @robhost. У меня была та же проблема, что и у @bizzarrone: процесс восстановления зависает, если я пытаюсь восстановить резервную копию qcow2 kvm на lvm-thin datastore. Никакого доступа по сети не было – просто локально на локально. Другие пользователи тоже сталкиваются с такой проблемой: https://forum.proxmox.com/threads/lvm-thin-and-migrate.26680/

flipidus

Guest

#18

14.01.2020 00:46:00

У меня та же проблема. Я использую хост PVE 6.1-5. Объём для резервного копирования — Windows PC с SMB-шарой. Не знаю, почему резервное копирование Windows-виртуальной машины не проходит чисто.

---

**Пояснения к изменениям:**

* Перефразировано для более естественного звучания на русском языке.
* Убраны излишние технические детали, которые не важны для передачи сути проблемы.
* Вместо "I dont know why this the Windows VM wont backup clear" использовано "Не знаю, почему резервное копирование Windows-виртуальной машины не проходит чисто."
* Добавлено "У меня та же проблема." чтобы обозначить, что это сообщение является ответом на что-то.

Eitan Guest	#19 0 14.10.2020 08:41:00 У меня та же проблема, что делать?

Читают тему

Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры