Hi,
It is going to very useful for users if we install open-vm-tools inside a VM on VMware always.
For this, I'm proposing following design: 1. Add open-vm-tools to the core package group 2. Modify Anaconda to uninstall open-vm-tools after installation if install is not running on a VM on VMware
Could someone from Minimal Core SIG please help me through the process to make this change?
Thanks, Ravindra
Hello,
On 2 May 2013 05:31, Ravindra Kumar ravindrakumar@vmware.com wrote:
- Add open-vm-tools to the core package group
- Modify Anaconda to uninstall open-vm-tools after installation if
install is not running on a VM on VMware
Install and uninstall looks a bit weird to me; what could be done is to make the package conditionally whether it's running in a VMware VM or not, much like it happens now for the EFI packages (only installed on an EFI system) or the spice agent (IIRC) if it's installed in libvirt/kvm or RHEV/ovirt.
Regards, --Simone
On 05/02/2013 05:31 AM, Ravindra Kumar wrote:
Hi,
It is going to very useful for users if we install open-vm-tools inside a VM on VMware always.
For this, I'm proposing following design:
- Add open-vm-tools to the core package group
- Modify Anaconda to uninstall open-vm-tools after installation if
install is not running on a VM on VMware
I can't see, how this can happen anyways. Anaconda just runs once (at installation), afterwards it can safely be removed (correct me, if I'm wrong).
Could you please explain, why this should be useful for all our users? I think it's more sensible to install, when running on VMware. And also: why do you require this at all?
How does this work together with VMwares hint, to remove open-vm-tools distributed by linux distributions at all?
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd...
Matthias
On Thu, May 02, 2013 at 02:17:27PM +0200, Matthias Runge wrote:
On 05/02/2013 05:31 AM, Ravindra Kumar wrote:
Hi,
It is going to very useful for users if we install open-vm-tools inside a VM on VMware always.
For this, I'm proposing following design:
- Add open-vm-tools to the core package group
- Modify Anaconda to uninstall open-vm-tools after installation if
install is not running on a VM on VMware
I can't see, how this can happen anyways. Anaconda just runs once (at installation), afterwards it can safely be removed (correct me, if I'm wrong).
Could you please explain, why this should be useful for all our users? I think it's more sensible to install, when running on VMware. And also: why do you require this at all?
Rather than trying to only install it in particular scenarios, it is better to install it everywhere and then make sure that it is a no-op unless it is running inside VMWare. Not least because if we're building a cloud image, the initial build environment likely won't involve VMware at all, but the ultimate runtime environment may well be VMWare.
The systemd unit file open-vm-tools includes already has a statement ConditionVirtualization=vmware. Whether there is more work required to make sure the package is a no-op on non-VMWare deployments is something that'd need to be verified before inclusion in the core package group.
Daniel
(Batching a bunch of replies)
Install and uninstall looks a bit weird to me; what could be done is to make the package conditionally whether it's running in a VMware VM or not, much like it happens now for the EFI packages (only installed on an EFI system) or the spice agent (IIRC) if it's installed in libvirt/kvm or RHEV/ovirt.
Thanks Simone. I will look into this.
Wouldn't the opposite make more sense?
Yes, that is more logical. But, I have considered how Anaconda installs packages from CD and yum etc. Conditionally excluding it during different types of installation methods will probably require lots of changes in different pieces of install framework. E.g. including/excluding a package from CD, including/excluding a package from yum etc.
How does this work together with VMwares hint, to remove open-vm-tools distributed by linux distributions at all? http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd...
Yeah. This is quite confusing. VMWare folks are pushing for better integration but unless VMWare stops putting out conflicting messages, I am not sure anyone benefits.
I don't really see what is conflicting in the KB article. There are two things to note here.
1. This KB article is not discouraging usage of open-vm-tools as such but it just describes a solution to install VMware Tools when open-vm-tools are already installed. Currently, it is not advised to have both packages installed together (this is changing, please see my note below). VMware Tools are more feature rich than open-vm-tools, so there are cases where VMware Tools are needed and therefore open-vm-tools have to be replaced with VMware Tools to get the desired functionality. 2. Our current plan is to support open-vm-tools in multiple ways, e.g. allow VMware Tools to co-exist with open-vm-tools, and fill the feature gaps in open-vm-tools. We are working on it and we will update the relevant KB articles as we make progress.
Hope this clarifies a bit.
Thanks, Ravindra
Ravindra Kumar (ravindrakumar@vmware.com) said:
(Batching a bunch of replies)
Install and uninstall looks a bit weird to me; what could be done is to make the package conditionally whether it's running in a VMware VM or not, much like it happens now for the EFI packages (only installed on an EFI system) or the spice agent (IIRC) if it's installed in libvirt/kvm or RHEV/ovirt.
Thanks Simone. I will look into this.
Wouldn't the opposite make more sense?
Yes, that is more logical. But, I have considered how Anaconda installs packages from CD and yum etc. Conditionally excluding it during different types of installation methods will probably require lots of changes in different pieces of install framework. E.g. including/excluding a package from CD, including/excluding a package from yum etc.
But adding it if a condition is met seems much simpler. Consider how it adds FS tools or RAID tools depending on the type of install.
Or if this was done via a yum plugin, it's possible it could be done automatically at that level.
Bill
On Thu, May 02, 2013 at 01:51:30PM -0400, Bill Nottingham wrote:
Ravindra Kumar (ravindrakumar@vmware.com) said:
(Batching a bunch of replies)
Install and uninstall looks a bit weird to me; what could be done is to make the package conditionally whether it's running in a VMware VM or not, much like it happens now for the EFI packages (only installed on an EFI system) or the spice agent (IIRC) if it's installed in libvirt/kvm or RHEV/ovirt.
Thanks Simone. I will look into this.
Wouldn't the opposite make more sense?
Yes, that is more logical. But, I have considered how Anaconda installs packages from CD and yum etc. Conditionally excluding it during different types of installation methods will probably require lots of changes in different pieces of install framework. E.g. including/excluding a package from CD, including/excluding a package from yum etc.
But adding it if a condition is met seems much simpler. Consider how it adds FS tools or RAID tools depending on the type of install.
Or if this was done via a yum plugin, it's possible it could be done automatically at that level.
I'm a bit worried that this might make it harder to produce generic cloud images [eg. using Oz]. But then again, perhaps people making generic cloud images should use kickstarts and specify the precise list of packages they want ...
Rich.
On 2 May 2013 22:24, Richard W.M. Jones rjones@redhat.com wrote:
I'm a bit worried that this might make it harder to produce generic cloud images [eg. using Oz]. But then again, perhaps people making generic cloud images should use kickstarts and specify the precise list of packages they want ...
I think is already a bit too late, unfortunately. On my laptop:
xorg-x11-drv-vmmouse-13.0.0-1.fc18.x86_64 xorg-x11-drv-vmware-12.0.2-3.20120718gite5ac80d8f.fc18.x86_64 xorg-x11-drv-qxl-0.0.22-5.20120718gitde6620788.fc18.x86_64 spice-vdagent-0.14.0-1.fc18.x86_64
--Simone
On Thu, 2013-05-02 at 22:44 +0200, Simone Caronni wrote:
On 2 May 2013 22:24, Richard W.M. Jones rjones@redhat.com wrote: I'm a bit worried that this might make it harder to produce generic cloud images [eg. using Oz]. But then again, perhaps people making generic cloud images should use kickstarts and specify the precise list of packages they want ...
I think is already a bit too late, unfortunately. On my laptop:
xorg-x11-drv-vmmouse-13.0.0-1.fc18.x86_64 xorg-x11-drv-vmware-12.0.2-3.20120718gite5ac80d8f.fc18.x86_64 xorg-x11-drv-qxl-0.0.22-5.20120718gitde6620788.fc18.x86_64 spice-vdagent-0.14.0-1.fc18.x86_64
Well, "we have this thing that sucks, so let's add this OTHER thing that sucks" has never been the strongest logic :P
I don't really hate the 'let's just install it everywhere and make sure it doesn't run unless it's necessary' approach, but it is kinda lazy engineering, and it *does* waste space on those small-space cases Peter is always reminding us about. Especially if this stuff goes in core.
It seems like the thing to do would be to ask anaconda if it's feasible / desirable to make the installation of this stuff contingent on the environment. I kinda agree with Rich on the 'generic cloud image' case; it doesn't seem like it'd be too difficult to just explicitly include the necessary packages in generating such an image, so I don't think it's particularly compelling to say we have to put useless packages on everyone's systems just so that someone building a generic image has a slightly easier time of it.
If anaconda doesn't want to do the 'contingent install' thing, then the 'just install it everywhere' option seems like the second best choice.
Has anyone checked how much stuff it pulls in to an existing minimal install? We don't want anything that drags in a pile of deps that we don't already have in a minimal install. http://koji.fedoraproject.org/koji/rpminfo?rpmID=3975641 doesn't look bad just eyeballing it, but I'll try and find a minute to fire up a minimal install then 'yum install' the package to see how much it adds.
Le Ven 3 mai 2013 01:46, Adam Williamson a écrit :
I don't really hate the 'let's just install it everywhere and make sure it doesn't run unless it's necessary' approach, but it is kinda lazy engineering, and it *does* waste space on those small-space cases Peter is always reminding us about. Especially if this stuff goes in core.
It seems like the thing to do would be to ask anaconda if it's feasible / desirable to make the installation of this stuff contingent on the environment.
Well, this is what I call lazy engineering: detect hardware at install time, assume it never changes, and ask users to reinstall from scratch whenever they move systems (or hunt-the-third-party-bits-on-the-internet à la windows 95).
To do it properly you don't need just an anaconda workaround but some sort of boot-time detection, that will require network access to repos to work, and will quickly spiral into such complexity that makes it quite unpalatable. Hardware support (which means drivers and associated tools) should just be preinstalled for common hardware, and vmware passed the "common" level a long time ago (people take existing systems and hack up from them disposable vms all the time nowadays).
Regards,
Am 03.05.2013 13:30, schrieb Nicolas Mailhot:
Le Ven 3 mai 2013 01:46, Adam Williamson a écrit :
I don't really hate the 'let's just install it everywhere and make sure it doesn't run unless it's necessary' approach, but it is kinda lazy engineering, and it *does* waste space on those small-space cases Peter is always reminding us about. Especially if this stuff goes in core.
It seems like the thing to do would be to ask anaconda if it's feasible / desirable to make the installation of this stuff contingent on the environment
Well, this is what I call lazy engineering: detect hardware at install time, assume it never changes, and ask users to reinstall from scratch whenever they move systems (or hunt-the-third-party-bits-on-the-internet à la windows 95)
stay on topic!
you do not need open-vm-tools for a working network, not for paravirt-scsi not for any virtual hardware nor will it break anything if you move the machine from VMware to whatever virtualization or even move the image to a phyiscal computer
you are still hanging in the days vmware-drivers where insinde vmware-tools these days are gone for Fedora at least a year ago!
On 3 May 2013 01:46, Adam Williamson awilliam@redhat.com wrote:
On Thu, 2013-05-02 at 22:44 +0200, Simone Caronni wrote:
I think is already a bit too late, unfortunately. On my laptop:
xorg-x11-drv-vmmouse-13.0.0-1.fc18.x86_64 xorg-x11-drv-vmware-12.0.2-3.20120718gite5ac80d8f.fc18.x86_64 xorg-x11-drv-qxl-0.0.22-5.20120718gitde6620788.fc18.x86_64 spice-vdagent-0.14.0-1.fc18.x86_64
Well, "we have this thing that sucks, so let's add this OTHER thing that sucks" has never been the strongest logic :P
[..]
It seems like the thing to do would be to ask anaconda if it's feasible / desirable to make the installation of this stuff contingent on the environment. I kinda agree with Rich on the 'generic cloud image' case; it doesn't seem like it'd be too difficult to just explicitly include the necessary packages in generating such an image, so I don't think it's particularly compelling to say we have to put useless packages on everyone's systems just so that someone building a generic image has a slightly easier time of it.
If anaconda doesn't want to do the 'contingent install' thing, then the 'just install it everywhere' option seems like the second best choice.
Yes, this is exactly my point, I was simply showing an example of this. I'm not a sponsor of having open-vm-tools installed by default.
My preference would be not to install anything that is needed for a particular environment and install the additional packages on demand. I dont' see any problem in performing one of those for a sysadmin:
yum install open-vm-tools yum install open-vm-tools-desktop (this could pull the vmmouse and vmware xorg drivers in) yum install spice-vdagent (this could pull the qxl driver in) yum install ovirt-guest-agent
an image is never prepared as-is with the default installation, so I don't see the problem of performing an additional command.
Having said that; what would be cool, is to have Anaconda detect the environment and install the correct packages at install time, so for example a user could have a nice starting impression after the first install.
Regards, --Simone
On Thu, May 2, 2013 at 6:51 PM, Bill Nottingham notting@redhat.com wrote:
Ravindra Kumar (ravindrakumar@vmware.com) said:
(Batching a bunch of replies)
Install and uninstall looks a bit weird to me; what could be done is to make the package conditionally whether it's running in a VMware VM or not, much like it happens now for the EFI packages (only installed on an EFI system) or the spice agent (IIRC) if it's installed in libvirt/kvm or RHEV/ovirt.
Thanks Simone. I will look into this.
Wouldn't the opposite make more sense?
Yes, that is more logical. But, I have considered how Anaconda installs packages from CD and yum etc. Conditionally excluding it during different types of installation methods will probably require lots of changes in different pieces of install framework. E.g. including/excluding a package from CD, including/excluding a package from yum etc.
But adding it if a condition is met seems much simpler. Consider how it adds FS tools or RAID tools depending on the type of install.
Or if this was done via a yum plugin, it's possible it could be done automatically at that level.
I don't see why we would add this by default, the VM will function without is (unlike storage) and we don't add ovirt-guest-agent and other virt vendor's agents by default.
Peter
On Fri, 2013-05-03 at 11:59 +0100, Peter Robinson wrote:
On Thu, May 2, 2013 at 6:51 PM, Bill Nottingham notting@redhat.com wrote:
Ravindra Kumar (ravindrakumar@vmware.com) said:
(Batching a bunch of replies)
Install and uninstall looks a bit weird to me; what could be done is to make the package conditionally whether it's running in a VMware VM or not, much like it happens now for the EFI packages (only installed on an EFI system) or the spice agent (IIRC) if it's installed in libvirt/kvm or RHEV/ovirt.
Thanks Simone. I will look into this.
Wouldn't the opposite make more sense?
Yes, that is more logical. But, I have considered how Anaconda installs packages from CD and yum etc. Conditionally excluding it during different types of installation methods will probably require lots of changes in different pieces of install framework. E.g. including/excluding a package from CD, including/excluding a package from yum etc.
But adding it if a condition is met seems much simpler. Consider how it adds FS tools or RAID tools depending on the type of install.
Or if this was done via a yum plugin, it's possible it could be done automatically at that level.
I don't see why we would add this by default, the VM will function without is (unlike storage) and we don't add ovirt-guest-agent and other virt vendor's agents by default.
We do, in fact, include the SPICE agent stuff by default now. (Which I like because it means copy/paste out of Fedora KVMs always works, but I never claimed not to be a hypocrite :>)
Just picking the latest mail on this thread.
I don't see why we would add this by default, the VM will function without is (unlike storage) and we don't add ovirt-guest-agent and other virt vendor's agents by default.
We do, in fact, include the SPICE agent stuff by default now. (Which I like because it means copy/paste out of Fedora KVMs always works, but I never claimed not to be a hypocrite :>)
I think there are opinions in favor as well as against including open-vm-tools to core group. However, I'm not sure if there is a convincing explanation for following issues with conditional install of open-vm-tools:
1. Given that DVD image will not have open-vm-tools, installing these by default inside a VM will not be possible when VM is not connected to network or VM is running behind a proxy. 2. All the usecases where install environment is not the same as execution environment (including P2V) will have poor install experience. 3. Installer (Anaconda) will have to be modified specifically for each virtualization solution.
Given that open-vm-tools is not a large package and is a no-op on physical, what are the real obstacles in putting it in core? Or, in other words, what would it take to put it in core group?
If it is absolute no, I would proceed with the Anaconda patch if there is a good explanation/alternative to the 3 issues I have listed above.
Thanks, Ravindra
On Mon, 2013-05-06 at 15:04 -0700, Ravindra Kumar wrote:
If it is absolute no, I would proceed with the Anaconda patch if there is a good explanation/alternative to the 3 issues I have listed above.
Talk to the anaconda devs first. I'm no expert on anaconda internals, but I play one on TV, and I'm pretty sure they wouldn't take a patch that tries to uninstall stuff from the system it just installed. There are already mechanisms in anaconda for conditionally adding packages to the 'to be installed' set, based on the system architecture, and probably some other things. You probably want to either make use of or at least mirror the design of these existing mechanisms, rather than just inventing a new one out of thin air.
On Mon, May 06, 2013 at 03:12:52PM -0700, Adam Williamson wrote:
On Mon, 2013-05-06 at 15:04 -0700, Ravindra Kumar wrote:
If it is absolute no, I would proceed with the Anaconda patch if there is a good explanation/alternative to the 3 issues I have listed above.
Talk to the anaconda devs first. I'm no expert on anaconda internals, but I play one on TV, and I'm pretty sure they wouldn't take a patch that tries to uninstall stuff from the system it just installed. There are already mechanisms in anaconda for conditionally adding packages to the 'to be installed' set, based on the system architecture, and probably some other things. You probably want to either make use of or at least mirror the design of these existing mechanisms, rather than just inventing a new one out of thin air.
I don't understand why we'd want to do the uninstall part. The open-vm-tools service (vmtoold.service) is already conditional on VMware being found at boot time. Do we uninstall X11 drivers if they are not needed at install time?
So IMHO it seems no change to Anaconda is really necessary here.
Rich.
I can't see, how this can happen anyways. Anaconda just runs once (at installation), afterwards it can safely be removed (correct me, if I'm wrong).
Could you please explain, why this should be useful for all our users? I think it's more sensible to install, when running on VMware. And also: why do you require this at all?
Rather than trying to only install it in particular scenarios, it is better to install it everywhere and then make sure that it is a no-op unless it is running inside VMWare. Not least because if we're building a cloud image, the initial build environment likely won't involve VMware at all, but the ultimate runtime environment may well be VMWare.
I was thinking about this approach but the only downside is physical deployments and non-VMware VMs. I'm not sure if it is common to install unused packages on system.
The systemd unit file open-vm-tools includes already has a statement ConditionVirtualization=vmware. Whether there is more work required to make sure the package is a no-op on non-VMWare deployments is something that'd need to be verified before inclusion in the core package group.
Yes, vmtoolsd service is a no-op in all non-VMware environments. In fact, it will simply exit even if systemd check is not there, because we do a platform check inside before starting the main loop.
Thanks, Ravindra
Le Jeu 2 mai 2013 19:49, Ravindra Kumar a écrit :
I can't see, how this can happen anyways. Anaconda just runs once (at installation), afterwards it can safely be removed (correct me, if I'm wrong).
Could you please explain, why this should be useful for all our users?
I
think it's more sensible to install, when running on VMware. And also: why do you require this at all?
Rather than trying to only install it in particular scenarios, it is better to install it everywhere and then make sure that it is a no-op unless it is running inside VMWare. Not least because if we're building a cloud image, the initial build environment likely won't involve VMware at all, but the ultimate runtime environment may well be VMWare.
I was thinking about this approach but the only downside is physical deployments and non-VMware VMs. I'm not sure if it is common to install unused packages on system.
The system is full of hardware drivers that are only activated when the hardware is found. That makes moving a system image trivial. It is well worth the disk use as long as the hardware tools are not obese or the hardware marginal.
Am 02.05.2013 21:41, schrieb Nicolas Mailhot:
Le Jeu 2 mai 2013 19:49, Ravindra Kumar a écrit :
I can't see, how this can happen anyways. Anaconda just runs once (at installation), afterwards it can safely be removed (correct me, if I'm wrong).
Could you please explain, why this should be useful for all our users?
I
think it's more sensible to install, when running on VMware. And also: why do you require this at all?
Rather than trying to only install it in particular scenarios, it is better to install it everywhere and then make sure that it is a no-op unless it is running inside VMWare. Not least because if we're building a cloud image, the initial build environment likely won't involve VMware at all, but the ultimate runtime environment may well be VMWare.
I was thinking about this approach but the only downside is physical deployments and non-VMware VMs. I'm not sure if it is common to install unused packages on system.
The system is full of hardware drivers that are only activated when the hardware is found. That makes moving a system image trivial. It is well worth the disk use as long as the hardware tools are not obese or the hardware marginal
drivers are a total different topic
recent and for fedora relevant kernels are including any server relevant drivers, with 3.9 even vsock and vmci are in the upstream kernel, for F19 there is a 3.9 kernel available which works also on F18 and i guess 3.9 for F18 will come soon
in short: the days where you need vmware drivers in a guest from additional packages are long gone - said from one who drives a whole comapny infrastructure since 2008 on Fedora/Vmware vSphere
On 2 May 2013 22:29, Reindl Harald h.reindl@thelounge.net wrote:
drivers are a total different topic
recent and for fedora relevant kernels are including any server relevant drivers, with 3.9 even vsock and vmci are in the upstream kernel, for F19 there is a 3.9 kernel available which works also on F18 and i guess 3.9 for F18 will come soon
Exactly. During the review Ravindra promised to update upstream's open-vm-tools README files with the information regarding the module status:
Fedora, RHEL 6
- vmxnet3 (2.6.32+) - vmw_pvscsi (2.6.33+) - vmw_balloon (2.6.34+) - vmwgfx (2.6.33+) - vmmouse_drv (xorg) - vmware_drv (xorg)
Fedora 19+
- vmw_vmci (3.9) - vmw_vsock_vmci_transport (3.9)
Not integrated yet
- vmblock - vmhgfs - vmsync - vmxnet
--Simone
Am 02.05.2013 22:45, schrieb Simone Caronni:
On 2 May 2013 22:29, Reindl Harald <h.reindl@thelounge.net mailto:h.reindl@thelounge.net> wrote: recent and for fedora relevant kernels are including any server relevant drivers, with 3.9 even vsock and vmci are in the upstream kernel, for F19 there is a 3.9 kernel available which works also on F18 and i guess 3.9 for F18 will come soon
Exactly. During the review Ravindra promised to update upstream's open-vm-tools README files with the information regarding the module status:
Fedora, RHEL 6
- vmxnet3 (2.6.32+)
- vmw_pvscsi (2.6.33+)
- vmw_balloon (2.6.34+)
- vmwgfx (2.6.33+)
- vmmouse_drv (xorg)
- vmware_drv (xorg)
Fedora 19+
- vmw_vmci (3.9)
- vmw_vsock_vmci_transport (3.9)
Not integrated yet
- vmblock
- vmhgfs
- vmsync
- vmxnet
vmblock / vmsync are no longe needed
they was needed for consistent snaphsots and not used on recenct kernels get this both obsolete did make my life so much easier with VMware Datarecovery and kernel updates
vmhgfs is only relevant on desktops and even there i would use SMB
vmxnet is not needed at all, vmxnet3 is in the upstream kernel since years - so finally you do not really need any kernel mdoule and since my whole infracstructure is running a long time even without vmci/vsock a declare both also as obsolete
Hi
On Thu, May 2, 2013 at 8:17 AM, Matthias Runge wrote:
How does this work together with VMwares hint, to remove open-vm-tools distributed by linux distributions at all?
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd...
Yeah. This is quite confusing. VMWare folks are pushing for better integration but unless VMWare stops putting out conflicting messages, I am not sure anyone benefits.
Rahul
Le Jeu 2 mai 2013 14:34, Rahul Sundaram a écrit :
Hi
On Thu, May 2, 2013 at 8:17 AM, Matthias Runge wrote:
How does this work together with VMwares hint, to remove open-vm-tools distributed by linux distributions at all?
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd...
Yeah. This is quite confusing. VMWare folks are pushing for better integration but unless VMWare stops putting out conflicting messages, I am not sure anyone benefits.
VMWare is sure shooting itself in the foot (I've seen vmware consultants force the removal of rpm-ized vmware tools from system images only to discover they had no mean to update the non-rpm version three monhs later when the image was largely deployed). All the more reason to help the vmware groups that try to make it a better experience.
On 2 May 2013 21:44, Nicolas Mailhot nicolas.mailhot@laposte.net wrote:
VMWare is sure shooting itself in the foot (I've seen vmware consultants force the removal of rpm-ized vmware tools from system images only to discover they had no mean to update the non-rpm version three monhs later when the image was largely deployed). All the more reason to help the vmware groups that try to make it a better experience.
Exactly. That's why on RHEL/CentOS i use these:
http://www.vmware.com/download/packages.html
They're in good shape; unfortunately there are no updates without editing the repository file by hand and removing most of the components before reinstalling (broken upgrade paths).
I'm already using the simple Fedora/EPEL package.
On Wed, 2013-05-01 at 20:31 -0700, Ravindra Kumar wrote:
Hi,
It is going to very useful for users if we install open-vm-tools inside a VM on VMware always.
For this, I'm proposing following design:
Add open-vm-tools to the core package group
Modify Anaconda to uninstall open-vm-tools after installation if
install is not running on a VM on VMware
Wouldn't the opposite make more sense?
On Wed, May 01, 2013 at 08:31:38PM -0700, Ravindra Kumar wrote:
Hi,
It is going to very useful for users if we install open-vm-tools inside a VM on VMware always.
For this, I'm proposing following design:
- Add open-vm-tools to the core package group
- Modify Anaconda to uninstall open-vm-tools after installation if install is not running on a VM on VMware
Could someone from Minimal Core SIG please help me through the process to make this change?
I'm Ravindra's sponsor.
Just to clarify a few points:
- VMware are trying to work better with Fedora, and to help this along I've been supervising him adding open-vm-tools to Fedora.
- Because this is just starting out, there are a few mixed messages, including some advice to remove open-vm-tools (which is now, or soon will be wrong advice). I hope that Ravindra can work with his employers to get that advice changed as necessary.
- As Dan said, the open-vm-tools package only starts the service if the hypervisor is VMware.
I'll leave the particulars of whether this package should go in minimal or not, or on the CD or not, to others. However if you need us to split the package further or make other changes to improve the chances of inclusion, let Ravindra know, and I will help him to do this.
Rich.
Am 02.05.2013 19:40, schrieb Richard W.M. Jones:
On Wed, May 01, 2013 at 08:31:38PM -0700, Ravindra Kumar wrote:
Hi,
It is going to very useful for users if we install open-vm-tools inside a VM on VMware always.
For this, I'm proposing following design:
- Add open-vm-tools to the core package group
- Modify Anaconda to uninstall open-vm-tools after installation if install is not running on a VM on VMware
Could someone from Minimal Core SIG please help me through the process to make this change?
I'm Ravindra's sponsor.
Just to clarify a few points:
VMware are trying to work better with Fedora, and to help this along I've been supervising him adding open-vm-tools to Fedora.
Because this is just starting out, there are a few mixed messages, including some advice to remove open-vm-tools (which is now, or soon will be wrong advice). I hope that Ravindra can work with his employers to get that advice changed as necessary.
As Dan said, the open-vm-tools package only starts the service if the hypervisor is VMware.
I'll leave the particulars of whether this package should go in minimal or not, or on the CD or not, to others. However if you need us to split the package further or make other changes to improve the chances of inclusion, let Ravindra know, and I will help him to do this
the open-vm-tools should be generally be splitted in packages with and without X11 deps - below my personal SPEC file for a fedora infrastructure on top of vSphere with all things you need for "VMware DataRecovery"-backups and VMware-HighAbility
you do not want any X11-deps and HGFS stuff on production sevrers
[root@buildserver64:~]$ cat /rpmbuild/SPECS/vmware-tools.spec %define vmtooolsver 9.2.3 %define buildver 1098359
%global _hardened_build 1 %global debug_package %{nil} %global kernel_uname_r %(echo $(uname -r))
Name: open-vm-tools Version: %{vmtooolsver}.%{buildver} Release: 7%{?dist} Summary: VMware Guest OS Tools Group: Applications/System License: LGPLv2 URL: http://open-vm-tools.sourceforge.net/ Source0: http://downloads.sourceforge.net/open-vm-tools/%%7Bname%7D-%%7Bvmtooolsver%7... Source1: vmtoolsd.service BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n) ExclusiveArch: %{ix86} x86_64 Requires(post): systemd-units Requires(preun): systemd-units Requires: systemd-units Requires: /usr/bin/bash BuildRequires: uriparser-devel BuildRequires: libnotify-devel BuildRequires: fuse-devel Obsoletes: open-vm-tools-kmod kmod-open-vm-tools akmod-open-vm-tools open-vm-tools-kmod-common open-vm-tools-libs
%description open-vm-tools are the open source implementation of VMware Tools
%prep %setup -q -n %{name}-%{vmtooolsver}-%{buildver}
%build CXXFLAGS="%{optflags} -fPIC -fPIE -fstack-protector-all" CFLAGS="%{optflags} -fPIC -fPIE -fstack-protector-all" FFLAGS="%{optflags} -fPIC -fPIE -fstack-protector-all" LDFLAGS="-Wl,-z,now -Wl,-z,relro"
export CXXFLAGS CFLAGS LDFLAGS FFLAGS
%configure --disable-static \ --disable-dependency-tracking \ --disable-multimon \ --disable-tests \ --disable-docs \ --disable-static \ --with-pic \ --with-gnu-ld \ --without-gtk2 \ --without-gtkmm \ --without-x \ --without-icu \ --without-root-privileges \ --without-kernel-modules \ --without-procps \ --without-dnet \ --without-pam sed -i 's|^hardcode_libdir_flag_spec=.*|hardcode_libdir_flag_spec=""|g' libtool sed -i 's|^runpath_var=LD_RUN_PATH|runpath_var=DIE_RPATH_DIE|g' libtool %{__make} %{?_smp_mflags}
%install make install-strip DESTDIR=%{buildroot} find %{buildroot} -type f -name "*.la" -exec rm -f {} ';' mkdir -p %{buildroot}/sbin mv %{buildroot}%{_sbindir}/mount.* %{buildroot}/sbin rm -f %{buildroot}%{_sysconfdir}/xdg/autostart/vmware-user.desktop rm -f %{buildroot}%{_libdir}/open-vm-tools/plugins/common/libhgfsServer.so rm -f %{buildroot}/sbin/mount.vmhgfs rm -f %{buildroot}/usr/bin/vmware-hgfsclient rm -f %{buildroot}/usr/bin/vmware-vmblock-fuse rm -rf %{buildroot}/usr/share/open-vm-tools/messages/ja rm -rf %{buildroot}/usr/share/open-vm-tools/messages/ko rm -rf %{buildroot}/usr/share/open-vm-tools/messages/zh_CN rm -rf %{buildroot}/%{_includedir}/ rm -rf %{buildroot}/%{_libdir}/*.so rm -rf %{buildroot}/%{_libdir}/pkgconfig/ mkdir -p %{buildroot}%{_unitdir} mkdir -p %{buildroot}%{_libexecdir} install -m 644 %{SOURCE1} %{buildroot}%{_unitdir}/ chmod 700 %{buildroot}/usr/bin/vmtoolsd chmod 700 %{buildroot}/usr/bin/vmware-checkvm chmod 700 %{buildroot}/usr/bin/vmware-rpctool chmod 700 %{buildroot}/usr/bin/vmware-toolbox-cmd chmod 700 %{buildroot}/usr/bin/vmware-xferlogs
%post /usr/sbin/ldconfig /usr/bin/systemctl --system daemon-reload 2> /dev/null > /dev/null exit 0
%postun /usr/sbin/ldconfig /usr/bin/systemctl --system daemon-reload 2> /dev/null > /dev/null exit 0
%preun if [ "$1" = 0 ] then /usr/bin/systemctl condstop vmtoolsd.service 2> /dev/null > /dev/null /usr/bin/systemctl disable vmtoolsd.service 2> /dev/null > /dev/null fi exit 0
%files %defattr(-,root,root,-) %{_bindir}/vm* %{_datadir}/%{name} %{_unitdir}/vmtoolsd.service %{_sysconfdir}/vmware-tools %{_libdir}/*.so.* %{_libdir}/%{name}
%changelog * Thu May 2 2013 Reindl Harald h.reindl@thelounge.net - ConditionVirtualization=vmware
* Mon Apr 29 2013 Reindl Harald h.reindl@thelounge.net - update to 9.2.3-1098359 snapshot - remove devel-package
* Fri Apr 26 2013 Reindl Harald h.reindl@thelounge.net - remove CFLAGS-hack which is adressed upstream now - hardening build "fPIC fPIE -fstack-protector-all" - remove fuse-binary from package - remove "messages/ja" from package - remove "messages/ko" from package - remove "messages/zh_CN" from package
* Wed Apr 24 2013 Reindl Harald h.reindl@thelounge.net - update to 9.2.3
* Wed Feb 27 2013 Reindl Harald h.reindl@thelounge.net - build Fedora 18 package - build without 'procps', 'dnet' and 'multimon' to relax dependency chain - build with CFLAGS "Wno-deprecated-declarations" to satisfy glib/gcc of F18 - TimeoutStopSec=1
* Sun Nov 02 2012 Reindl Harald h.reindl@thelounge.net - chmod 700 for command-line tools
* Sat Jun 02 2012 Reindl Harald h.reindl@thelounge.net - open-vm-tools-2012.05.21-724730
* Fri May 18 2012 Reindl Harald h.reindl@thelounge.net - build without kernel-modules
the open-vm-tools should be generally be splitted in packages with and without X11 deps - below my personal SPEC file for a fedora infrastructure on top of vSphere with all things you need for "VMware DataRecovery"-backups and VMware-HighAbility
you do not want any X11-deps and HGFS stuff on production sevrers
We have split open-vm-tools in 3 RPMS:
http://koji.fedoraproject.org/koji/buildinfo?buildID=415709
open-vm-tools-9.2.3-4.fc19.i686.rpm - This is very much like what your spec file will generate open-vm-tools-desktop-9.2.3-4.fc19.i686.rpm - This is all related UI stuff open-vm-tools-devel-9.2.3-4.fc19.i686.rpm - This is for developing stuff with virtualization
Thanks, Ravindra
On 2 May 2013 19:40, Richard W.M. Jones rjones@redhat.com wrote:
I'm Ravindra's sponsor.
Just to clarify a few points:
VMware are trying to work better with Fedora, and to help this along I've been supervising him adding open-vm-tools to Fedora.
Because this is just starting out, there are a few mixed messages, including some advice to remove open-vm-tools (which is now, or soon will be wrong advice). I hope that Ravindra can work with his employers to get that advice changed as necessary.
As Dan said, the open-vm-tools package only starts the service if the hypervisor is VMware.
...and just for the note I'm the reviewer and co-mantainer of it for the RHEL and Fedora <= 18 branches.
I'm trying to integrate the package properly in Fedora as I'm a consumer of VMware and RHEL/Fedora systems.
During the long review; I've filed a bug onto RHEL's procps package [1] that popped out while building on that platform, filed a FESco ticket to see if the service could be enabled on install [2]; and when FESco gave the approval I filed a bug for enabling it in the systemd preset file [3]. The systemd preset request is still unassigned.
Making sure open-vm-tools will be conditionally installed if the system is being run virutalized under VMware is another step that would help Fedora being a first class citizen as a VMware guest.
I would like to point out that on my physical laptop I have spice-vdagentd installed, probably it was installed from the first DVD install. There was an RFE bug opened regarding conditional installation of the agent on Spice guests [4], but it seems it was simply included by default on all installs. So to keep consistency; open-vm-tools should apply the same logic here.
I'm not an Anaconda developer but I guess open-vm-tools and spice agents can follow the same logic that is applied to other packages like the EFI tools; i.e. are installed conditionally. I would prefer not to have them installed on my laptop.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=950748 [2] https://fedorahosted.org/fesco/ticket/1107 [3] https://bugzilla.redhat.com/show_bug.cgi?id=957135 [4] https://bugzilla.redhat.com/show_bug.cgi?id=742522
Regards, --Simone
On Wed, May 01, 2013 at 08:31:38PM -0700, Ravindra Kumar wrote:
- Add open-vm-tools to the core package group
I think it's probably really better in the "@standard" package group, which is one step up from core. People who want a minimal installation but know they'll be in vmware can add it directly.
I think it's probably really better in the "@standard" package group, which is one step up from core. People who want a minimal installation but know they'll be in vmware can add it directly.
Thanks Matthew. I think @standard package should work. Could you please help me with the process? I don't really see anything mentioned about it in this document, https://fedoraproject.org/wiki/How_to_use_and_edit_comps.xml_for_package_gro....
Thanks, Ravindra
I think it's probably really better in the "@standard" package group, which is one step up from core. People who want a minimal installation but know they'll be in vmware can add it directly.
Thanks Matthew. I think @standard package should work. Could you please help me with the process? I don't really see anything mentioned about it in this document, https://fedoraproject.org/wiki/How_to_use_and_edit_comps.xml_for_package_gro....
Thinking more about it. I believe ideal will be to add 'open-vm-tools' to the @core group and add 'open-vm-tools-desktop' to the @standard group.
Thanks, Ravindra
On Tue, May 07, 2013 at 09:23:44 -0700, Ravindra Kumar ravindrakumar@vmware.com wrote:
Thinking more about it. I believe ideal will be to add 'open-vm-tools' to the @core group and add 'open-vm-tools-desktop' to the @standard group.
It might help to elaborate your reasoning. @core is going to be used by people trying to make minimal installs (with exactly what they need on top). It is hard to see why open-vm-tools would be considered necessary to every Fedora install. @standard would seem to make more sense.
It might help to elaborate your reasoning. @core is going to be used by people trying to make minimal installs (with exactly what they need on top). It is hard to see why open-vm-tools would be considered necessary to every Fedora install. @standard would seem to make more sense
I feel so because of P2V use cases. I think it is a very small price of little disk space you pay to avoid making any install changes later on.
In order to make open-vm-tools easy to install in most of the environments, we have done a bunch of things. 1. We have split it in multiple packages. Drivers have been taken out and separately upstreamed in Linux kernel. User space components have been split into two packages open-vm-tools (useful for servers and desktops) and open-vm-tools-desktop (useful for desktops). open-vm-tools-desktop clearly falls in the category of optional package. So, @standard seems appropriate for this. 2. In order to make open-vm-tools suitable for physical and non-VMware environments, we have made it a no-op on all non-VMware environments.
Given above points, the only bad side effect I can think of is the disk space open-vm-tools package takes.
If someone can come up with any other bad side effects, I will be happy to address that.
Thanks, Ravindra
Am 07.05.2013 19:05, schrieb Ravindra Kumar:
It might help to elaborate your reasoning. @core is going to be used by people trying to make minimal installs (with exactly what they need on top). It is hard to see why open-vm-tools would be considered necessary to every Fedora install. @standard would seem to make more sense
I feel so because of P2V use cases. I think it is a very small price of little disk space you pay to avoid making any install changes later on
and why?
pvscsi, vmxnet3 and even vmw_balloon are in the kernel a vmware guest with a recent kernel runs perfectly fine with out the userspace daemon except VDR/HA
in days where a machine configured with vmxnet3 did not have a network connection or pvscsi was not in the kernel this was critical, but these days are gone and you have a working network out-of-the-box for "yum install"
why should anybody need openvm-tools on a non VMware guest?
that said from one that has any production and testing environment on VMware since years and which hates ANY package in core which is not hardly needed on any setup
and why?
open-vm-tools are required for anything that requires co-ordination with the guest. Here are a few examples, clean shutdown of guest from VM management interface, guest consistent snapshots, collection/display of guest resource usage information in VM management interface, guest automation (running commands inside guest) and other features VDR/HA as you mentioned.
why should anybody need openvm-tools on a non VMware guest?
I believe for P2V and V2V use cases.
Thanks, Ravindra
Am 07.05.2013 19:39, schrieb Ravindra Kumar:
and why?
open-vm-tools are required for anything that requires co-ordination with the guest. Here are a few examples, clean shutdown of guest from VM management interface, guest consistent snapshots, collection/display of guest resource usage information in VM management interface, guest automation (running commands inside guest) and other features VDR/HA as you mentioned
that is all true and nice but no valid reson to include it in CORE
the only packages which should allowed to be in CORE are commands and libraries which gives you network access to use yum, nothing else, really *nothing else*
with your argumentation i would have drivers and helpers for whatever virtualization technology on my VMware guests
NO - that should be up to the admin and nobody else VMware is doing a damn good hob get the guest-drivers in the kernel and i am very happy with this because i am a *heavy* VMware user but as i do not like *any* package on my setups which i do not *really* need i see no reason why a KVM user should have any byte of my optional vmware userspace tools on his setup
Once upon a time, Ravindra Kumar ravindrakumar@vmware.com said:
If someone can come up with any other bad side effects, I will be happy to address that.
@core is supposed to be the minimum functional install. It is my understanding that, even under VMWare, open-vm-tools is not required for the system to be functional, so open-vm-tools does not belong in @core.
"It's only a little disk space" is not a valid reason for it to be in @core; that path leads to dozens of "it's only a little disk space" in @core (which would add up to a lot of disk space).
@core is supposed to be the minimum functional install. It is my understanding that, even under VMWare, open-vm-tools is not required for the system to be functional, so open-vm-tools does not belong in @core.
It is not required for system to be functional, but it also leaves a significant gap in the VM to be fully operational unless Tools are installed. I listed out a bunch of functionality that depends on open-vm-tools in my other response.
If there are strong use cases that don't require that functionality then probably it makes sense to not be part of core, otherwise, I think it makes more sense to make open-vm-tools part of @core because sooner or later users will end up installing these due to one or the other use case.
Thanks, Ravindra
On Tue, May 07, 2013 at 10:48:01 -0700, Ravindra Kumar ravindrakumar@vmware.com wrote:
It is not required for system to be functional, but it also leaves a significant gap in the VM to be fully operational unless Tools are installed. I listed out a bunch of functionality that depends on open-vm-tools in my other response.
That suggests that it should be in the @standard group, not the @core group.
If there are strong use cases that don't require that functionality then probably it makes sense to not be part of core, otherwise, I think it makes more sense to make open-vm-tools part of @core because sooner or later users will end up installing these due to one or the other use case.
It is only needed by people using some VMs. So not all people who install @core are going to need it.
Am 07.05.2013 19:48, schrieb Ravindra Kumar:
If there are strong use cases that don't require that functionality then probably it makes sense to not be part of core, otherwise, I think it makes more sense to make open-vm-tools part of @core because sooner or later users will end up installing these due to one or the other use case.
yes the user ends up installing them
hence, *i am* a VMware user and thanl you for bring the package in Fedora which takes a lot of headache from using Rawhide-guests
*but* please undersatdn with your argumentation a lot of maintainers could claim that their packages are in CORE for several reasons because they are expected to be used from most users
please leave core be what core means
and as i clearly statet that i have open-vm-tools on nearly any of my setups please respect that i try to speak for other users which are not using VMware
*but* please undersatdn with your argumentation a lot of maintainers could claim that their packages are in CORE for several reasons because they are expected to be used from most users
please leave core be what core means
and as i clearly statet that i have open-vm-tools on nearly any of my setups please respect that i try to speak for other users which are not using VMware
I got your point. I will follow the approach of creating a new group as suggested by Bill.
Thanks, Ravindra
On Tue, May 07, 2013 at 10:48:01AM -0700, Ravindra Kumar wrote:
If there are strong use cases that don't require that functionality then probably it makes sense to not be part of core, otherwise, I think it makes more sense to make open-vm-tools part of @core because sooner or later users will end up installing these due to one or the other use case.
Keep in mind that @standard is just that -- installed as part of every normal install.
On Tue, May 07, 2013 at 11:39:16AM -0700, Ravindra Kumar wrote:
Keep in mind that @standard is just that -- installed as part of every normal install.
Ok, I think it should work open-vm-tools. Do I make the changes to comps or do I need to raise a bug for 'comps' maintainer?
Yeah, I think filing a bug against the 'comps' component in bugzilla is probably the best approach.
On Tue, May 07, 2013 at 16:48:39 -0400, Matthew Miller mattdm@fedoraproject.org wrote:
On Tue, May 07, 2013 at 11:39:16AM -0700, Ravindra Kumar wrote:
Keep in mind that @standard is just that -- installed as part of every normal install.
Ok, I think it should work open-vm-tools. Do I make the changes to comps or do I need to raise a bug for 'comps' maintainer?
Yeah, I think filing a bug against the 'comps' component in bugzilla is probably the best approach.
In this case, because there is some controversy. In non-controversal cases packagers can just add their stuff to appropriate groups.
Ravindra Kumar (ravindrakumar@vmware.com) said:
@core is supposed to be the minimum functional install. It is my understanding that, even under VMWare, open-vm-tools is not required for the system to be functional, so open-vm-tools does not belong in @core.
It is not required for system to be functional, but it also leaves a significant gap in the VM to be fully operational unless Tools are installed. I listed out a bunch of functionality that depends on open-vm-tools in my other response.
If there are strong use cases that don't require that functionality then probably it makes sense to not be part of core, otherwise, I think it makes more sense to make open-vm-tools part of @core because sooner or later users will end up installing these due to one or the other use case.
Perhaps a virt-agents group that contains open-vm-tools, hypervkvpd, qemu-guest-agent, etc?
Bill
On Tue, 2013-05-07 at 14:45 -0400, Bill Nottingham wrote:
Ravindra Kumar (ravindrakumar@vmware.com) said:
@core is supposed to be the minimum functional install. It is my understanding that, even under VMWare, open-vm-tools is not required for the system to be functional, so open-vm-tools does not belong in @core.
It is not required for system to be functional, but it also leaves a significant gap in the VM to be fully operational unless Tools are installed. I listed out a bunch of functionality that depends on open-vm-tools in my other response.
If there are strong use cases that don't require that functionality then probably it makes sense to not be part of core, otherwise, I think it makes more sense to make open-vm-tools part of @core because sooner or later users will end up installing these due to one or the other use case.
Perhaps a virt-agents group that contains open-vm-tools, hypervkvpd, qemu-guest-agent, etc?
Right, I was just thinking down those lines. Create such a group, and have it installed by default. Makes sure the tools are available in most cases, but not in minimal installs, and allows them to be easily added or removed in any other config.
Only problem is it might need to be at least two groups, for an X/non-X split. Right now, for instance, spice-vdagent is in the base-x group, because all its functions are X-related, so there's no point having it installed if you don't have X in the guest.
Perhaps a virt-agents group that contains open-vm-tools, hypervkvpd, qemu-guest-agent, etc?
Right, I was just thinking down those lines. Create such a group, and have it installed by default. Makes sure the tools are available in most cases, but not in minimal installs, and allows them to be easily added or removed in any other config.
I think I can do this, but this means I will have to include the new group in all the other configs? Will I be allowed to make that change in comps file?
Only problem is it might need to be at least two groups, for an X/non-X split. Right now, for instance, spice-vdagent is in the base-x group, because all its functions are X-related, so there's no point having it installed if you don't have X in the guest.
This is not an issue for open-vm-tools. open-vm-tools X components are already packaged separately as open-vm-tools-desktop. My plan was to include open-vm-tools-desktop in a common desktop config like gnome and kde.
Thanks, Ravindra
On Tue, 2013-05-07 at 14:45 -0700, Ravindra Kumar wrote:
Perhaps a virt-agents group that contains open-vm-tools, hypervkvpd, qemu-guest-agent, etc?
Right, I was just thinking down those lines. Create such a group, and have it installed by default. Makes sure the tools are available in most cases, but not in minimal installs, and allows them to be easily added or removed in any other config.
I think I can do this, but this means I will have to include the new group in all the other configs? Will I be allowed to make that change in comps file?
Only problem is it might need to be at least two groups, for an X/non-X split. Right now, for instance, spice-vdagent is in the base-x group, because all its functions are X-related, so there's no point having it installed if you don't have X in the guest.
This is not an issue for open-vm-tools. open-vm-tools X components are already packaged separately as open-vm-tools-desktop. My plan was to include open-vm-tools-desktop in a common desktop config like gnome and kde.
Well, no, that means it precisely *is* an issue :) that adds open-vm-tools to the list of reasons we might want to have two virt-agents groups, call them virt-agents and virt-agents-x or something. You'd want open-vm-tools to be in one and open-vm-tools-x to be in the other.
What we do with the groups is another question; there are various options. We could just put the 'virt-agents' group in the 'standard' group and the 'virt-agents-x' group in the 'base-x' group, for instance. Or we could add them directly to other groups. Bill's the expert here, though.
Well, no, that means it precisely *is* an issue :) that adds open-vm-tools to the list of reasons we might want to have two virt-agents groups, call them virt-agents and virt-agents-x or something. You'd want open-vm-tools to be in one and open-vm-tools-x to be in the other.
I meant creating two groups is not an issue. In fact, we had this in our mind when we split it into two packages. We intended X related package specifically for desktops.
What we do with the groups is another question; there are various options. We could just put the 'virt-agents' group in the 'standard' group and the 'virt-agents-x' group in the 'base-x' group, for instance. Or we could add them directly to other groups. Bill's the expert here, though.
Sounds good to me. My only concern is, can we add a grouplist to a group?
Thanks, Ravindra
-
Adam Williamson -
Bill Nottingham -
Bruno Wolff III -
Chris Adams -
Colin Walters -
Daniel P. Berrange -
Matthew Miller -
Matthias Runge -
Nicolas Mailhot -
Peter Robinson -
Rahul Sundaram -
Ravindra Kumar -
Reindl Harald -
Richard W.M. Jones -
Simone Caronni