11:36 a.m.
Hello,
I was thinking about how to implement the following APIs in the test driver:
-virDomainFSFreeze
-virDomainFSThaw
-virDomainFSTrim
The first two are conceptually paired. They both get a mountpoints
argument. The QEMU driver (which is the only driver implementing this
currently) ignores this completely.
However, I thought that we can allow it and pretend that the only
available mountpoints are "/" and "/boot" (like in a default Fedora
installation). The following questions arise though:
- Should we keep some kind of temporary or permanent state on the test
driver about this? Because it makes sense for virDomainFSThaw to
succeed only on mountpoints for which previously virDomainFSFreeze has
been called. If so, *where* exactly should we keep this state?
- In case a non-existing mountpoint is passed to either of the first 2
APIs. Should we fail? If so, a new error code should be introduced for
this. Also for the cases above where e.g. Thaw is called on a fs that
isn't frozen probably yet another different error code must be used.
Should we add all these new error codes?
Or maybe all the above is more complicated than necessary and it's
fine if we ignore mountpoints completely like the QEMU driver does and
make all 3 APIs above to always succeed no matter what in the test
driver?
Thanks,
Ilias
5:58 a.m.
On Wed, Jun 26, 2019 at 06:36:28PM +0200, Ilias Stamatis wrote:
Hello,
I was thinking about how to implement the following APIs in the test driver:
-virDomainFSFreeze
-virDomainFSThaw
-virDomainFSTrim
The first two are conceptually paired. They both get a mountpoints
argument. The QEMU driver (which is the only driver implementing this
currently) ignores this completely.
What do you mean by "ignores this completely"? From the code the
mountpoints are passed to QEMU agent and that agent issues appropriate
commands in the VM OS.
However, I thought that we can allow it and pretend that the only
available mountpoints are "/" and "/boot" (like in a default Fedora
installation). The following questions arise though:
Sounds reasonable, in general we should probably accept only mountpoints
that are reported by virDomainGetFSInfo.
- Should we keep some kind of temporary or permanent state on the
test
driver about this? Because it makes sense for virDomainFSThaw to
succeed only on mountpoints for which previously virDomainFSFreeze has
been called. If so, *where* exactly should we keep this state?
I guess it makes sense to store the state of mountpoints, it should not
be that difficult, the proper place would be domain private data.
- In case a non-existing mountpoint is passed to either of the first
2
APIs. Should we fail? If so, a new error code should be introduced for
this. Also for the cases above where e.g. Thaw is called on a fs that
isn't frozen probably yet another different error code must be used.
Should we add all these new error codes?
No need to introduce new error codes, I think that reusing
OPERATION_IS_INVALID or something like that is perfectly fine with
reasonable error message.
Or maybe all the above is more complicated than necessary and
it's
fine if we ignore mountpoints completely like the QEMU driver does and
make all 3 APIs above to always succeed no matter what in the test
driver?
If it would require a lot of code and would be complicated it is
probably not worth it, but doesn't look that way so I would say give
it a try and we'll see :).
Pavel
6:28 a.m.
On Thu, Jul 4, 2019 at 12:58 PM Pavel Hrdina <phrdina(a)redhat.com> wrote:
On Wed, Jun 26, 2019 at 06:36:28PM +0200, Ilias Stamatis wrote:
> Hello,
>
> I was thinking about how to implement the following APIs in the test driver:
> -virDomainFSFreeze
> -virDomainFSThaw
> -virDomainFSTrim
>
> The first two are conceptually paired. They both get a mountpoints
> argument. The QEMU driver (which is the only driver implementing this
> currently) ignores this completely.
What do you mean by "ignores this completely"? From the code the
mountpoints are passed to QEMU agent and that agent issues appropriate
commands in the VM OS.
I meant qemuDomainFSThaw and qemuDomainFSTrime. In the case of
virDomainFSFreeze you are right.
> However, I thought that we can allow it and pretend that the only
> available mountpoints are "/" and "/boot" (like in a default
Fedora
> installation). The following questions arise though:
Sounds reasonable, in general we should probably accept only mountpoints
that are reported by virDomainGetFSInfo.
> - Should we keep some kind of temporary or permanent state on the test
> driver about this? Because it makes sense for virDomainFSThaw to
> succeed only on mountpoints for which previously virDomainFSFreeze has
> been called. If so, *where* exactly should we keep this state?
I guess it makes sense to store the state of mountpoints, it should not
be that difficult, the proper place would be domain private data.
Ok, since we decided last time to introduce and start using domain
private data in general this can be solved easily then.
> - In case a non-existing mountpoint is passed to either of the first 2
> APIs. Should we fail? If so, a new error code should be introduced for
> this. Also for the cases above where e.g. Thaw is called on a fs that
> isn't frozen probably yet another different error code must be used.
> Should we add all these new error codes?
No need to introduce new error codes, I think that reusing
OPERATION_IS_INVALID or something like that is perfectly fine with
reasonable error message.
Ok, I'll use this code then.
> Or maybe all the above is more complicated than necessary and it's
> fine if we ignore mountpoints completely like the QEMU driver does and
> make all 3 APIs above to always succeed no matter what in the test
> driver?
If it would require a lot of code and would be complicated it is
probably not worth it, but doesn't look that way so I would say give
it a try and we'll see :).
Sure. I'll provide an implementation based on the above.
Thanks!
Ilias
Pavel
6:39 a.m.
On Thu, Jul 04, 2019 at 01:28:36PM +0200, Ilias Stamatis wrote:
On Thu, Jul 4, 2019 at 12:58 PM Pavel Hrdina
<phrdina(a)redhat.com> wrote:
>
> On Wed, Jun 26, 2019 at 06:36:28PM +0200, Ilias Stamatis wrote:
> > Hello,
> >
> > I was thinking about how to implement the following APIs in the test driver:
> > -virDomainFSFreeze
> > -virDomainFSThaw
> > -virDomainFSTrim
> >
> > The first two are conceptually paired. They both get a mountpoints
> > argument. The QEMU driver (which is the only driver implementing this
> > currently) ignores this completely.
>
> What do you mean by "ignores this completely"? From the code the
> mountpoints are passed to QEMU agent and that agent issues appropriate
> commands in the VM OS.
I meant qemuDomainFSThaw and qemuDomainFSTrime. In the case of
virDomainFSFreeze you are right.
Right, I check only FSFreeze, we don't have to copy QEMU driver
behavior so if the test driver can easily support it I would go for it.
Pavel
1998
days inactive
2006
days old
3 comments
2 participants
participants (2)
-
Ilias Stamatis -
Pavel Hrdina