Я не совсем уверен, как сформулировать этот вопрос (отсюда и неудачный заголовок), поэтому позвольте мне привести пример того, что я пытаюсь сделать.
На моем (старом) хосте Xen я могу представить файловые системы LVM напрямую каждому гостю. Эти файловые системы фактически создаются и форматируются на хосте и передаются напрямую. Например, для одного из моих хостов, использующих отдельные разделы tmp и swap, я определяю хранилище следующим образом:
диск = [
'phy: / dev / vg1 / guest1-swap, sda1, w',
'phy: / dev / vg1 / guest1-disk, sda2, w',
'phy: / dev / vg1 / guest1-tmp, sda3, w',
]
Итак, guest1-swap отформатирован как раздел подкачки, guest1-disk и guest1-tmp отформатированы с помощью ext4, и с точки зрения гостя он просто видит их как три отформатированных раздела в / dev / sda.
(Это может показаться большим трудом, но есть сценарии подготовки, такие как потрясающий ксен-инструменты, что автоматизировало почти все).
Это дает некоторые действительно полезные возможности, две из которых мне особенно интересно выяснить для KVM:
Смонтируйте гостевые файловые системы из ОС хоста. Я могу монтировать любую гостевую файловую систему только для чтения в любое время, даже когда гость работает. Это имеет дополнительное преимущество, позволяя мне создавать моментальные снимки LVM любого существующего тома во время работы гостя. Таким образом, я могу централизованно выполнять резервное копирование всех моих гостей во время работы с хоста.
Изменение размера тома онлайн. Поскольку тома содержат стандартные файловые системы Linux, я могу использовать комбинацию lvextend и resize2fs для увеличения своих гостевых файловых систем, опять же, пока они подключены к сети.
В настоящее время я настраиваю хост KVM, который заменит хост Xen. Подобно настройке Xen, я использую LVM для обеспечения прямого доступа к файловой системе, но KVM / qemu ведет себя иначе в том смысле, что всегда создает файл изображения для гостей даже на томе LVM. С точки зрения гостя, он видит это как неразмеченный диск, и гость должен применить метку раздела, а затем создать разделы и файловые системы.
С точки зрения гостя это нормально, но с точки зрения сервера / управления это кажется гораздо менее гибким, чем описанная мною установка Xen. Я все еще новичок в KVM, поэтому я могу (надеюсь) что-то упустить.
Я столкнулся с этой проблемой, когда пытался повторно реализовать мое прежнее решение для резервного копирования на хосте KVM, и команда mount заблокировалась, когда я попытался смонтировать одну из файловых систем гостя. Итак, решение этой проблемы - моя текущая проблема, но это также заставило меня задуматься об изменении размера, потому что я уверен, что эта проблема также возникнет в какой-то момент.
Итак, вот мои вопросы:
Есть ли способ заставить kvm / qemu использовать файловые системы томов LVM напрямую, как я описал для моей установки Xen? Я использую libvirt для управления, если это имеет значение.
Если нет, что я могу сделать, чтобы получить аналогичные функции монтирования / резервного копирования под KVM? Я видел дискуссии об использовании для этого libguestfs w / FUSE, но действительно ли это лучший вариант? Я бы предпочел придерживаться монтирования собственной файловой системы, если это вообще возможно.
Также, если нет, можно ли изменить размер файловой системы онлайн под KVM? Я нашел несколько обсуждений / советов по этому поводу, но ответы, кажется, повсюду, без четких и определенно простых решений.
Извините за длинный пост, просто хотел убедиться, что он понятен. Пожалуйста, дайте мне знать, могу ли я предоставить любую другую информацию, которая была бы полезна. Жду обсуждения. :-)
virt-*
tools) может обеспечить доступ к гостевым файловым системам более чистым способом, чем все, что вы перемонтируете на хост напрямую, хотя оба варианта возможны.resize2fs
будет работать на виртуальной машине так же, как и на физическом оборудовании, единственная проблема заключается в том, что гость повторно определяет изменения размера. Пытаться virt-resize
как стандартный инструмент, но lvresize
и qemu-img
также можно легко использовать (хотя и в автономном режиме, обычно требующем гостевой перезагрузки). думаю lvresize
с участием resize2fs
действительно будет работать без гостевого перезапуска, но я еще не пробовал
Я использую qemu-kvm + libvirt именно с той конфигурацией, о которой вы спрашиваете, по причинам, которые вы указали, но дополнительно потому, что я получаю много лучшая производительность без уровня файловой системы хоста KVM в области видимости. Если вы добавите VG в качестве «пула хранения» в virt-manager, вы можете создать такие виртуальные машины с помощью его удобного мастера. (Но в наши дни я просто пишу XML вручную, используя существующую виртуальную машину в качестве шаблона).
Вот очищенный вывод virsh dumpxml для одного из моих гостей:
<domain type='kvm'>
<name>somevm</name>
<uuid>f173d3b5-704c-909e-b597-c5a823ad48c9</uuid>
<description>Windows Server 2008 R2</description>
<memory unit='KiB'>4194304</memory>
<currentMemory unit='KiB'>4194304</currentMemory>
<vcpu placement='static'>2</vcpu>
<os>
<type arch='x86_64' machine='pc-1.1'>hvm</type>
<boot dev='hd'/>
</os>
<features>
<acpi/>
<apic/>
<pae/>
</features>
<cpu mode='custom' match='exact'>
<model fallback='allow'>Nehalem</model>
<vendor>Intel</vendor>
<feature policy='require' name='tm2'/>
<feature policy='require' name='est'/>
<feature policy='require' name='monitor'/>
<feature policy='require' name='smx'/>
<feature policy='require' name='ss'/>
<feature policy='require' name='vme'/>
<feature policy='require' name='dtes64'/>
<feature policy='require' name='rdtscp'/>
<feature policy='require' name='ht'/>
<feature policy='require' name='ds'/>
<feature policy='require' name='pbe'/>
<feature policy='require' name='tm'/>
<feature policy='require' name='pdcm'/>
<feature policy='require' name='vmx'/>
<feature policy='require' name='ds_cpl'/>
<feature policy='require' name='xtpr'/>
<feature policy='require' name='acpi'/>
</cpu>
<clock offset='localtime'/>
<on_poweroff>destroy</on_poweroff>
<on_reboot>restart</on_reboot>
<on_crash>restart</on_crash>
<devices>
<emulator>/usr/bin/kvm</emulator>
<disk type='block' device='disk'>
<driver name='qemu' type='raw'/>
<source dev='/dev/vg1/somevm'/>
<target dev='hda' bus='virtio'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/>
</disk>
<disk type='file' device='cdrom'>
<driver name='qemu' type='raw'/>
<target dev='hdc' bus='ide'/>
<readonly/>
<address type='drive' controller='0' bus='1' target='0' unit='0'/>
</disk>
<controller type='usb' index='0'>
<address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x2'/>
</controller>
<controller type='ide' index='0'>
<address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/>
</controller>
<controller type='pci' index='0' model='pci-root'/>
<interface type='bridge'>
<mac address='00:00:00:00:00:00'/>
<source bridge='br0'/>
<model type='virtio'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
</interface>
<serial type='pty'>
<target port='0'/>
</serial>
<console type='pty'>
<target type='serial' port='0'/>
</console>
<input type='tablet' bus='usb'/>
<input type='mouse' bus='ps2'/>
<input type='keyboard' bus='ps2'/>
<graphics type='vnc' port='-1' autoport='yes'/>
<video>
<model type='vga' vram='9216' heads='1'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
</video>
<memballoon model='virtio'>
<address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
</memballoon>
</devices>
<seclabel type='none' model='none'/>
</domain>
Еще одна мысль (не относящаяся к вашему вопросу, но это может помочь): если можете, убедитесь, что вы используете паравиртуализированные сетевые, блочные, случайные, тактовые драйверы и т. Д. - они значительно быстрее, чем полностью виртуализированные. Это "model = virtio" выше. Вам необходимо загрузить модули драйверов в ядро хоста, такие как virtio_net.
Вот вывод команды virsh pool-dumpxml vg1:
<pool type='logical'>
<name>vg1</name>
<uuid>9e26648e-64bc-9221-835f-140f6def0556</uuid>
<capacity unit='bytes'>3000613470208</capacity>
<allocation unit='bytes'>1824287358976</allocation>
<available unit='bytes'>1176326111232</available>
<source>
<device path='/dev/md1'/>
<name>vg1</name>
<format type='lvm2'/>
</source>
<target>
<path>/dev/vg1</path>
<permissions>
<mode>0700</mode>
</permissions>
</target>
</pool>
Я не знаю, как точно воспроизвести описанное вами поведение Xen. Однако вы можете использовать kpartx
чтобы предоставить разделы в LV, который содержит образ всего диска, как блочные устройства на хосте, которые затем можно смонтировать и т. д.
Смотрите мой ответ на мой вопрос по этому поводу на KVM загрузка ядра без образа и существующего раздела. Короче говоря, получить virt-install для создания конфигурации для этого довольно просто, учитывая небольшую модификацию гостя / etc / fstab.