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
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
*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
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
On Wed, May 01, 2013 at 08:31:38PM -0700, Ravindra Kumar wrote:
1. 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
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
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
On Tue, May 07, 2013 at 09:23:44 -0700,
Ravindra Kumar ravindraku...@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
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
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.
Once upon a time, Ravindra Kumar ravindraku...@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
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
@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
On Tue, May 07, 2013 at 10:48:01 -0700,
Ravindra Kumar ravindraku...@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
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
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?
Thanks,
Ravindra
--
devel mailing list
devel@lists.fedoraproject.org
Ravindra Kumar (ravindraku...@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
On Tue, 2013-05-07 at 14:45 -0400, Bill Nottingham wrote:
Ravindra Kumar (ravindraku...@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
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
On Tue, May 07, 2013 at 16:48:39 -0400,
Matthew Miller mat...@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
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
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
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
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
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,
On Thu, May 2, 2013 at 6:51 PM, Bill Nottingham nott...@redhat.com wrote:
Ravindra Kumar (ravindraku...@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
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
On 3 May 2013 01:46, Adam Williamson awill...@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
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
On Fri, 2013-05-03 at 11:59 +0100, Peter Robinson wrote:
On Thu, May 2, 2013 at 6:51 PM, Bill Nottingham nott...@redhat.com wrote:
Ravindra Kumar (ravindraku...@vmware.com) said:
(Batching a bunch of replies)
Install and uninstall looks a bit weird to me; what could be
done is to make
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
Hello,
On 2 May 2013 05:31, Ravindra Kumar ravindraku...@vmware.com wrote:
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
Install and uninstall looks a bit weird to me; what could be
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:
1. Add open-vm-tools to the core package group
2. Modify Anaconda to uninstall open-vm-tools after
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:
1. Add open-vm-tools to the core package group
2. Modify Anaconda to uninstall
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:
1. Add open-vm-tools to the
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_UScmd=displayKCexternalId=1013096
Yeah. This is
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:
1. Add open-vm-tools to the core package group
2. Modify Anaconda to uninstall
(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
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.
Ravindra Kumar (ravindraku...@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
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:
1. Add open-vm-tools to the
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
On 2 May 2013 19:40, Richard W.M. Jones rjo...@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,
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
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?
On Thu, May 02, 2013 at 01:51:30PM -0400, Bill Nottingham wrote:
Ravindra Kumar (ravindraku...@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
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
On 2 May 2013 21:44, Nicolas Mailhot nicolas.mail...@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
On 2 May 2013 22:24, Richard W.M. Jones rjo...@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
On 2 May 2013 22:29, Reindl Harald h.rei...@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
Am 02.05.2013 22:45, schrieb Simone Caronni:
On 2 May 2013 22:29, Reindl Harald h.rei...@thelounge.net
mailto:h.rei...@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
On Thu, 2013-05-02 at 22:44 +0200, Simone Caronni wrote:
On 2 May 2013 22:24, Richard W.M. Jones rjo...@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
52 matches
Mail list logo
