Hello,motivated by the other Xen thread here (I also will share a few experiences soon), I am currently considering the approach that could be advantageous for my use case in terms of storage.
Once again, we have a small NUC system as a Xen host. I exclusively use PV virtualization in the DomUs. In the Dom0, there is a large FFS filesystem where the storage of the DomUs should be stored as image files. I would like to have this set up for reasons that I can explain if necessary.
In doing so, I would like to keep the image files as compact as possible, meaning they should only contain the base system and selected packages suitable for the workload. The actual payload should be located in a separate image file within the VM, which will be linked as a separate block device in the DomU configuration.
A question that arises in this context is whether it would be sensible to run the images without partitions, i.e., without GPT, and instead have the FFS directly on the block device. I have a sense of the advantages and disadvantages of each option in terms of flexibility:
++ GPT: VM image can also be booted using HVM/Qemu/nvmm++ GPT: An image can contain multiple partitions, i.e., root and swap (thus saving VND devices)
-- GPT: Image creation is more complex-- GPT: Image handling is more complex when it is exclusively used for VM (take care on GUID duplicates for examples)
The partitionless approach would consequently require attaching the swap as another image file, which would result in 3 VND devices per DomU.
This leads to the main reason for my question: apart from the VND nodes in /dev that I can easily generate in sufficient numbers using MAKEDEV, what other unknown limitations might I potentially encounter earlier with this approach compared to another approach where I require fewer VND devices? An assessment would greatly help me, which pertains to the number of approximately 20-30 VMs on a system with 8GB of RAM (Dom0 = 512MB).
Thank you very much for your input. Best regards, Matthias
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature