[libvirt] [PATCH] vz: set mount point for container image-based disks
From: Maxim Nestratov <mnestratov@virtuozzo.com> In order to support not only root disks with type=file for containers, we need to specify mount points for them. For instance, if a secondary disk is added by the following record in xml: <disk type='file' device='disk'> <driver type='ploop' cache='writeback'/> <source file='/vz/some_path_to_image_dir'/> <target bus='sata' dev='sdb'/> </disk> we are going to add it to container mounted to '/mnt/sdb' path. Signed-off-by: Maxim Nestratov <mnestratov@virtuozzo.com> --- src/vz/vz_sdk.c | 35 +++++++++++++++++++++++++++++++---- 1 files changed, 31 insertions(+), 4 deletions(-) diff --git a/src/vz/vz_sdk.c b/src/vz/vz_sdk.c index 744b58a..6642933 100644 --- a/src/vz/vz_sdk.c +++ b/src/vz/vz_sdk.c @@ -3292,21 +3292,48 @@ static int prlsdkAddDisk(PRL_HANDLE sdkdom, goto cleanup; } - if (bootDisk == true) { + if (bootDisk) { pret = PrlVmDev_GetIndex(sdkdisk, &devIndex); prlsdkCheckRetGoto(pret, cleanup); if (prlsdkAddDeviceToBootList(sdkdom, devIndex, devType, 0) < 0) goto cleanup; - /* If we add physical device as a boot disk to container - * we have to specify mount point for it */ - if (isCt) { + } + + if (isCt) { + + /* If we add a disk as a boot disk to a container + * (it doesn't matter whether it has image or real device backend) + * we have to specify the root mount point for it */ + if (bootDisk) { pret = PrlVmDevHd_SetMountPoint(sdkdisk, "/"); prlsdkCheckRetGoto(pret, cleanup); + } else { + + /* In case of image we need to specify a mount point + * to make it usable within a container */ + if (disk->src->type == VIR_STORAGE_TYPE_FILE) { + char *mount_point; + char *dev_name = strrchr(disk->dst, '/'); + + if (!dev_name) { + virReportError(VIR_ERR_CONFIG_UNSUPPORTED, "%s", + _("Unexpected format of disk destination '%s'.")); + goto cleanup; + } + + if (virAsprintf(&mount_point, "/mnt%s", dev_name) < 0) + goto cleanup; + + pret = PrlVmDevHd_SetMountPoint(sdkdisk, mount_point); + VIR_FREE(mount_point); + prlsdkCheckRetGoto(pret, cleanup); + } } } + return 0; cleanup: PrlHandle_Free(sdkdisk); -- 1.7.1
On Sun, Sep 20, 2015 at 10:17:51PM +0300, Maxim Nestratov wrote:
From: Maxim Nestratov <mnestratov@virtuozzo.com>
In order to support not only root disks with type=file for containers, we need to specify mount points for them. For instance, if a secondary disk is added by the following record in xml:
<disk type='file' device='disk'> <driver type='ploop' cache='writeback'/> <source file='/vz/some_path_to_image_dir'/> <target bus='sata' dev='sdb'/> </disk>
we are going to add it to container mounted to '/mnt/sdb' path.
That's not what the <disk> element is for. <disk> is about exposing block device nodes to the container. It shouldn't try todo anything with this device nodes. They might be used as raw data storage by an application, so we can't assume they should be mounted. If you want to mount things then you should be using <filesystem> instead. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
21.09.2015 11:44, Daniel P. Berrange пишет:
On Sun, Sep 20, 2015 at 10:17:51PM +0300, Maxim Nestratov wrote:
From: Maxim Nestratov <mnestratov@virtuozzo.com>
In order to support not only root disks with type=file for containers, we need to specify mount points for them. For instance, if a secondary disk is added by the following record in xml:
<disk type='file' device='disk'> <driver type='ploop' cache='writeback'/> <source file='/vz/some_path_to_image_dir'/> <target bus='sata' dev='sdb'/> </disk>
we are going to add it to container mounted to '/mnt/sdb' path. That's not what the <disk> element is for. <disk> is about exposing block device nodes to the container. It shouldn't try todo anything with this device nodes. They might be used as raw data storage by an application, so we can't assume they should be mounted.
If you want to mount things then you should be using <filesystem> instead.
Regards, Daniel Hm. It actually means that any disks with type file shouldn't work in containers. Right? And working root disks like this is a mistake? But why? In vz, any images plugged into containers are also treated as disks. The only difference between 'filesystem' and 'disk' is whether we should mount it or not. That's all. While from point of view of a container user it is just another storage. Why not just mount it automatically?
Best, Maxim
On Mon, Sep 21, 2015 at 12:14:57PM +0300, Maxim Nestratov wrote:
21.09.2015 11:44, Daniel P. Berrange пишет:
On Sun, Sep 20, 2015 at 10:17:51PM +0300, Maxim Nestratov wrote:
From: Maxim Nestratov <mnestratov@virtuozzo.com>
In order to support not only root disks with type=file for containers, we need to specify mount points for them. For instance, if a secondary disk is added by the following record in xml:
<disk type='file' device='disk'> <driver type='ploop' cache='writeback'/> <source file='/vz/some_path_to_image_dir'/> <target bus='sata' dev='sdb'/> </disk>
we are going to add it to container mounted to '/mnt/sdb' path. That's not what the <disk> element is for. <disk> is about exposing block device nodes to the container. It shouldn't try todo anything with this device nodes. They might be used as raw data storage by an application, so we can't assume they should be mounted.
If you want to mount things then you should be using <filesystem> instead.
Hm. It actually means that any disks with type file shouldn't work in containers. Right?
No, the disk source on the host is not correlated to how it is exposed to the guest. With <disk type="file"> it means you have to setup some kind of loop device in the host OS, and then expose the block device to the guest with that. The same if you have <disk type="network"> then you have to use host kernel or qemu-nbd, for example, to setup a block device that you can then expose to the guest.
And working root disks like this is a mistake? But why?
Yes, that would be a mistake too. The root filesystem should be exposed using <filesystem> with a <target> of /
In vz, any images plugged into containers are also treated as disks. The only difference between 'filesystem' and 'disk' is whether we should mount it or not. That's all. While from point of view of a container user it is just another storage. Why not just mount it automatically?
The <disk> element is intended to expose raw block devices to the guest. The <filesystem> is intended to expose mounted volumed to the guest. A <disk> can support both type=block and type=file as sources on the host side, as well as others like type=network. A <filesystem> can support both type=block and type=file as sources on the host, as well as a few others. If you make <disk> automatically mount volumes, then you've just discarded the only semantic difference between <filesystem> and <disk>, which is not only wrong but also pointless. If you want to mount it, you should just use <filesystem>, and not try to make <disk> do the same as <filesystem>. It is key that <disk> does *not* try to interpret what todo with the storage - it is entirely upto the guest to decide what todo with it. For example, an oracle database might decide to use the block device directly as data storage. Or you might be running an application that wants to manipulate the filesystem (eg a fsck tool) inside the block dev, so again it would be inappropriate to mount it. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
21.09.2015 12:23, Daniel P. Berrange пишет:
On Mon, Sep 21, 2015 at 12:14:57PM +0300, Maxim Nestratov wrote:
21.09.2015 11:44, Daniel P. Berrange пишет:
On Sun, Sep 20, 2015 at 10:17:51PM +0300, Maxim Nestratov wrote:
From: Maxim Nestratov <mnestratov@virtuozzo.com>
In order to support not only root disks with type=file for containers, we need to specify mount points for them. For instance, if a secondary disk is added by the following record in xml:
<disk type='file' device='disk'> <driver type='ploop' cache='writeback'/> <source file='/vz/some_path_to_image_dir'/> <target bus='sata' dev='sdb'/> </disk>
we are going to add it to container mounted to '/mnt/sdb' path. That's not what the <disk> element is for. <disk> is about exposing block device nodes to the container. It shouldn't try todo anything with this device nodes. They might be used as raw data storage by an application, so we can't assume they should be mounted.
If you want to mount things then you should be using <filesystem> instead.
Hm. It actually means that any disks with type file shouldn't work in containers. Right? No, the disk source on the host is not correlated to how it is exposed to the guest.
With <disk type="file"> it means you have to setup some kind of loop device in the host OS, and then expose the block device to the guest with that. The same if you have <disk type="network"> then you have to use host kernel or qemu-nbd, for example, to setup a block device that you can then expose to the guest.
And working root disks like this is a mistake? But why? Yes, that would be a mistake too. The root filesystem should be exposed using <filesystem> with a <target> of /
In vz, any images plugged into containers are also treated as disks. The only difference between 'filesystem' and 'disk' is whether we should mount it or not. That's all. While from point of view of a container user it is just another storage. Why not just mount it automatically? The <disk> element is intended to expose raw block devices to the guest.
The <filesystem> is intended to expose mounted volumed to the guest.
A <disk> can support both type=block and type=file as sources on the host side, as well as others like type=network.
A <filesystem> can support both type=block and type=file as sources on the host, as well as a few others.
If you make <disk> automatically mount volumes, then you've just discarded the only semantic difference between <filesystem> and <disk>, which is not only wrong but also pointless. If you want to mount it, you should just use <filesystem>, and not try to make <disk> do the same as <filesystem>.
It is key that <disk> does *not* try to interpret what todo with the storage - it is entirely upto the guest to decide what todo with it. For example, an oracle database might decide to use the block device directly as data storage. Or you might be running an application that wants to manipulate the filesystem (eg a fsck tool) inside the block dev, so again it would be inappropriate to mount it.
Regards, Daniel Ok. I see. Thank you for the explanation. Please, disregard the patch then.
participants (3)
-
Daniel P. Berrange -
Maxim Nestratov -
Maxim Nestratov