On 03/22/2013 09:37 PM, Chris Evich wrote:
On 03/22/2013 04:22 AM, Alex Jia wrote:
On 03/21/2013 10:05 PM, Chris Evich wrote:
On 03/21/2013 04:29 AM, Alex Jia wrote:
On 03/20/2013 11:33 PM, Chris Evich wrote:
On 03/20/2013 06:11 AM, Yu Mingfei wrote:
virsh_instance = virsh.VirshPersistent(**virsh_dargs)
IIRC, you can recycle this by calling virsh_instance.new_session()
here, but it's only very small nit-pick, what you have is fine. The
test looks good overall.
ToDo: IIRC, there's a way to reboot the host and have autotest resume
testing when it comes up. I'm almost 100% sure this doesn't work with
current virt-test code, but it would be nice to get it
As usual, we restart libvirtd service to emulate host reboot for this
kinds of testing, in addition, you had better to check whether
$network.xml exists under the
/etc/libvirt/$hypervisor/networks/autostart/.
Yes, it's the "...also check XYZ" appendixes why I'm not 100%
comfortable "simulating" reboots. Not only can we get false-PASS, but
we can also get false-FAIL very easy. Remember, this must work across
multiple distro's, the overall variability is probably larger that we
realize.
IMHO, we need to be testing this with a host reboot also since this is
what autostart is designed for. Otherwise, if we run into an issue
with simulated reboot + autostart, engineering will be mad if it is
not reproducible problem on real host reboot.
Yes, agree, testers should verify if the virtual network can be
automatically started when the host machine boots, and the autotest
supports the feature, we can continue to do the rest of testing after
rebooting host.
For some internal test suite, it's not more powerful than autotest, so
it's a optional solution to simulate host reboots for us, but from
technical point of view, you may destroy the defined virtual
network(with autostart enabled) then restart libvirtd service to check
it, for this, we need to know what the happen is after running virsh
net-autostart <domain> and rebooting host.
The following is common structure in libvirt source codes, as usual,
when libvirt daemon starts it will register kinds of drivers such as
virRegisterNetworkDriver then daemonSetupNetworking() and initialization
function for the qemu daemon, so the networkStartup() will be called and
the networkShutdown() will be called after stopping libvirtd service, I
will list some important function call in here to explain why it should
be feasible for destroying virtual network then restart libvirtd service
to simulate reboot+autostart.
static virStateDriver networkStateDriver = {
.name = "Network",
.initialize = networkStartup,
.cleanup = networkShutdown,
.reload = networkReload,
};
networkDestroy->networkShutdownNetwork
service libvirtd restart will call the
networkStartup()->networkAutostartConfigs->networkStartNetwork
When we reboot host, the libvirtd service will be stopped firstly and
relevant '.cleanup' registered function will be called, for above codes,
the networkShutdown() will destroy virtual network and free allocated
resource, the networkShutdownNetwork() is a similar function with the
networkShutdown(), so we use the networkDestroy() to simulate this
process. For host boots, it's the same process, the libvirtd service
will be started then call the networkStartup(), which will load all of
configuration such as virNetworkLoadAllConfigs(..,..,
driverState->networkAutostartDir), in here, the networkAutostartDir is
/etc/libvirt//qemu/networks/autostart, which is created by the
networkSetAutostart(), which will call
virFileMakePath(driver->networkAutostartDir) and symlink(configFile,
autostartLink) firstly, so I suggest testers should check $network.xml
under the directory, for save directory, it often is put some persistent
configurations.
Cool! Thanks for the code analysis. Do you know if we have access to
pull directory/file paths directly from libvirt's python bindings?
I'd love to do this, in preference to hard-coding paths like
"/etc/libvirt//qemu/networks/autostart" in our tests/code.
AFAIK, There isn't a libvirt's python API can do this now(see libvirt.py
from libvirt-python component),
but you may get some details from libvirt source codes, for example,
In ./gnulib/lib/configmake.h:
#define SYSCONFDIR "/etc"
In src/network/bridge_driver.c:
static int
networkStartup(bool privileged,
virStateInhibitCallback callback ATTRIBUTE_UNUSED,
void *opaque ATTRIBUTE_UNUSED)
{
char *base = NULL;
// ignore some codes
if (privileged) {
// ignore some codes
if ((base = strdup(SYSCONFDIR "/libvirt")) == NULL)
goto out_of_memory;
} else {
// ignore some codes
userdir = virGetUserConfigDirectory();
if (virAsprintf(&base, "%s", userdir) == -1) {
}
// ignore some codes
if (virAsprintf(&driverState->networkConfigDir, "%s/qemu/networks",
base) == -1)
goto out_of_memory;
if (virAsprintf(&driverState->networkAutostartDir,
"%s/qemu/networks/autostart",
base) == -1)
goto out_of_memory;
// ignore some codes
}
In src/util/virutil.c:
char *virGetUserConfigDirectory(void)
{
return virGetXDGDirectory("XDG_CONFIG_HOME", ".config");
}
static char *virGetXDGDirectory(const char *xdgenvname, const char
*xdgdefdir)
{
const char *path = getenv(xdgenvname);
char *ret = NULL;
char *home = virGetUserEnt(geteuid(), VIR_USER_ENT_DIRECTORY);
if (path && path[0]) {
if (virAsprintf(&ret, "%s/libvirt", path) < 0)
goto no_memory;
} else {
if (virAsprintf(&ret, "%s/%s/libvirt", home, xdgdefdir) < 0)
goto no_memory;
}
// ignore some codes
}
So I think we may also construct similar function to generate
"/etc/libvirt//qemu/networks/autostart" avoiding hard code.
_______________________________________________
Virt-test-devel mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/virt-test-devel
