[libvirt] How to avoid the disk still persistent after no persistent hotplug and with restarting libvirtd then.
9:17 a.m.
Libvirt loads the domain conf from the status file
(/var/run/libvirt/qemu/$dom.xml)
if the domain is running, the problem if one restart libvirtd just after
some changing on the domain conf, and then destroy/start the guest.
libvirt will never known what the original domain conf is then.
(vm->newdef is NULL at this moment, generally libvirt restore the domain
conf
to the original conf (vm->newDef) when destroying and shutdown).
Following is a demo of the problem:
1) hotplug a disk to a running domain without "--persistent" specified.
2) restart libvirtd
3) Destroy/start the guest
4) you will see the hotpluged disk is still there.
The solution in my mind is to add some attribute to the status XML, such
as "live_updated=1", and do the checking when loading the domain conf
from status XML:
* if "live_updated=1", then loads the domain conf from the persistent
domain XML.
But the problem is:
For a persistent domain, if one made changes on the domain conf both
persistently and transiently, we have no way to known which part are
changed. Loading from the persistent domain conf is not correct either.
For a transient domain, we still have no way to get the original domain
conf,
that means one will still be surprised when seeing the the disk is still
there.
Any idea on this?
Thanks
Osier
12:16 p.m.
On 08/19/2011 08:17 AM, Osier Yang wrote:
Libvirt loads the domain conf from the status file
(/var/run/libvirt/qemu/$dom.xml)
if the domain is running, the problem if one restart libvirtd just after
some changing on the domain conf, and then destroy/start the guest.
libvirt will never known what the original domain conf is then.
(vm->newdef is NULL at this moment, generally libvirt restore the domain
conf
to the original conf (vm->newDef) when destroying and shutdown).
Sounds to me like this is a bug in libvirtd reloading. For a running
persistent guest, libvirt should be looking in two files: both the
running state (/var/run/libvirt/qemu/$dom.xml) and the next-boot state
(/etc/lib/libvirt/qemu/$dom.xml); and if they differ, then assign
vm->newDef to the persistent definition. In other words, the bug is
that vm->newdef was NULL after libvirtd restart.
The solution in my mind is to add some attribute to the status XML,
such
as "live_updated=1", and do the checking when loading the domain conf
from status XML:
Shouldn't need any XML changes; rather, libvirtd just needs to be taught
to properly reconstruct its state from multiple files, instead of
assuming that the first file that worked was all the state it needed.
For a transient domain, we still have no way to get the original
domain
conf,
that means one will still be surprised when seeing the the disk is still
there.
For a transient domain, it is already forbidden to request a persistent
change. So you can't get into this situation in the first place unless
you have a persistent domain.
--
Eric Blake eblake(a)redhat.com +1-801-349-2682
Libvirt virtualization library http://libvirt.org
4:12 a.m.
于 2011年08月20日 01:16, Eric Blake 写道:
On 08/19/2011 08:17 AM, Osier Yang wrote:
> Libvirt loads the domain conf from the status file
> (/var/run/libvirt/qemu/$dom.xml)
> if the domain is running, the problem if one restart libvirtd just after
> some changing on the domain conf, and then destroy/start the guest.
> libvirt will never known what the original domain conf is then.
> (vm->newdef is NULL at this moment, generally libvirt restore the domain
> conf
> to the original conf (vm->newDef) when destroying and shutdown).
Sounds to me like this is a bug in libvirtd reloading. For a running
persistent guest, libvirt should be looking in two files: both the
running state (/var/run/libvirt/qemu/$dom.xml) and the next-boot state
(/etc/lib/libvirt/qemu/$dom.xml); and if they differ, then assign
vm->newDef to the persistent definition.
Is this too expensive? Need to compare most of the properties of the
domain conf (except the auto-generated info, and some other fixed info
such as domain name, UUID, etc. All other info which could be changed
lively should be compared).
Instead remeber if there was live changes in XML cost low, though need
to modify much of the functions I guess.
In other words, the bug is that vm->newdef was NULL after libvirtd
restart.
Yes.
> The solution in my mind is to add some attribute to the status XML, such
> as "live_updated=1", and do the checking when loading the domain conf
> from status XML:
Shouldn't need any XML changes; rather, libvirtd just needs to be
taught to properly reconstruct its state from multiple files, instead
of assuming that the first file that worked was all the state it needed.
> For a transient domain, we still have no way to get the original domain
> conf,
> that means one will still be surprised when seeing the the disk is still
> there.
For a transient domain, it is already forbidden to request a
persistent change. So you can't get into this situation in the first
place unless you have a persistent domain.
8:13 a.m.
On 08/22/2011 03:12 AM, Osier Yang wrote:
于 2011年08月20日 01:16, Eric Blake 写道:
> On 08/19/2011 08:17 AM, Osier Yang wrote:
>> Libvirt loads the domain conf from the status file
>> (/var/run/libvirt/qemu/$dom.xml)
>> if the domain is running, the problem if one restart libvirtd just after
>> some changing on the domain conf, and then destroy/start the guest.
>> libvirt will never known what the original domain conf is then.
>> (vm->newdef is NULL at this moment, generally libvirt restore the domain
>> conf
>> to the original conf (vm->newDef) when destroying and shutdown).
>
> Sounds to me like this is a bug in libvirtd reloading. For a running
> persistent guest, libvirt should be looking in two files: both the
> running state (/var/run/libvirt/qemu/$dom.xml) and the next-boot state
> (/etc/lib/libvirt/qemu/$dom.xml); and if they differ, then assign
> vm->newDef to the persistent definition.
Is this too expensive? Need to compare most of the properties of the
domain conf (except the auto-generated info, and some other fixed info
such as domain name, UUID, etc. All other info which could be changed
lively should be compared).
We don't necessarily have to do a comparison. Just blindly parsing in
both files is a good enough approach, even in the case where the two
files end up not describing any difference in inactive configuration.
My main point was that since we track state in two files, we should be
restoring two files when libvirtd restarts, but right now we are only
restoring one.
--
Eric Blake eblake(a)redhat.com +1-801-349-2682
Libvirt virtualization library http://libvirt.org
4841
days inactive
4844
days old
3 comments
2 participants
participants (2)
-
Eric Blake -
Osier Yang