On Thu, Jun 11, 2015 at 09:38:24 +0800, zhang bo wrote:
On 2015/6/10 17:31, Daniel P. Berrange wrote:
> On Wed, Jun 10, 2015 at 10:28:08AM +0100, Daniel P. Berrange wrote:
>> On Wed, Jun 10, 2015 at 05:24:50PM +0800, zhang bo wrote:
>>> On 2015/6/10 16:39, Vasiliy Tolstov wrote:
>>>
>>>> 2015-06-10 11:37 GMT+03:00 Daniel P. Berrange
<berrange(a)redhat.com>:
>>>>> The udev rules are really something the OS vendor should setup, so
>>>>> that it "just works"
>>>>
>>>>
>>>> I think so, also for vcpu hotplug this also covered by udev. May be we
>>>> need something to hot remove memory and cpu, because in guest we need
>>>> offline firstly.
>>>>
>>>
>>>
>>> In fact ,we also have --guest option for 'virsh sevvcpus' command,
which also
>>> uses qga commands to do the logical hotplug/unplug jobs, although udev rules
seems
>>> to cover the vcpu logical hotplug issue.
>>>
>>> virsh # help setvcpus
>>> .........................
>>> --guest modify cpu state in the guest
>>>
>>>
>>> BTW: we didn't see OSes with udev rules for memory-hotplug-event setted
by vendors,
>>> and adding such rules means that we have to *interfere within the guest*, It
seems
>>> not a good option.
>>
>> I was suggesting that an RFE be filed with any vendor who doesn't do it
>> to add this capability, not that we add udev rules ourselves.
>
> Or actually, it probably is sufficient to just send a patch to the upstream
> systemd project to add the desired rule to udev. That way all Linux distros
> will inherit the feature when they update to new udev.
>
Then, here comes the question: how to deal with the guests that are already in use?
I think it's better to operate them at the host side without getting into the guest.
That's the advantage of qemu-guest-agent, why not take advantage of it?
Such guests would need an update qemu-guest-agent anyway. And installing
a new version of qemu-guest-agent is not any easier than installing an
updated udev or a new udev rule. That is, I don't think the
qemu-guest-agent way has any benefits over a udev rule. It's rather the
opposite.
Jirka