Hello list ,
1. I find that some errors would be raised when to start vms concurrently
,
and find there is a coarse-grain lock in start code of xend written in
python,
but in XendBootloader.py there is a little time to release and then
re-aquire
the lock .
I want to know whether which is why errors occur when starting
concurrently .
and how to solve these problems ? just to modify the coarse-grain lock of
xen source code in the part to fine-grain lock ?
if so there will be a long time and hard work.
2. when I start a vm using vhd , it should mount the vhd file to
/dev/xvdp in
dom0 and then this virtual device is encapsulated to a vbd object ,finally
which
is installed in xenstore by backend process before pygrub is working .
This set-up procedure would cost some time , so if the device have not
prepared when pygrub continues to work , some errors take place .
I want to know whether i could add a event to notify the frontend that the
device is completely prepared ?
and where is the backend code related ?
1. I find that some errors would be raised when to start vms concurrently
,
and find there is a coarse-grain lock in start code of xend written in
python,
but in XendBootloader.py there is a little time to release and then
re-aquire
the lock .
I want to know whether which is why errors occur when starting
concurrently .
and how to solve these problems ? just to modify the coarse-grain lock of
xen source code in the part to fine-grain lock ?
if so there will be a long time and hard work.
2. when I start a vm using vhd , it should mount the vhd file to
/dev/xvdp in
dom0 and then this virtual device is encapsulated to a vbd object ,finally
which
is installed in xenstore by backend process before pygrub is working .
This set-up procedure would cost some time , so if the device have not
prepared when pygrub continues to work , some errors take place .
I want to know whether i could add a event to notify the frontend that the
device is completely prepared ?
and where is the backend code related ?